排查一次GC问题

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-b08

using 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% used

28353 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的整个过程，以及各个节点阶段的详细内容

理解CMS GC日志 - 简书 

链接里有，其实主要理解到这里就差不多了，一般而言，我们排查问题更多的还是找到出问题的点，从而定位到代码段，并最终完成代码修改，我遇见的问题还不够多，对java底层和JVM底层的原理也了解尚浅，还是希望能有更多机会去实践