4-JVM-GC 深入理解垃圾收集算法

垃圾收集算法

一、分代收集理论

当前虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期的不同将内存分为几块。一般将Java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。目前关于分代收集理论，主要有以下几种假说：

1. 弱分代假说（Weak Generational Hypothesis）:绝大多数对象都是朝生夕灭。
2. 强分代假说（Strong Generational Hypothesis）:熬过越多次垃圾收集过程的对象久越难以消亡。
3. 跨代引用假说（Intergenerational Reference Hypothesis）:跨代引用相对于同代引用来说仅占极少数。

二、垃圾收集算法

1、标记-复制算法

为了解决效率问题，”复制“收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的另一半进行回收。

示意图如下：

优点：效率高

缺点：每次会有一大块内存使用不到，降低了内存使用率

适用场景：比如在新生代中，每次收集都会有大量的对象（近99%）死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。

2、标记-清除算法

算法分为“标记”和“清除”阶段：标记存活的对象，统一回收所有未被标记的对象（一般选择这种）；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，比较简单但是会带来两个明显的问题：

• 效率问题（如果需要标记的对象太多，效率不高）
• 空间问题（标记清除后会产生大量不连续的碎片）

示意图如下：

优点：

​ 需要标记的对象不多时，效率比较高；

​ 能充分利用到分配的空间；

缺点：

​ 当需要标记的对象过多时，效率不太高；

​ 标记清除后会产生大量不连续的碎片，就会导致在程序在需要分配大块内存时，无法找到在足够的连续内存而不得不提前进行另一次垃圾回收动作。

适用场景：一般老年代的对象存活率比较高，而且没有额外的空间对其进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意！“标记-清楚”和“标记-整理”算法会比复制算法慢10倍以上。

2. 标记-整理算法

这是根据老年代的特点出的一种标记算法，标记过程仍然是与“标记-清除”算法一样，但是后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

示意图如下：

优点：可以弥补标记-清除算法当中，内存区域分散的问题，也能消除复制算法当中，内存减半的高额代价。

缺点：效率不高，不仅要标记所有存活对象，而且还要重新整理存活对象的引用地址。

效率：复制算法>标记-清除算法>标记-整理算法

内存整齐度：复制算法=标记-整理算法>标记-清除算法

内存利用率：标记-整理算法>标记-清除算法>标记-复制算法

三、垃圾收集器

若收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

1、Serial收集器（-XX:+UseSerialGc -XX:+UseSerialOldGC）

Serial（串行）收集器是最基本、历史最悠久的垃圾收集器。看名字就知道这是一个单线程收集器，它的“单线程”的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候，必须暂停其他所有的工作线程（“Stop the world”），直到它收集结束。

新生代采用复制算法，老年代采用标记-整理算法。

​ 虚拟机的设计者们当然知道Stop the world 带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断压缩（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。

​ 但是Serial收集器有没有优于其他垃圾收集器的地方呢？当然有，它简单而高效（与其他收集器的单线程相比）。Serial收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。

​ Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器，它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。

2、Parallel Scavenge收集器（-XX:+UseParallelGc(年轻代),-XX:+UseParallelOldGC(老年代)）

Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数，收集算法、回收策略等等）和Serial收集器类似，默认的收集线程数跟CPU核数相同，当然也可以用参数（-XX:ParallelGCThrerads）指定收集线程数，但是一般不推荐修改。

Parallel Scavenge收集器关注点是吞吐量（高效率的理由CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。

Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，可以选择把内存优化交给虚拟机去完成也是一个不错的选择。

新生代采用复制算法，老年代采用标记-整理算法。

Parallel Old收集器是parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法，在注重吞吐量以及CPU资源的场合，都可以优先考虑Parallel Scavenge收集器和Parallel Old收集器（JDK8默认的新生代和老年代收集器）

3、ParNew收集器（-XX:+UseParNewGC）

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。

