深入理解Java虚拟机：JVM高级特性与最佳实践 - 总结2

JVM 垃圾回收三部曲：

• 哪些对象需要回收
• 何时回收这些对象
• 怎样回收回收这些对象

哪些对象需要回收：

• 判断一个对象是否可回收

1. 引用计数：
   1. 定义：给对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1
   2. 问题：两个对象会出现循环引用问题，此时引用计数器永远不为 0，导致 GC 收集器无法回收。

2. 可达性（java使用此方法）：

   1. 定义：通过 GC Roots 作为起始点进行搜索，能够到达到的对象都是都是可用的，不可达的对象可被回收。

   2. GC Roots 一般包含以下内容：

      1. 虚拟机栈中引用的对象
      2. 方法区中类静态属性引用的对象
      3. 方法区中的常量引用的对象
      4. 本地方法栈中引用的对象

• 涉及概念：
  • 引用类型：
    • 强引用：只要强引用存在，垃圾回收器永远不会回收调掉被引用的对象。
    • 软引用：非必须引用，当对象只有软引用时，内存溢出之前进行回收。
      • 软引用主要用户实现类似缓存的功能，在内存足够的情况下直接通过软引用取值，无需繁忙地从真实来源查询数据，提升速度；当内存不足时，自动删除这部分缓存数据，从真正的来源查询这些数据。
    • 弱引用：当对象只有弱引用时，只能生存到下一次垃圾收集发生之前，当垃圾收集器工作时，无论当前内存是否足够，都会被回收。
    • 虚引用：又称为幽灵引用或者幻影引用，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

方法区的回收：

作用：主要是对常量池的回收和对类的卸载

常量池的回收和堆中对象回收类似。

类的卸载条件很多，需要满足以下三个条件，并且满足了也不一定会被卸载：

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

可以通过 -Xnoclassgc 参数来控制是否对类进行卸载。

在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGo 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载功能，以保证不会出现内存溢出。

 

怎样回收回收这些对象

具体的垃圾回收算法：

• 标记 - 清除算法：将需要回收的对象进行标记，然后清除。如图所示：

  • 不足：

    • 标记和清除过程效率都不高

    • 会产生大量碎片

  • 作用：之后的算法都是基于该算法进行改进。

• 复制算法：将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。如图所示：
  • 不足：是只使用了内存的一半。
  • 作用：当每次能够有大量对象回收时，推荐使用该算法或该算法的变种。例如，现在的商业虚拟机都采用这种收集算法来回收新生代，但是并不是将内存划分为大小相等的两块，而是分为一块较大的 Eden 空间和两块较小的 Survior 空间，每次使用 Eden 空间和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上，最后清理 Eden 和 Survivor。HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1，保证了内存的利用率达到 90 %。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 空间就不够用了，需要依赖于老年代进行分配担保，也就是借用老年代的空间。
• 标记-整理算法：让所有存活的对象都向一段移动，然后直接清理掉端边界以外的内存。

• 分代收集算法:

  现在的商业虚拟机采用分代收集算法，它使用了前面介绍的几种收集算法，根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。

  一般将 Java 堆分为新生代和老年代。

• 新生代使用：复制算法
• 老年代使用：标记 - 清理 或者 标记 - 整理 算法。

Hotspot 算法实现

枚举根节点

可达性分析效率问题：

1. 以可达性分析中从 GC Roots 节点找引用链这个操作为例，可作为 GC Roots 的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中, 现在很多应用仅仅方法区就有数百兆，如果要逐个检査这里面的引用，那么必然会消耗很多时间。为此在 HotSpot 的实现中，使用一组称为 OopMap 的数据结构来加快查找 GC Roots 节点的效率，

   1. 在类加载完成的时候，HotSpot 就把对象内什么偏移量上是什么类型的数据计算出来。

   2. 在 JIT 编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样,GC 在扫描时就可以直接得知这些信息了。

