深入理解java虚拟机（第二版）——第三章：垃圾收集器与内存分配策略

一、对象存活统计算法

1.引用计数器法

每当对象被引用一次时，计数器的值就加一；当引用失效时，计数器的值就减一。在任何时刻，计数器为0的值时不会被使用的。

优点：实现简单，判定效率高。

缺点：无法解决对象之间相互调用的问题。

public class ReferenceCountingGC{
    public Object instance = null;       
    public static void testGC(){
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        objA.instance = objB;
        objB.instance = objA;
        objA = null;
        objB = null;

        System.gc();
    }
}

上面代码在gc之后objA和objB会回收，所以虚拟机并没有使用引用计数法。

2.可发行分析计算

该方法以一系列“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有任何引用链条时，则证明对象是不可用的。在java中，可以作为GC Roots的对象包括：

• 虚拟机栈中引用的对象。
• 方法区中静态属性引用的对象。
• 方法区中常量引用的对象
• 本地方法栈中引用的对象

二、对象的死亡过程

处在可达性分型中不可达的对象，暂时处于缓刑阶段。具体的死亡过程如下：

                                                  

其中，判断finalize()方法是否 需要执行的标准有两个：

• finalize()方法有没有被重写，没被重写不调用
• finalize()方法已经执行过，不调用。

换句话说，一个对象只有重写了finalize()方法并且第一个执行，虚拟机才会执行该对象的finalize()方法。

三、垃圾收集算法

1.标记-清除算法

标记清除算法是最基础的算法，此算法分为两个阶段标记和清除

标记：标记需要回收的对象

清除：统一回收被标记的对象。

缺点：效率低，标记和清除两个过程的效率都不高。清除后会产生大量的碎片空间，在分配大对象时碎片空间无法利用会触发另一次垃圾回收。

2.复制算法

复制算法讲内存分为大小相同的两块，当一块使用完了之后将其中存活的对象复制到另一块上面。然后将之前的内存空间整个清理掉。复制算法的具体过程分为

标记：区分存活和需要收集的对象

复制：将存活的对象诸葛复制到新的空间

清理：将就得空间一次性清理掉

优点：复制后新空间和旧空间没有内存碎片。新对象的分配简单高效，只要一动指针即可。

缺点： 代价高昂，可用内存缩小为了原来的一半。

复制算法的变种：

人们发现在新生代区使用复制算法时，死亡对象的比例约为98%，即每次需要复制的存活对象大约只有2%，这样就不需要将原内存划分为两块1:1的内存，而是根据新生代的特点分成8:1:1的三块内存，eden区占8，两块survivor分别占1。每次使用eden和一块survivor，当回收后将eden'和survivor存活的对象复制到另一块survivor上，这样讲复制算法原来的浪费一半的内存空间压缩到10%。但是这样并不总是保险的，即有时候存活的对象会超过10%，这时另一块survivor空间就会放不下。这时jvm的做法是向老年代借一块空间来存放存活对象。这叫做分配担保，即当survivor空间不够时由老年代担保可以将不够的空间从老年代划出使用。

3.标记-整理算法

前面的复制算法适用于存活对象较少的区域，如果存活对象较多时存活空间划分较小会频繁触发分配担保，这样可能会影响到担保空间的正常使用，如果担保空间不够用触发full GC会使垃圾收集的效率大大降低。

标记-整理算法时适用于老年代的算法。需要两个步骤

标记：标记存活对象

整理：将存活对象移动到空间的一端，将端边界以外的空间都清理掉。移动的时候不管要清理的对象。直接让存活对象覆盖。之后整体清理。

四、Hotspot的算法实现

1.枚举根节点

在根节点枚举中，GCRoots的主要节点在全局性的引用和执行上下文中，如果逐个检查会很消耗时间。

另外可达性分析要求执行系统必须冻结在某个时间点上，不可以出现分析过程中引用关系还在出现不断变化的过程中。

HotSpot的准确式GC
       HotSpot采用了准确式GC以提升GC roots的枚举速度。所谓准确式GC，就是让JVM知道内存中某位置数据的类型什么。比如当前内存位置中的数据究竟是一个整型变量还是一个引用类型。这样JVM可以很快确定所有引用类型的位置，从而更有针对性的进行GC roots枚举。HotSpot是利用OopMap来实现准确式GC的。当类加载完成后，HotSpot 就将对象内存布局之中什么偏移量上数值是一个什么样的类型的数据这些信息存放到 OopMap 中；在 HotSpot 的 JIT 编译过程中，同样会插入相关指令来标明哪些位置存放的是对象引用等，这样在 GC 发生时，HotSpot 就可以直接扫描 OopMap 来获取对象引用的存储位置，从而进行 GC Roots 枚举。

