垃圾收集器与内存分配策略

此文内容摘自<深入理解java虚拟机 第二版>，选择一些脉络性的记录下，自己的理解很少，有时间看看还是可以的。

1.对象已死吗？

在堆里存放这java世界几乎所有的对象实例，垃圾回收器在对堆进行回收前，第一件事就是要确定这些对象之中那些对象还“存活”着，

哪些对象已经“死去”（即不可能再被任何途径使用的对象）。

1.1 引用计数器法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值加1；当引用失效时就减1；任何计数器为0的对象就是不可能再被使用的。

引用计数器法实现简单，判断效率高，在大部分情况下是不错的算法。但是在主流的java虚拟机里面没有选用引用计数器法来管理内存，主要的

原因是它很难解决对象之间的相互循环引用的问题。如这种代码：

objA.instance = objB;

objB.instance = objA;

objA = null;

objB = null;

System.gc();//假如在这里发生gc，objA和objB实际上并没有回收。

1.2 可达性分析算法

算法的基本思路是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots

没有任何引用链相连时（从GC Roots到这个对象不可达），则证明此对象是不可用的。

在java语言中，可以作为GC Roots的对象包括以下几种：

(1) 虚拟机栈（栈帧中的本地变量表）中引用到的对象；

(2) 方法区中类静态变量引用到的对象；

(3) 方法去中常量引用到的对象；

(4) 本地方法栈中JNI (即一般所说的Native方法) 引用到的对象。

如下图所示，object5、object6、object7虽然有关联，但是它们到GC Roots是不可达的，会被判定为可回收对象。

1.3 引用

在JDK1.2之前，java中的引用很传统：如果reference类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。

一个对象在这种定义下只有引用或者没有没引用两种状态。

在JDK1.2之后，java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用 4种。

2 垃圾收集算法

2.1 标记 - 清除算法

最基础的收集算法是 标记 - 清除 算法算法分为 标记 和清除两个阶段：首先标记出所有需要被回收的对象，在标记完成后统一回收所有被标记的对象。

不足：一个是效率问题，标记和清除两个过程效率都不高；另一个是空间问题，标记清除后产生大量的不连续的内存碎片，空间碎片太多可能导致以后

在需要分配较大对象时，无法找到足够的了连续内存而不得不提前触发另一次垃圾回收动作。

下图是 标记 - 清除 算法的执行过程图：图中上半部分是回收前状态，下半部分是回收后状态。

2.2 复制算法

接了解决效率问题，一种称为“f复制”的算法出现了，它将可用内存分为大小相等的两块，每次只是用其中一块。当着一块的内存用完了，就将还存活的

对象复制到另一块上面，然后把使用过的内存一次清理掉。这样每次都是对整个半区进行内存回收，内存分配时不用考虑内存碎片等复杂情况，只要一动栈顶指针，

按顺序分配内存即可，实现简单，运行高效。

不足：将内存缩小为原来的一般，代价有点高。

下图是复制算法示意图：（此图中 存活对象 和保留区域 颜色基本一样，自己区分）

2.3 标记 - 整理算法

根据老年代的特点（对象存活率比较高），有人提出了另外一种 “标记 - 整理” 算法，标记过程任然与“标记 - 清除” 算法一样，但后续步骤不是直接对可回收对象

进行清理，而是让所有的存活对象都向一端移动，然后直接清理掉端边界以外的内存.

下图是标记-整理算法示意图：

2.4 分代收集算法

当前的商业虚拟机的垃圾收集器都采用 “分代收集” 算法，这种算法并没有什么新的思路，只是根据对象存活周期的不同将内存划分为几块。

一般把java堆分为新生代和老年代，这样就可以根据各个年代放入特点采用 适当的收集算法。在新生代垃圾收集时每次都发现有大批对象死去，

只有少量存活，那就选用复制算法，只要付出少量存活的对象的 复制成本就可已完成收集。而老年代中对象存活率比较高，

