理解HotSpot的CMS GC

探讨cms垃圾回收算法之前，先简单介绍下hotspot的内存模型：

                 图1（hotspot内存模型）

我们知道hotspot内存模型是分代的（generational collection）。Perm 也即是permanent generation，eden 和两个survivor区属于young generation,最后一个区域我们定义为old generation(也可以称之为mature generation或者 tenured generation).需要注意的是，其实每个generation都是整个jvm内存堆的一个子堆而已。

  Hotspot的generation

  大部分对象最开始都分配在eden区，但是有些大对象也会被直接分配到old generation中去。Survivor空间保存那些至少在一次年轻代回收（young generation collection）中存活下来的对象，这些对象还要经历一次筛选，如果它们还能在下一次垃圾回收中存活，那么他们就被移送到old generation .需要注意的是在任意时间两个survivor区只有一个是存储对象的，而另外一个则是空的，它们在每次垃圾回收过程后交换角色（空的区变成对象存储区，存储区则变成空的）。最后说一下perm区，官方的说法是“永久代保存那些jvm认为很方便被垃圾回收所管理的对象，比如描述类和方法的对象以及这些类和方法本身”， permanent generation的几乎不进行垃圾回收，因为它只在jvm发生major GC 的时候才进行垃圾回收，所以事实上我们可以认为当jvm发生full GC的时候，perm区才会进行GC.

   到这里我们终于可以开始研究cms算法了。

  首先给出cms的全名，concurrent mark-sweep collector.我们知道jvm垃圾回收的算法大致可以分为串行算法（serial collector），并行算法(parallel collector) 和并发算法（concurrent collector）.cms 算法属于并发算法，因为对应用程序的影响小，因此也被称为低延迟回收器（low latency collector）.

   Cms在处理young generation的垃圾回收时采用的算法和parallel collector是一样的,利用多硬件多cpu的特点。这里稍微提下parallel和concurrent的区别，事实上concurrent微观上还是串行的，只不过是在多个线程之间进行调度；parallel的在微观上还是并行的，多个任务在不同的cpu上各自运行。

   废话不多说，我们接下来看下cms算法在处理young generation垃圾回收时的具体做法：

本质上来说，这种算法是对串行算法的优化，但是它依然是需要freeze掉应用程序的，也就是我们说的，停止整个世界（stop the world and copy）.利用多cpu的特点，降低GC损耗，也因此提高了应用的吞吐量。

 

                 图2（串行算法和并行算法的对比）

Cms与其它算法比较起来优势体现在对old generation进行垃圾回收效率，接下来我们详细分析下：

 

            图3 （串行算法和cms算法对比）

一个cms回收周期以一个短暂停开始，称之为初始标记（initial mark）,在这个阶段算法会确认初始的能直接从应用代码中可触及的存活对象集合；然后在并发标记阶段，回收器标记所有从初始标记阶段对象集合中传递可及的对象。因为这个阶段过程中，应用程序还在运行，因此不能保证所有存活的对象都被标记了，为了解决这个问题，第三个阶段被引入了，我们称之为重新标记（remark）；它通过访问所有在并发标记阶段改变了的对象来完成最终标记。因为这个过程中freeze应用程序的时间比初始标记的时间更长，因此多个线程会并行（parallel）来处理以提高效率。这样就可以保证所有存活的对象都被标记了。因此接下来的清扫阶段（sweep）,所有被确认的垃圾都被回收了。注意，在intial mark和remark阶段，应用程序和serial collector一样，freeze了应用程序。在remark过程中，由于增加了回收器的工作了，所以事实上增加了开销，但是我们却能让暂停时间减少，这是一种权衡。

 我们需要知道的cms的缺点

 1）Cms回收器是唯一不做压缩（compact）的算法

 

                   图4（cms不做压缩）

这样节省了时间，但是由于空闲内存区域不连续，回收器不能用一个简单的指针来指出下一个能把对象分配的空闲区域。取而代之，它使用一定数目的list连接成一片未分配的内存区域，每次一个对象要被分配，它将在合适的list（根据需要的内存多少）中找出一个足够大的区域来存储对象。结果，old generation的内存分配比简单的增加指针技术更昂贵。这同时也要给young generation垃圾回收带来了额外的开销，因为大部分情况下old generation需要分配内存是因为young generation在进行垃圾回收。

