GC问题的排查有两个方面的入手点
(1)排查GC问题的关键还是搞清楚内存到底被什么东西占用着,什么东西没有释放,内存是怎么分布的。
(2)同时GC是一个动态的过程,又要结合代码的运行过程,去判断什么到底什么情况下会出现问题,并最终得到修改问题的地方
如果你熟悉代码,那么GC过程理应是白盒,那么相对而言,你发现问题的过程很大程度上是围绕第一点去做,也更快速
如果你不熟悉代码,那么GC过程就是黑盒,那么你的过程最好还是从(1)到(2),先搞清楚内从里的内容,再去考虑代码中有可能出现问题的点,再结合运行时状态,去分析可能出现问题的地方
这里面有很多工具去监控
(1)JVM最原始的方式就是jdk develop包中的JVM命令,包含jstat,jmap等等
(2)oom之后打出dump,或者手动打出dump文件之后,可以用mat,或者jvisualVM去看内存的使用情况
(3)GC log,最好是开发者日志,能看到所有GC相关的内容
往下我们分别看看这些常用的手段能干什么
(1)原生命令
jstat 查看不同代内存、使用情况,GC情况
eg:jstat -gcutil pid 1000
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
1.53 0.00 71.45 64.93 90.70 80.82 16 0.286 4 0.371 0.657
S0、S1 代表年轻代两个Survivor区大小;
E 代表 Eden 区大小;O(Old)代表老年代大小;M(Metaspace)代表元空间大小;
YGC(Young GC)代表Minor GC次数;YGCT代表Minor GC耗时;
FGC(Full GC)代表Full GC次数;FGCT代表FGC总耗时
GCT代表Minor & Full GC共计耗时。
当然你的打印频率是被pid后的参数控制的
正常情况下这也是jvisualVM监控JVM后台数据的来源
jmap 查看JVM内存使用快照和一些基础配置,懂英语的都懂,我就不多介绍
eg:jmap -heap 8768
Attaching to process ID 8768, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08using thread-local object allocation.
Parallel GC with 10 thread(s)Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 1073741824 (1024.0MB)
NewSize = 88604672 (84.5MB)
MaxNewSize = 357564416 (341.0MB)
OldSize = 177733632 (169.5MB)
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 = 119537664 (114.0MB)
used = 85410992 (81.45426940917969MB)
free = 34126672 (32.54573059082031MB)
71.4511135168243% used
From Space:
capacity = 119013376 (113.5MB)
used = 1822976 (1.738525390625MB)
free = 117190400 (111.761474609375MB)
1.5317404322687225% used
To Space:
capacity = 119013376 (113.5MB)
used = 0 (0.0MB)
free = 119013376 (113.5MB)
0.0% used
PS Old Generation
capacity = 716177408 (683.0MB)
used = 464995832 (443.45458221435547MB)
free = 251181576 (239.54541778564453MB)
64.9274644530535% used28353 interned Strings occupying 2485064 bytes.
jstack 这个命令主要是查看当前pid下,某个具体的tid的状态,使用这个命令前,请学习线程的状态相关的内容,一般而言top或者jps拿进程,top -Hp pid拿线程,之后使用jstack tid
这里的mixed mode是标明JVM的编译器模式,采用了混合编译
eg:jstack 8768
2022-03-28 20:05:50
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode):"AWT-Windows" #32 daemon prio=6 os_prio=0 tid=0x0000000024787000 nid=0x1cb0 runnable [0x0000000034e5e000]
java.lang.Thread.State: RUNNABLE
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)"Java2D Disposer" #30 daemon prio=10 os_prio=2 tid=0x000000001abcb800 nid=0x1da8 in Object.wait() [0x0000000025a9e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000cd93a280> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x00000000cd93a280> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at sun.java2d.Disposer.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)"Bundle File Closer" #28 daemon prio=6 os_prio=0 tid=0x000000001abcf000 nid=0x970 in Object.wait() [0x000000003044f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000c289f358> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
at java.lang.Object.wait(Unknown Source)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:400)
- locked <0x00000000c289f358> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:336)"Worker-2" #27 prio=5 os_prio=0 tid=0x000000001abc9000 nid=0x2440 in Object.wait() [0x000000001cecf000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000c018d260> (a org.eclipse.core.internal.jobs.WorkerPool)
at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:197)
- locked <0x00000000c018d260> (a org.eclipse.core.internal.jobs.WorkerPool)
at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:239)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
(2)dump文件的应用,
dump文件一般情况下就是jvisualVM加载或者交由MAT工具加载,之后分析内容就行,花里胡哨一大堆,一看就明白,说白了就是展示了内存里面什么东西最多,什么东西消耗了内存,比如下图就是java线程占用了85%的内存
其中的内容也是一看就懂我觉得没有太多要说的
当然jvisualVM也可以加载dump不过他更直观的应该是GC过程的实时显示
总结,想怎么玩都行,无所谓,能看懂就行,你这么看觉得只管就这么看,你jstat直观就jstat,看你心情
(3)GClog
其实GClog里能反映的主要是针对jstat的内容做详细展示,包含GC的整个过程,以及各个节点阶段的详细内容
链接里有,其实主要理解到这里就差不多了,一般而言,我们排查问题更多的还是找到出问题的点,从而定位到代码段,并最终完成代码修改,我遇见的问题还不够多,对java底层和JVM底层的原理也了解尚浅,还是希望能有更多机会去实践