GC——CMS收集器

java垃圾回收算法之-CMS(并发标记清除)

概述

如果你的JAVA应用程序有以下几个特点，那么可以使用Concurrent Mark Sweep (CMS) 垃圾收集器。

1. 希望JAVA垃圾回收器回收垃圾的时间尽可能短；
2. 应用运行在多CPU的机器上，有足够的CPU资源；
3. 有比较多生命周期长的对象；
4. 希望应用的响应时间短。

---

CMS也是采用分代策略的，用于收集老年代的垃圾对象，并且分为好几个阶段来执行GC。在某些阶段，应用的线程会被挂起，也就是stop-the-world。而在另外的阶段里，垃圾回收线程可以与应用的线程一起工作。

---

收集阶段

1. 初始标记(CMS-initial-mark)
2. 并发标记(CMS-concurrent-mark)
3. 重新标记(CMS-remark)
4. 并发清除(CMS-concurrent-sweep)
5. 并发重置状态等待下次CMS的触发(CMS-concurrent-reset)

---

CMC垃圾回收过程会把应用线程挂起两次 
第一次：CMS-initial-mark 初始标记

这个阶段会扫描root对象直接关联的可达对象。注意不会递归的追踪下去，只是到达第一层而已。这个过程，会STW，但是时间很短。

第二次：CMS-remark 重新标记

在并发mark阶段，应用的线程可能产生新的垃圾，所以需要重新标记，这个阶段也是会STW。

至于并发标记、清除和重置这三个阶段

应用线程和垃圾回收线程是可以一起工作的，垃圾回收线程会占用部分CPU资源。

---

缺点

---

Concurrent Mode Failure

由于cms垃圾回收线程可以和应用的线程一起工作，那么应用线程仍然需要申请内存，如果这个时候老年代的空间已经不够用了。那么会有Concurrent Mode Failure 这样的日志输出，之后会进行一次Full GC的操作，所有的应用线程都会停止工作。

---

浮动垃圾

由于cms垃圾回收线程可以跟应用的线程一起工作，那么应用的线程也会产生垃圾，这些称之为浮动垃圾。

---

降低吞吐量 
由于应用线程和垃圾回收线程一起工作，那么垃圾回收线程也就抢占了系统资源，会对应用的吞吐量造成一定的影响。为了保证垃圾回收过程中，应用线程有足够的内存可以使用，当堆内存的空间使用率达到68%的时候，CMS开始触发垃圾回收。

---

内存碎片

CMS是基于标记-清除算法的，会造成内存碎片，具体请看我之前写的一篇文章 
java垃圾回收算法之-标记清除