JVM 调优/问题排查 浅谈

参考：https://www.cnblogs.com/xingzc/p/5756119.html

https://www.cnblogs.com/yang-hao/p/5939487.html

https://blog.csdn.net/chenjianandiyi/article/details/52442021

https://www.bilibili.com/video/av52674111

JVM指令

标准指令，X指令，XX指令，其中XX指令是调优的关键。

XX指令

boolean型：-XX:[+-] name 表示启用/禁用name属性。比如：-XX:+UseG1GC

KV类型：-XX:[+-] name=value

查看类指令

-XX:+PrintFlagsFinal 

JPS -l  查看JAVA进程PID

jinfo   -flag  <参数名 不写打印全部属性>  进程PID   查看进程属性值

jstat   查看JVM类装载、垃圾收集、jit编译

jstat  -gc pid  <间隔ms>  <连续打印次数> 

JMAP 堆内存dump 导出后用MAT分析

当堆非常大几个G时，JMAP会让进程停止超长时间。

推荐不要在线上直接堆dump。把问题进程通过Nginx做主备替换/分布式环境安全下线后，再执行dump。

Jstack -l ${PID} （线程dump -l 打印锁信息）

打印进程7930的线程dump到txt文件，并下载到本地。SecureCRT作为Linux客户端为例。

 

配置样例

Linux 修改 /tomcat/bin/catalina.sh 文件，把下面信息添加到文件第一行。

机子内存如果是 8G，一般 PermSize 配置是主要保证系统能稳定起来就行：

https://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html

CMS样例：
jdk1.7 4V8G                                     //8G机器，分4G给堆，其他留给 栈+PermSize+DirectMemory+系统

-server                                         //应用于服务器JVM 内部会有特殊处理的
-Xms4g -Xmx4g -Xmn2g -Xss768k                   //官方推荐 年轻代:堆 3:8 。默认栈是1M
-XX:PermSize=512m -XX:MaxPermSize=512m          //JVM总内存：堆+栈+PermSize+DirectMemory...
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+DisableExplicitGC                          //忽略System.gc()
-XX:MaxDirectMemorySize=512M                    //外部内存(非JVM内存)，默认是Xmx。一定注意Xmx+DirectMemory不要超过主机内存

-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-Xloggc:{CATALINA_BASE}/logs/gc.log 

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath={CATALINA_BASE}/logs 

-XX:+UseParNewGC                                 //新生代使用 ParNew 回收器，老年代使用串行收集器

-XX:ParallelGCThreads={value}                    //这个参数是指定并行 GC 线程的数量，一般最好和 CPU 核心数量相当。默认情况下，当 CPU 数量小于8， ParallelGCThreads 的值等于 CPU 数量，当 CPU 数量大于 8 时，则使用公式：3+（（5*CPU）/ 8）；同时这个参数只要是并行 GC 都可以使用，不只是 ParNew。
//注意当使用类似docker时，必须配置成容器分配的核心数。否则会以物理机真是核心为准。GC可能速度会严重下降。

//老年代CMS相关配置：
-XX:+UseCMSInitiatingOccupancyOnly              //CMS触发阈值自定义
-XX:CMSInitiatingOccupancyFraction=68           //老年代占用68%(默认值)时开始进行CMS收集，避免分担担保引起FULLGC
-verbose:gc 

-XX:+CMSClassUnloadingEnabled                  //CMS可清理持久代，移除不再使用的class

//CMS-碎片优化
-XX:+UseCMSCompactAtFullCollection             //使用CMS时可以开启对年老代的压缩。(解决碎片)
-XX:CMSFullGCsBeforeCompaction=5 (0默认)       //上面配置开启的情况下，这里设置多少次FullGC后，对年老代进行压缩，控制FullGC频率。

//CMS-STW优化，CMS主要在两次标记时STW
-XX:+CMSParallelInitialMarkEnabled             //初始标记并行执行(默认是串行)
-XX:+CMSScavengeBeforeRemark                   //CMS执行前先ygc，减少重标记阶段用时