新生代采用复制算法，老年代采用标记-整理算法。

它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收集器）配合工作。

4、CMS收集器（-XX:UseConcMarkSweepGC(老年代)）

CMS（Concurrent Mark Sweep）收集器是一种以获取量最短回收停顿时间为目标的收集器，它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机上第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程于用户线程（基本上）同时工作。

从名字中的Mark Sweep这两个词就可以看出，CMS收集器是一种“标记-清除“算法实现的，它的运作过程相比于前面的几种垃圾收集器来说更复杂一些，整个过程分为四个步骤：

• 初始标记： 暂停所有的其他线程（STW），并记录下gc roots直接能引用的对象，速度很快。
• **并发标记：**并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行，因为用户程序继续运行，可能会导致已经标记过的对象状态发生改变。
• **重新标记：**重新标记阶段就是为了修正并发标记期间，因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短，主要用到三色标记里的增量更新算法做重新标记。
• **并发清理：**开启用户线程，同时GC线程开始对未标记的区域做清扫，这个阶段如果有新增对象会被标记为黑色，不做任何处理。
• 并发重置：重置本次GC过程中的标记数据。

过程示意图如下：

主要优点：并发收集、低停顿。

但是它有下面几个明显的缺点：

• 对CPU资源敏感（会和服务抢资源）
• 无法处理浮动垃圾（在并发标记和并发清理阶段又产生垃圾，这种垃圾只能等到下次GC再清理了）；
• 它使用回收算法-“标记-清除”算法，会导致收集结束时，会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection 可让JVM在执行完标记清楚后再做整理。
• 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次出发full gc，也就是“concurrent mode failure”，此时会进入stop the world，用Serial old垃圾收集器来回收。

CMS相关的核心参数：

1. -XX:+UseConcMarkSweepGC 启用cms
2. -XX:ConGCThreads 并发的GC线程数
3. -XX:+UseCMSCompactAtFullCollection FullGC 之后做压缩整理（减少碎片）
4. -XX:CMSFullGCsBeforeCompaction 多少次FullGC之后压缩一次，默认是0，代表每次FullGC之后都会压缩一次
5. -XX:CMSInitiatingOccupancyFraction 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
6. -XX:+CMSScavengeBeforeRemark 在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时80%都在标记阶段
7. -XX:UseCMSInitiatingOccupancyOnly 只使用设定的回收阈值（-XX:CMSInitiatingOccupancyFraction设定的值），如果不指定，JVM仅在第一次使用设定值，后续则会自动调整。
8. -XX:CMSParallelInitialMarkEnabled 表示在初始化标记的时候多线程执行，缩短STW
9. -XX:CMSParallelRemarkEnabled 在重新标记的时候多线程执行，锁哦端STW

四、垃圾收集底层算法实现

三色标记

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。

这里我们引入“三色标记”来给大家解释一下，把GC Roots可达性分析遍历对象过程中遇到的对象，按照“是否访问过“这个条件标记成以下三种颜色：

• **黑色：**表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如有其他对象引用指向了黑色对象，无需重新扫描一遍，黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
• **灰色：**表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
• **白色：**表示对象尚未被垃圾收集器访问过，显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

上图代码示例：

public class ThreeColorRemark{
  public static void main(String[] args){
    A a = new A();
    //开始做并发标记
    D d = a.b.d; //1.读
    a.b.d = null; //2.写
    a.d = d; //3.写
  }
  
  class A {
    B b =new B();
    D d = null;
  }
  
  class B {
    C c = new C();
    D d = new D();
  }
  
  class C {
  }
  
  class D{}
}

多标-浮动垃圾

在并发标记过程中，如果由于方法运行结束导致部分局部变量（gc root）被摧毁，这个gc root 引用的对象之前又被扫描过（被标记为非垃圾对象），那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。

另外，针对并发标记（还没有并发清理）开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变成为垃圾，这也算是浮动垃圾的一部分。

漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案：增量更新（Incremental Update）和原始快照(Snapshot At The Begining,，SATB)。

**增量更新：**就是当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次，这可以简化理解为：黑色对象一旦新插入了指向白色对象的引用之后，它就变回为灰色对象了。

**原始快照：**就是当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色（目的就是让这种对象在本轮GC清理中能存活下来，待下一轮GC的时候重新扫描，这个对象也有可能是浮动垃圾）

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。

写屏障

给某个对象的成员变量赋值时，其底层的代码大概长这样：

/**
* @param field 某对象的成员变量，如a,b,c,d
* @param new_value 新增，如 null
*/
void oop_field_store(oop* field, oop new_value){
  *field = new new_value; //默认操作
}

所谓写屏障，其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）：

void oop_field_store(oop* field, oop new_value){
  pre_write_barier(field); //写屏障-写前操作
  *field = new_value;
  post_write_barrier(field, value);	//写屏障-写后操作
}

• 写屏障实现SATB

  当对象B的成员变量的引用发生变化时，比如引用消失（a.b.d = null），我们可以利用写屏障，将原来成员变量的引用对象D记录下来。

  void pre_wirte_barrier(oop* field){
    oop old_value = *field; //获取旧值
    remark_set.add(old_value);	//记录原来的引用对象
  }
  

• 写屏障实现增量更新

  当对象A的成员变量的引用发生变化时，比如新增引用（a.d = d），我们可以利用写屏障，将A新的成员变量引用对象D记录下来：

  void post_write_barrier(oop* field, oop new_value){
    remark_set.add(new_value);
  }
  

读屏障

oop oop_field_load(oop* field){
  pre_load_barrier(field);	//读屏障-读取操作
  return *field;
}

读屏障是直接针对第一步：D d = a.b.d，当读取成员变量时，一律记录下来：

void pre_load_barrier(oop* field){
  oop old_value = *field;
  remark_set.add(old_value);	//记录读取到的对象
}

现代追踪式（可达性分析）的垃圾回收器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同：比如白色/黑色集合一般都不会出现（但是有其他体现颜色的地方）、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以是广度/深度遍历等等。

对于读写屏障，以Java hotspot VM为例，其并发标记时对漏标的处理方案如下：

• CMS：写屏障+增量更新
• G1，Shenandoah：写屏障+SATB
• ZGC：读屏障

工程实现中，读写屏障还有其他功能，比如写屏障可以用于记录跨代/区引用的变化，读屏障可以用于支持移动对象的并发执行等功能之外，还有性能的考虑，所以对于选择哪种，每款垃圾收集器都有自己的想法。

为什么G1用SATB？CMS用增量更新？

个人理解：SATB相对增量更新效率会更高（当然SATB可能会造成更多的浮动垃圾），因为不需要在重新标记阶段再次深度扫描被删除的引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话，G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。

记忆集与卡表

在新生代做GC Roots可达性扫描过程中可能会碰到跨代引用的对象，这种如果又去对老年代再去扫描，效率太低了。为此，在新生代可以引入记录集（Remember Set）的数据结构（记录从非收集区到收集区的指针集合），避免把整个老年代加入GC Roots扫描范围。事实上并不是新生代、老年代之间才有跨代引用的问题，所有涉及部分区域收集（Partial GC）行为的垃圾收集器，典型的如G1、ZGC和Shenandoah收集器，都会面临相同的问题。

垃圾收集场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在收集区域的指针即可，无需了解跨代引用的全部细节。

hotspot使用一种叫做“卡表”（cardtable）的方式实现记忆集，也是目前最常用的一种方式，关于卡表与记忆集的关系，可以类比为Java语言中HashMap与Map的关系。

卡表是使用一个字节数组实现：CARD_TABLE[]，每个元素对应着其标识的内存区域一块特定大小的内存块，称为“卡页”。

hotspot使用的卡页是2^9大小，即512字节。