现在很多线上服务器会使用CMS+ParNew的结合来进行垃圾回收，这对于需要低延迟的应用通常是一个较好的选择，但是CMS在使用过程中可能会遇到两个严重问题: 晋升失败、并发模式失效。

当你遇到这两个问题中的任意一个时，jvm会开始进行单线程的full gc，这意味着这段时间内业务线程会被暂停无法工作（这叫做STW），而这通常会持续几秒甚至十几秒，这对于需要低延迟的web等应用显然是无法接受的。下面就来聊聊这两种问题的发生及解决方案。

并发模式失效

当遇到并发模式失效的问题时，你会在gc日志中看到concurrent mode failure的字样：

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]

并发模式失效一般是在执行CMS GC的过程中业务线程将对象放入老年代，而此时老年代空间不足而产生的。此时jvm会放弃使用并发的CMS GC，转而采用单线程的full GC。

此问题的解决比较简单，只要配置jvm参数-XX:CMSInitiatingOccupancyFraction为一个较低的数值即可（默认值68），这个参数用于控制老年代内存占用达到多少百分比时开始进行CMS GC，调低这个参数可以让CMS提前开始GC，从而让老年代有足够空间容纳对象，配置时需要配合-XX:+UseCMSInitiatingOccupancyOnly强制生效。

晋升失败

当遇到并发模式失效的问题时，你会在gc日志中看到promotion failed的字样：

2019-05-17T11:33:00.929+0800: 347318.539: [GC (Allocation Failure) 2019-05-17T11:33:00.929+0800: 347318.539: [ParNew (promotion failed): 2149319K->2142454K(3145728K), 0.9624688 secs]2019-05-17T11:33:01.892+0800: 347319.501: [CMS: 2890954K->263787K(4194304K), 2.1415182 secs] 5040165K->263787K(7340032K), [Metaspace: 107948K->107948K(1146880K)], 3.1043123 secs] [Times: user=3.30 sys=0.00, real=3.10 secs]

该问题是在进行Minor GC时，部分对象需要晋升到老年代，而此时老年代虽然空间足够，但是由于内存碎片问题，导致找不到一块连续空间放下晋升的对象而导致的。CMS GC采用的是标记-清除算法，所以容易造成内存碎片问题，解决此办法的的一个思路是调低-XX:CMSInitiatingOccupancyFraction参数，让CMS尽早开始回收，但这个方法并不总能奏效。
目前网上有非常多误导人的资料（笔者就入坑了），这里引述网上一段错误的资料：

解决这个问题的办法就是可以让CMS在进行一定次数的Full GC（标记清除）的时候进行一次标记整理算法，CMS提供了以下参数来控制：
-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCBeforeCompaction=N（这里N代表数字）
也就是CMS在进行N次Full GC（标记清除）之后进行一次标记整理算法，从而可以控制老年代的碎片在一定的数量以内，甚至可以配置CMS在每次Full GC的时候都进行内存的整理（即配置N=0）。

笔者在实践的时候配置了如上两个参数，结果仍然会出现promotion failed的问题，在疑惑之下笔者只能进入openjdk源码寻找真相。笔者这里就不贴源码了，直接说结论：
上面那段错误资料中有些地方还是说的对的，解决碎片问题，最好的办法就是触发标记整理算法，但是-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCBeforeCompaction=N这两个参数配置并不是控制每隔N次CMS GC触发一次整理，而是用来控制每隔N次Full GC触发一次整理（这里的Full GC是指单线程的Full GC，在openjdk源码里称为Foreground CMS GC，而通常的并发CMS GC在openjdk源码里命名为Background CMS GC），所以这两个参数其实有点鸡肋，我的应用已经因为晋升失败而触发了Full GC，就算Full GC之后碎片消除了又怎么样呢？长暂停已经出现了，经过数次CMS GC之后内存碎片又会出现，又会出现晋升失败而触发Full GC的问题！

从这看起来我们已经进入了一个怪圈，这个问题好像无解了。其实还有出路，笔者这里介绍一个解决此问题的偏方（据说阿里也在使用）：
思路就是除了配置-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0这两个参数之外（其实这两个参数默认值就是这样的，表示每次触发FullGC时压缩堆，可以不用配置），还要在每天业务低峰期（比如凌晨三点时）手动调用代码System.gc()，这样可以强制触发一次Full GC，从而触发标记整理，消除内存碎片（要让System.gc()生效，要注意不能有-XX:+DisableExplicitGC这个jvm参数，这个参数的作用是禁止在代码中调用System.gc()）。 如果你们的应用要求比较严格，任何时候都不能容忍Full GC带来的长暂停，你可以在调用System.gc()之前先把本机流量摘掉，gc完成后再重新接入流量，当然这还要求集群中的多台服务器不能在同一时刻同时触发GC，这可以通过给定时任务增加随机延迟或者采用分布式锁等方法实现。
笔者信心满满地把代码发到线上，然而过了几天，晋升失败的问题又出现了，只能一脸懵逼继续排查，研究一番后我注意到我们应用有这样一个jvm参数：-XX:+ExplicitGCInvokesConcurrent，查询资料得知这个参数只对System.gc()生效，这个参数存在时，调用System.gc()实际触发的是并发CMS，这个参数不存在时，调用System.gc()实际触发的是单线程的Full GC，看来就是它了，于是去除此参数后重新发布，问题解决！

笔者感悟：JVM很难，网上错误的观点很多，读者需要有自己的判断。