极简版 HotSpot的算法实现

本文是学习《深入理解JAVA虚拟机》的学习笔记（3）

HotSpot 的算法实现

这个比较抽象，先大概了解下

在可达性分析中，从GC Roots 节点找到所有的引用链，这个过程中逐个检查，势必会消耗大量时间。而且这执行期间还要确保一致性快照中进行。就是说检查期间，对象的引用关系不能发生变化。这就导致GC进行时必须停顿所有JAVA执行的线程，也就是所谓的“Stop The Word”。当GC停顿时，虚拟机怎样直接知道哪些地方存放着方法的引用，避免一个不漏的检查所有的上下文。在HotSpot的实现中，用OopMap来达到这个目的。

当类加载完成时，HotSpot把对象内什么偏移量上是什么 类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样GC扫描时就可以直接获得这些信息了。

安全点

在OopMap的协助下，HotSpot可以快速完成GC Roots枚举，但并不是每一条指令都生成OopMap。前文说“特定位置”记录信息，这指的就是安全点（Safepoint）。程序执行到达安全点，才可能停顿下来开始GC。让程中断在安全点有两种方案。抢先式中断和主动式中断，现在几乎所有的虚拟机都是使用主动式中断，就是GC不直接操作线程，而是给一个标志，各线程主动去轮询这个标志，线程拿到这个标志就中断挂起。轮询标志和安全点是重合的。

安全区域

当一个线程处于sleep 或blocked状态时，是无法响应JVM的中断请求的，这时就需要安全区域（Save Region）来解决。安全区域指一段代码片段中，引用关系不会发生变化，这个区域中任意开始GC都是安全的。当线程执行进入安全区域时，要标识自己已进入了。这段时间发起GC时，就不用管标识自己为Safe Region的线程。当线程离开Safe Region 时，先判断是否已完成根节点枚举，若未完成，线程先等待。

收集器

首先明确一点最好的收集器，更没有完美的收集器，我们只是在不同的场景下，选择最合适的收集器。如果真存在任何场景下都完美的收集器，那HotSpot也就没必要实现多种收集器了。

先说说新生代的收集器

Serial收集器

新生代收集器，它是最基本、发展历史最悠久的收集器。采用复制算法。啥是复制算法请看上一篇 垃圾回收算法
看它的名字，就知道这个收集器是单线程的。

“单线程”并不仅仅是说，它必需是一个CPU或一个线程执行收集工作，更重要的是，它进行行垃圾收集时，必须停止其他所有的工作线程，直至收集完成。

特点是简单高效，你想啊，停掉别的线程，只有它一个线程单独执行收集，没有线程交互的开销，可以得到最高的单线程收集效率。在Client模式下的虚拟机，是个很好的选择。

ParNew收集器

它也是新生代收集器，其实就是Serial收集器的多线程版本。除了Serial外，只有它可以与CMS收集器配合工作。在单CPU的环境中，不会比Serial收集器效果好。

Parallel Scavenge 收集器

新生代收集器，使用复制算法，并行的多线程收集器。Parallel Scavenge 收集器的目标是达到一个可控制的吞吐量（Throughput）。吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。

比如说虚拟机总共运行时间是100分钟，其中垃圾收集的时间是1分钟，那吞吐量就是99%。高吞吐量意味着高效的利用CPU时间，主要适合在后台运算而不需要太多交互的任务。

相关参数

-XX:MaxGCPauseMillis 设置最大垃圾收集停顿时间，参数的值是一个大于0的毫秒数，收集器尽可能地保证内在回收花费的时间不超过设定值。这不意味着此参数值小，GC收集就更快。GC停顿时间的缩短是以牺牲吞吐量和新生代空间来换取的。系统把新生代调小，收集300MB新生代肯定比收集500MB快。但这直接导致GC收集变频繁。原来10秒收集一次，每次停顿100毫秒，现在变成5秒收集一次，每次停顿70毫秒。停顿时间确实下降，但吞吐量也下降了。

-XX:GCTimeRatio 设置吞吐量大小。参数的值是0到100之间的整数，也就是垃圾收集时间占总时间的比率，默认值是99，就是允许最大1%（1/(1+99)）

-XX:+UseAdaptiveSizePolicy 这是一个开关参数，当打开此参数之后，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整参数（-Xmn -XX:SurvivorRatio），以提供最合适的停顿时间或最大吞量。这就是GC**自适应调节策略（GC Ergonomics）。老年代垃圾收集器，点这里