CMS
CMS，全称Concurrent Low Pause Collector，是jdk1.4后期版本开始引入的新gc算法，在jdk5和jdk6中得到了进一步改进，它的主要适合场景是对响应时间的重要性需求大于对吞吐量的要求，能够承受
垃圾回收线程和应用线程共享处理器资源
，并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收，也就是
年老代的回收
，目标是尽量减少应用的暂停时间，减少full gc发生的几率，
利用和应用程序线程并发的垃圾回收线程
来标记清除年老代。在我们的应用中，因为有缓存的存在，并且对于响应时间也有比较高的要求，因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器，以便获得更短的垃圾回收的暂停时间，提高程序的响应性。
CMS并非没有暂停，而是用
两次短暂停
来替代串行标记整理算法的长暂停，它的收集周期是这样：
初始标记
(CMS-initial-mark) ->
并发标记
(CMS-concurrent-mark) ->
重新标记
(CMS-remark) ->
并发清除
(CMS-concurrent-sweep) ->并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。
其中的1，3两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象开始标记存活的对象，这个阶段称为初始标记；第二次暂停是在并发标记之后，暂停所有应用程序线程，重新标记并发标记阶段遗漏的对象（在并发标记阶段结束后对象状态的更新导致）。第一次暂停会比较短，第二次暂停通常会比较长，并且remark这个阶段可以并行标记。
而并发标记、并发清除、并发重设阶段的所谓并发，是指
一个或者多个垃圾回收线程和应用程序线程并发地运行
，垃圾回收线程不会暂停应用程序的执行，如果你有多于一个处理器，那么并发收集线程将与应用线程在不同的处理器上运行，显然，这样的开销就是会降低应用的吞吐量。Remark阶段的并行，是指暂停了所有应用程序后，启动一定数目的垃圾回收进程进行并行标记，此时的应用线程是暂停的。
CMS的young generation的回收采用的仍然是并行复制收集器，这个跟Paralle gc算法是一致的。
下面是参数介绍和遇到的问题总结，
1、启用CMS：-XX:+UseConcMarkSweepGC。 咳咳，这里犯过一个低级错误，竟然将+号写成了-号
2。CMS默认启动的回收线程数目是 (ParallelGCThreads + 3)/4) ，如果你需要明确设定，可以通过-XX:ParallelCMSThreads=20来设定,其中ParallelGCThreads是年轻代的并行收集线程数
3、CMS是不会整理堆碎片的，因此为了防止堆碎片引起full gc，通过会开启CMS阶段进行合并碎片选项：-XX:+UseCMSCompactAtFullCollection，开启这个选项一定程度上会影响性能，阿宝的blog里说也许可以通过配置适当的CMSFullGCsBeforeCompaction来调整性能，未实践。
4.为了减少第二次暂停的时间，开启并行remark: -XX:+CMSParallelRemarkEnabled，如果remark还是过长的话，可以开启-XX:+CMSScavengeBeforeRemark选项，强制remark之前开始一次minor gc，减少remark的暂停时间，但是在remark之后也将立即开始又一次minor gc。
5.为了避免Perm区满引起的full gc，建议开启CMS回收Perm区选项：
+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
6.默认CMS是在tenured generation沾满68%的时候开始进行CMS收集，如果你的年老代增长不是那么快，并且希望降低CMS次数的话，可以适当调高此值：
-XX:CMSInitiatingOccupancyFraction=80
这里修改成80%沾满的时候才开始CMS回收。
7.年轻代的并行收集线程数默认是(ncpus <=
? ncpus : 3 + ((ncpus * 5) /
，如果你希望设定这个线程数，可以通过-XX:ParallelGCThreads= N 来调整。
8.进入重点，在初步设置了一些参数后，例如：
-server -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=64m
-XX:MaxPermSize=64m -XX:-UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSParallelRemarkEnabled
-XX:SoftRefLRUPolicyMSPerMB=0
需要在生产环境或者压测环境中测量这些参数下系统的表现，这时候需要打开GC日志查看具体的信息，因此加上参数：
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/home/test/logs/gc.log
在运行相当长一段时间内查看CMS的表现情况，CMS的日志输出类似这样：
4391.322: [GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user=0.02 sys=0.02, real=0.03 secs]
4391.352: [CMS-concurrent-mark-start]
4391.779: [CMS-concurrent-mark: 0.427/0.427 secs] [Times: user=1.24 sys=0.31, real=0.42 secs]
4391.779: [CMS-concurrent-preclean-start]
4391.821: [CMS-concurrent-preclean: 0.040/0.042 secs] [Times: user=0.13 sys=0.03, real=0.05 secs]
4391.821: [CMS-concurrent-abortable-preclean-start]
4392.511: [CMS-concurrent-abortable-preclean: 0.349/0.690 secs] [Times: user=2.02 sys=0.51, real=0.69 secs]
4392.516: [GC[YG occupancy: 111001 K (235968 K)]4392.516: [Rescan (parallel) , 0.0309960 secs]4392.547: [weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user=0.17 sys=0.00, real=0.09 secs]
4392.609: [CMS-concurrent-sweep-start]
4394.310: [CMS-concurrent-sweep: 1.595/1.701 secs] [Times: user=4.78 sys=1.05, real=1.70 secs]
4394.310: [CMS-concurrent-reset-start]
4394.364: [CMS-concurrent-reset: 0.054/0.054 secs] [Times: user=0.14 sys=0.06, real=0.06 secs]
其中可以看到CMS-initial-mark阶段暂停了0.0303050秒，而CMS-remark阶段暂停了0.0932010秒，因此两次暂停的总共时间是0.123506秒，也就是123毫秒左右。两次短暂停的时间之和在200以下可以称为正常现象。
但是你很可能遇到两种fail引起full gc：Prommotion failed和Concurrent mode failed。
Prommotion failed的日志输出大概是这样：
[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K->1120688K(
2166784K), 9.2214860 secs] 1458785K->1120688K(2520704K), 9.4584090 secs]
这个问题的产生是由于救助空间不够，从而向年老代转移对象，年老代没有足够的空间来容纳这些对象，导致一次full gc的产生。解决这个问题的办法有两种完全相反的倾向：增大救助空间、增大年老代或者去掉救助空间。增大救助空间就是调整-XX:SurvivorRatio参数，这个参数是Eden区和Survivor区的大小比值，默认是32，也就是说Eden区是Survivor区的32倍大小，要注意Survivo是有两个区的，因此Surivivor其实占整个young genertation的1/34。调小这个参数将增大survivor区，让对象尽量在survitor区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio 设置成比较大的值（比如65536)来做到。在我们的应用中，将young generation设置成256M，这个值相对来说比较大了，而救助空间设置成默认大小(1/34)，从压测情况来看，没有出现prommotion failed的现象，年轻代比较大，从GC日志来看，minor gc的时间也在5-20毫秒内，还可以接受，因此暂不调整。
Concurrent mode failed的产生是由于CMS回收年老代的速度太慢，导致年老代在CMS完成前就被沾满，引起full gc，避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值，让CMS更早更频繁的触发，降低年老代被沾满的可能。我们的应用暂时负载比较低，在生产环境上年老代的增长非常缓慢，因此暂时设置此参数为80。在压测环境下，这个参数的表现还可以，没有出现过Concurrent mode failed。
CMS垃圾回收器周期
一旦young的空间大小（包含eden和survivor空间）已经完善得满足应用对MinorGC产生延迟要求，注意力可以转移到优化CMS垃圾回收器，降低最差延迟时间的时间长度以及最小化最差延迟的频率。目标是保持可用的old代空间和并发垃圾回收，避免stop-the-world压缩垃圾回收。
stop-the-world压缩垃圾回收是垃圾回收影响延迟的最差情况，对某些应用来说，恐怕无法完全避免开这些，但是本节提供的优化信息至少可以减少他们的频率。
成功的优化CMS垃圾回收器需要达到的效果是old代的里面的垃圾回收的效率要和young代转移对象到old代的效率相同，没有能够完成这个标准可以称为“比赛失败”，比赛失败的结果就是导致stop-the-world压缩垃圾回收。不比赛中失败的一个关键是让下面两个事情结合起来：1、old代有足够的空间。2、启动CMS垃圾回收周期开始时机——快到回收对象的速度比较转移对象来的速度更快。
CMS周期的启动是基于old代的空间大小的。如果CMS周期开始的太晚，他就会输掉比赛，没有能够快速的回收对象以避免溢出old代空间。如果CMS周期开始得太早，会造成不必要的压力以及影响应用的吞吐量。但是，通常来讲过早的启动总比过晚的启动好。
HotSpot VM自动地计算出当占用是多少时启动CMS垃圾回收周期。不过在一些场景下，对于避免stop-the-world垃圾回收，他做得并不好。如果观察到stop-the-world垃圾回收，你可以优化该什么时候启动CMS周期。在CMS垃圾回收中，stop-the-world压缩垃圾回收在垃圾回收日志中输出是“concurrent mode failure”，下面一个例子：
174.445: [GC 174.446: [ParNew: 66408K->66408K(66416K), 0.0000618
secs]174.446: [CMS (
concurrent mode failure
): 161928K->162118K(175104K),
4.0975124 secs] 228336K->162118K(241520K)
如果你发现有concurrent mode failure你可以通过下面这个选项来控制什么时候启动CMS垃圾回收：
命令行代码
- -XX:CMSInitiatingOccupancyFraction=
这个值指定了CMS垃圾回收时old代的空间占用率该是什么值。举例说明，如果你希望old代占用率是65%的时候，启动CMS垃圾回收，你可以设置-XX:CMSInitiatingOccupancyFraction=65。另外一个可以同时使用的选项是
命令行代码
- -XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseCMSInitiatingOccupancyOnly指定HotSpot VM总是使用-XX:CMSInitiatingOccupancyFraction的值作为old的空间使用率限制来启动CMS垃圾回收。如果没有使用-XX:+UseCMSInitiatingOccupancyOnly，那么HotSpot VM只是利用这个值来启动第一次CMS垃圾回收，后面都是使用HotSpot VM自动计算出来的值。
-XX:CMSInitiatingOccupancyFraction=这个指定的值，应该比垃圾回收之后存活对象的占用率更高，怎么样计算存活对象的大小前面在“决定内存占用”的章节已经说过了。如果不比存活对象的占用量大，CMS垃圾回收器会一直运行。通常的建议是-XX:CMSInitiatingOccupancyFraction的值应该是存活对象的占用率的1.5倍。举例说明一下，假如用下面的Java堆选项配置：
命令行代码
- -Xmx1536m -Xms1536m -Xmn512m
那么old代的空间大小是1024M（1536-512 = 1024m）。如果存活对象的大小是350M的话，CMS垃圾回收周期的启动阀值应该是old代占用空间是525M，那么占用率就应该是51%（525/1024=51%），这个只是初始值，后面还可能根据垃圾回收日志进行修改。那么修改后的命令行选项是：
命令行代码
- -Xmx1536m -Xms1536m -Xmn512m -XX:+UseCMSInitiatingOccupancyOnly
- -XX:CMSInitiatingOccupancyFraction=51
该多早或者多迟启动CMS周期依赖于对象从young代转移到old代的速率，也就是说，old代空间的增长率。如果old代填充速度比较缓慢，你可以晚一些启动CMS周期，如果填充速度很快，那么就需要早一点启动CMS周期，但是不能小于存活对象的占用率。如果需要设置得比存活对象的占用率小，应该是增加old代的空间。
想知道CMS周期是开始的太早还是太晚，可以通过评估垃圾回收信息识别出来。下面是一个CMS周期开始得太晚的例子。为了更好阅读，稍微修改了输出内容：
[ParNew 742993K->648506K(773376K), 0.1688876 secs]
[ParNew 753466K->659042K(773376K), 0.1695921 secs]
[CMS-initial-mark 661142K(773376K), 0.0861029 secs]
[Full GC 645986K->234335K(655360K), 8.9112629 secs]
[ParNew 339295K->247490K(773376K), 0.0230993 secs]
[ParNew 352450K->259959K(773376K), 0.1933945 secs]
注意FullGC在CMS-inital-mark之后很快就发生了。CMS-initial-mark是报告CMS周期多个字段中的一个。下面的例子会使用到更多的字段。
下面是一个CMS开始的太早了的情况：
[ParNew 390868K->296358K(773376K), 0.1882258 secs]
[CMS-initial-mark 298458K(773376K), 0.0847541 secs]
[ParNew 401318K->306863K(773376K), 0.1933159 secs]
[CMS-concurrent-mark: 0.787/0.981 secs]
[CMS-concurrent-preclean: 0.149/0.152 secs]
[CMS-concurrent-abortable-preclean: 0.105/0.183 secs]
[CMS-remark 374049K(773376K), 0.0353394 secs]
[ParNew 407285K->312829K(773376K), 0.1969370 secs]
[ParNew 405554K->311100K(773376K), 0.1922082 secs]
[ParNew 404913K->310361K(773376K), 0.1909849 secs]
[ParNew 406005K->311878K(773376K), 0.2012884 secs]
[CMS-concurrent-sweep: 2.179/2.963 secs]
[CMS-concurrent-reset: 0.010/0.010 secs]
[ParNew 387767K->292925K(773376K), 0.1843175 secs]
[CMS-initial-mark 295026K(773376K), 0.0865858 secs]
[ParNew 397885K->303822K(773376K), 0.1995878 secs]
CMS-initial-mark表示CMS周期的开始， CMS-initial-sweep和CMS-concurrent-reset表示周期的结束。注意第一个CMS-initial-mark报告堆大小是298458K，然后注意，ParNew MinorGC报告在CMS-initial-mark和CMS-concurrent-reset之间只有很少的占用量变化，堆的占用量可以通过ParNew的->的右边的数值来表示。在这个例子中，CMS周期回收了很少的垃圾，通过在CMS-initial-mark和CMS-concurrent-reset之间只有很少的占用量变化可看出来。这里正确的做法是启动CMS周期用更大的old代空间占用率，通过使用参数
-XX:+UseCMSInitiatingOccupancyOnly和-XX:CMSInitiatingOccupancyFraction=。基于初始（CMS-initial-mark）占用量是298458K以及Java堆的大小是773376K，就是CMS发生的占用率是35%到40%（298458K/773376K=38.5%），可以使用选项来强制提高占用率的值。
下面是一个CMS周期回收了大量old代空间的例子，而且没有经历stop-the-world压缩垃圾回收，也就没有并发错误（concurrent mode failure）。同样的修改输出格式：
[ParNew 640710K->546360K(773376K), 0.1839508 secs][CMS-initial-mark 548460K(773376K), 0.0883685 secs][ParNew 651320K->556690K(773376K), 0.2052309 secs][CMS-concurrent-mark: 0.832/1.038 secs][CMS-concurrent-preclean: 0.146/0.151 secs][CMS-concurrent-abortable-preclean: 0.181/0.181 secs][CMS-remark 623877K(773376K), 0.0328863 secs][ParNew 655656K->561336K(773376K), 0.2088224 secs][ParNew 648882K->554390K(773376K), 0.2053158 secs][ParNew 489586K->395012K(773376K), 0.2050494 secs][ParNew 463096K->368901K(773376K), 0.2137257 secs][CMS-concurrent-sweep: 4.873/6.745 secs][CMS-concurrent-reset: 0.010/0.010 secs][ParNew 445124K->350518K(773376K), 0.1800791 secs][ParNew 455478K->361141K(773376K), 0.1849950 secs]
在这个例子中，在CMS周期开始的时候，CMS-initial-mark表明占用量是548460K。在CMS周期开始和结束（CMS-concurrent-reset）之间，ParNew MinorGC报告显著的减少了对象的占用量。尤其，在CMS-concurrent-sweep之前，占用量从561336K降低到了368901K。这个表明在CMS周期中，有190M空间被垃圾回收。需要注意的是，在CMS-concurrent-sweep之后的第一个ParNew MinorGC报告的占用量是350518K。这个说明超过190M被垃圾回收（561336K-350518K=210818K=205.88M）。
如果你决定优化CMS周期的启动，多尝试几个不同的old代占用率。监控垃圾回收信息以及分析这些信息可以帮助你做出正确的决定。
强制的垃圾回收
如果你想要观察通过调用System.gc()来启动的FullGC，当使用用CMS的时候，有两种方法来处理这种情况。
1、你可以请求HotSpot VM执行System.gc()的时候使用CMS周期，使用如下命令选项：
命令行代码
- -XX:+ExplicitGCInvokesConcurrent
- 或者
- -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
第一个选项在Java 6及更新版本中能够使用，第二选项在从Java 6 Update 4之后才有。如果可以，建议使用后者。
2、你可以请求HotSpot VM选项忽视强制的调用System.gc()，可以使用如下选项:
命令行代码
- -XX:+DisableExplicitGC
这个选项用来让其他垃圾回收器忽略System.gc()请求。
当关闭的强制垃圾回收需要小心，这样做可能对Java性能产生很大的影响，关闭这个功能就像使用System.gc()一样需要明确的理由。
在垃圾回收日志里面找出明确的垃圾回收信息是非常容易的。垃圾回收的输出里面包含了一段文字来说明FullGC是用于调用System.gc().下面是一个例子:
2010-12-16T23:04:39.452-0600: [Full GC (System)[CMS: 418061K->428608K(16384K), 0.2539726 secs]418749K->4288608K(31168K),[CMS Perm : 32428K->32428K(65536K)],0.2540393 secs][Times: user=0.12 sys=0.01, real=0.25 secs]
注意Full GC后面的（System）标签，这个说明是System.gc()引起的FullGC。如果你在垃圾回收日志里面观察到了明确的FullGC，想想为什么会出现、是否需要关闭、是否需要把应用源代码里面的相关代码删除掉，对CMS垃圾回收周期是否有意义。
并发的Permanent代垃圾回收
FullGC发生可能是由于permanent空间满了引起的，监控FullGC垃圾回收信息，然后观察Permanent代的占用量，判断FullGC是否是由于permanent区域满了引起的。下面是一个由于permanent代满了引起的FullGC的例子:
2010-12-16T17:14:32.533-0600: [Full GC[CMS: 95401K->287072K(1048576K), 0.5317934 secs]482111K->287072K(5190464K),[CMS Perm : 65534K->58281K(65536K)], 0.5319635 secs][Times: user=0.53 sys=0.00, real=0.53 secs]
注意permanent代的空间占用量，通过CMS Perm :标签识别。permanent代空间大小是括号里面的值，65536K。在FullGC之前permanent代的占用量是->左边的值，65534K，FullGC之后的值是58281K。可以看到的是，在FullGC之前，permanent代的占用量以及基本上和permanent代的容量非常接近了，这个说明，FullGC是由Permanent代空间溢出导致的。同样需要注意的是，old代还没有到溢出空间的时候，而且没有证据说明CMS周期启动了。
HotSpot VM默认情况下，CMS不会垃圾回收permanent代空间，尽管垃圾回收日志里面有CMS Perm标签。为让CMS回收permanent代的空间，可以用过下面这个命令选项来做到:
命令行代码
- -XX:+CMSClassUnloadingEnabled
如果使用Java 6 update 3及之前的版本，你必须指定一个命令选项:
命令行代码
- -XX:+CMSPermGenSweepingEnabled
你可以控制permanent的空间占用率来启动CMS permanent代垃圾回收通过下面这个命令选项:
命令行代码
- -XX:CMSInitiatingPermOccupancyFraction=
这个参数的功能和-XX:CMSInitiatingOccupancyFraction很像，他指的是启动CMS周期的permanent代的占用率。这个参数同样需要和-XX:+CMSClassUnloadingEnabled配合使用。如果你想一直使用-XX:CMSInitiatingPermOccupancyFraction的值作为启动CMS周期的条件，你必须要指定另外一个选项:
命令行代码
- -XX:+UseCMSInitiatingOccupancyOnly
CMS暂停时间优化
在CMS周期里面，有两个阶段是stop-the-world阶段，这个阶段所有的应用线程都被阻塞了。这两阶段是“初始标记”阶段和“再标记”阶段，尽管初始标记解决是单线程的，但是通过不需要花费太长时间，至少比其他垃圾回收的时间短。再标记阶段是多线程的，线程数可通过命令选项来控制：
命令行代码
- -XX:ParallelGCThreads=
在Java 6 update 23之后，默认值是通过Runtime.availableProcessors()来确定的，不过是建立在返回值小于等于8的情况下，反之，会使用Runtime.availableProcessors()*5/8作为线程数。如果有多个程序运行在同一个机器上面，建议使用比默认线程数更少的线程数。否则，垃圾回收可能会引起其他应用的性能下降，由于在同一个时刻，垃圾回收器使用太多的线程。
在某些情况下设置下面这个选项可以减少再标记的时间：
命令行代码
- -XX:+CMSScavengeBeforeRemark
这个选项强制HotSpot VM在FullGC之前执行MinorGC，在再标记步骤之前做MinorGC，可以减少再标记的工作量，由于减少了young代的对象数，这些对象能够在old代获取到的。
如果应用有大量的引用或者finalizable对象需要处理，指定下面这个选项可以减少垃圾回收的时间:
命令行代码
- -XX:+ParallelRefProcEnabled
这个选项可以用HotSpot VM的任何一种垃圾回收器上，他会是用多个的引用处理线程，而不是单个线程。这个选项不会启用多线程运行方法的finalizer。他会使用很多线程去发现需要排队通知的finalizable对象。
下一步
这一步结束，你需要看看应用的延迟需要是否满足了,无论是使用throughput垃圾回收器或者并发垃圾回收器。如果没有能够满足应用的需要，那么回头看看需求是否合理或者修改应用程序。如果满足了应用的需求，那么我们就进入下一步——优化吞吐量。