GC问题排查实战五-G1日志分析以及动态年龄调整机制

G1分析

这次我们用G1试试。

参数

-Xms8192M -Xmx8192M -Xmn4096M -Xss1M -XX:+UseG1GC -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintReferenceGC -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:MetaspaceSize=256M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/app/log/gc/gc.log -XX:ErrorFile=/data/log/error/error.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/heap/heap_hprof.bin -Dfile.encoding=UTF-8

跑完后数据

gc日志数据

同样我们找高的点看看：

看看日志，这个日志比较详细，更加直白的会告诉你哪些步骤耗时，可以看到也是处理引用和拷贝对象，也就是复制的消耗：

然后我找个耗时小的看看：

可以看到这个消耗的比较少，拷贝的对象也不多，引用处理也不多：

safepoint相关数据

动态年龄调整机制(ParNew作为例子)

当GC之后检查幸存区的年龄分布，发现年龄累计(小于等于)已经超过幸存区的一半(-XX:TargetSurvivorRatio默认是50)了，这个时候其实是有个动态年龄计算规则，当累积的某个年龄大小超过了survivor区的一半时，取这个年龄和MaxTenuringThreshold中更小的一个值，作为新的晋升年龄阈值，刚好这个时候年龄2累计(等于小于)的大小刚好超过幸存区的一半了，所以这个时候晋升的年龄就是2，因此后一次GC处理就会把年龄为2的晋升过去了，而且这里可以看到new threshold 2 (max 6)，比如最开始是6，年龄为1的没有超过幸存区的一半，所以没调整，没晋升，耗时不多：

第二次GC后发现年龄为2的累计居然超过了幸存区的一半，那就调整阈值，这次耗时不是晋升，是因为处理引用和幸存区复制的耗时，下一次会有晋升了：

第三次就有晋升，比较耗时，主要就是因为复制，以及上一次年龄为1的经过GC后没被清除，年龄变2了，然后阈值又是2，所以他们要晋升，年龄2的又超过幸存区一半了，那下次还有晋升，年龄阈值还是2：

第四次必然有晋升，比较耗时，但是阈值改回来了，以为最后剩下年龄2的没超过幸存区一半，下次处理就不会有晋升了：

后一次就没了晋升了，阈值没变，多了年龄是3的对象，但是累计也不超过幸存区的一半，耗时也少了：

hotspot相关源码jdk1.8-b26

当然这个也动态年龄调整以及晋升不是我自己猜的，看看相关源码，是累计的的值大于幸存区容量乘以TargetSurvivorRatio系数，然后后面有打印的话会打印：

后面打印的就是这堆东西：

哪些收集器会用到这个机制

那我们再看看这个调节是在哪些用到的，首先是默认的新生代收集器DefNewGeneration：

然后是G1CollectorPolicy：

还有一个ParNewGeneration：

这个机制在哪个阶段被使用

我们拿ParNewGeneration的收集过程看看，不过我能力有限，并不打算分析源码，只是把这个动态调节的位置展示下，可以看到这个调节的方法在最后被调用，后面都是打印日志了，也就是说是在收集阶段最后才会进行调整的，然后这个年龄就会影响后一次收集的对象晋升：

年龄阈值在哪个阶段被使用

我们再来看下对象晋升再哪里，再扫描弱引用的时候会调用ParNewGeneration的copy_to_survivor_space方法：

然后就是处理的时候，先判断年龄，小于阈值的就先从to区分配内存，失败的话就说明溢出了，然后就尝试放老年代，还不够的话记录晋升失败，当然幸存区放的下的话就对象年龄**+1**：

其实就是标记后，对活的对象进行年龄阈值判断，处理能不能放下，放下年龄**+1**，或者放不下晋升或者失败。

总结

通过这3种垃圾回收器回收年轻代的例子，想说明如果发现年老代收集的耗时很长，可以通过什么方式来排查，首先当然是要有足够的日志，比如引用处理，对象年龄，对象拷贝，像G1的话就很详细，当然还可能有safepoint的等待线程的问题，然后根据具体的日志内容进行分析，看看到底哪块是主要耗时，然后进行优化，举个例子，比如我不想那么早把这些生命周期很短的晋升到老年代，放置老年代频繁的GC，那我可以调大年轻代以及幸存区比例，让他尽可能在年轻代就被清除，当然还可以调整比较幸存区比例的那个参数，当然也不是一味的调大年轻代，如果刚好业务对象存活的时间久，就会在幸存区频繁的复制，也是耗时的，所以没有万能的策略，只有根据具体业务选择不同的策略，这个就要看对业务以及垃圾回收器的理解啦，当然多学点理论知识还是好的，JVM相对来说理论比较多，虽然貌似实战没啥用，但是知道总比不知道好，手里有剑跟有剑不用是两码事对吧。

好了，今天就到这里了，希望对学习理解有帮助，大神看见勿喷，仅为自己的学习理解，能力有限。