-XX:ConcGCThreads 或者 -XX:ParallelCMSThreads  //除了上面设置线程的方式，你也可以通过这个两个参数任意一个手工设定 CMS 并发线程数。
//注意当使用类似docker时，必须配置成容器分配的核心数。否则会以物理机真是核心为准。GC可能速度会严重下降。

-Dfile.encoding：默认文件编码
-server：表示这是应用于服务器的配置，JVM 内部会有特殊处理的
-XX:+UseConcMarkSweepGC (CMS) 设置GC收集器（注意碎片化，见下文）
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/heap/dump 让JVM在遇到OOM(OutOfMemoryError)时生成Dump文件

--堆栈设置
-Xmx1024m：设置JVM最大可用内存为1024MB(默认物理内存1/4)
-Xms1024m：设置JVM最小内存为1024m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xss128k：设置每个线程的栈大小。JDK5.0以后每个线程栈大小为1M(单线程栈不够用或线程过多都有可能栈溢出)

--设置年轻代
-Xmn1g：设置年轻代大小为1G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。
-XX:NewSize：设置年轻代大小
-XX:NewRatio=4：设置年轻代（包括 Eden 和两个 Survivor 区）与老年代的比值（除去永久代）。设置为 4，则年轻代与老年代所占比值为 1：4，年轻代占整个堆的 1/5
-XX:MaxNewSize：设置最大的年轻代大小
-XX:SurvivorRatio=n

--设置永久代
-XX:PermSize：设置永久代大小.jdk8 PermSize被MetaspaceSize代替?，MetaspaceSize共享heap，不会再有java.lang.OutOfMemoryError：PermGen space，可以不设置
-XX:MaxPermSize：设置最大永久代大小

--打印信息
-XX:+PrintGCDetails 
输出形式： [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K),0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps(打印GC发生的时间)
输出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime(GC程序暂停时间)
输出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime(打印每次GC前，程序未中断的执行时间，两次GC间隔？)
输出形式:Application time: 0.5291524 seconds


-XX:MaxTenuringThreshold=10：设置垃圾最大年龄，默认为：15。如果设置为 0 的话，则年轻代对象不经过 Survivor 区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在 Survivor 区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
-XX:+DisableExplicitGC：这个将会忽略手动调用 GC 的代码使得 System.gc() 的调用就会变成一个空调用，完全不会触发任何 GC

MinHeapFreeRatio 参数用来设置堆空间最小空闲比例，默认值是 40。当堆空间的空闲内存小于这个数值时，JVM 便会扩展堆空间。

MaxHeapFreeRatio 参数用来设置堆空间最大空闲比例，默认值是 70。当堆空间的空闲内存大于这个数值时，便会压缩堆空间，得到一个较小的堆。  

指针压缩

可以开启指针压缩，将类指针、引用指针等压缩为4位节约内存。但是堆超过32G时压缩自动失效，因为压缩后的指针只能记录32G的内存地址。

GC ROOT

jvm的CG是通过可达性完成的，从ROOT对象引用出发标记存活对象。未被标记的为垃圾对象。

ROOT：栈内变量引用，静态变量引用，常量池，JNI指针。

可以看出根主要在栈+方法区。

Java 的内存模型

-  Young，年轻代（易被 GC）。Young 区被划分为三部分，Eden 区和两个大小严格相同的 Survivor 区，其中 Survivor 区间中，某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用，在 Young 区间变满的时候，minor GC 就会将存活的对象移到空闲的Survivor 区间中，根据 JVM 的策略，在经过几次垃圾收集后，任然存活于 Survivor 的对象将被移动到 Tenured 区间。

-  Tenured，终身代。Tenured 区主要保存生命周期长的对象，一般是一些老的对象，当一些对象在 Young 复制转移一定的次数以后，对象就会被转移到 Tenured 区，一般如果系统中用了 application 级别的缓存，缓存中的对象往往会被转移到这一区间。

