Cyan Blog
2025-03-03
0
0
目录

JVM调优

# JVM 调优的参数可以在哪里设置参数值

# tomcat的设置vm参数

修改TOMCAT_HOME/bin/catalina.sh文件，如下图

JAVA_OPTS="-Xms512m -Xmx1024m"

img

# springboot项目jar文件启动

通常在linux系统下直接加参数启动springboot项目

nohup java -Xms512m -Xmx1024m -jar xxxx.jar --spring.profiles.active=prod &

nohup : 用于在系统后台不挂断地运行命令，退出终端不会影响程序的运行

参数 & ：让命令在后台执行，终端退出后命令仍旧执行。

# 用的 JVM 调优的参数都有哪些

对于JVM调优，主要就是调整年轻代、老年代、元空间的内存空间大小及使用的垃圾回收器类型。

https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html

# 设置堆空间大小

设置堆的初始大小和最大大小

-Xms：设置堆的初始化大小

-Xmx：设置堆的最大大小

堆空间最大大小的默认值是物理内存的1/4，初始大小是物理内存的1/64

为了防止垃圾收集器在初始大小、最大大小之间收缩堆而产生额外的时间，通常把最大、初始大小设置为相同的值。

堆太小，可能会频繁的导致年轻代和老年代的垃圾回收，会产生stw,暂停用户线程 堆内存大肯定是好的，存在风险，假如发生了fullgc，它会扫描整个堆空间，暂停用户线程的时间长

设置参考推荐：尽量大，也要考察一下当前计算机其他程序的内存使用情况

# 虚拟机栈的设置

每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，但一般256K就够用。通常减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。

-Xss 对每个线程stack大小的调整，-Xss128k

# 年轻代中Eden区和两个Survivor区的大小比例

该值如果不设置，则默认比例为8:1:1。Java官方通过增大Eden区的大小（survivor永远只占2份），来减少YGC发生的次数，但有时我们发现，虽然次数减少了，但Eden区满的时候，由于占用的空间较大，导致释放缓慢，此时STW的时间较长，因此需要按照程序情况去调优。

-XXSurvivorRatio=3，表示年轻代中的分配比率：survivor:eden = 2:3

# 年轻代和老年代的比例

年轻代和老年代默认比例为1：2。可以通过调整二者空间大小比率来设置两者的大小。

-XX:newSize 设置年轻代的初始大小

-XX:MaxNewSize 设置年轻代的最大大小

初始大小和最大大小两个值通常相同

# 年轻代晋升老年代阈值

8）一般情况下，年轻对象放在eden区，当第一次GC后，如果对象还存活，放到survivor区，此后，每GC一次，年龄增加1，当对象的年龄达到阈值，就被放到tenured老年区。

-XX:MaxTenuringThreshold = 15 表示存活15次后晋升老年代

如果想让对象留在年轻代，可以设置比较大的阈值。默认为15。取值范围0-15

5）一般来说，当survivor区不够大或者占用量达到50%，就会把一些对象放到老年区。通过设置合理的eden区，survivor区及使用率，可以将年轻对象保存在年轻代，从而避免full GC，使用-Xmn设置年轻代的大小

7）对于占用内存比较多的大对象，一般会选择在老年代分配内存。如果在年轻代给大对象分配内存，年轻代内存不够了，就要在eden区移动大量对象到老年代，然后这些移动的对象可能很快消亡，因此导致full GC。通过设置参数：-XX:PetenureSizeThreshold=1000000，单位为B，标明对象大小超过1M时，在老年代(tenured)分配内存空间。

# 设置垃圾回收收集器

-XX:+UseParallelGC:年轻代使用并行垃圾回收收集器。这是一个关注吞吐量的收集器，可以尽可能的减少垃圾回收时间。

-XX:+UseParallelOldGC:设置老年代使用并行垃圾回收收集器。

-XX:+UseG1GC:设置年轻代和老年代都使用G1垃圾回收收集器。

-XX:+UseConcMarkSweepGC:老年代使用CMS收集器降低停顿。

6）系统CPU持续飙高的话，首先先排查代码问题，如果代码没问题，则咨询运维或者云服务器供应商，通常服务器重启或者服务器迁移即可解决。

9）尝试使用大的内存分页：使用大的内存分页增加CPU的内存寻址能力，从而系统的性能。

-XX:+LargePageSizeInBytes 设置内存页的大小

# 说一下 JVM 调优的工具？

# 命令工具

# jps（Java Process Status）

输出JVM中运行的进程状态信息(现在一般使用jconsole)

img

# jstack

查看java进程内线程的堆栈信息。

jstack [option] <pid>

# jmap

用于生成堆转存快照

jmap [options] pid 内存映像信息

jmap -heap pid 显示Java堆的信息

