GC初步诊断（转载）

最新推荐文章于 2021-01-24 21:21:57 发布
最新推荐文章于 2021-01-24 21:21:57 发布
阅读量511 收藏 1
点赞数
分类专栏： JVM研究

原文地址：https://mp.weixin.qq.com/s/d58qlHRtXsXp8vR9n9iBTg

在这里插入图片描述
JVM的GC机制绝对是很多程序员的福音，它让Java程序员省去了自己回收垃圾的烦恼。从而可以把大部分时间专注业务身上，大大提高了业务开发速度，让产品需求尽快的落地抢占市场。但是也正因为如此，导致很多Java程序员对JVM和GC知之甚少，以我愚见大家对JVM&GC不够了解的有几个原因：

  • 门槛太高。我们平常接触的spring，dubbo，java集合&J.U.C，网上都有无数优秀的文章对其深入的分析。而且都是基于Java语言，我们在学习的过程中，可以自己很容易的debug源码更深入的了解。但是JVM则不然，它是C++开发的，能同时掌握C++和Java的程序员还是很少的，自己也不太好debug分析它的源码（就是编译jvm源码，都要折腾一番）。

  • 有价值的系列文章太少。网上几乎没有完整体系的文章，优秀的书籍也很少（可能大家听过或者看过最多的就是周志明的深入理解Java虚拟机，这确实是JVM领域比较少见的佳作）。

  • 接触的太少。虽然我们天天写Java代码，你写的每行代码JVM都会参与工作。但是很少进行GC调优，因为JVM是如此的优秀，绝大部分情况下，它只是默默的做你背后的女人（即使出问题了，也轮不到我们去排查，扎心了）。

R大是谁？语言是苍白的，请戳知乎链接：https://www.zhihu.com/question/24923005/answer/29512367。另外，如果对JVM很感兴趣的朋友，可以看一下R大在知乎上的一些答疑：https://www.zhihu.com/people/rednaxelafx。并且如果你也恰好看周志明的深入理解Java虚拟机，强烈建议结合R大的读书笔记进行阅读：https://book.douban.com/people/RednaxelaFX/annotation/24722612/。笔者还认识另外两位对JVM有一定研究的大牛：你假笨和占小狼，有性趣的同学可以关注并了解（网上其他文章，持保留意见）。

对于JVM&GC，很多人没有去了解它，很多人也没机会去了解它，甚至有部分人都不原因去了解它。然而要想成为一名优秀的Java程序员，了解JVM和它的GC机制，写出JVM GC机制更喜欢的代码。并且你能知道JVM这个背后的女人是否发脾气了，还知道她发脾气的原因，这是必须要掌握的一门技术，是通往高级甚至优秀必须具备的技能。

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

GC概念纠正

初步诊断GC之前，先对GC中最常误解的几个概念普及一下。对GC机制有一定了解的同学都知道，GC主要有YoungGC，OldGC，FullGC（还有G1中独有的Mixed GC，收集整个young区以及部分Old区，提及的概率相对少很多，本篇文章不打算讲解），大概解释一下这三种GC，因为很多很多的同学对OldGC和FullGC有非常大的误解；

关于CMS的foreground collect模式，以及FullGC

  • foreground collect

它发生的场景，比如业务线程请求分配内存，但是内存不够了，于是可能触发一次CMS GC，这个过程就必须要等待内存分配成功后线程才能继续往下面走，因此整个过程必须STW，因此这种CMS GC整个过程都是暂停应用的，但是为了提高效率，它并不是每个阶段都会走的，只走其中一些阶段，这些省下来的阶段主要是并行阶段：Precleaning、AbortablePreclean，Resizing这几个阶段都不会经历，但不管怎么说如果走了类似foreground这种CMS GC，那么整个过程业务线程都是不可用的，效率会影响挺大。相关源码可以在openjdk的concurrentMarkSweepGeneration.cpp中找到。

  • G1下的FullGC

G1或者ParNew+CMS组合前提下，如果真的发生FullGC，则是单线程完全STW的回收方式（SerialGC），可以想象性能有多差，如果是es，hbase等需要几十个G的堆，那更是灾难。不过JDK10将对其进行优化，可以参考：http://openjdk.java.net/jeps/307，如下图所示：
在这里插入图片描述

后面还有一段描述（Description）：
The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can’t reclaim memory fast enough a fall back full GC will occur. The current implementation of the full GC for G1 uses a single threaded mark-sweep-compact algorithm. We intend to parallelize the mark-sweep-compact algorithm and use the same number of threads as the Young and Mixed collections do. The number of threads can be controlled by the -XX:ParallelGCThreads option, but this will also affect the number of threads used for Young and Mixed collections.