-  Perm，永久代。(jdk8 被MetaspaceSize代替) 主要保存 class,method,filed 对象，这部门的空间一般不会溢出，除非一次性加载了很多的类，不过在涉及到热部署的应用服务器的时候，有时候会遇到 java.lang.OutOfMemoryError : PermGen space 的错误，造成这个错误的很大原因就有可能是每次都重新部署，但是重新部署后，类的 class 没有被卸载掉，这样就造成了大量的 class 对象保存在了 perm 中，这种情况下，一般重新启动应用服务器可以解决问题。

方法区：

1.7：类信息、常量池、静态变量、即时编译器编译后的代码等数据，存储在 Perm（永久带）。

1.8：常量池和静态变量放到了Java堆，类元数据放到了本地直接内存MetaSpace。

内存使用分析流程

假设情景：JVM堆内存有1G按照3:8分配，新生代总共约310mb，Eden为248mb，S1=S2=31MB。

服务只有一个方法，每次执行总共创建约10kb内容。每秒200次请求调用，那么此服务1s约2mb消耗。初步推断约124s将填满Eden区触发MinorGC。MinorGC(E+S区)后10mb存活放入S1区。可能4-5次MinorGC(10分钟)后S区将被填满，或是S区有半数对象同一个年龄，此时对象强制进入老年代。

以上情况分析可能存在问题：

1.新生代较小：对象等不到15次MinorGC就被放入老年代。

2 对象存活时间长：几次GC约10分钟，S区仍有大量对象没有释放

老年代对象来源

优化配置，减少直接晋升老年代的情况

https://blog.csdn.net/shanchahua123456/article/details/79634100

 

并行GC 

-XX:+UseParallelOldGC   年轻代：ParallelScavenge  (JDK1.8默认组合)

默认：15岁进入老年代

适用场景：10G以下的堆内存

执行思路：STW然后多线程处理垃圾。

CMS 并发标记清除(老年代)

 -XX:+UseConcMarkSweepGC   年轻代配合使用ParNew。JDK1.9以后CMS被废除。

默认：6岁进入老年代，最大可设置为15。

适用场景：几G到几十G的堆内存

执行思路：初始标记STW只标记Root，然后与业务线程并行执行垃圾标记，进入重新标记阶段STW检查错标。并发清除垃圾。

三色标记：黑色(对象完全被扫描完,不会再次被扫描)、灰色(对象的引用未扫描完)、白色(默认颜色，最后的白色为没有被引用的对象，将被回收)。

重标记阶段：解决错误标记，必须STW，是CMS最耗时阶段。比如 初始对象引用关系 ：A-->B-->C  ，A标记为黑色后开始扫描B的瞬间：引用关系转换为 A-->C ,A-->B。B下扫描不到C，且A为黑色也不会再次被扫描， 此时C将不会被扫描到，C错标为白色待清除。 

优点：STW时间短，有不错的吞吐量。

缺点：1、每次都扫描整个堆。

           2、因为标记清除算法不进行整理，所以存在碎片化问题，只能依靠FULLGC整理。触发(FULLGC)SerialOld单线程STW整理碎片，耗时巨大。见下文 promotion failed 、concurrent mode failure。可以手动触发FULLGC整理或重启解决碎片(推荐无业务时间执行)。

主要调优参数：STW优化、触发阈值、碎片压缩==》缩短STW，控制频率，避免OLD担保或转移失败引发FULLGC

//触发CMS相关配置：
-XX:+UseCMSInitiatingOccupancyOnly              //自定义CMS触发阈值
-XX:CMSInitiatingOccupancyFraction=68           //老年代占用68%(默认值)时，CMS开始回收老年代。如果经常出现因老年代空间不足或分担担保失败引起FULLGC，建议调小此值，提前CMS回收老年代，增加CMS回收频率。

//碎片压缩
-XX:+UseCMSCompactAtFullCollection                   //默认开启，FULLGC对年老代的压缩。(解决碎片)
-XX:CMSFullGCsBeforeCompaction=5                    //(0默认=每次都整理压缩)上面配置开启的情况下，这里设置多少次FullGC后，对年老代进行整理压缩。避免老年代因碎片而空间不足，CMS无法整理压缩碎片只能通过FullGC。

