笔记：JVM - 垃圾回收与锁机制

堆和方法区是线程共享的；另外 JVM 规范并没有要求一定要对方法区进行 GC ，因此堆是 GC 的工作重点。

FullGC 是收集整个堆和方法区。

* 堆中不存在该类及其子类的实例；

* 加载该类的类加载器已经被回收（该条件很难达成。因为类本身会引用加载它的类加载器？）；

* 该类的 Class 对象没有被引用。

由于垃圾对象是可能通过 finalize() 方法复活的，因此虚拟机中对象的状态可以是下面三种之一：

1. 可触及的：即根可达的；
2. 可复活的：根不可达，但重写了 finalize() 方法且该方法未被调用（有机会复活）；
3. 不可触及的：根不可达，且没有重写 finalize() 方法或已经调用了 finalize() 但还是不可达，这种情况下对象才会被回收。

public void method1(){
    {
        MyBigObject o = new MyBigObject();
    }
    
    //执行到这里 o 指向的对象不会被回收
    //因为该对象的地址仍然存在于栈帧的局部变量表的第 2 个 slot 中，第 1 个 slot 当然就是 this 了
    System.gc();
}
 
public void method2(){
    {
        MyBigObject o = new MyBigObject();
    }
    int tem = 1;
    
    //执行到这里 o 指向的对象会被回收
    //因为 slot 复用，使得栈帧中局部变量表的第 2 个 slot 已经变成了 1
    System.gc();
}

存疑：当一个线程出现 OOM 时，该线程会结束，并且释放该线程所占用的堆空间，对其它线程来说相当于发生了 GC 。

创建软/弱/虚引用时都可以指定一个队列，当软/弱/虚引用指向的对象被回收时，这个引用会被放入到那个队列中。

软/弱/虚引用本身也是一个对象，且被一个强引用所引用。

保证 GC 时用户线程都执行到了安全点的方式有两种：

* 抢先式中断（目前的虚拟机已不再采用）：中断所有线程，如果有线程没执行到安全点，则恢复它，让它执行到安全点；

* 主动式中断：设置一个中断标志，线程执行到安全点后检查这个标志，如果标志为真则将自己中断挂起。

吞吐量高，则程序运行速度快，适合那些在后台运算而不需要太多交互的任务，因此在服务器环境中很常用。

暂停时间短，则用户体验好，这对交互式应用程序来说是非常重要的。

可通过 -XX:GCTimeRatio 和 -XX:MaxGCPauseMillis 参数设置期望的最大的垃圾收集开销和单次 GC 最大的停顿时间。

28. 7 个经典的垃圾收集器如下图所示。

红色虚线表示 JDK 8 中不建议使用这样的组合关系，JDK 9 中彻底取消了这种组合关系；

绿色虚线表示 JDK 14 中删除了这种组合关系/垃圾收集器；

青色虚线表示 JDK 9 中不建议使用 CMS ，JDK 14 中删除了 CMS 。

29. 可通过 -XX:+PrintCommandLineFlags 参数来打印出命令行参数（其中就包含使用了哪个垃圾收集器的信息）。当启用了某个垃圾回收器时，与它相配合的垃圾回收器也会默认启用，比如使用 -XX:UseConcMarkSweepGC 开启 CMS 收集器时，ParNew 收集器也会默认启用。

30. 垃圾收集器的比较：

• 并行收集器更关注吞吐量，Java 8 默认的 GC 收集器。
• CMS 和 G1 更关注暂停时间，在延迟可控的情况下尽可能提高吞吐量，适合用于服务端。
• 串行收集器实现简单，没有切换线程的开销，因此在硬件配置较低时（如只有一个单核 CPU ）或者 Client 模式下，它的效果甚至是最好的。

Serial Old 在 Client 模式下是默认的老年代收集器；在 Server 模式下则主要与 PS 配合使用或者作为 CMS 的后备垃圾收集方案。

如果多核 CPU 使用了串行的收集器，那么 GC 时只会有一个 CPU 运行垃圾收集线程，而用户线程必须暂停（即使有空闲的 CPU）。

并行收集器 GC 线程的默认数量（ParallelGCThreads）：CPU 个数 count 小于 8 时，就是 count 个；大于 8 时，是 3 + [[5 * count] / 8 ] 个。

CMS 收集器 GC 线程的默认数量（ParallelCMSThreads）：[(ParallelGCThreads + 3) / 4] 个。

