深入理解JVM--垃圾回收机制

垃圾回收机制

总结自 周志明的《深入理解 Java 虚拟机》

抛出问题，带着问题去学习

• 哪些内存需要回收？
• 什么时候回收？
• 怎么回收？

如何判断对象是否死亡

引用计数器

​ 给对象加一个引用计数器，每有一个地方引用它时，那么计数器就 +1 ，当引用失效时就 -1 ，如果等于 0 的话这个对象就不可能再被引用了，即判断对象死亡。

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

缺点：没有办法解决循环引用的问题

public class GCTest {

    public Object instance = null;
	//为了占内存
    private static final int _1MB =  1024 *1024;

    private byte[] bigSize = new byte[2 * _1MB];

    public static void main(String[] args) {
        GCTest objA = new GCTest();
        GCTest objB = new GCTest();
	    //循环引用
        objA.instance = objB;
        objB.instance = objA;

        objA=null;
        objB=null;

        System.gc();
    }
}

​ 在这种情况下，虽然 objA、objB 都等于 null 了，实际上这两个对象不可能访问到了，但是他们之间还是互相引用着，所以计数器无法通知 GC 收集器去回收他们。

可达性分析算法

​ 现在主流的回收机制都是用可达性分析来判定对象是否存活的。

​ 从 GCROOTS 开始，从这些结点开始向下搜索，所走过的路径称为引用链，当一个对象到 GCROOTS 没有任何引用链的时候，那么就说明这个对象是不可用的，判定为可回收对象。

可作为 GCROOTS 的对象包括下面几种：

1. 虚拟机栈（栈帧中的本地变量表）中的引用对象
2. 方法区中类静态属性引用的对象
3. 方法区中常量引用的对象
4. 本地方法栈中的JNI（Java Native Interface）引用的对象

再谈引用

JDK 1.2 之前的引用很传统，reference 类型的数据就是另外一块内存的起始地址，JDK 1.2 之后对引用的概念进行了扩展：强引用、软引用、弱引用、虚引用

强引用

​ 在程序中很普遍，类似 “Object obj = new Object()” ，只要强引用还在，GC 就永远不会回收它，宁肯抛出 OOM ，也不会来回收强引用类型的对象

软引用

​ 用来描述还有用但非必需的对象。也就是说内存足够的情况下，GC 不会回收它，程序还可以照常使用。但是如果出现内存不足的情况，那么 GC 就会回收它，如果还不够才会抛出 OOM 异常，softReference 类实现软引用

弱引用

​ 也是类似软引用一样有用但非必需的，即可有可无的。但是引用的强度会比软引用要低一些，被弱引用引用的对象只能存活到发生下一次垃圾回收之前。当 GC 开始回收时，不管内存是否充足都会回收掉被关联的对象，weakReference。

虚引用

​ 又称幽灵引用和幻影引用，是最弱的一种引用，他与软引用和弱引用的区别就是它必须和引用队列联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

​ 引用的使用，弱引用和虚引用的使用很少，软引用也比较多，因为软引用可以加速JVM 对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生。

不可达对象并非“非死不可”

​ JVM 虚拟机判断一个对象死亡时，至少要经过两次标记的过程：

​ 如果对象在进行可达性分析后发现无与 GCROOTS 相连的引用链，那么这时会被第一次标记，并进行一次筛选：筛选的条件是是否有必要执行 finalize() 方法，如果对象没有覆盖 finalize() 方法，或者已经被调用过一次这个方法，那么都没必要执行 finalize() 方法。即一个对象的 finalize() 方法，只会执行一次

​ 如果有必要执行，那么就会进入一个队列，在这个队列里执行 finalize() 方法，finalize() 方法是对象逃脱死亡的最后一次机会，如果对象自救成功，那么在虚拟机对队列进行二次标记的时候就会被拿出来，剩下的就会被回收。

回收方法区

如何判断一个常量是废弃常量

运行时常量池主要回收的是废弃的常量。

​ 假如在常量池中存在字符串 “abc”，如果当前没有任何 String 对象引用该字符串常量的话，就说明常量 “abc” 就是废弃常量，如果这时发生内存回收的话而且有必要的话，”abc” 就会被系统清理出常量池。

（重点补充）

JDK 1.7 后的版本把运行时常量池从方法区中移出来了，Java 堆（Heap）中开辟了一块空间存放运行时常量池。

JDK 1.8 移除整个永久代，取而代之的是叫元空间的区域。

如何判断一个类是无用的类

方法区主要回收的是无用的类，那么如何判断一个类是无用的类的呢？

判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面 3 个条件才能算是 “无用的类” ：

• 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
• 加载该类的 ClassLoader 已经被回收。
• 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样不使用了就会必然被回收。

垃圾收集算法

标记-清除算法（后续算法的基础）

​ 该算法分为两个阶段：先标记、后清除。作为最基础的算法有两个问题：

1. 效率问题

2. 垃圾回收后空间问题（会产生大量的内存碎片）

   大量的内存碎片可能导致，后来要分配比较大的对象时，会因为内存空间不足而在此触发 GC 动作。

复制算法

​ 把可用的内存空间分为大小相同的两块，当一块空调用完时，就将还存活的对象复制到另一边的内存上，然后再将已使用过的内存空间全部清理掉。这样每次只针对一般的空间进行回收，也不会产生内存碎片的情况。

