后端通过gc。log调优JVM

　　一、GC日志查看
　　GC日志默认是关闭的，需要查看GC日志首先需要开启GC日志。
　　常用GC日志的配置有如下，组合以下命令，在启动时加入，就可以得到GC日志。
　　XX：PrintGC输出GC日志
　　XX：PrintGCDetails输出GC的详细日志
　　XX：PrintGCTimeStamps输出GC的时间戳（以基准时间的形式）
　　XX：PrintGCDateStamps输出GC的时间戳（以日期的形式，如20200504T21：53：59。2340800）
　　XX：PrintHeapAtGC在进行GC的前后打印出堆的信息
　　XX：GCLogFileSize日志大小
　　Xloggc：。。logsgc。log日志文件的输出路径
　　例如使用如下命令启动javaXX：PrintGCDateStampsverbose：gcXX：PrintGCDetailsXloggc：。。gc。logXX：UseGCLogFileRotationjardemo。jar
　　当项目启动，获取到gc。log后，可以使用GCeasy上传gc。log文件，进行分析。二、调整新生代老年代比例
　　分析的结果中注意到一点：新生代分配1G，使用峰值为0。93G，使用率约90；老年代分配2。1G，使用峰值为1。7G，使用率约80。也就是说老年代有部分空间没用到，能否提高利用率？
　　JVMmemorysize
　　堆的内存模型大致为新生代老年代12，能否通过增大新生代，减小老年代的方法来提高内存利用率？
　　JVM内存模型
　　例如把新生代、老年代比例设置为1：1，设置参数：XX：NewRatio1。
　　XX：NewRatio命令是设置Old与Yong的比例，比如值为2，也就是默认值，即OldGeneration：YongGeneration2，注意：该参数的值只能时正整数，无法使用小数，例如设置NewRatio0。5，是无法启动的。
　　NewRatio0。5
　　运行一段时间后，再看JVM内存使用
　　JVMmemorysize
　　发现内存使用率基本没有变化，但是，停顿时间有了明显的变化。系统运行了6天，调整前总停顿时间约5min30sec。
　　调整前总停顿时间
　　调整后总停顿时间约2min50sec，相较于调整前，停顿时间下降约50。
　　调整后总停顿时间
　　调整前，平均停顿时间20ms，最大停顿时间180ms。
　　调整前平均时间
　　调整后，平均停顿时间16ms，相较于调整前停顿时间下降约20，最大停顿时间140ms，下降约22。
　　调整后平均时间
　　分析原因，主要是FullGC次数减少。调整前FGC次数为6次。
　　调整前FGC
　　调整后FGC次数还不到3次，相较于调整前，FGC次数下降约50，而FGC一定会StopTheWorld，FGC次数减少，停顿时间自然会减少。
　　调整后FGC
　　为什么FGC次数会减少呢？
　　因为从年轻代晋升到老年代对象的数量减少了。调整前晋升数量约5MB。
　　调整前晋升数量
　　而调整后晋升数量不到2MB。
　　调整后晋升数量
　　因为年轻代增大了，可以容纳更多的对象，更多垃圾在年轻代就被回收了，所以导致晋升到老年代的对象减少，老年代对象减少导致FGC次数也减少，所以停顿时间也随之下降。
　　这里引出一个问题：年轻代调大后，YoungGC时间是否会增加？
　　答案是不会，应为YGC主要采用复制算法，耗时也集中在复制过程中，虽然年轻代增大了，但每次复制时，存活的对象数量大致不会改变，所以耗时并不会增加。
　　调整前YGC停顿时间集中在1040ms之间。
　　调整前YGC停顿时间
　　调整后YGC停顿时间基本不变，也是集中在1040ms之间，并且可以看到调整后YGC的最大停顿时间还下降了。
　　调整后YGC停顿时间
　　是否还能继续优化？三、调整晋升次数
　　过早晋升问题
　　比如说Old区触发的回收阈值是80，经历过一次GC之后下降到了10，这就说明Old区的70的对象存活时间其实很短，Old区大小每次GC后从1。3G回收到0。2G，也就是说回收掉了1。1G的垃圾，只有200M的活跃对象。整个Heap目前是4G，活跃对象只占了不到二十分之一。
　　调整后FGC
　　主要原因：
　　1、YoungEden区过小：过小的直接后果就是Eden被装满的时间变短，本应该回收的对象参与了GC并晋升，YoungGC采用的是复制算法，copying耗时远大于mark，也就是YoungGC耗时本质上就是copy的时间，没来及回收的对象增大了回收的代价，所以YoungGC时间增加，同时又无法快速释放空间，YoungGC次数也跟着增加。
　　2、对象太容易晋升。
　　解决办法：
　　对于第1点，上述已通过调大年轻代来解决。
　　对于第2点，可以继续优化，通过设置XX：MaxTenuringThreshold来设置年轻代晋升老年代的最大年龄阈值。需要注意的是XX：MaxTenuringThreshold设置的是最大阈值，也就是说有些对象没有达到阈值也会进入老年代，例如年轻代放不下的大对象。
　　所有的对象都在Eden区创建，当Eden区满了，那么就会触发一次YoungGC。少量有用的对象会复制到From区，年龄1。
　　当Eden区再次被用完，就再触发一次YoungGC，这个时候跟刚才稍稍有点区别。这次触发YoungGC后，会将Eden区与From区还在被使用的对象复制到To区，年龄1。
　　经过若干次YoungGC后，有些对象在From与To之间来回游荡，每游荡一次，对象的年龄1，当年龄达到From区与To区的底线（XX：MaxTenuringThreshold设置的阈值）的时候，这些家伙要是到现在还没挂掉，一起复制老年代吧。
　　MaxTenuringThreshold的取值范围是115，默认值是15，但CMS收集器MaxTenuringThreshold的默认值是6，但是官方文档并没有说明，为何CMS特殊是6。因此若使用CMS收集器时，可以考虑增大MaxTenuringThreshold的值。
　　文章来源：小道萧兮https：www。jianshu。comp7b0ef3c27a39