FullGC触发条件

这里列举一些可能导致FullGC的原因，这也是一些高级面试可能问到的问题：

  • 没有配置 -XX:+DisableExplicitGC情况下System.gc()可能会触发FullGC；
  • Promotion failed；
  • concurrent mode failure；
  • Metaspace Space使用达到MaxMetaspaceSize阈值；
  • 执行jmap -histo:live或者jmap -dump:live；

说明：统计发现之前YGC的平均晋升大小比目前old gen剩余的空间大，触发的是CMS GC；如果配置了CMS，并且Metaspace Space使用量达到MetaspaceSize阈值也是触发CMS GC；

这里可以参考笔者另外一篇文章：PermSize&MetaspaceSize区别

执行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服务基本情况如下：

日调用量1亿+次，接口平均响应时间8ms以内

  • 4个JVM
  • 每个JVM设置Xmx和Xms为4G并且Xmn1G
  • 4核CPU + 8G内存服务器
  • JDK7
  • AWS云服务器

GC情况如下图所示：
在这里插入图片描述

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

  1. JVM运行总时间为7293378秒（80243600+93600+5660+18）

  2. YoungGC频率为2秒/次（7293378/3397184，jstat结果中YGC列的值）

  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）

如果要清楚的统计CMS GC和FullGC的次数，只能通过GC日志了。

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

  1. YoungGC频率不超过2秒/次；

  2. CMS GC频率不超过1天/次；

  3. 每次YoungGC的时间不超过15ms；

  4. FullGC频率尽可能完全杜绝；

说明：这里只是参考，不是绝对，不能说这个GC状况有多好，起码横向对比业务规模，以及服务器规格，你的GC状况不能与笔者的dubbo服务有明显的差距。

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

YGC

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

  • 查看服务器SWAP&IO情况，如果服务器发生SWAP，会严重拖慢GC效率，导致STW时间异常长，拉长接口响应时间，从而影响用户体验（推荐神器sar，yum install sysstat即可，想了解该命令，请搜索"linux sar"）；

  • 查看StringTable情况（请参考：探索StringTable提升YGC性能）

  • 排查每次YGC后幸存对象大小（JVM模型基于分配的对象朝生夕死的假设设计，如果每次YGC后幸存对象较大，可能存在问题）

  • 未完待续……（可以在留言中分享你的idea）