​ 主流的虚拟机都采用这种算法来处理新生代。新生代的对象 98% 都是朝生暮死的，所以将新生代的内存布局分配为 Eden区、From Survivor区、To Survivor区，大小为 8:1:1 ，对象优先在 Eden 区上分配

​ 上图的 eden、s0(From)、s1(To)区都属于新生代，tentired 区属于老年代。大部分情况都是直接在 eden 上直接分配，在新生代回收过一次后，如果仍有对象存活这时候会进入 s1(To)，并且对象的年龄会 +1 ，当它的年龄到达一定程度的时候（默认是 15 岁，年龄的阈值可以通过 JVM 参数设置），就会被放到老年代。如果存活的对象大于 To Survivor 区的大小，那么就会通过分配担保机制将这些对象放入老年代。而分配完后，会将 to 和 from 对换一直保证 To的空间是空闲的，因此会有 10% 空间的浪费。Minor GC会一直重复这样的过程，直到“To”区被填满，”To”区被填满之后，会将所有对象移动到老年代中。

标记-整理算法

​ 复制收集算法在对象存活率较高的情况下，效率就会比较低下。如果发生这种存活率 100% 的情况，那么复制算法显然是不适合的而且还会占用大量的空间，所以在老年代中不能采取这样的算法。

​ 所以根据老年代的特点，有一种标记-整理算法，它与标记-清除算法很像，但是标记完后不是直接删除，而是将所有存活的对象向一端移动，然后清理掉端边界以外的内存。

分代-收集算法

• 新生代：存活率低–复制算法
• 老年代：存活率高–标记-清除算法、标记-整理算法

垃圾收集器

Serial收集器

​ 是最基本、发展历史最悠久的收集器。Serial（串行）看名字就知道是单线程收集器。不过这里的 “单线程” 的意义不仅仅意味着它只会用一条垃圾收集线程去完成收集工作，而且在它工作收集的时候，还必须暂停用户当前的所有线程，直至它工作结束

新生代采用复制算法，老年代采用标记-整理算法。用在 client 模式下的虚拟机上会不错。

ParNew收集器

​ ParNew 收集器其实就是 Serial 收集器的多线程版本，实际实现上也公用了许多代码。支持多个垃圾收集线程去执行收集任务，但是还是会暂停用户线程。

新生代采用复制算法，老年代采用标记-整理算法。运行在 Server 模式下的虚拟机的首选

除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器，后面会介绍到）配合工作。

并行和并发概念补充：

• 并行（Parallel） ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
• 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个 CPU 上。

Parallel Scavenge收集器

​ 它与 ParNew 收集器几乎一模一样，都是多线程收集器

JVM 参数：
-XX:+UseParallelGC 
    //使用 Parallel 收集器+ 老年代串行
-XX:+UseParallelOldGC
    //使用 Parallel 收集器+ 老年代并行

Parallel Scavenge 收集器关注的是吞吐量（高效的利用cpu），而 CMS 等垃圾收集器注重的是用户线程的停顿时间（提高用户体验），吞吐量就是 cpu 中用于用户运行代码的时间和 cpu 的总运行时间的比值。

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

Serial old 收集器

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

Parallel old 收集器

​ 一样是 Parallel Scavenge 收集器的老年代版本。标记-整理算法

CMS 收集器（Concurrent Mark Sweep）

​ CMS 收集器以最短停顿时间为目标，注重用户的使用体验。

​ CMS 收集器是第一个真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

​ 从名字可以看出 Mark Sweep 使用的是标记-清除算法，实现也更加复杂，整个过程分为四部分：

1. 初始标记：暂停所有其他的线程，并记录下直接与 root连接的对象，速度很快
2. 并发标记：同时开启 GC 线程和用户线程，用一个闭包结构记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以无法保证实时性，所以这个算法会跟踪记录这些发生引用更新的地方。
3. 重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
4. 并发清除： 开启用户线程，同时 GC 线程开始对为标记的区域做清扫。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：

• 对 CPU 资源敏感；
• 无法处理浮动垃圾；
• 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。

G1 收集器

​ G1 收集器是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征。

​ hotspot 团队想让它将来替代 CMS 收集器

被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备一下特点：

• 并行与并发：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。
• 分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。
• 空间整合：与 CMS 的“标记–清理”算法不同，G1 从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
• 可预测的停顿：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。

G1 收集器的运作大致分为以下几个步骤：

• 初始标记
• 并发标记
• 最终标记
• 筛选回收

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来)。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 GF 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

内存分配策略

​ 对象优先在 eden 区上分配，如果 eden 区的空间不足以分配，那么虚拟机将发起一次 Minor GC

• 新生代 GC（Minor GC）:指发生新生代的的垃圾收集动作，Minor GC 非常频繁，回收速度一般也比较快。
• 老年代 GC（Major GC/Full GC）:指发生在老年代的 GC，出现了 Major GC 经常会伴随至少一次的 Minor GC（并非绝对），Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。

​ 大对象会直接分配在老年代（比如：数组、字符串），为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。

​ 长期存活的对象也会进入老年代，默认年龄 15 进入，但是虚拟机有动态对象年龄判定如果 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需达到要求的年龄。

打印 GC 日志

//虚拟机参数
-XX:+PrintGCDetails

老年代年龄阈值

//虚拟机参数
-XX:MaxTenuringThreshold