2）Cms的另外一个缺点在于比需要比其它回收器更大的堆大小。考虑到在标记阶段应用还允许运行，分配内存还在继续，因此old generation会继续增长。此外，尽管回收器保证在标记阶段确认所有存活的对象，有些对象在那个阶段仍然可能变成垃圾，那么他们就只能等到下次old generation进行垃圾回收的时候才能被回收。这些对象被称为“漂浮垃圾”（floating garbage）.最后由于缺少压缩，碎片容易产生，为了处理碎片，cms回收器记录常。见的对象大小，预计未来需求，然后分割或者链接空闲区域来满足需求。

灵活的机制

不像其它的回收器，cms回收器不会等到old generation满了才去回收垃圾，而是在old generation满了以前就开始垃圾回收。可是如果old generation真的满了，cms恢复成并行和串行回收器使用的更消耗时间的停止世界（stop the world） mark-sweep-compact算法。当然cms会尽量避免出现这种情况，它采取一种策略，根据以前的回收耗费时间以及多快old generation 被填满的统计数据决定何时启动垃圾回收。同时如果old generation 的使用率超过一个被称为initiating occupancy的值后，它会启动一次垃圾回收。这个值可以通过命令行选项 –XX:CMSInitiatingOccupancyFraction=n,来设置。n是old generation的使用率。默认值是68.

总之，相比并行回收器，cms回收器降低了old generation的停滞时间，有时候会极大的降低，代价就是young generation 的pause会稍微长一些，同时吞吐量有些下降，需要更大一些的堆。

何时使用cms回收器？

如果你的应用需要更短的垃圾回收暂停时间同时能承担垃圾回收和应用程序分享处理器资源，那么就使用cms回收器吧。如果你的机器有多个处理器，这个算法带来的好处会更多，所以它对web 服务器和交互应用尤其合适。

选择cms算法

如果你想应用cms算法，你必须显示的在命令行中指明选项-XX:+UseConcMarkSweepGC，如果你想让它在增量模式下运行，依然可以通过选项–XX:+CMSIncrementalMode 选项来做到。

 

 

解释下full GC：当old 或者permanent generation填满，full GC(有时候我们称之为major GC)就会被触发，也就是所有的generation都被回收了。通常，young generation首先被回收，使用为那个generation设计的算法进行回收，因为通常这都是young generation 最有效的算法。而old generation回收器的算法则被应用到perm和old generation上。如果压缩（compact）发生，每个代都各自被压缩。如果old generation太满以至于无法接收从young generation过来的对象，除了cms回收器以外,young generation 的垃圾回收算法不会运行，old generation的算法会应用到整个堆。（当然old generation 的cms算法是个例外，因为它不能去回收young generation）.

CMS(concurrent mark sweep)并发清除标记的缩写，CMS尽可能的减少垃圾回收中的暂停，但是它仍然需要很少的暂停。暂停是指，停止应用程序的运行，JVM启动线程进行垃 圾回收。CMS主要是针对old space空间的垃圾回收，copy collector主要针对young space的垃圾回收工作。启用CMS需要在JVM设置–XX:+UseConcMarkSweepGC。 

CMS工作的基本阶段分为： 
初始化标记：第一次暂停，初始化标记，在old space收集根集合，标记存活对象 
并发标记：运行时标记，遍历old space，标记存活对象 
准备清理：并发的标记前一阶段被修改的对象 
重新标记：第二次暂停，检查，标记，检查脏页的对象，标记前一阶段被修改的对象 
并发清理：运行过程中清理，扫面old space，释放不可到达对象占用的空间 
并发重置：此次CMS结束后，重设CMS状态等待下次CMS的触发 

碎片问题 
因为年老代的并发收集器使用标记，清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但 是，当堆空间较小时，运行一段时间以后，就会出现"碎片"，如果并发收集器找不到足够的空间分配给新对象，那么并发收集器将会停止，然后使用传统的标记， 清除方式进行回收。如果出现"碎片"，可能需要进行如下配置: 
-XX:+UseCMSCompactAtFullCollection:使用并发收集器时，开启对年老代的压缩。 -XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下这里设置多少次Full GC后，对年老代进行压缩。 

CMS中的暂停时长 
第一阶段暂停：初始化标记 
CMS标记可到达对象，收集根集，根集的引用主要来自线程栈和young space，收集线程栈的引用非常快，少于一毫秒。收集young space的引用依赖于young space空间对象的数量，young space包括Eden space和Survivor space，如果在young space垃圾回收发生之后，这是young space已经被清理了，Eden space为空，Survivor space很小，这是后收集只需要很少的时间。如果在young space满的时候收集，需要花很长的时间。所以如果选择CMS，可以通过设置CMS初始化标记的延迟时间，延迟到young space垃圾回收之后开始工作标记。–XX:CMSWaitDuration=这个值可以长于young space垃圾回收的周期。 

