JavaSEjava jvmJava-GC

初步诊断你的GC

2017-11-27  本文已影响3110人  阿飞的博客

前言

JVM的GC机制让Java程序员省去了自己垃圾回收的烦恼，大大提高了生产效率。但是正因为JVM垃圾回收机制足够优秀，导致很多Java程序员对JVM这个黑盒了解甚少，很多人没有去了解它，很多人也没机会去了解它。然而要想成为一名优秀的Java程序员，了解JVM和它的GC机制，写出JVM GC机制更喜欢的代码，是必须要掌握的一门技术；

这篇文章我主要说一下如何初步诊断JVM的GC是否正常，重点讲解诊断GC，而不是JVM基础和GC基础。所以看这篇文章，需要对JVM有一定的了解，比如常用的垃圾回收器，堆的模型以及分代等，如果你还对JVM一无所知，那么请先花点时间看一下周志明的<<深入理解Java虚拟机>>，重点关注"第二部分 自动内存管理机制"。

GC概念纠正

对GC机制有一定了解的同学都知道，GC主要有YoungGC，OldGC，FullGC（还有G1中独有的Mixed GC，收集整个young区以及部分Old区，提及的概率相对少很多，本篇文章不打算讲解），在讲解如何判断这三种GC是否正常之前，先再次解释一下这三种GC，因为很多很多的同学对OldGC和FullGC有误解；

FullGC触发条件

说明：统计发现之前YGC的平均晋升大小比目前old gen剩余的空间大，触发CMS GC；Metaspace Space使用达到Metaspace阈值是触发CMS GC；

执行jmap -histo:live触发FullGC的gc log如下--关键词Heap Inspection Initiated GC，通过jstat -gccause pid 2s的LGCC列也能看到同样的关键词：
[Full GC (Heap Inspection Initiated GC) 2018-03-29T15:26:51.070+0800: 51.754: [CMS: 82418K->55047K(131072K), 0.3246618 secs] 138712K->55047K(249088K), [Metaspace: 60713K->60713K(1103872K)], 0.3249927 secs] [Times: user=0.32 sys=0.01, real=0.32 secs]