jmap -dump:format=b,file=heap.hprof pid

​ format=b表示以hprof二进制格式转储Java堆的内存

​ file=用于指定快照dump文件的文件名。

例：显示了某一个java运行的堆信息

C:\Users\yuhon>jmap -heap 53280
Attaching to process ID 53280, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.321-b07

using thread-local object allocation.
Parallel GC with 8 thread(s)   //并行的垃圾回收器

Heap Configuration:  //堆配置
   MinHeapFreeRatio         = 0   //空闲堆空间的最小百分比
   MaxHeapFreeRatio         = 100  //空闲堆空间的最大百分比
   MaxHeapSize              = 8524922880 (8130.0MB) //堆空间允许的最大值
   NewSize                  = 178257920 (170.0MB) //新生代堆空间的默认值
   MaxNewSize               = 2841640960 (2710.0MB) //新生代堆空间允许的最大值
   OldSize                  = 356515840 (340.0MB) //老年代堆空间的默认值
   NewRatio                 = 2 //新生代与老年代的堆空间比值，表示新生代：老年代=1：2
   SurvivorRatio            = 8 //两个Survivor区和Eden区的堆空间比值为8,表示S0:S1:Eden=1:1:8
   MetaspaceSize            = 21807104 (20.796875MB) //元空间的默认值
   CompressedClassSpaceSize = 1073741824 (1024.0MB) //压缩类使用空间大小
   MaxMetaspaceSize         = 17592186044415 MB //元空间允许的最大值
   G1HeapRegionSize         = 0 (0.0MB)//在使用 G1 垃圾回收算法时，JVM 会将 Heap 空间分隔为若干个 Region，该参数用来指定每个 Region 空间的大小。

Heap Usage:
PS Young Generation
Eden Space: //Eden使用情况
   capacity = 134217728 (128.0MB)
   used     = 10737496 (10.240074157714844MB)
   free     = 123480232 (117.75992584228516MB)
   8.000057935714722% used
From Space: //Survivor-From 使用情况
   capacity = 22020096 (21.0MB)
   used     = 0 (0.0MB)
   free     = 22020096 (21.0MB)
   0.0% used
To Space: //Survivor-To 使用情况
   capacity = 22020096 (21.0MB)
   used     = 0 (0.0MB)
   free     = 22020096 (21.0MB)
   0.0% used
PS Old Generation  //老年代 使用情况
   capacity = 356515840 (340.0MB)
   used     = 0 (0.0MB)
   free     = 356515840 (340.0MB)
   0.0% used

3185 interned Strings occupying 261264 bytes.

# jhat

用于分析jmap生成的堆转存快照（一般不推荐使用，而是使用Ecplise Memory Analyzer）

# jstat

是JVM统计监测工具。可以用来显示垃圾回收信息、类加载信息、新生代统计信息等。

常见参数：

①总结垃圾回收统计

jstat -gcutil pid

img

字段 含义
S0 幸存1区当前使用比例
S1 幸存2区当前使用比例
E 伊甸园区使用比例
O 老年代使用比例
M 元数据区使用比例
CCS 压缩使用比例
YGC 年轻代垃圾回收次数
YGCT 年轻代垃圾回收消耗时间
FGC 老年代垃圾回收次数
FGCT 老年代垃圾回收消耗时间
GCT 垃圾回收消耗总时间

②垃圾回收统计

jstat -gc pid

img

-C 容量 -U 已使用

# 可视化工具

# jconsole

用于对jvm的内存，线程，类 的监控，是一个基于 jmx 的 GUI 性能监控工具

打开方式：java 安装目录 bin目录下 直接启动 jconsole.exe 就行

img

可以查看内存、线程、类等信息

img

# VisualVM：故障处理工具

能够监控线程，内存情况，查看方法的CPU时间和内存中的对 象，已被GC的对象，反向查看分配的堆栈

打开方式：java 安装目录(jdk8以上需要下载) bin目录下 直接启动 jvisualvm.exe就行

监控程序运行情况

img

查看运行中的dump

img

查看堆中的信息

img

# java内存泄露的排查思路

# 原因

如果线程请求分配的栈容量超过java虚拟机栈允许的最大容量的时候，java虚拟机将抛出一个StackOverFlowError异常

如果java虚拟机栈可以动态拓展，并且扩展的动作已经尝试过，但是目前无法申请到足够的内存去完成拓展，或者在建立新线程的时候没有足够的内存去创建对应的虚拟机栈，那java虚拟机将会抛出一个OutOfMemoryError异常

如果一次加载的类太多，元空间内存不足，则会报OutOfMemoryError: Metaspace

img

# 解决

1、通过jmap指定打印他的内存快照 dump(Dump文件是进程的内存镜像。可以把程序的执行状态通过调试器保存到dump文件中)

  • 使用jmap命令获取运行中程序的dump文件

