CMS垃圾收集器

CMS全称 ConcurrentMarkSweep，是一款并发的、使用标记-清除算法的垃圾回收器， 若是老年代使用CMS垃圾回收器，须要添加虚拟机参数-“XX:+UseConcMarkSweepGC”
缺点:

1. CMS收集器对CPU资源很是敏感，在并发阶段，它虽然不会致使用户线程停顿，可是因为占用了一部分线程，因此会致使应用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是（cpu数量+3）/4。
2. CMS收集器没法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而致使一次Full GC。在JDK1.6中，CMS收集器当老年代使用了92%的空间后才会进行收集，因此若是CMS运行期间预留的内存没法知足程序须要，就会出现一次“Concurrent Mode Failure”。经过-XX:CMSInitiatingOccupancyFraction能够调整百分比。
   该参数必须配合UseCMSInitiatingOccupancyOnly使用才有效
3. CMS因为是基于标记-清除算法实现的收集器，因此就可能会在收集结束的时候产生大量空间碎片。若是老年代中没有足够大的连续空间来分配当前对象，那么就会可能提早触发Full GC并进行碎片整理
   JVM参数

-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDateStamps 
-Xloggc:D:\aa.gc 
-XX:+PrintTenuringDistribution 
-XX:+UseConcMarkSweepGC 
-Xmx1024m 
-Xms1024m

日志以下：