没有额外的空间对他进行分配担保，就必须使用“标记 - 清理” 或者 “标记 - 整理” 算法来进行回收。

3 HotSopt的算法实现

3.1 枚举根节点

3.2 安全点

3.3 安全区域

4 垃圾收集器

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。这里讨论的收集器是基于JDK1.7 Update 14之后的Hotspot虚拟机（在这个版本中正式提供了商用的G1收集器，之前G1任处于试验状态），这个虚拟机包含的所有收集器如下图所示：

图中展示了7种不同年代的收集器，如果两个收集器之间有连线，就说明他们可以搭配使用。虚拟机所处的区域，则表明它是属于新生代收集器还是老年代收集器。

4.1 Serial 收集器

这个收集器是一个单线程的收集器，但它的“单线程”不仅仅说明它只会使用一个CPU或者一条线程去完成垃圾收集工作，更重要的是它在垃圾收集时，必须暂停其他所有的工作线程，直到他收集结束。这就是“Stop The World”

4.2 ParNew 收集器

ParNew收集器其实就是Seraial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其他行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。

4.3 Paralell Scavenge 收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去与ParNew都一样。Parallel Scavenge收集器的特点是它的关注点与其他的收集器不同，CMS等收集器关注点事近可能的缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控的吞吐量（Throughput）。

4.4 Serial Old收集器

Serial Old是Serial收集器的老年代版本，同样是一个单线程的收集器，使用“标记 - 整理” 算法。这个收集器主要意义在于给Client模式是下的虚拟机使用。如果在Server模式下，主要还有两个用途：一种是在jdk1.5以及在之前的版本中与Parallel Scavenge收集器搭配使用，另一种就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure 时使用。

4.5 Parallel Old 收集器

Parallel Old收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在JDK1.6才开始提供。在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。

4.6 CMS收集器

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验，CMS收集器是Sun HotSpot虚拟机中第一款真正意义上并发垃圾收集器，它第一次实现了让垃圾收集线程和用户线程同时工作。
CMS工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下4个阶段：
初始标记：只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
并发标记：进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
重新标记：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。
并发清除：清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。

CMS收集器有以下三个不足：
(1) CMS收集器对CPU资源非常敏感，其默认启动的收集线程数=(CPU数量+3)/4，在用户程序本来CPU负荷已经比较高的情况下，如果还要分出CPU资源用来运行垃圾收集器线程，会使得CPU负载加重。
(2) CMS无法处理浮动垃圾(Floating Garbage)，可能会导致Concurrent ModeFailure失败而导致另一次Full GC。由于CMS收集器和用户线程并发运行，因此在收集过程中不断有新的垃圾产生，这些垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好等待下一次GC时再将其清理掉，这些垃圾就称为浮动垃圾。CMS垃圾收集器不能像其他垃圾收集器那样等待年老代机会完全被填满之后再进行收集，需要预留一部分空间供并发收集时的使用，可以通过参数- XX:CMSInitiatingOccupancyFraction来设置年老代空间达到多少的百分比时触发CMS进行垃圾收集，默认是68%。如果在CMS运行期间，预留的内存无法满足程序需要，就会出现一次ConcurrentMode Failure失败，此时虚拟机将启动预备方案，使用Serial Old收集器重新进行年老代垃圾回收。
(3) CMS收集器是基于标记-清除算法，因此不可避免会产生大量不连续的内存碎片，如果无法找到一块足够大的连续内存存放对象时，将会触发因此Full GC。CMS提供一个开关参数-XX:+UseCMSCompactAtFullCollection，用于指定在Full GC之后进行内存整理，内存整理会使得垃圾收集停顿时间变长，CMS提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，用于设置在执行多少次不压缩的Full GC之后，跟着再来一次内存整理。

4.7 G1收集器

4.8 理解GC 日志

4.9 垃圾收集器参数总结

5.1 内存分配与回收策略  

新开了一篇：http://blog.csdn.net/wufengui1315/article/details/45629103