jvm垃圾回收算法梳理

背景

java建立了垃圾回收机制，但是JVM版本不同，使用的回收算法也不同。但是回收算法主要关注两点：（1）发现无用信息对象；（2）回收被无用对象占用的内存空间，使该空间可被程序再次使用。

垃圾回收算法

1.引用计数法(Reference Counting Collector)

1.1算法分析

引用计数是垃圾收集器中的早期策略。在这种方法中，堆中每个对象实例都有一个引用计数。当一个对象被创建时，且将该对象实例分配给一个变量，该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时，计数加1（a = b,则b引用的对象实例的计数器+1），但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。

1.2优缺点

优点：引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。

缺点：无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，他们的引用计数永远不可能为0.

2.tracing算法(Tracing Collector) 或 标记-清除算法(mark and sweep)

2.1根搜索算法

根搜索算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点。

java中可作为GC Root的对象有

1.虚拟机栈中引用的对象（本地变量表）

2.方法区中静态属性引用的对象

3. 方法区中常量引用的对象

4.本地方法栈中引用的对象（Native对象）

2.2tracing算法的示意图

2.3标记-清除算法分析

标记-清除算法采用从根集合进行扫描，对存活的对象对象标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收，如上图所示。标记-清除算法不需要进行对象的移动，并且仅对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。

3.compacting算法 或 标记-整理算法

标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。在基于Compacting算法的收集器的实现中，一般增加句柄和句柄表。

4.copying算法(Compacting Collector)

该算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。它开始时把堆分成 一个对象 面和多个空闲面， 程序从对象面为对象分配空间，当对象满了，基于copying算法的垃圾 收集就从根集中扫描活动对象，并将每个 活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞)，这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。一种典型的基于coping算法的垃圾回收是stop-and-copy算法，它将堆分成对象面和空闲区域面，在对象面与空闲区域面的切换过程中，程序暂停执行。

5.generation算法(Generational Collector)

分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的回收算法，以便提高回收效率。

三.GC（垃圾收集器）

新生代收集器使用的收集器：Serial、PraNew、Parallel Scavenge

老年代收集器使用的收集器：Serial Old、Parallel Old、CMS

Serial收集器（复制算法)

新生代单线程收集器，标记和清理都是单线程，优点是简单高效。

Serial Old收集器(标记-整理算法)

老年代单线程收集器，Serial收集器的老年代版本。

ParNew收集器(停止-复制算法)　

新生代收集器，可以认为是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。

Parallel Scavenge收集器(停止-复制算法)

并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。

Parallel Old收集器(停止-复制算法)

Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先

CMS(Concurrent Mark Sweep)收集器（标记-清理算法）

高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择。

CMS已经在一定程度上把垃圾回收给应用带来的负担降到了最小，把应用的吞吐量推到了一个极限。但是缺点：

1）Full GC所带来的应用暂停。

2）CMS导致内存碎片问题。

针对CMS的问题，G1做了针对性优化。

Garbage First（G1）

  G1是个均衡的算法。他吸取了增量收集优点，把整个堆划分为一个一个等大小的区域（region），避免了CMS把整个堆做为一个内存块。内存的回收和划分都以 region为单位；同时，他也吸取了CMS的特点，把这个垃圾回收过程分为几个阶段，分散一个垃圾回收过程；而且，G1也认同分代垃圾回收的思想，认为 不同对象的生命周期不同，可以采取不同收集方式，因此，它也支持分代的垃圾回收。为了达到对回收时间的可预计性，G1在扫描了region以后，对其中的 活跃对象的大小进行排序，首先会收集那些活跃对象小的region，以便快速回收空间（要复制的活跃对象少了），因为活跃对象小，里面可以认为多数都是垃 圾，虽然在清理这些区块时G1仍然需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。这也是为什么G1命名为Garbage First的原因：第一时间处理垃圾最多的区块。

就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合：

1. 服务端多核CPU、JVM内存占用较大的应用（至少大于4G）
2. 应用在运行过程中会产生大量内存碎片、需要经常压缩空间
3. 想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象

在G1中，堆被划分成 许多个连续的区域(region)。每个区域大小相等，在1M~32M之间。JVM最多支持2000个区域，可推算G1能支持的最大内存为2000*32M=62.5G。区域(region)的大小在JVM初始化的时候决定，也可以用-XX:G1HeapReginSize设置。