2. 可达性分析对执行时间的敏感还体现在 GC 停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行——这里“一致性”的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。这点是导致 GC 进行时必须停顿所有 Java 执行线程（Sun 将这件事情称为“Stop The World”）的其中一个重要原因，即使是在号称（几乎）不会发生停顿的 CMS 收集器中，枚举根节点时也是必须要停顿的。

GC安全点和安全区域 Safe-point (or safepoint)
　　

　　但是对每一个指令都保存那些信息太昂贵了。 它需要大量空间保存那些信息。 这是不必要的，因为 只有一小部分指令有机会在实际执行时阻塞。 JIT只需要保存那部分指令的信息就够了-- 他们就把叫做安全点。安全点意味着对应根枚举来说，在该点阻塞是安全的。顺便说一下，并不是所有编程语言的编译器都能够确切知道堆栈信息。 只有安全语言有这个能力。 比如， C/C++就没有。

函数阻塞 Mutator suspension
　　对于安全点，现在的问题是，我们怎么保证函数在安全点阻塞。有两种基本方法来阻塞当前函数，抢先或者自愿。抢先式的方法是无论任何时候GC需要进行一次收集，它都立即阻塞当前函数的执行。当它发现函数被阻塞在一个不安全的点时，它会恢复函数执行，向前滚动到一个安全点。这种方法在ORP【1】中实现，它是Harmony的前一个版本。但是，目前几乎没有JVM使用这种方法。在Harmony中实现的方法是自愿阻塞。当GC触发一次垃圾回收，它只是简单的设置一个标志； 当前执行函数会轮询这个标志， 当发现这个标志置位的时候，他们就会阻塞。那些轮询的点都是安全点。 多数情况下， JIT负责在合适的位置插入轮询程序。 有时，VM也需要有一些轮询点。
轮询点 Polling point
　　那么哪里是正确轮询GC触发事件的地点呢？ 就像我们上面讨论的，我们不想在每一个指令处都设置轮询点。 对于自愿阻塞，一个更严重的问题是轮询负载。因此插入轮询点需要遵循一些基本原则：

1. 第一，轮询点应该足够频繁，以便GC不需要等待当前函数阻塞的时间太长， 因为其他函数还在等着GC释放空间来继续执行。
2. 第二，轮询点不能太多，导致增加运行负载过重。

　　最好的结果是刚好有足够的轮询点满足需求：

1. 一类强制的轮询点是内存分配点。分配可以触发一次垃圾收集，因此分配必须是安全点
2. 长时间的执行总是和方法调用或者循环 有关。因此，调用点和循环回边点也是期望的轮询点　　

　　这些就是Harmony中的轮询点： 分配点，调用点和循环回边点。 多数情况下运行时负载小于1%。 不幸的是，我们发现单独安全点是不够的。

安全区域 Safe-region
　　为什么不够呢？ 因为我们忘掉了一种常见执行的情况。我们忘了它，因为它实际上不是长时间执行，而是长时间闲置。有这样一类情况程序不能及时响应GC触发事件，比如sleep，因系统调用阻塞。 这些操作不是JVM能够控制的。JVM在此期间不能够响应GC事件。 因此，我们引入了安全区域的概念来解决这个问题。

　　安全区域是其中引用不会改变的一段代码片段，那么在其中任一点进行根枚举都是安全的。 换句话说，安全区域是安全点的一个很大的扩展。

　　在安全点的设计中，如果GC触发事件发生了，执行函数通过轮询进行响应。它通过设置一个准备好的标志（ready flag）来响应。 那么GC就可以进行根枚举了。这是一个握手协议。

　　安全区域也遵循这个协议。执行函数在进入安全区域时设置ready flag。在它离开安全区域以前，它先检查GC是否完成了枚举（或者收集），并且不再需要执行函数呆在阻塞状态。如果是真的，它就向前执行，离开安全区域； 否则，它就像安全点一样阻塞他自己。

　　在Harmony的实现中，我们插入 suspend_enable 和 suspend_disable来标志安全区域的界限。

具体JVM在垃圾回收时怎样应用如上算法，如下所示：

 垃圾收集器：

以上是 HotSpot 虚拟机中的 7 个垃圾收集器，连线表示垃圾收集器可以配合使用。