执行jmap -dump:live触发FullGC的gc log如下--关键词Heap Dump Initiated GC，通过jstat -gccause pid 2s的LGCC列也能看到同样的关键词：
[Full GC (Heap Dump Initiated GC) 2018-03-29T15:31:53.825+0800: 354.510: [CMS2018-03-29T15:31:53.825+0800: 354.510: [CMS: 55047K->56358K(131072K), 0.3116120 secs] 84678K->56358K(249088K), [Metaspace: 62153K->62153K(1105920K)], 0.3119138 secs] [Times: user=0.31 sys=0.00, real=0.31 secs]

健康的GC

诊断GC的第一步，当然是知道你的JVM的GC是否正常。那么GC是否正常，首先就要看YoungGC，OldGC和FullGC是否正常；无论是定位YoungGC，OldGC，FullGC哪一种GC，判断其是否正常主要从两个维度：GC频率和STW时间；要得到这两个维度的值，我们需要知道JVM运行了多久，执行如下命令即可：

ps -p pid -o etime

运行结果参考，下面的运行结果表示这个JVM运行了24天16个小时37分35秒，如果JVM运行时间没有超过一天，执行结果是这样"16:37:35"：

[afei@ubuntu ~]$ ps -p 11864 -o etime
    ELAPSED
24-16:37:35

那么怎样的GC频率和STW时间才算是正常呢？这里以我以前开发过的一个读多写少的dubbo服务作为参考，该dubbo服务基本情况如下：

GC情况如下图所示：


GC统计信息

根据这张图输出数据，可以得到如下一些信息：

  1. JVM运行总时间为6944534秒（day*24*3600+hour*3600+minutes*60+second）
  2. YoungGC频率为4s/次（建议通过GC日志中两次YoungGC时间差计算得出）
  3. CMS GC频率为9天/次（FGC=18，即最多发生9次CMS GC，所以CMS GC频率为80/9≈9天/次）
  4. 每次YoungGC的时间为6ms（通过YGCT/YGC计算得出）
  5. FullGC几乎没有（JVM总计运行80天，FGC才18，即使是18次FullGC，FullGC频率也才4.5天/次，更何况实际上FGC=18肯定包含了若干次CMS GC）

根据上面的GC情况，给个可参考的健康的GC状况：

  1. YoungGC频率5秒/次；
  2. CMS GC频率不超过1天/次；
  3. 每次YoungGC的时间不超过20ms；
  4. FullGC频率尽可能完全杜绝；

说明：G1&CMS时，FullGC回收算法会退化成Serial+SerialOld，即单线程串行回收，且完全STW，影响很大且STW时间完全不可预估，所以FullGC频率尽可能完全杜绝。另外，可参考的健康的GC状况这里只是参考，不是绝对，不能说这个GC状况有多好，起码横向对比业务规模，以及服务器规格，你的GC状况不能与上面的dubbo服务有明显的差距；

了解GC健康时候的样子，那么接下来把脉你的JVM GC，一一讲解YoungGC，OldGC，FullGC。看看是有疾在腠理，还是在肌肤，还是在肠胃，甚至已经在骨髓病入膏肓了；

YoungGC

YoungGC是最频繁发生的，发生的概率是OldGC和FullGC的的10倍，100倍，甚至1000倍。同时YoungGC的问题也是最难定位的。这里给出YoungGC定位三板斧（都是踩过坑）：

  1. 查看服务器SWAP&IO情况，如果服务器发生SWAP，会严重拖慢GC效率，导致STW时间异常长，拉长接口响应时间，从而影响用户体验（推荐神器sar，yum install sysstat即可，想了解该命令，请搜索"linux sar"）；
  2. 查看StringTable情况（请参考探索StringTable提升YGC性能）
  3. 排查每次YoungGC后幸存对象大小（JVM模型基于分配的对象朝生夕死的假设设计，如果每次YoungGC后幸存对象较大，可能存在问题）
  4. 未完待续……（可以在留言中分享你的IDEA）
排查每次YoungGC后幸存对象大小可通过GC日志中发生YoungGC的日志计算得出：
例如下面两行GC日志，第二次YoungGC相比第一次YoungGC，整个Heap并没有增长（都是647K），说明回收效果非常理想：
2017-11-28T10:22:57.332+0800: [GC (Allocation Failure) 2017-11-28T10:22:57.332+0800: [ParNew: 7974K->0K(9216K), 0.0016636 secs] 7974K->647K(19456K), 0.0016865 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-11-28T10:22:57.334+0800: [GC (Allocation Failure) 2017-11-28T10:22:57.334+0800: [ParNew: 7318K->0K(9216K), 0.0002355 secs] 7965K->647K(19456K), 0.0002742 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
再看下面两行GC日志，第二次YoungGC相比第一次YoungGC，整个Heap从2707K增长到了4743K，说明回收效果一般：
2017-11-28T10:26:41.890+0800: [GC (Allocation Failure) 2017-11-28T10:26:41.890+0800: [ParNew: 7783K->657K(9216K), 0.0013021 secs] 7783K->2707K(19456K), 0.0013416 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-11-28T10:26:41.892+0800: [GC (Allocation Failure) 2017-11-28T10:26:41.892+0800: [ParNew: 7982K->0K(9216K), 0.0018354 secs] 10032K->4743K(19456K), 0.0018536 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

可参考的健康的GC状况给出建议YoungGC频率5秒/次，经验值3秒~6秒/次都是比较合理的YoungGC频率；

  1. 检查Young区，Young区在整个堆占比在25%~40%比较合理，如果Young区太小，建议扩大Xmn。
  2. 检查SurvivorRatio，保持默认值8即可，Eden:S0:S1=8:1:1是一个比较合理的值；

OldGC

上面已经提及：到目前为止HotSpot JVM虚拟机只单独回收Old区的只有CMS GC。触发CMS GC条件比较简单，JVM有一个线程定时扫描Old区，时间间隔可以通过参数-XX:CMSWaitDuration=2000设置（默认就是2s），如果发现Old区占比超过参数-XX:CMSInitiatingOccupancyFraction=75设定值（CMS条件下默认为68%），就会触发CMS GC。建议搭配-XX:+UseCMSInitiatingOccupancyOnly参数使用，简化CMS GC触发条件，只有在Old区占比满足条件的情况下才触发CMS GC；

可参考的健康的GC状况给出建议CMS GC频率不超过1天/次，如果CMS GC频率1天发生数次，甚至上10次，说明你的GC情况病的不轻了，建议follow如下步骤进行初步症断：

  1. 检查Young区与Old区比值，尽量留60%以上的堆空间给Old区；
  2. 通过jstat查看每次YoungGC后晋升到Old区对象占比，如果发现每次YoungGC后Old区涨好几个百分点，甚至上10个点，说明有大对象，建议dump（jmap -dump:format=b,file=app.bin pid）后用MAT分析；
  3. 如果不停的CMS GC，Old区降不下去，建议先执行jmap -histo pid | head -n20 查看TOP20对象分布，如果除了[B和[C，即byte[]和char[]，还有其他占比较大的实例，如下图所示中TOP1的Object数组，也可通过dump后用MAT分析问题；
  4. 如果TOP20对象中有StandartSession对象，排查你的业务代码中有没有显示使用HttpSession，例如String id = request.getSession().getId();，一般的OLTP系统几乎不会使用HttpSession，且HttpSession的的生命周期很长，会加快Old区增长速度；
异常的大对象.png

FullGC

 [afei@aliyun~]$ jstat -gccause 23606 2s 5
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC                 
  0.00 100.00  37.50  83.17  93.31  84.35   5597   24.116     0    0.000   24.116 G1 Evacuation Pause  No GC               
  0.00 100.00  37.50  83.17  93.31  84.35   5597   24.116     0    0.000   24.116 G1 Evacuation Pause  No GC               
  0.00 100.00  37.50  83.17  93.31  84.35   5597   24.116     0    0.000   24.116 G1 Evacuation Pause  No GC               
  0.00 100.00  37.50  83.17  93.31  84.35   5597   24.116     0    0.000   24.116 G1 Evacuation Pause  No GC               
  0.00 100.00  37.50  83.17  93.31  84.35   5597   24.116     0    0.000   24.116 G1 Evacuation Pause  No GC
System.gc引起的FullGC.png
上一篇下一篇

猜你喜欢

热点阅读