//STW优化，CMS主要在两次标记阶段STW
-XX:+CMSParallelInitialMarkEnabled                //初始标记阶段并行执行(默认是串行)
-XX:+CMSScavengeBeforeRemark                  //CMS执行前先ygc，减少重标记阶段用时

-XX:ConcGCThreads 或者 -XX:ParallelCMSThreads  //除了上面设置线程的方式，你也可以通过这个两个参数任意一个手工设定 CMS 并发线程数。

-XX:+CMSClassUnloadingEnabled                  //CMS可清理持久代，移除不再使用的class

 

G1 GC

https://blog.csdn.net/coderlius/article/details/79272773

简单原理解说：https://www.bilibili.com/video/BV13J411g7A1

马士兵：https://www.bilibili.com/video/BV1EJ411V7id

优化：

https://www.cnblogs.com/yunxitalk/p/8987318.html

https://blog.csdn.net/j3T9Z7H/article/details/100111287

JDK1.7加入JVM，1.9成为默认垃圾回收器。G1将整个堆内存分割成2048(默认)个块。每次只清理垃圾较多的区域，有更加短的STW时间，吞吐量稍稍低于CMS(可提升硬件弥补)。使用三色标记法。

适用场景：1.8或以上JDK版本，几G到上百G的堆内存，对响应时间有苛刻要求的业务。

流程：初始标记root(stw) -> 并发标记 ->最终标记(stw) ->复制回收(标记复制法)。与CMS如出一辙。

复制回收：当前区域标记的非垃圾对象复制到新的空区域，清除当前区域垃圾，不存在碎片化问题。而且时间可控，最多可分八次执行。

优点：

    1、使用标记复制算法，减少碎片化问题。

    2、可配置的STW预期时间。区域间独立适合并发清理。

    3、配置参数少，调优简单。

    4、优先回收垃圾比例高区域。不会扫描整个堆，适合超大内存。

缺点：

    1、每次不是清除所有垃圾，有内存浪费

主要调优参数：https://blog.csdn.net/qq_27529917/article/details/87072130

常用调优参数：STW优化、触发阈值、转移预留 ==》缩短STW，控制频率，避免OLD担保或转移失败引发FULLGC

        - 不要手工指定年轻代/老年代大小，让G1自己调节就可以。

-XX:ParallelGCThreads STW期间，并行GC线程数，加快执行效率。

-XX:ConcGCThreads=n  并发标记阶段，并行执行的线程数。

-XX:MaxGCPauseMillis  设置G1收集过程目标停顿时间，默认值200ms 。设置的太小会影响回收效率。

-XX:G1ReservePercent  老年代为对象转移预留空间。默认值是10%，如果GC日志出现对象晋升失败"to-space exhausted"和“Evacuation Failure”，触发FULLGC，可调大预留比例。

-XX:InitiatingHeapOccupancyPercent  设置触发标记周期的堆占用率阈值，默认值是45%。适当调小阈值，可以减少因老年代不足导致对象转移失败或分担担保失败造成FULLGC，调小会增加标记周期和回收的频率，不要过小。

 

CMS VS G1

https://club.perfma.com/article/138044

 

FULL GC

FULLCG是对新生代，旧生代，以及持久代的统一回收，STW时间长。系统中应当尽量减少或避免出现FULLGC。也是JVM调优的重点之一。他不是上面提到的任何一种GC，所有带有“FullCollection”字样的VM参数都是跟真正的full GC相关。

如下几种情况下会发生FullGC：

《持久代空间不足

《老年代空间不足  （注意：CMS/G1是到达阈值时触发，FullGC是空间不足时触发。尽可能避免此情况。）

《CMS GC时出现了promotion failed和concurrent mode failure，老年代不足，对象晋升失败

《G1  GC时出现"to-space exhausted"和“Evacuation Failure”，老年代不足，对象晋升失败

《统计得到新生代minor gc时晋升到老年代的平均大小小于老年代剩余空间（老年代不足，分担担保失败）

《直接调用System.gc，可以DisableExplicitGC来禁止

