JAVA基础之垃圾收集器

当前虚拟机的垃圾收集一般采用分代收集算法，这种算法本身没有创新性，只是根据对象存活周期的不同将内存分为几块。一般将java堆内存分为新生代和老年代，这样我们就可以根据不同年龄到的特点选择不同的垃圾收集算法。标记整理。

磊杰哟

1060人浏览 · 2024-04-22 22:39:05

磊杰哟 · 2024-04-22 22:39:05 发布

一 JVM垃圾收集

分代收集思想

当前虚拟机的垃圾收集一般采用分代收集算法，这种算法本身没有创新性，只是根据对象存活周期的不同将内存分为几块。一般将java堆内存分为新生代和老年代，这样我们就可以根据不同年龄到的特点选择不同的垃圾收集算法。

比如：

新生代中，每次收集都会有大量的对象(接近99%)被回收，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。
老年代中，对象的存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择标记清除或标记整理算法进行垃圾收集。注意标记清除或标记整理算法会比复制算法慢10倍以上；

二常见的垃圾收集算法

标记清除算法

该算法分为标记和清除两个阶段：

标记阶段：标记存活的对象(一般选择这种)；
回收阶段：统一回收所有未被标记的对象；

这是最基础的收集算法，比较简单，但是会带来两个明显的问题：

效率问题：如果标记的垃圾对象太多，效率会很低；
空间问题：标记清除后会产生大量不连续的碎片空间；

标记复制算法

为了解决标记清除算法效率问题，复制算法出现了，它将内存分为大小相同的两块，每次使用其中一块，当其中一块被使用完后，将还存活的对象复制到另一块空间，然后把已经使用的空间一次性清空。其实是用空间换时间的思想；

标记整理算法

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

三垃圾收集器

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

3.1 Serial收集器

Serial(串行)收集器是最基础、历史最悠久的垃圾收集器。是一款单线程收集器。它的单线程意味着他只会使用一条垃圾收集线程完成垃圾收集工作，更重要的是它在垃圾收集工作的时候必须暂停其他所有其他工作线程(Stop The Word),直到它收集完成；

缺点：Stop The Word带来了不好用户体验；
优点：简单而高效(与其他收集器的单线程相比)，Serial收集器没有线程交互的开销，自然可以获得很高的单线程收集效率；

Serial Old收集器时Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两个用途：

在JDK1.5及以前的版本中与Parallel Scavenge收集器搭配使用；
作为CMS收集器的后备方案；

开启参数：-XX:UseSerialGC -XX:UseSerialOldGC

3.2 Parallel Scavenge收集器

Parallel Scavenge收集器其实是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其他行为(控制参数、收集参数、回收策略)和Serial收集器类似。默认的收集线程数等于CPU核数，当然也可以通过参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改；

Parallel Scavenge收集器关注点是吞吐量(高效率的利用CPU)。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间(提高用户体验)。所谓吞吐量=CPU用于运行用户代码的时间/CPU总消耗时间;Parallel Scavenge收集器提供了很多参数功用户找到最合适的停顿时间或最大吞吐量，如果对于收集器不是太了解，建议保持默认值；

Parallel Old收集器时Parallel Scagvenge收集器的老年代版本；使用多线程和标记整理算法。在注重吞吐量以及CPU资源的场景，都可以优先考虑ParallelScavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)；

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

-XX:+UseParallelGC(年轻代) -XX:+UseParallelOldGC(老年代)

3.3 ParNew收集器

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

ParNew收集器许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器配合工作；

新生代采用复制算法；

-XX:+UseParNewGC

3.5 CMS收集器

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

CMS收集器时一种标记清除算法实现的，它的执行过程相对于前面集中垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

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

CMS收集器是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

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

3.5.1 CMS的相关核心参数

-XX:UseConcMarkSweepGC 使用CMS垃圾收集器
-XX:ConcGCThreads 并发的GC线程数
-XX:UseCMSCompactAtFullCollection FullGC之后做压缩整理(减少碎片)
-XX:CMSFullGCsBeforeCompaction 多少次FullGC之后压缩一次，默认时0，代表每次FullGC后会压缩一次
-XX:CMSInitiatingOccupancyFraction 当老年代使用率达到该比例时触发FullGC(默认92,单位百分比)
-XX:CMSInitiatingOccupancyOnly 只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设置的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
-XX:+CMSScavengeBeforeRemark 在CMS GC前启动一次minor gc,降低CMS GC标记阶段时的开销，一般CMS的GC耗时80%的时间都在标记阶段；
-XX:+CMSParallelInitialMarkEnabled 在初始标记的时候多线程执行，缩短STW
-XX:+CMSParallelRemarkEnabled 在重新标记的时候多线程执行，缩短STW

四垃圾收集底层算法

4.1 三色标记

在并发标记的过程中，因为标记期间应用线程还在继续运行，对象间的引用可能会发生变化，多标和漏标的情况就可以发生。漏标的问题主要引入了三色标记算法来解决。

三色标记算法是把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 {
}

4.2 存在的问题以及解决方案

4.2.1 多标-浮动垃圾

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

4.2.2 漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重的bug，必须要解决，有两种解决方案：增量更新和原始快照；

增量更新：当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用就下来，等并发扫描结束之后，再以这些记录的引用关系中的黑色对象为根，重新扫描一次，可以简化理解为，黑色对象一旦插入了指向白色对象的引用之后，就变回灰色对象了。
原始快照：当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录的引用关系中的灰色对象为根，重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(目的是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象可能是浮动垃圾)；

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

4.2.2.1 写屏障

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

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

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

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

写屏障实现SATB

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

void pre_write_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); // 记录读取到的对象
}

为什么G1使用SATB，CMS用增量更新解决三色标记的问题？

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