2019-04-11T16:30:48.164+0800: 14.035: [GC (CMS Initial Mark) [1 CMS-initial-mark: 0K(699072K)] 33843K(1013632K), 0.0066881 secs] [Times: user=0.09 sys=0.00, real=0.01 secs] 
2019-04-11T16:30:48.179+0800: 14.044: [CMS-concurrent-mark-start] 
2019-04-11T16:30:48.179+0800: 14.044: [CMS-concurrent-mark: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2019-04-11T16:30:48.179+0800: 14.044: [CMS-concurrent-preclean-start] 
2019-04-11T16:30:48.179+0800: 14.047: [CMS-concurrent-preclean: 0.003/0.003 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2019-04-11T16:30:48.179+0800: 14.047: [CMS-concurrent-abortable-preclean-start] 
2019-04-11T16:30:52.428+0800: 18.302: [CMS-concurrent-abortable-preclean: 2.860/4.254 secs] [Times: user=9.47 sys=1.09, real=4.25 secs] 
2019-04-11T16:30:52.428+0800: 18.302: [GC (CMS Final Remark) [YG occupancy: 203965 K (314560 K)]2019-04-11T16:30:52.428+0800: 18.303: [Rescan (parallel) , 0.0177423 secs]2019-04-11T16:30:52.447+0800: 18.320: [weak refs processing, 0.0001500 secs]2019-04-11T16:30:52.447+0800: 18.320: [class unloading, 0.0287879 secs]2019-04-11T16:30:52.475+0800: 18.349: [scrub symbol table, 0.0121125 secs]2019-04-11T16:30:52.497+0800: 18.362: [scrub string table, 0.0012159 secs][1 CMS-remark: 0K(699072K)] 203965K(1013632K), 0.0623200 secs] [Times: user=0.13 sys=0.00, real=0.07 secs]

Old GC过程

1. 初始化标记（CMS Initial Mark）
   2019-04-11T16:30:48.164+0800: 14.035: [GC (CMS Initial Mark) [1 CMS-initial-mark: 0K(699072K)] 33843K(1013632K), 0.0066881 secs] [Times: user=0.09 sys=0.00, real=0.01 secs]
   整个过程会STW。
   标记GC Roots可达的老年代对象；
   遍历新生代对象，标记可达的老年代对象；
2. 并发标记（CMS-concurrent-mark）

2019-04-11T16:30:48.179+0800: 14.044: [CMS-concurrent-mark-start] 
2019-04-11T16:30:48.179+0800: 14.044: [CMS-concurrent-mark: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

该阶段GC线程和应用线程并发执行，遍历InitialMarking阶段标记出来的存活对象，而后继续递归标记这些对象可达的对象。

1. 预处理（CMS-concurrent-preclean）

2019-04-11T16:30:48.179+0800: 14.044: [CMS-concurrent-preclean-start] 
2019-04-11T16:30:48.179+0800: 14.047: [CMS-concurrent-preclean: 0.003/0.003 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

处理新生代已经发现的引用，好比在并发阶段，在Eden区中分配了一个A对象，A对象引用了一个老年代对象B（这个B以前没有被标记），在这个阶段就会标记对象B为活跃对象。

1. 可中断的预清理（CMS-concurrent-abortable）

2019-04-11T16:30:48.179+0800: 14.047: [CMS-concurrent-abortable-preclean-start] 
2019-04-11T16:30:52.428+0800: 18.302: [CMS-concurrent-abortable-preclean: 2.860/4.254 secs] [Times: user=9.47 sys=1.09, real=4.25 secs]

该阶段发生的前提是，新生代Eden区的内存使用量大于参数 CMSScheduleRemarkEdenSizeThreshold 默认是2M，若是新生代的对象太少，就没有必要执行该阶段，直接执行从新标记阶段。
由于CMS GC的终极目标是下降垃圾回收时的暂停时间，因此在该阶段要尽最大的努力去处理那些在并发阶段被应用线程更新的老年代对象，这样在暂停的从新标记阶段就能够少处理一些，暂停时间也会相应的下降。

1. 从新标记（CMS Final Remark）

2019-04-11T16:30:52.428+0800: 18.302: [GC (CMS Final Remark) [YG occupancy: 203965 K (314560 K)]2019-04-11T16:30:52.428+0800: 18.303: [Rescan (parallel) , 0.0177423 secs]2019-04-11T16:30:52.447+0800: 18.320: [weak refs processing, 0.0001500 secs]2019-04-11T16:30:52.447+0800: 18.320: [class unloading, 0.0287879 secs]2019-04-11T16:30:52.475+0800: 18.349: [scrub symbol table, 0.0121125 secs]2019-04-11T16:30:52.497+0800: 18.362: [scrub string table, 0.0012159 secs][1 CMS-remark: 0K(699072K)] 203965K(1013632K), 0.0623200 secs] [Times: user=0.13 sys=0.00, real=0.07 secs]

并发从新标记，STW过程。
遍历新生代对象，从新标记根据GC Roots，从新标记。

针对并发模式失效的调优

发生并发模式失效每每是因为CMS不能以足够快的速度清理老年代空间：新生代须要进行垃圾回收时，CMS收集器计算发现老年代没有足够的空闲空间能够容纳这些晋级对象，不得不先对老年代进行垃圾回收。
当老年代空间的占用达到某个程度时，并发回收就开始了。一个CMS后台线程要在老年代剩余空间用尽以前，完成老年代空间的扫描回收工做。若是并发回收速度太慢，就会发生并发模式失效。
能够经过如下途径避免这种失效：

1. 想办法增大老年代空间，要么只移动部分的新生代对象到老年代，要么增长更多的堆空间。
2. 以更高的频率运行后台回收线程。
3. 使用更多的后台回收线程。
   若是有更多的内存可用，更好的方案是增长堆的大小，不然能够尝试调整后台线程运行的方式来解决这个问题。

给后台线程更多的运行机会

同时设置-XX:CMSInitiatingOccupancyFraction=N和-XX:+UseCMSInitiatingOccupancyOnly。对特定的程序，该标志的更优值能够根据GC日志中CMS周期首次启动失败时的值获得。具体方法是，在垃圾回收日志中寻找并发模式失效，找到后再反向查找CMS周期最近的启动记录。日志中含有CMS-initial-mark信息的一行包含了CMS周期启动时，老年代空间的占用状况。

调整CMS后台线程

每一个CMS后台线程都会100%地占用机器上的一颗CPU。若是应用程序发生并发模式失效，同时又有额外的CPU周期可用，能够设置-XX:ConcGCThreads=N标志，增长后台线程的数目。默认ConcGCThreads =（ParallelGCThreads+3）/4。当有4个并行线程时，有1个并发线程，
当有5~8个并行线程时，有2个并发线程。ParallelGCThreads表示的是GC并行时使用的线程数，若是新生代使用ParNew，那么ParallelGCThreads也就是新生代GC线程数。默认状况下，当CPU数量小于8时，ParallelGCThreads的值就是CPU的数量，当CPU数量大于8时，ParallelGCThreads的值等于3+5*cpuCount/8。

java学习笔记/jvm