在G1中没有物理上的Yong(Eden/Survivor)/Old Generation，它们是逻辑的，使用一些非连续的区域(Region)组成的.

 

一次完整G1GC的详细过程：

G1在运行过程中主要包含如下4种操作方式：

1. YGC（不同于CMS）
2. 并发阶段
3. 混合模式
4. full GC （一般是G1出现问题时发生）

1 YGC

G1的新生代收集跟ParNew类似，当新生代占用达到一定比例的时候，开始出发收集。

  图中每个小区块都代表G1的一个区域（Region），区块里面的字母代表不同的分代内存空间类型（如[E]Eden,[O]Old,[S]Survivor）空白的区块不属于任何一个分区；G1可以在需要的时候任意指定这个区域属于Eden或是O区之类的。

G1 YoungGC在Eden充满时触发，在回收之后所有之前属于Eden的区块全变成空白。然后至少有一个区块是属于S区的（如图半满的那个区域），同时可能有一些数据移到了O区。

并发阶段：

一个并发G1回收周期前后内存占用情况如下图所示：

从上面的图表可以看出以下几点：
1、Young区发生了变化、这意味着在G1并发阶段内至少发生了一次YGC（这点和CMS就有区别），Eden在标记之前已经被完全清空，因为在并发阶段应用线程同时在工作、所以可以看到Eden又有新的占用
2、一些区域被X标记，这些区域属于O区，此时仍然有数据存放、不同之处在G1已标记出这些区域包含的垃圾最多、也就是回收收益最高的区域
3、在并发阶段完成之后实际上O区的容量变得更大了（O+X的方块）。这时因为这个过程中发生了YGC有新的对象进入所致。此外，这个阶段在O区没有回收任何对象：它的作用主要是标记出垃圾最多的区块出来。对象实际上是在后面的阶段真正开始被回收.

G1并发标记周期可以分成几个阶段、其中有些需要暂停应用线程。

第一个阶段是初始标记(Initial-Mark) 阶段。这个阶段会暂停所有应用线程. 并且会触发一次普通Mintor GC。对应GC log:GC pause (young) (inital-mark).下面是日志示例：

de style="color: rgb(102, 102, 102); font-size: 14px; line-height: 35px; white-space: normal;"   >50.541: [GC pause (young) (initial-mark), 0.27767100 secs]de>
de style="color: rgb(102, 102, 102); font-size: 14px; line-height: 35px; white-space: normal;"   >[Eden: 1220M(1220M)->0B(1220M)de>
de style="color: rgb(102, 102, 102); font-size: 14px; line-height: 35px; white-space: normal;"   >Survivors: 144M->144M Heap: 3242M(4096M)->2093M(4096M)]de>
de style="color: rgb(102, 102, 102); font-size: 14px; line-height: 35px; white-space: normal;"   >[Times: user=1.02 sys=0.04, real=0.28 secs]de>

  上面的日志表明发生了YGC、应用线程为此暂停了280毫秒，Eden区被清空（71MB从Young区移到了O区）。

日志里面initial-mark的字样表明后台的并发GC阶段开始了。因为初始标记阶段本身也是要暂停应用线程的， G1正好在YGC的过程中把这个事情也一起干了 。

第二阶段，G1开始扫描根区域（Root Region Scanning），程序运行过程中会回收survivor区(存活到老年代)，这一过程必须在young GC之前完成。日志示例：

de>50.819: [GC concurrent-root-region-scan-start]de>
de>51.408: [GC concurrent-root-region-scan-end, 0.5890230]de>

一共花了580毫秒，这个过程没有暂停应用线程；是后台线程并行处理的。这个阶段不能被YGC所打断、因此后台线程有足够的CPU时间很关键。如果Young区空间恰好在Root扫描的时候满了、YGC必须等待root扫描之后才能进行。带来的影响是YGC暂停时间会相应的增加。这时的GC日志是这样的：

350.994: [GC pause (young)

351.093: [GC concurrent-root-region-scan-end, 0.6100090]

351.093: [GC concurrent-mark-start],0.37559600 secs]

GC暂停这里可以看出在root扫描结束之前就发生了，表明YGC发生了等待，等待时间大概是100毫秒。

第三阶段：在root扫描完成后，G1进入了一个并发标记阶段（ Concurrent Marking ）。