《存在rmi调用时，默认会每分钟执行一次System.gc，可以通过-Dsun.rmi.dgc.server.gcInterval=3600000来设置大点的间隔。

 

项目实例

截取的同一时段eden，s，old三个区域的变化。为观察提前执行了FULLCG。曲线图比较直观，但是生产环境推荐看GC日志能清楚地知道执行了哪种GC。

13：18 并发任务开始后eden区开始猛增。13：19前触发一次YGC后eden区内存使用量下降，s区内存使用量基本到顶。同时老年代使用量逐步提高，应该是s区不足导致部分对象提前提升。

13：20 触发一次YGC。随后20秒左右s区内存基本清空。应该是YGC后s区内存不够用，或是s区同代过半 ，所以直接晋升到老年代。

此时老年代也出发GC阈值执行了GC。

 

 

调优建议

基本步骤：打印GC日志、通过日志分析项目吞吐量+STW、分析GC原因

GC日志分析工具：GCeasy网站、GcViewer(github) 有助于分析GC原因、并提出优化意见

GcViewer：https://www.cnblogs.com/o-andy-o/p/4058271.html  https://blog.csdn.net/u013213157/article/details/74687028

日志格式设置：

设置日志名规则，滚动日志，最多5个文件，每个20M，打印时间戳.....这样设置可以控制只保留最近的5个GC日志文件，总大小不超过100M。

 

若JVM内存出现问题，首先考虑分析内存dump->hprof文件信息

代码调优优先参数调优，根本是找到代码问题，JVM调优只是最终手段