CMS 收集器的和用户线程并发的 GC 线程的数量用 -XX:ConcGCThread 参数指定，一般是并行线程数的 1/4 。

PS 收集器和 ParNew 收集器的区别：

* 底层框架不同，因此 ParNew 可以和 CMS 配合工作，而 PS 不可以。PS 和 ParallelOld 底层框架是自成一派的。

* PS 是吞吐量优先的，并且有自适应调节策略。PS 比 ParNew 更早出现。

由于最耗时的并发标记和并发清理工作都是可以和用户线程并发执行的，因此总体上程序是低延迟的。

由于 GC 线程和用户线程并发工作，因此不能等到内存不足时才 GC ，而是当堆使用率达到阈值（JDK 6 前默认 68% ，JDK 6 开始默认 92%，用 -XX:CMSInitiatingOccupancyFraction 参数指定）时，就开始 GC ，确保用户线程在 GC 期间仍然有足够的空间来支持程序的运行。

如果用户线程产生垃圾的速度大于 GC 线程回收垃圾的速度（或者老年代内存碎片过多），从而导致用户线程空间不足，就会产生一次 "Concurrent Mode Failure" ，这时候 JVM 将采用备用的 Serial Old 收集器来对老年代进行垃圾回收和内存整理，导致停顿时间变长。

CMS 回收的是老年代，此时新生代中的对象可能作为 GC Roots ，因此在重新标记阶段，需要扫描新生代，看看新生代的对象是否引用了老年代中的对象；可以通过 -XX:+CMSScavengeBeforeRemark 参数让 CMS 在重新标记前先进行 YGC ，以缩短重新标记阶段的扫描时间。

CMS 优点是低延迟、并发收集；缺点有：

* 产生内存碎片，因此在若干次 GC 后需要进行碎片整理；

* 对 CPU 资源非常敏感，并发阶段虽然不会导致用户线程暂停，但总的吞吐量是降低了的（暂停时间和吞吐量的矛盾性）；

* 无法处理浮动垃圾：比如在并发标记中，某个对象已经被 CMS 标记为可达的，但如果此时用户线程取消了对该对象的引用（即该对象事实上已经变成了垃圾），就会导致该对象在此次 GC 中不会被回收。

在并发标记阶段，可能会出现两种特殊情况，注意辨别这两种情况：

1. 一个对象可能原本已经是垃圾了，但此时用户线程又重新引用了这个对象。重新标记阶段就是为了防止这样的漏标对象被误回收。

2. 一个对象可能原本已经被 CMS 标记为可达的，但此时用户线程取消了对该对象的引用。这时候该对象就是浮动垃圾。

G1 并不是全方面优于 CMS ，G1 会有更高的内存占用（比如需要维护 Remember Set）和额外执行负载。一般来说，内存在 6 到 8 GB 之间时，两者性能差不多；内存比 6 GB 小时 CMS 更有优势，内存比 8GB 大则 G1 有优势。

G1 的 Region 大小可以用 -XX:G1HeapRegionSize 参数来设置，必须是 2 的 N 次幂，且在 1 到 32 MB 之间。

而 Region 的个数相对而言比较固定，G1 会尽量将堆内存划分成 2048 个 Region ，因此 Region 的大小默认是堆内存的 1 / 2000。

所有 Region（除了 Humongous ）的大小相同，且在 JVM 生命周期内大小不会改变。对象大于 0.5 个 Region 时会被分配到 Humongous 区；如果 1 个 H 区还放不下，则分配到连续的 1 块 H 区。由于 H 区存放的是大对象，因此 H 区一般也可以看作是老年代的一部分。G1 不会拷贝大对象，GC 时优先考虑大对象；当老年代不再引用某个大对象时，这个大对象会在下次 YGC 时被回收。

G1 的设计原则是简化 JVM 性能调优，一般我们只需要设置堆的最大大小和允许的最大停顿时间即可，其余的交给 G1 来调整。

当 G1 的 GC 线程较慢时，G1 还可以调用应用线程来承担后台运行的 GC 工作，加速垃圾回收。

33. G1 的垃圾回收模式：YoungGC ，MixedGC ，FullGC 。G1 的垃圾回收过程有 4 个环节，最主要的是前 3 个：