第二阶段暂停：重新标记 
前期的并发标记几乎完成了大部分的标记工作，但是在并发标记的过程中，有的对象被修改了，为了达到更精确的目的，需要暂停应用程序，检查从并发标 记阶段开始被修改的对象，重新标记。卡表（card table）技术就是用来记录在标记过程中old space被修改的页。Remark阶段时间主要花在young space的扫描上，所以保证remark之前进行一次young space的垃圾回收。–XX:+CMSScavengeBeforeRemark强制JVM执行这个过程。 

CMS什么时候开始？ 
CMS应该在old space撑爆之前启动，当old space的空闲空间越来越少，低于某个阈值的时候将激发CMS。实际情况是，CMS可能被延迟到young space垃圾回收完成以后。 
正常情况是，young space的对象在垃圾回收后幸存下来后，会被晋升到old space。所以CMS循环总是发生在young space回收之后，这样初始化标记就会很快。但是也有特殊情况，大对象总是直接分配到old space，导致空闲空间下降后，引发CMS时，还未做young space回收，Eden space里有很多对象，初始化标记要花很长时间。避免这种长时间的暂停可以配置–XX:CMSWaitDuration延迟CMS的执行。 
我们还可以配置old space引发CMS的阈值，这个阈值表示的old space的使用率， XX:+UseCMSInitiatingOccupancyOnly  XX:CMSInitiatingOccupancyFraction=70，当old space的空间占用达到70%后会强制JVM执行CMS。 
如果配置了 XX:+ExplicitGCInvokesConcurrent，当应用程序调用System.gc()，JVM会启动CMS。 
如果配置了-XX:+DisableExplicitGC 标志自动将 System.gc() 调用转换成一个空操作。 

CMS中的Full GC 
以下情况会导致Full GC： 
CMS回收垃圾速度不够快； 
垃圾回收周期启动太晚了； 
Old space碎片过多； 
JVM本省设置内存不够； 
上面三种情况都会导致old space没有足够的空间分配给新对象，引发Full GC，应用程序会抛出内存溢出异常。内存溢出，是指系统没有内存分配给新对象，内存泄露是指，为对象分配的内存，使用后没有释放，这块内存一直被占用，导致总的可用内存空间的减少。 

永久代空间的回收 
另外一个导致full GC的原因在于永久代（permanent space），因为默认情况下，JVM的CMS是不会去回收永久代的对象。如果应用程序使用了大量的类加载和发射，就需要回收永久代的对象。 XX:+CMSClassUnloadingEnabled允许CMS回收永久代的不可到达对象。 

利用多核 
CMS分阶段工作，很多阶段是并发执行的，其他阶段也可以并行执行，通过下面配置可以减小应用程序被暂停的时长。 
XX:+CMSConcurrentMTEnabled 允许CMS在并发阶段使用多核. 
XX:+ConcGCThreads= 指定CMS并发阶段的线程数. 
XX:+ParallelGCThreads= 指定在暂停阶段并行工作的线程数（默认情况等于物理核的数量）. 
XX:+UseParNewGC 指示JVM使用并行收集器收集young space结合CMS工作. 


以下是对JVM中常见配置总结 
-Xms128m表示JVM Heap(堆内存)最小尺寸128MB，初始分配 
-Xmx512m表示JVM Heap(堆内存)最大允许的尺寸256MB，按需分配。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。 

-Xss1m 设置每个线程的堆栈大小1M。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物 理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。 

-Xmn2g:设置年轻代大小为2G。整个堆大小=年轻代大小+年老代大小+持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。 
使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。 
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5 
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6 。 

PermSize和maxPermSize表示虚拟机为java永久生成对象（Permanate generation）如class对象、方法对象这些可反射对象分配内存限制，这些内存不包括在Heap（堆内存）区之中。 
-XX:PermSize=64MB 最小尺寸，初始分配 
-XX:MaxPermSize=256MB 最大允许分配尺寸，按需分配 
MaxPermSize缺省值和-server -client选项相关。 
-server选项下默认MaxPermSize为64m 
-client选项下默认MaxPermSize为32m 

-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入 年老代。 对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活 时间，增加在年轻代即被回收的概率 

收集器设置 
-XX:+UseSerialGC:设置串行收集器 
-XX:+UseParallelGC:设置并行收集器 
-XX:+UseParalledlOldGC:设置并行年老代收集器 
-XX:+UseConcMarkSweepGC:设置并发收集器 
-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。 
-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。 
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。 
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。 
-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片。 

并行收集器设置 
-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。 
-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间 
-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n) 
并发收集器设置 
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。 
-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。