存储器的分配与回收算法实现_[干货] JAVA - JVM - 12 内存回收-跟搜索算法的 HotSpot 实现...

目录：

[干货] JAVA - JVM - 1 JVM一套带走

[干货] JAVA - JVM - 2 内存两分

[干货] JAVA - JVM - 3 字符串常量池

[干货] JAVA - JVM - 4 类加载

[干货] JAVA - JVM - 9 内存回收

[干货] JAVA - JVM - 10 内存回收-跟搜索算法

[干货] JAVA - JVM - 11 内存回收-回收策略

[干货] JAVA - JVM - 12 内存回收-跟搜索算法的 HotSpot 实现

[干货] JAVA - JVM - 13 内存回收-HotSopt 的分代策略和收集器

[干货] JAVA - JVM - 14 内存并发- JMM Volatile CAS

[干货] JAVA - JVM - 15 内存并发-Synchronize wait notify

---

根枚举算法和 OOPMap

在根枚举算法中，栈中的本地变量表是CGRoot之一。扫描本地变量表中的所有数据，如果是引用类型，就意味着它所引用的对象是不可回收的。但问题是，栈上的本地变量表里面只有一部分数据是 Reference 类型的(它们是我们所需要的)，那些非 Reference 类型的数据对我们而言毫无用处，但我们还是不得不对整个栈全部扫描一遍，这是对时间和资源的一种浪费。

一个很自然的想法是，能不能用空间换时间，在某个时候把栈上代表引用的位置全部记录下来，这样到真正 gc 的时候就可以直接读取，而不用再一点一点的扫描了。事实上，大部分主流的虚拟机也正是这么做的，比如 HotSpot ，它使用一种叫做 OopMap 的数据结构来记录这类信息。

类加载完成后，jvm就把对象内的数据是基本类型还是引用类型计算出来放到OOPMAP中了，随着JIT也会更新。

安全点 SafePoint

但是随着而来的又有一个问题，就是在方法执行的过程中， 可能会导致引用关系发生变化，那么保存的OopMap就要随着变化。如果每次引用关系发生了变化都要去修改OopMap的话，这又是一件成本很高的事情。所以这里就引入了安全点的概念。

什么是安全点？OopMap的作用是为了在GC的时候，快速进行可达性分析，所以OopMap并不需要一发生改变就去更新这个映射表。只要这个更新在GC发生之前就可以了。所以OopMap只需要在预先选定的一些位置上记录变化的OopMap就行了。这些特定的点就是SafePoint(安全点)。由此也可以知道，程序并不是在所有的位置上都可以进行GC的，只有在达到这样的安全点才能暂停下来进行GC。

既然安全点决定了GC的时机，那么安全点的选择就至为重要了。安全点太少，会让GC等待的时间太长，太多会浪费性能。所以安全点的选择是以程序“是否具有让程序长时间执行的特征”为标准的(NaNa 注：这句话是从书上看来的，不知道作者自己能不能看明白这话啥意思，反正我是看不懂)，所以我们这里了解一下结果就行了。一般会在如下几个位置选择安全点：

循环的末尾

方法临返回前 / 调用方法的call指令后

可能抛异常的位置

安全区

安全点的使用似乎解决了OopMap计算的效率的问题，但是这里还有一个问题。安全点需要程序自己跑过去，那么对于那些已经停在路边休息或者看风景的程序(比如那些处在Sleep或者Blocked状态的线程)，他们可能并不会在很短的时间内跑到安全点去。所以这里为了解决这个问题，又引入了安全区域的概念。

安全区域很好理解，就是在程序的一段代码片段中并不会导致引用关系发生变化，也就不用去更新OopMap表了，那么在这段代码区域内任何地方进行GC都是没有问题的。这段区域就称之为安全区域。线程执行的过程中，如果进入到安全区域内，就会标志自己已经进行到安全区域了。那么虚拟机要进行GC的时候，发现该线程已经运行到安全区域，就不会管该线程的死活了。所以，该线程在脱离安全区域的时候，要自己检查系统是否已经完成了GC或者根节点枚举(这个跟GC的算法有关系)，如果完成了就继续执行，如果未完成，它就必须等待收到可以安全离开安全区域的Safe Region的信号为止。

---

未完待续