在整个堆中进行并发标记(和应用程序并发执行)，此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那个这个区域会被立即回收(图中打X)。同时，并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)。 GC日志里面下面的信息代表这个阶段的开始和结束：

de>111.382: [GC concurrent-mark-start]de>
de>....de>
de>120.905: [GC concurrent-mark-end, 9.5225160 sec]de>

de> de>

第四阶段： 再标记（Remark） 会有短暂停顿(STW)。再标记阶段是用来收集 并发标记阶段 产生新的垃圾(并发阶段和应用程序一同运行)；G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。

第五阶段： 清理（Copy/Clean up） 多线程清除失活对象，会有STW。G1将回收区域的存活对象拷贝到新区域，清除Remember Sets，并发清空回收区域并把它返回到空闲区域链表中。

 

复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。

四、五阶段日志示例如下：

de>120.910: [GC remark 120.959:de>
de>[GC ref-PRC, 0.0000890 secs], 0.0718990 secs]de>
de>[Times: user=0.23 sys=0.01, real=0.08 secs]de>
de>120.985: [GC cleanup 3510M->3434M(4096M), 0.0111040 secs]de>
de>[Times: user=0.04 sys=0.00, real=0.01 secs]de>

这两个阶段同样会暂停应用线程，但时间很短。接下来还有额外的一次并发清理阶段：

de>120.996: [GC concurrent-cleanup-start]de>
de>120.996: [GC concurrent-cleanup-end, 0.0004520]de>

到此为止，正常的一个G1周期已完成–这个周期主要做的是发现哪些区域包含可回收的垃圾最多（标记为X），实际空间释放较少。

混合GC：

接下来G1执行一系列的混合GC。这个时期因为会同时进行YGC和清理上面已标记为X的区域，所以称之为混合阶段，下面是一个混合GC执行的前后示意图：

 像普通的YGC那样、G1完全清空掉Eden同时调整survivor区。另外，两个标记也被回收了，他们有个共同的特点是包含最多可回收的对象，因此这两个区域绝对部分空间都被释放了。这两个区域任何存活的对象都被移到了其他区域（和YGC存活对象晋升到O区类似）。这就是为什么G1的堆比CMS内存碎片要少很多的原因–移动这些对象的同时也就是在压缩对内存。下面是一个混合GC的日志：

de>79.826: [GC pause (mixed), 0.26161600 secs]de>
de>....de>
de>[Eden: 1222M(1222M)->0B(1220M)de>
de>Survivors: 142M->144M Heap: 3200M(4096M)->1964M(4096M)]de>
de>[Times: user=1.01 sys=0.00, real=0.26 secs]de>

上面的日志可以注意到Eden释放了1222MB、但整个堆的空间释放内存要大于这个数目。数量相差看起来比较少、只有14MB，但是要考虑同时有survivor区的对象晋升到O区；另外，每次混合GC只是清理一部分的O区内存，整个GC会一直持续到几乎所有的标记区域垃圾对象都被回收，这个阶段完了之后G1会重新回到正常的YGC阶段。周期性的，当O区内存占用达到一定数量之后G1又会开启一次新的并行GC阶段.

关于Remembered Set概念：G1收集器中，Region之间的对象引用以及其他收集器中的新生代和老年代之间的对象引用是使用Remembered Set来避免扫描全堆。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序对Reference类型数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之间(在分代中例子中就是检查是否老年代中的对象引用了新生代的对象)，如果是便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当内存回收时，在GC根节点的枚举范围加入Remembered Set即可保证不对全局堆扫描也不会有遗漏。

G1虽然保留了CMS关于代的概念，但是代已经不是物理上连续区域，而是一个逻辑的概念。在标记过程中，每个区域的对象活性都被计算，在回收时候，就可以根据用户设置的停顿时间，选择活性较低的区域收集，这样既能保证垃圾回收，又能保证停顿时间，而且也不会降低太多的吞吐量。Remark阶段新算法的运用，以及收集过程中的压缩，都弥补了CMS不足。

***************************总结************************

本次学习笔记梳理了jvm垃圾回收相关算法，目前主流的还是cms,但是针对cms的问题，G1做了针对性优化。成熟后逐步替代cms.

参考：

http://www.importnew.com/16173.html

http://www.importnew.com/15311.html

http://ifeve.com/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3g1%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8/