2.serial收集器

是最古老的也是最基础的收集器，单线程是因为当他在进行工作时必须停止其他活动的线程

优点：简单高效，没有线程切换带来的开销。在个人桌面管理中，stop the world的时间一般能控制在几十毫秒，在这时使用serial收集器是很好的选择。

3.ParNew收集器

parNew是serial的多线程版本，注意在parnew工作时仍然会停止其他工作线程。不同的是相比于serial，parnew采用多线程的方式回收垃圾。在多核cpu时收集速度会明显的高于serial。但是在单核或者核心较少的机器中，serial会高于parnew的收集速度。

4.parallel scavenge收集器

是一个新生代收集器，使用复制算法，并行收集。

特点：关注吞吐量。吞吐量=客户代码运行时间/（客户代码运行时间+垃圾收集时间）

两个重要的参数：

        MaxGCPauseMillis：最大垃圾收集停顿时间。太大垃圾收集停顿时间明显，影响用户体验。太小导致垃圾收集不完整，容易触发频繁的GC，降低吞吐量。

       GCTimeRatio：垃圾收集时间占比。计算方式为：用户代码运行时间/垃圾收集时间。如19 = 19:1，实际垃圾收集时间为1：（19+1） = 5%

5.serial old收集器

serial old类似于serial收集器，serial一般使用于新生代，serial old适用于老年代。采用的收集算法是标记-整理。主要的使用场景：

主要使用于client模式下的虚拟机

在server模式下，当CMS并发收集失败时，作为CMS的后备方案。

6.parallel old收集器

parallel old是parallel scavenge的老年代版本。采用标记-整理算法。

主要使用场景为配合新生代paralle scavenge使用，使得“吞吐量优先的概念”成为名副其实。在paralle old出现之前，parallel scavenge只能和serial old配合，由于serial old是单线程的版本，在多核cpu中能力有限，使得新生代的parallen scavenge的“吞吐量优先”效果有限。

7.CMS（cocurrent mark sweep）收集器

是并发清除收集器，强调以最短的收集停顿时间为目的。相比于前几个收集器，CMS比较复杂。整个过程分为4个步骤：

• 初始标记：仅仅标记GC Roots能直接关联到的对象。
• 并发标记：进行GC Roots Tracing过程。
• 重新标记：修正并发期间因用户程序继续运作而导致标记产生变化的一部分对象的标记记录
• 并发清除：最后多线程清除已标记两次的对象。

其中初始标记和和重新标记两个过程需要stop the world。最耗时的是并发标记和并发整理，由于这两个过程是与用户线程并发进行的所以总体来说CMS可以说成是并行的垃圾收集器。除了以上优点，CMS的缺点如下：

缺点：

CMS对CPU资源非常敏感。CMS默认的回收线程数为（cpu核心+3）/4，看以看到当cpu核心数增多时CMS线程的变化趋势为   1->四份之一的总核心数。即当cpu越多时CMS占用的资源越少。当cpu核心越少，CMS占用的资源越多，严重影响用户代码的执行。分析这种情况，当运行并发标记和并发清除时，CMS线程独占CPU，使得用户线程停滞或者分配到其他CPU，此时用户代码执行速度大大降低。在这种情况下提出了i-CMS，改变点就是在CMS执行并发标和并发清除时和用户线程交替运行，此时的CMS线程是并行收集吗？（未确定），这样整个垃圾收集的过程会拉长，但是用户代码执行效率提高了。实践证明不好用。 

并发清除时用户线程会产生新的垃圾，这些垃圾称为浮动垃圾。由于并发性，所以需要在清除时需要额外的空间给用户线程使用。所以CMS一般需要预留一块内存，而垃圾收集也并不是在老年代填满了才进行。使用CMSInitiatingOccupancyFraction控制触发垃圾回收的内存占比。当调的太高时，可能预留空间会无法满足浮动垃圾的使用从而产生Cocurrent Mode Failure。此时采用serial old收集器。调的太小则硬件浪费严重。

CMS的收集算法是标记-清除，所以会空间碎片。如果大对象无法分配内存则会触发Full GC 。为了解决这个问题，使用-XX:+UseCMSCompactAtFullCollection参数控制在CMS收集完后进行空间整理。由于内存整理无法并发，所以在整理时会停掉用户线程，增加停顿时间。因此在此基础上增加了-XX:CMSFullGCsBeforeCompaction来控制执行n次不压缩的CMS后来一次整理空间的CMS。