排查每次YGC后幸存对象大小可通过GC日志中发生YGC的日志计算得出，例如下面两行GC日志，第二次YGC相比第一次YGC，整个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日志，第二次YGC相比第一次YGC，整个Heap从2707K增长到了4743K，说明回收效果不太理想，如果每次YGC时发现好几十M甚至上百M的对象幸存，那么可能需要着手排查了：

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状况给出建议YGC频率不超过2秒/次，经验值2秒~10秒/次都是比较合理的YGC频率；

  • 如果YGC频率远高于这个值，例如20秒/次，30秒/次，甚至60秒/次，这种情况下，说明JVM相当空闲，处于基本上无事可做的状态。建议缩容，减少服务器浪费；

  • 如果YoungGC频率远低于这个值，例如1秒/次，甚至1秒/好多次，这种情况下，JVM相当繁忙，建议follow如下步骤进行初步症断：

  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设置（默认就是2s），扫描发现Old区占比超过参数-XX:CMSInitiatingOccupancyFraction设定值（CMS条件下默认为68%），就会触发CMS GC。建议搭配-XX:+UseCMSInitiatingOccupancyOnly参数使用，简化CMS GC触发条件，只有在Old区占比满足-XX:CMSInitiatingOccupancyFraction条件的情况下才触发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 -n10 查看TOP10对象分布，如果除了[B和[C，即byte[]和char[]，还有其他占比较大的实例，如下图所示中排名第一的Object数组，也可通过dump后用MAT分析问题；

  4. 如果TOP10对象中有StandartSession对象，排查你的业务代码中有没有显示使用HttpSession，例如String id = request.getSession().getId();，一般的OLTP系统都是无状态的，几乎不会使用HttpSession，且HttpSession的的生命周期很长，会加快Old区增长速度；

在这里插入图片描述

笔者曾经帮一位朋友排查过一个问题：他也是TOP对象中有StandartSession对象，并且占比较大，后面让他排查发现在接口中使用了HttpSession生成一个唯一ID，让他改成用UUID就解决了OldGC频繁的问题。

FullGC

如果配置CMS，由于CMS采用标记清理算法，会有内存碎片的问题，推荐配置一个查看内存碎片程度的JVM参数：PrintFLSStatistics。

如果配置ParallelOldGC，那么每次Old区满后，会触发FullGC，如果FullGC频率过高，也可以通过上面OldGC提及的排查方法；

如果没有配置-XX:+DisableExplicitGC，即没有屏蔽System.gc()触发FullGC，那么可以通过排查GC日志中有System字样判断是否由System.gc()触发，日志样本如下：

558082.666: [Full GC (System) [PSYoungGen: 368K->0K(42112K)] [PSOldGen: 36485K->32282K(87424K)] 36853K->32282K(129536K) [PSPermGen: 34270K->34252K(196608K)], 0.2997530 secs]

或者通过jstat -gccause pid 2s pid判定，LGCC表示最近一次GC原因，如果为System.gc，表示由System.gc()触发，GCC表示当前GC原因，如果当前没有GC，那么就是No GC：

在这里插入图片描述

菜鸟撸码
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
面试阿里巴巴，只因不懂JVM，面试官让我回去等通知
msbjyJava的博客
06-04 395
前言 JVM的GC机制绝对是很多程序员的福音，它让Java程序员省去了自己回收垃圾的烦恼。从而可以把大部分时间专注业务身上，大大提高了业务开发速度，让产品需求尽快的落地抢占市场。但是也正因为如此，导致很多Java程序员对JVM和GC知之甚少，以我愚见大家对JVM&GC不够了解的有几个原因： 门槛太高。我们平常接触的spring，dubbo，java集合&J.U.C，网上都有无数优秀的文章对其深入的分析。而且都是基于Java语言，我们在学习的过程中，可以自己很容易的debug源码更深入
gc4023 datasheet
03-27
GC4023 CMOS图像传感器数据手册 GC4023是一款高性能的CMOS图像传感器，用于capturing高质量图像。该传感器具有1/2.7英寸的感光面积、4Mega像素的高分辨率和低噪音的特点。该传感器的datasheet提供了详细的技术规格...
GC问题诊断
weixin_33801856的博客
11-24 241
2019独角兽企业重金招聘Python工程师标准>>> ...
初步诊断你的GC
落叶翩翩的CSDN博客
11-28 1569
前言 JVM的GC机制让Java程序员省去了自己垃圾回收的烦恼，大大提高了生产效率。但是正因为JVM垃圾回收机制足够优秀，导致很多Java程序员对JVM这个黑盒了解甚少，很多人没有去了解它，很多人也没机会去了解它。然而要想成为一名优秀的Java程序员，了解JVM和它的GC机制，写出JVM GC机制更喜欢的代码，是必须要掌握的一门技术； 这篇文章我主要说一下如何初步诊断JVM的GC是否允许正常，重点
注意项：Java heap dump的坑
sodawoods的博客
01-24 731
观察到服务的内存占用高，想把堆dump下来看看，然后你执行了下面的指令。 jmap -dump:live,format=b,file=heap.hprof $pid 之后使用MAT等工具打开查看，发现堆变小了？ 使用jstat -gc $pid看，出现了一次FullGC？ 查看GC日志，发现堆的大小从57.6G变成了16G？ 2021-01-24T10:29:55.221+0800: 131918.685: [Full GC (Heap Dump Initiated GC) 131932.469: [G
你的 JVM 还好吗？GC 初步诊断
Java爬坑之路
08-24 1286
前言 JVM的GC机制绝对是很多程序员的福音，它让Java程序员省去了自己回收垃圾的烦恼。从而可以把大部分时间专注业务身上，大大提高了业务开发速度，让产品需求尽快的落地抢占市场。但是也正因为如此，导致很多Java程序员对JVM和GC知之甚少，以我愚见大家对JVM&GC不够了解的有几个原因： 门槛太高。我们...
gc02m1 datasheet
03-27
GC02M1 datasheet GC02M1是一款CMOS图像传感器，具有高分辨率、低噪声和高灵敏度等特点。下面是根据GC02M1 datasheet的内容生成的相关知识点： 1. 传感器概述 GC02M1是一款1/5英寸的CMOS图像传感器，具有200万像素...
GC6153_SERIAL_GC6153
09-11
标题 "GC6153_SERIAL_GC6153" 指向的是一款基于MTK（MediaTek）平台的驱动程序，专为控制SPI接口的GC6153芯片而设计。这款驱动程序的主要功能是确保GC6153芯片在系统中能够正确地被初始化、配置和操作，从而实现其...
GC9106_GC9106_
10-03
GC9106TFT彩屏说明书以及初始化源代码
gc.rar_gc
09-19
标题中的"gc.rar_gc"可能是指“Garbage Collection”在编程领域的含义，尤其是与Java语言相关的内存管理机制。GC是垃圾收集的缩写，它是自动的内存管理过程，用于识别并回收不再使用的对象所占用的内存空间。在Java...
漫话：给女朋友解释GC如何判断什么东西可以回收？
u011277123的博客
08-16 1600
漫话编程 Hollis 今天 周一晚上下班，我高高兴兴的回到家里面，女朋友蹦蹦跳跳的朝我跑过来，手里拿着扫把和拖布。这是又要打我么？我又做错了什么事情么？我大脑在高速旋转。这时，女朋友打破了沉默。 嗨，回来啦。诺，给你，我知道你最近在学习做家务。   Execuse Me？我在学习做家务？开什么玩笑，我躲还来不及呢。 唉，你就别谦虚啦。我今天帮你拿了一份快递，是一本书《垃圾回收的...
如何判断那些内存需要回收（GC）
weixin_38696033的博客
02-05 1241
一、通过可达性分析算法来判断对象是否还活着，这个算法的基本思路就是通过一系列的被称为“GC ROOT”的对象作为起始点，从这些节点往下开始搜素，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连接（用画图来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的，因此就会被判定为可回收的对象（在java语言中，可作为GC Roots的对象包括下面几种，1、虚拟
如何判断一个对象是否存活?(或者GC对象的判定方法)?
知识分享
11-30 2373
这个问题，面试被问到的概率还是很大的。以下关于如何判断一个对象是否存活的回答，完全参照《深入理解Java虚拟机》一书，有需要的可以看书学习。以下是题目解析 判断对象是否存活的算法包括： 引用计数算法 可达性分析算法 问题的回答就是通过引用计数算法或者可达性分析算法去判断一个对象是否存活，下面开始具体描述这两种算法。 引用计数算法（Reference Countin...
ART运行时Foreground GC和Background GC切换过程分析
热门推荐
老罗的Android之旅
05-04 1万+
通过前面一系列文章的学习，我们知道了ART运行时既支持Mark-Sweep GC，又支持Compacting GC。其中，Mark-Sweep GC执行效率更高，但是存在内存碎片问题；而Compacting GC执行效率较低，但是不存在内存碎片问题。ART运行时通过引入Foreground GC和Background GC的概念来对这两种GC进行扬长避短。本文就详细分析它们的执行过程以及切换过程。
golang查看gc是否有异常
小白菜的专栏
11-24 471
# 一、gc分析命令 ``` GODEBUG=gctrace=1 go run *.go ``` # 二、执行命令，分析内容如下 ``` gc 1 @0.001s 13%: 0.004+2.5+0.023 ms clock, 0.019+0.18/1.7/2.3+0.094 ms cpu, 4->6->6 MB, 5 MB goal, 4 P gc 2 @0.017s 6%: 0.002+4.1+0.020 ms clock, 0.009+0/3.4/5.6+0.0..
GC触发原因
weixin_43835869的博客
12-31 1099
GC触发条件：GCLocker Initiated GC、Allocation Failure、Metadata GC Threshold
GC的判定的2种方式
imooc_000000的博客
05-13 2068
注：参考 https://blog.csdn.net/qq_1681163/article/details/52277380 https://blog.csdn.net/u014142287/article/details/51424725 java的四种引用https://www.cnblogs.com/huajiezh/p/5835618.html对象是否死亡的2中判定方法：引用计数和可达性分...
GC对象的判定方法
zhang_java_11的博客
07-23 618
GC对象的判定方法 判断一个对象是否存活有两种方法: 引用计数法   所谓引用计数法就是给每一个对象设置一个引用计数器，每当有一 个地方引用这个对象时，就将计数器加一，引用失效时，计数器就减一。当一个对象的引用计数器为零时，说明此对象没有被引用， 也就是“死对象”,将会被垃圾回收.   引用计数法有一个缺陷就是无法解决循环引用问题，也就是说当对象 A 引用对象 B，对象 B 又引用者对象 A，那么此时 A、B 对象的引用计数器都不为零，也就造成无法完成垃圾回收，所以主流的虚拟机都没有采用这种算法。 可达性
磁力链磁力链磁力链.txt
最新发布
07-22
磁力链
GC0328 CMOS图像传感器数据手册
"GC0328 DataSheet for FAE_V1.0_20120921.pdf" 本文档是关于格科微（GalaxyCore Inc.）GC0328 CMOS 图像传感器的数据手册，适用于电子工程师、硬件设计师以及需要调试摄像头传感器效果的技术人员。GC0328 是一款1/...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值