常见内存溢出OOM：堆溢出(dump检查)；metadata溢出(Class加载过多）；栈总内存溢出(可能Thread过多，默认栈1m)；单线程栈溢出(递归太深，方法栈帧太多) 等

设置-XX:+HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=/path/heap/dump

dump内存对比，推荐使用MAT，定位占用内存的 大对象或数量异常对象，

加大虚拟机内存，调整内存分配比例，检查引用释放问题(数组，容器，TL)，检查局部变量（单线程栈溢出 ）

外部内存溢出：IO链接创建未关闭。IO会使用jvm外的物理内存。系统的IO内核先把内容缓存到系统内存中在拷贝到JVM系统中。TCP链接等最好用连接池，可以限制创建连接总数，同时减少握手带来的消耗。

Minor/Full GC频繁：(分别低于10s/10分钟一次,仅参考)

有无异常占用或是碎片：

dump内存对比gc前后，哪些对象一直不能被GC，哪些增长过于迅速。

检查引用释放问题。

减少大对象/数组等创建（复用、及时释放）

容量过小：

提高对应年代的内存容量。或调整年轻代老年代比例。

（年轻代太小会造成频繁MinorGC，导致更多对象进入老年代，导致频繁Full GC）

Minor/Full GC STW时间过长：（勇士超过50ms/1s,仅参考）

改变GC策略（CMS 最小停顿/G1 吞吐量大适合4g以上堆内存）。

堆内存可能过大，可适当缩小堆，

或集群、分布式处理，减少单进程堆大小且保证并发量

总结：

推荐上线前进行压力测试，调优jvm参数。

1、减少使用、创建全局变量和大对象，多复用减少new()，并及时释放 = null；（例如：方法很长，中途有不用的大对象，请赋值 null）

2、调整新生代/s区/老年代的大小到最合适比例；

3、减少因S区不足、同年过半等情况，直接晋升老年代。

4、选择合适的GC收集器，并进行针对调优；

5、搭建集群、微服务拆分，减少单jvm压力。

      而且业务应用上下线/替换更灵活，即使宕机/重启某个jvm也能保证整个系统高可用。

6、重启。在集群/分布式架构中，保证高可用前提下，可以重启单个jvm实例。

7、使用外部缓存Redis。

8、业务冷门时间，手动执行FULLGC。

 

简单例子：

使用-Xmn调到1/3 总内存，避免年轻代过大，gc时间长。(用-XX:NewRatio设置可能无效，用 -Xmn)。

添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小，调整进入老年代年龄-XX:MaxTenuringThreshold。

-Xms -Xmx,最大最小值设置相同，防止垃圾收集器收缩堆产生额外开销

架构方面调优

使用集群/分布式微服务框架。减少单机的内存压力，减少单机对整个系统的影响，可以灵活的上线下线单个JVM实例，同时也保证了业务的高可用性和吞吐量。即使最极端的情况某一个JVM需要安全下线、宕机、重启，其他JVM服务也能保证整个系统的可用性。

 

使用堆外内存

原文：https://www.cnblogs.com/z-sm/p/6235157.html

使用对外内存的原因：

• 对垃圾回收停顿的改善。由于堆外内存是直接受操作系统管理而不是JVM，所以当我们使用堆外内存时，即可保持较小的堆内内存规模。从而在GC时减少回收停顿对于应用的影响。
• 提升程序I/O操作的性能。通常在I/O通信过程中，会存在堆内内存到堆外内存的数据拷贝操作，对于需要频繁进行内存间数据拷贝且生命周期较短的暂存数据，都建议存储到堆外内存。

 

网络借鉴的调优总结

https://www.cnblogs.com/lcword/p/5857918.html

年轻代大小选择

 

• 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
• 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

年老代大小选择

• 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得： 减少年轻代和年老代花费的时间，一般会提高应用的效率
  • 并发垃圾收集信息
  • 持久代并发收集次数
  • 传统GC信息
  • 花在年轻代和年老代回收上的时间比例
• 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

 

较小堆引起的碎片问题

因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回 收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空 间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：

 

• -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
• -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩
•  

使用CMS垃圾收集器产生promotion failed –> concurrent mode failure

https://blog.csdn.net/21aspnet/article/details/88772421

CMS并行GC是大多数应用的最佳选择，然而， CMS并不是完美的，在使用CMS的过程中会产生2个最让人头痛的问题：

1. promotion failed
2. concurrent mode failure

第一个问题promotion failed 是在进行Minor GC时，Survivor Space放不下，对象只能放入老年代，而此时老年代也放不下造成的，多数是由于老年带有足够的空闲空间，但是由于碎片较多，这时如果新生代要转移到老年带的对象比较大，所以，必须尽可能提早触发老年代的CMS回收来避免这个问题（promotion failed时老年代CMS还没有机会进行回收，又放不下转移到老年带的对象，因此会出现下一个问题concurrent mode failure，需要stop-the-wold GC- Serail Old）。

下面是一个promotion failed的一条gc日志：

106.641: [GC 106.641: [ParNew (promotion failed): 14784K->14784K(14784K), 0.0370328 secs]106.678: [CMS106.715: [CMS-concurrent-mark: 0.065/0.103 secs] [Times: user=0.17 sys=0.00, real=0.11 secs]
(concurrent mode failure): 41568K->27787K(49152K), 0.2128504 secs] 52402K->27787K(63936K), [CMS Perm : 2086K->2086K(12288K)], 0.2499776 secs] [Times: user=0.28 sys=0.00, real=0.25 secs]

第二个问题concurrent mode failure 是在执行CMS GC的过程中同时业务线程将对象放入老年代，而此时老年代空间不足，这时CMS还没有机会回收老年带产生的，或者在做Minor GC的时候，新生代救助空间放不下，需要放入老年代，而老年代也放不下而产生的。尽管CMS使用一个叫做分配担保的机制，每次Minor GC之后要保证新生代的空间survivor + eden > 老年带的空闲时间，但是对象分配是不可预测的，总会有写对象分配在老年带是满足不了的。

下面是一个concurrent mode failure的一条gc日志：

0.195: [GC 0.195: [ParNew: 2986K->2986K(8128K), 0.0000083 secs]0.195: [CMS0.212: [CMS-concurrent-preclean: 0.011/0.031 secs] [Times: user=0.03 sys=0.02, real=0.03 secs]
(concurrent mode failure): 56046K->138K(57344K), 0.0271519 secs] 59032K->138K(65472K), [CMS Perm : 2079K->2078K(12288K)], 0.0273119 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]

首先我们经常遇到promotion failed问题，这也确实是个很头痛的问题，一般是进行Minor GC的时候，发现救助空间不够，所以，需要移动一些新生带的对象到老年带，然而，有些时候尽管老年带有足够的空间，但是由于CMS采用标记清除算法，默认并不使用标记整理算法，可能会产生很多碎片，因此，这些碎片无法完成大对象向老年带转移，因此需要进行CMS在老年带的Full GC来合并碎片。

这个问题的直接影响就是它会导致提前进行CMS Full GC, 尽管这个时候CMS的老年带并没有填满，只不过有过多的碎片而已，但是Full GC导致的stop-the-wold是难以接受的。

解决这个问题的办法就是可以让CMS在进行一定次数的Full GC（标记清除）的时候进行一次标记整理算法，CMS提供了以下参数来控制：

-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCBeforeCompaction=5

也就是CMS在进行5次Full GC（标记清除）之后进行一次标记整理算法，从而可以控制老年带的碎片在一定的数量以内，甚至可以配置CMS在每次Full GC的时候都进行内存的整理。

另外，有些应用存在比较大的对象朝生熄灭，这些对象在救助空间无法容纳，因此，会提早进入老年带，老年带如果有碎片，也会产生promotion failed, 因此我们应该控制这样的对象在新生代，然后在下次Minor GC的时候就被回收掉，这样避免了过早的进行CMS Full GC操作，下面的一个配置样例就通过增加救助空间的大小来解决这个问题：

-Xmx4000M -Xms4000M -Xmn600M -XXmSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled eCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

上面讨论了promotion failed引起的原因以及解决方案，除了promotion failed还有一个情况会引起CMS回收失败，从而退回到Serial Old收集器进行回收，我们在线上尤其要注意的是concurrent mode failure出现的频率，这可以通过-XX:+PrintGCDetails来观察，当出现concurrent mode failure的现象时，就意味着此时JVM将继续采用Stop-The-World的方式来进行Full GC，这种情况下，CMS就没什么意义了，造成concurrent mode failure的原因是当minor GC进行时，旧生代所剩下的空间小于Eden区域+From区域的空间，或者在CMS执行老年带的回收时有业务线程试图将大的对象放入老年带，导致CMS在老年带的回收慢于业务对象对老年带内存的分配。

解决这个问题的通用方法是调低触发CMS GC执行的阀值，CMS GC触发主要由CMSInitiatingOccupancyFraction值决定，默认情况是当旧生代已用空间为68%时，即触发CMS GC，在出现concurrent mode failure的情况下，可考虑调小这个值，提前CMS GC的触发，以保证旧生代有足够的空间。

总结：

1. promotion failed –> concurrent mode failure

Minor GC后， Survivor Space容纳不了剩余对象，将要放入老年带，老年带有碎片或者不能容纳这些对象，就产生了concurrent mode failure, 然后进行stop-the-world的Serial Old收集器。

解决办法：-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCBeforeCompaction=5（CMS一定频率执行标记整理法） 或者 调大新生代或者救助空间

2. concurrent mode failure

CMS是和业务线程并发运行的，在执行CMS的过程中有业务对象需要在老年带直接分配，例如大对象，但是老年代没有足够的空间来分配，所以导致concurrent mode failure, 然后需要进行stop-the-world的Serial Old收集器。

解决办法：+XX:CMSInitiatingOccupancyFraction(调低触发CMS GC执行的阀值,提前触发GC)，调大老年带的空间，+XX:CMSMaxAbortablePrecleanTime

总结一句话：使用标记整理清除碎片和提早进行CMS GC操作。

检查工具

当堆非常大几个G时，dump会让jvm进程停止超长时间。推荐不要在线上直接堆dump。把问题进程通过Nginx做主备替换/分布式环境安全下线后，再执行dump。

Arthas 

全方位监控和检测工具，极力推荐。

使用指南：https://alibaba.github.io/arthas/

显示线程的CPU使用率。检测GC频率和效果，堆内存下降则发生了GC。

GC日志分析

GCeasy网站、GcViewer(github) 有助于分析GC原因、并提出优化意见

GcViewer：

要查看GC日志首先要知道GC的log放在哪里，使用jps命令查看当前有哪些java进程在运行，找到我们要查看的java程序的进程pid。使用命令jinfo pid 来查看这个进程对应的java 信息，可以看到大概在最下面的地方有个参数-Xloggc:，他对应的就是gc log的位置

https://www.cnblogs.com/o-andy-o/p/4058271.html  

https://blog.csdn.net/u013213157/article/details/74687028

http://cmsblogs.com/?p=3817

https://www.bilibili.com/video/av52674111/?p=31

GcViewer几个关键值：吞吐量(推荐达到90%以上)、FullGC次数、FullGC用时占比、各GC最大/平均pause时间、GC间隔时间

配置GC日志

对应的参数列表

-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xloggc:../logs/gc.log 日志文件的输出路径

设置日志名规则，滚动日志，最多5个文件，每个20M，打印时间戳.....这样设置可以控制只保留最近的5个GC日志文件，总大小不超过100M。

Eclipse Memory Analysis Tools (MAT内存泄漏 ->OOM)

https://cloud.tencent.com/developer/article/1361381

https://www.bilibili.com/video/av52674111/?p=7

官网下载安装后是一个单独的Eclipse程序，MAT可以分析heapdump[hprof]文件，分析可疑的问题对象，找到占用最大内存的对象类型，定位到其保存的引用，找到未释放的引用。若堆文件过大需要调整mat的Xmx配置，否则报错。其最主要是图中标注的两项功能。

Leak Suspects报告中会给出OOM可能诱因

MAT按内存占用比例查找

比如发现User对象占用异常，右键分析其GCROOTS。

 

分析结果，找到大量User对象强引用存在于MemoryController.userList中未被释放

MAT按照对象数量查找

同样可以右键分析

 

Linux Top

排查定位占用CPU/内存异常   的JAVA进程ID和JAVA线程ID

top 找到进程7930占用CPU异常

top 打印进程7930的线程占用情况，进程7930中前四个线程占用cpu较高。

此处线程PID对应jstack的线程dump文件中的nid=0x2037 (10-16进制转化)。可以直接定位线程dump文件中的问题所在。

 

Jstack -l ${PID} （线程dump -l 打印锁信息）

jps/top 查看java程序PID。

打印进程7930的线程dump到txt文件，并下载到本地。SecureCRT作为Linux客户端为例。

查看线程状态，检查使线程阻塞/等待的方法，并找到死锁的对应线程。

可以看到线程处于阻塞状态 at org.apache.lucene.index.IndexWriter.commit方法中，其在等待锁 waiting to lock <0x000000072039ce18> 。其已经拿到的锁locked <0x0000000711ab59c8>。通过期等待可以找到对应的持锁线程，看其停留在哪个方法里，导致不能释放锁。

"Thread-33" prio=10 tid=0x00002aaac8013000 nid=0x3264 waiting for monitor entry [0x00000000437e4000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3525)
        - waiting to lock <0x000000072039ce18> (a java.lang.Object)
        at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3505)
        at com.xiaomi.miliao.mt.fulltextindex.UserIndexUpdater.updatePlUserIndex(UserIndexUpdater.java:229)
        - locked <0x0000000711ab59c8> (a java.lang.Object)
        at com.xiaomi.miliao.mt.fulltextindex.SearcherDelegate.updatePlUserIndex(SearcherDelegate.java:522)
        at 

一般在线程dump文件结尾会有deadlock分析

 

VisualVM (堆dump,大内存对象检查,线程dump+死锁)

可以查看对象的成员变量，和他被哪些外部对象引用。排查未被释放的原因，但是其没有MAT直观，不利于反向推导问题引用。 

线程dump与Jstack相同，死锁分析会在最后显示

cpu抽样器：动态实时检查方法/线程 总用时和占用CPU时间

内存抽样器：动态实时检查各类型对象/线程占用内存情况

jconsole（监控内存中各个区使用状况和GC频率,检查Thread死锁）

如图堆内存下降，必然是发生了GC