java cms 过程_一文就懂Java虚拟机的CMS收集器原理及使用

)，并且适合于有足够CPU资源提供给GC线程使用的那些应用程序。所以，如果你需要较短的GC停顿时间并且CPU数量充足，那么使用CMS收集器。例如，如果应用程序有较多长期存活的对象，那么老年代就会很大，导致GC暂停时间很长，并且有至少2个以上cpu核，那么适合使用CMS收集器。

CMS收集器针对新生代和老年代分别回收(新生代minor gc，老年代major gc)。因为新生代空间较小，老年代空间较大，所以GC暂停时间大部分是老年代的major gc导致的。因此，CMS用多个垃圾回收线程来track老年代中的存活对象，并且这些线程与用户线程一起并发执行，这样可以减少major gc的停顿时间。

CMS收集器的major gc过程是基于Mark-Sweep回收算法实现的，也就是说它分为Mark和Sweep两大阶段。因为Mark阶段最消耗时间，做网站所以为了减少停顿，Mark阶段又被细分为Initial Mark，Concurrent Mark和Remark这3个标记阶段。因此，CMS的major gc过程总共分为4个阶段，如下图所示：

initial mark阶段：需要停顿(Stop The World)，怎么建网站但是持续时间很短，只枚举出从GC Roots和新生代的中的对象可以直接引用到的对象。

concurrent mark阶段：与用户线程并发运行，持续时间长但是不会停顿，需要占用一些用户线程的CPU资源，这个阶段会把老年代中所有存活和不存活对象枚举出来。

remark阶段：因为concurrent mark阶段时间长并且是与用户线程并发运行，在这过程中，某些对象又会变成可回收，所以需要进行一些修正。remark阶段就是做这些修正的，并且修正过程需要停顿。这里的停顿时间比initial mark长一些。

以上是正常情况下的Major GC回收过程，关键的地方都图中有所体现。通过让执行时间最长的concurrent mark阶段与用户线程并发运行，减少了停顿时间。特殊情况：如果CMS回收过程还没有执行完，老年代的剩余空间就用完了，或者，当前老年代空间不能满足一次内存分配请求(可能对象较大)，那么此时将停顿所有用户线程，执行Full GC直到回收过程结束(不再区分concurrent mark和remark)，然后再恢复用户线程，如下图所示。

之前遇到面试官问我哪些情况会触发Full GC，当时羞涩的我只回答出来老年代空间不够及System.gc这两种情况。其实，触发Full GC的原因有以下几点：

CMS收集器在发现老年代即将变满的时候就开始一收操作，例如已用空间的百分比达到92%。这是默认值，可以通过-:CMSInitiatingOccupancyFraction=修改。

我们没有讲CMS收集器的minor gc。因为minor gc非常简单，就是执行Copy算法而已，把eden空间中的对象往survivor空间拷贝。

minor gc也停顿，时间也很短，可以与remark阶段的暂停时间比较；minor gc可以在major gc的执行过程中发生，与major gc的停顿阶段交替运行，但是不会重叠，如图：

最后再补充说明一下，这本《深入理解Java虚拟机：JVM高级特性与最佳时间》，虽然写的还行，但是跟JDK文档相比起来逊色太多而且有一些错误。如果想把Java的垃圾回收相关知识理解好，少走弯，看Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide。提到的这本书可以作为帮助我们理解的。这是我走过的弯，以为多看几遍这本jvm的书就能理解JVM的想法太天真了。