一、调优目的
- 避免OOM
- 减少Full GC
二、判断标准
- 每次YGC耗时在100ms以内
- 每次FGC耗时在1s以内
- FGC频率最多几小时一次
三、调优依据
3.1 运行日志
3.2 GC情況（jstat）
- jps -l 查看运行的java程序进程
- jstat（JVM statistics Monitor）命令查看各种状态，包含GC状态
jstat -gc 25772 2000 20：代表每隔2000ms输出一次进程25772的内存情况，总共输出20次
C:\Users\Administrator>jstat -gc 25772 2000 20
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
55808.0 9216.0 0.0 8896.0 1260544.0 146741.4 344064.0 266516.3 134912.0 127714.6 15872.0 14629.5 25 0.570 4 0.393 0.964
S0C：年轻代中第一个survivor（幸存区）的容量 (KB)
S1C：年轻代中第二个survivor（幸存区）的容量 (KB)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (KB)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (KB)
EC：年轻代中Eden（伊甸园）的容量 (KB)
EU：年轻代中Eden（伊甸园）目前已使用空间 (KB)
OC：Old代的容量 (KB)
OU：Old代目前已使用空间 (KB)
MC：元空间的容量 (KB)
MU：元空间目前已使用空间 (KB)
CCSC：压缩类空间的容量 (KB)
CCSU：压缩类空间已使用空间 (KB)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(秒)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(秒)
GCT：从应用程序启动到采样时gc用的总时间(秒)
- java程序启动时可以配置gc日志的相关参数，将其打印出来，或保存到本地
3.3 线程快照（jstack可以用来排查CPU飙升、死锁、死循环等）
jstack命令（可使用该命令导出到本地文件）
C:\Users\Administrator>jstack 25772
2024-03-07 11:38:09
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.341-b10 mixed mode):
...
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x0000017bfeca3e80 (object 0x000000008a0e36e8, a java.lang.Object),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x0000017bfeca5e80 (object 0x000000008a0e36f8, a java.lang.Object),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at TestDeadLock$Thread2.run(TestDeadLock.java:40)
- waiting to lock <0x000000008a0e36e8> (a java.lang.Object)
- locked <0x000000008a0e36f8> (a java.lang.Object)
at java.lang.Thread.run(java.base@9.0.4/Thread.java:844)
"Thread-0":
at TestDeadLock$Thread1.run(TestDeadLock.java:22)
- waiting to lock <0x000000008a0e36f8> (a java.lang.Object)
- locked <0x000000008a0e36e8> (a java.lang.Object)
at java.lang.Thread.run(java.base@9.0.4/Thread.java:844)
Found 1 deadlock.
...
...
3.4 堆快照（jmap）
jmap命令查看当前堆情况，或者保存到本地文件
jmap -histo pid 输出堆的直方图，包含类名、对象数量、占用大小
jmap -histo:live pid 同上，只输出存活对象
jmap -dump:format=b,file=xxx.hprof pid 导出dump文件
jmap -heap pid查看堆的使用占比情况
C:\Users\Administrator>jmap -heap 25772
Attaching to process ID 25772, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.341-b10
using thread-local object allocation.
Parallel GC with 10 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 4227858432 (4032.0MB)
NewSize = 88080384 (84.0MB)
MaxNewSize = 1409286144 (1344.0MB)
OldSize = 176160768 (168.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 1290797056 (1231.0MB)
used = 218955584 (208.81231689453125MB)
free = 1071841472 (1022.1876831054688MB)
16.96282021888962% used
From Space:
capacity = 9437184 (9.0MB)
used = 9109504 (8.6875MB)
free = 327680 (0.3125MB)
96.52777777777777% used
To Space:
capacity = 57147392 (54.5MB)
used = 0 (0.0MB)
free = 57147392 (54.5MB)
0.0% used
PS Old Generation
capacity = 352321536 (336.0MB)
used = 272912736 (260.2698669433594MB)
free = 79408800 (75.73013305664062MB)
77.46126992361886% used
56894 interned Strings occupying 5551600 bytes.
3.5 查看和调整虚拟机运行参数(jinfo)
jinfo pid 输出全部的参数和系统属性
jinfo -flags pid 输出全部的参数
ps -aux 参看进程的启动命令
C:\Users\Administrator>jinfo 21252
Attaching to process ID 21252, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.341-b10
Java System Properties:
spring.output.ansi.enabled = always
java.runtime.name = Java(TM) SE Runtime Environment
java.vm.version = 25.341-b10
...
四、对症下药
- 如果发现新生代GC频繁，可以调大新生代内存空间。-Xms1024m -Xmx1024m 可以直接调整heap大小，默认新生代占1/3
- 如果FGC比较频繁，且回收后老年代占用较小，原因可能是Survivor From区太小，很多临时变量被直接放入了老年代。可以通过-XX:SurvivorRatio=4 -XX:-UseAdaptiveSizePolicy将默认Eden:Survivor=8:1改为4:1
- 调大后，GC次数少了，但每次GC时间变长的话，可以考虑换一个垃圾收集器，比如把并行收集器改为并发收集器，两者虽都是多线程GC，但后者可以在GC某些阶段不暂停应用，一边GC一边运行
- 如果内存空间大小合理，但GC依然频繁，那可能是堆里的对象有问题，可以通过jmap查看堆里的对象，找到占用较多的对象，然后找到相关业务代码进行分析
五、内存泄露的排查思路
- jstat查看堆和gc是否有异常情况
- 使用MAT工具分析
- MAT工具会给出一个分析结果，并定位到有问题的类
- 常见原因有：循环引用、内存对象泄露没有被销毁、动态分配内存以后未释放、长期持有对象引用、资源未关闭等
六、CPU飙升的排查实践
- top -Hp pid：查找cpu占用最高的线程号nid
- printf '%x\n' 线程id：转为16进制的线程号nid
- jstack pid | grep -A 200 0x[nid]，例如：jstack 41 | grep -A 200 0x61
七、OOM排查实践
- 最开始发现服务不可用，日志显示OOM
- jstat -gc pid查看FGC次数特别多，jstack pid未发现明显异常，jmap -heap pid发现堆大小为512M（容器总内存为2G，默认占1/4）
- 同时把heap dump下来（保存现场），并用MAT工具分析内存泄漏和查看占用多的对象的GC Root，未发现明显异常
- 尝试把堆内存调大到1G：-Xms1024m -Xmx1024m（默认新生代:老年代=1:2）
- 重启服务后，虽然没有OOM了，但FGC依然频繁，且回收后老年代占用较小
- 怀疑是Survivor区太小，导致每次YGC时，有很多对象直接放入了老年代
- 尝试调大Survivor区：-XX:SurvivorRatio=4 -XX:-UseAdaptiveSizePolicy将默认Eden:Survivor=8:1改为4:1
- 运行了17个小时后观察：FGC次数6次，总时间为1.218秒，YGC次数1010次，总时间为29.822秒。问题解决
八、其它
JDK1.8对应的MAT工具版本：https://eclipse.dev/mat/previousReleases.php
image.png
;
