full gc排查思路

遇到full gc问题 或者服务器内存飙高问题不要慌，凡事一定都有解决办法，相信自己。
‘

1、第一步通过jdk自带的命令来了解一下大概的情况

JDK的自带工具，包括jmap、jstat等常用命令：

查看堆内存各区域的使用率以及GC情况

jstat -gcutil -h20 pid 1000

查看堆内存中的存活对象，并按空间排序

jmap -histo pid | head -n20

dump堆内存文件

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

jstat 命令看一下各个代的情况 确定的确是对象过多，那么具体如何排查是哪个对象呢

排查问题我们主要靠代码运行规律 ，工作经验 以及对Java对象的敏感度。

逐一排查，定能攻破，最重要的一点是相信自己一定能搞定

如果自己都不相信自己，怎么能让别人相信你，怎么能最终成为我们自己想成为的人呢。

好的 今天就逐步为大家展开排查思路

后续大家可以借鉴此经验来排查有关内存过大问题。

2、具体排查

第一步，先确认问题，遇到问题先想一想，不要盲目排查

先来看下第一张图片的各个参数hanyi，对我们分析gc问题帮助很大，
有的时候对一个名词理解的准确，我们做起事情来回更加得心应手。

S0 存活区 这里面的数据指的是占SO区的百分比
S1 存活区 这里面的数据是占S1区的百分比
E eden 伊甸园区 这里面的数据是占eden区的百分比
O 老年代 这里面的数据是占老年代的百分比
M 元数据区 可以理解成方法区
CCS 这个我也不知道
YGC 这个很重要 程序启动到当前 yongGC 所用的时间 单位是次数
YGCT 这个很重要 程序启动到当前 yongGC 所用的时间 单位是S
FGC 这个很重要 程序启动到当前 FUllGC 所用的时间 单位是次数
FGCT 这个很重要 程序启动到当前 FullGC 所用的时间 单位是S
GCT
这里面有一个注意的问题
我们看S0 一直是0 这个跟我们所用的垃圾回收期有关系

如果是复制算法 那么肯定是跟大家理解的一样 s1和eden复制 将存活的到s0 或者s1和eden复制 将存活的复制到s1 这样反复将存活的对象就行复制 但是G1可能不是这样的。

第二步 下载dump文件 根据dump文件进行分析。当然要结合代码情况，确认发生问题代码的大概问题。
用这个工具的时候注意一下，文件的格式不要选错，要不然解析不了。

第三步，根据代码情况确定哪些对象比较多，是不是都比较多，那可能是同一个对象引用的，导致我们看到很多对象的实例个数是一致的。这里就是看具体的对象然后进行分析了。多分析几次。

分析源头，看引用，到底是哪个类引用的，也就是找出我们的GCROOT ，一般GCROOT都是我们自己写的，可能看到我们自己的代码痕迹，找到这个那就是成功了一半。

最后 借用一下明朝那些事里 当前明月对王阳明的评价

学识渊博莫测，志趣高妙难知，如蛇屈伸，如龙变化，龙乘风云，可上九天。

我们不必达到此高度，但是成为一个有内涵，有学识的人总是好的。

向着这个方向努力。

时光不负有心人。