1. YoungGC：Eden 区用尽时开始 YoungGC ，使用一个并行的独占式的收集器来完成垃圾回收。
2. Concurrent Marking：当堆使用率达到阈值（用 -XX:InitiatingHeapOcuppancyPercent 指定，默认 45% ；JDK 9 前，阈值设置完就固定下来了；JDK 9 开始，这个参数设置的只是初始值，允许 G1 对阈值进行动态调整，从而尽量避免退化成 FullGC ）时，开始老年代并发标记。
3. MixedGC：并发标记完成后，G1 会将最具回收价值的老年代 Region 中存活的对象复制到空闲区中，后者变成了老年代的一部分，而前者变回空闲区；除了老年代，新生代在该阶段也会被回收，这也是"混合回收"这个名字的由来。
4. FullGC：是备用的、独占式的、单线程的、高强度的垃圾回收方案，主要是作为一种失败保护机制。

问题引入：位于 E 区的对象 A 是可能被位于 O 区的对象引用的，那么，进行 YoungGC 时，为了确定 A 是不是垃圾，我们还得把所有 O 区扫描一遍，即全局扫描，这会大大影响效率（这和我们之前提到的老年代的对象可能临时性地成为根对象相对应）。在各种分代收集器中，这种现象是普遍存在的，在 G1 尤其突出（因为 Region 多，且堆内存大）。

记忆集就是用来避免全局扫描的。每个 Region 都有一个记忆集，如果 Region 2 上的对象 B 引用了 Region 1 上的对象 A ，那么 Region 1 的记忆集就会记录：Region 2 上的对象 B 引用了我上面的对象（应该不用记录下来具体引用的是我上面的哪个对象）。

一个 Region 又会被分成很多个卡，如果老年代的卡上的对象引用了新生代上的对象，则该卡被标记为脏卡。

进行 YGC 时，脏卡上的对象作为 GC Roots ，而无需扫描整个老年代。

执行了 son.father = father; 之类的语句时，需要更新 Rset ，但对 Rset 的处理需要线程同步；因此，为了提高性能，JVM 仅仅是把相关的信息放到 Dirty Card Queue 中（其中还会使用到 Post-write Barrier）；在进行 YoungGC 时，G1 才会对该队列中所有 Card 进行处理以更新 Rset 。

G1 是通过 SATB 算法来解决漏标问题的，涉及到 pre-write barrier 和 satb_mark_queue ，具体可自行了解。

并发标记后，G1 还可以知道哪些类不再被使用了，从而卸载这些类。通过 -XX:ClassUnloadingWithConcurrentMark 参数启用（默认启用）。

JDK 9 对 G1 进行了很多的增强，G1 也成为了 JDK 9 的默认垃圾回收器。

如果 MinorGC 和 FullGC 频繁，则可能是新生代过小导致的；新生代过小导致 MinorGC 频繁，同时也会让一些生存周期短的对象晋升到老年代，从而又导致 FullGC 频繁。CMS 停顿时间长，则可能是因为重新标记阶段需要搜索的对象过多；此时可以在重新标记前先进行 YGC ，从而减少需要搜索的对象。JDK 8 之前，如果老年代空间充裕，但发生了 FullGC ，则是因为永久代空间不足。

可以通过参数 -XX:BiasedLockingStartupDelay 来设置偏向锁在 JVM 启动多久后才打开。

在启动偏向锁功能后，新创建的对象默认处于偏向锁状态（即匿名偏向）；锁膨胀的过程为：偏向锁 -> 轻量级锁 -> 重量级锁。

在调用了一个对象的 hashCode() 方法后，如果对该对象进行加锁，那么会直接用轻量级锁而不是偏向锁，因为使用偏向锁需要在对象的 MarkWord 中记录一些信息（主要是该锁偏向的那个线程的 ID ），导致该对象的哈希值没地方存放。轻量级锁不会导致哈希值的丢失，因为轻量级锁会将 LR 指针存放到锁对象的 MarkWord 中，而 LR 中记录了该对象的哈希值。

重量级锁对象的 MarkWord 存放在它对应的 Monitor 中，解锁时再将 Monitor 中的数据还原到锁对象中。

偏向锁在解锁后，其 MarkWord 依然是记录之前偏向的那个线程的 ID 而不是清除掉它。

撤销偏向锁的方式：调用锁的 hashCode() 方法，多个线程争夺该锁，调用锁的 wait()/notify() 方法（因为只有重量级锁有这些方法）。

JVM 发现有 19 个锁在被线程 1 获取后又被线程 2 获取，且线程 2 还要继续获取偏向于线程 1 的锁，因此直接让后面的锁直接偏向线程 2 。

注意这里说的批量重偏向和批量撤销可能有误，可以自行去详细了解。