jmap -dump:format=b,file=heap.hprof pid

  • 使用vm参数获取dump文件

有的情况是内存溢出之后程序则会直接中断，而jmap只能打印在运行中的程序，所以建议通过参数的方式的生成dump文件，配置如下：

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/home/app/dumps/ 指定生成后文件的保存目录

2、通过工具， VisualVM（Ecplise MAT）去分析 dump文件

VisualVM可以加载离线的dump文件

文件-->装入--->选择dump文件即可查看堆快照信息

如果是linux系统中的程序，则需要把dump文件下载到本地（windows环境）下，打开VisualVM工具分析。VisualVM目前只支持在windows环境下运行可视化

3、通过查看堆信息的情况，可以大概定位内存溢出是哪行代码出了问题

4、找到对应的代码，通过阅读上下文的情况，进行修复即可

# 总结

内存泄漏通常是指堆内存，通常是指一些大对象不被回收的情况 1、通过jmap或设置jvm参数获取堆内存快照dump 2、通过工具VisualVM去分析dump文件，VisualVMi可以加载离线的dump文件 3、通过查看堆信息的情况，可以大慨定位内存溢出是哪行代码出了问题 4、找到对应的代码，通过阅读上下文的情况，进行修复即可

# CPU飙高排查方案与思路？

1.使用top命令查看占用cpu的情况，查看是哪一个进程占用cpu较高，

2.查看当前线程中的进程信息

ps H -eo pid,tid,%CPU | grep 40940

ps：用于查看系统进程状态的命令。

H：显示进程的线程（即 threads 模式）。

-eo pid,tid,%CPU：自定义输出列：

  • pid：进程 ID（Process ID）。
  • tid：线程 ID（Thread ID）。
  • %CPU：CPU 使用率百分比。

3.通过上述执行结果分析CPU较高的线程

其中线程id是一个十进制，我们需要把这个线程id转换为16进制才行，因为通常在日志中展示的都是16进制的线程id名称

转换方式：

在linux中执行命令

printf "%x\n" 30979

4.可以根据线程 id 找到有问题的线程，进一步定位到问题代码的源码行号

执行命令

jstack 30978   此处是进程id

# 频繁FullGC问题如何排查

  1. 收集GC日志

    首先，我们需要开启详细的GC日志。在VM参数中添加：

    -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log

  2. 分析GC日志

    使用工具（如GCViewer）分析GC日志，我们发现：

    • Full GC频率：每10分钟一次
    • 每次Full GC耗时：平均3秒
    • Old Gen使用情况：每次GC后仍然保持在80%以上

    GC日志片段示例：

    2023-05-15T14:30:45.123+0800:[Full GC (Ergonomics)[PSYoungGen:20M->0M(60M)[ParoldG...

  3. 监控JVM内存使用情况

    使用工具如VisualVM或JConsole实时监控JVM内存使用。我们观察到： Eden区：频繁被填满后触发Minor GC Survivor区：经常接近满载 Old Gen:持续增长，即使在Full GC后也难以下降

  4. 分析堆内存 使用jmap生成堆转储文件：(生成时间长会导致系统停顿，线上环境谨慎使用) jmap -dump:format=b,file=heap_dump.hprof <pid>

    使用MAT(Memory Analyzer Tool)分析堆转储，发现：

    • 大量的com.example.Order 对象占用了Old Gen的大部分空间
    • 这些 Order对象中包含了大量历史订单数据

  5. 检查代码中的内存使用 审查相关代码，发现问题：

  6. 调整JVM参数 临时调整VM参数以缓解问题：

    -Xms4g -Xmx4g -XX:NewRatio=2 -XX:SurvivorRatio=8

  7. 优化代码

# 对象在堆中的==内存布局==⭐

# JDK9将String底层实现char[]改为byte[]

并没有将String底层实现char[]改为byte[]，而是引入了compact string的优化，减少string的内存消耗

java字符串在内部是由char[]来表示，jdk内部使用UTF-16意味着每个char由两个字节组成，如果一个字符串只包含一个英文字符/ASCII字符，只需要一个字节就可以表示，意味着字符串实际存储空间比需要存储的空间多一倍，

因此，jdk9引入compact string的优化，将char[]改为byte[]，只有存储非ASCII字符才会使用char[]，纯ASCII字符会存储在byte[]，从而节省一半空间

这个优化是在编译器和运行时环境实现的。透明的，使用jvm参数-xx: UseCompressedStrings

#面试#Java
上次更新: 2025/5/3 23:15:15
垃圾回收
课后测试

← 课后测试→

最近更新
01
项目优化
05-06
02
项目优化
05-06
03
延迟消息
05-05
更多文章>
Theme by Vdoing | Copyright © 2025-2025 Cyan Blog