OopMap与安全点和安全区域与RememberedSet

首先: 首先非常感谢原文作者的分享，这几天我也是在读周志明老师的<深入理解JVM虚拟机> 感觉对OopMap 和 RememberdSet解释很困惑的时候,然后看了很多文章都没用找到通俗易懂的解释,然后突然发现了这个帖子,反正对于我这个菜鸟来说,我看懂了,就总结一下吧

原文地址：http://dsxwjhf.iteye.com/blog/2201685

OopMap 用于根节点枚举

​ 首先:对于HotSpot虚拟机来说,OopMap主要就是用来实现准确GC 但是OopMap记录了栈上本地变量到堆上对象的引用关系用于根节点枚举 肯定是基础啦

其作用是：垃圾收集时，收集线程会对栈上的内存进行扫描，看看哪些位置存储了 Reference 类型。如果发现某个位置确实存的是 Reference 类型，就意味着它所引用的对象这一次不能被回收。但问题是，栈上的本地变量表里面只有一部分数据是 Reference 类型的（它们是我们所需要的），那些非 Reference 类型的数据对我们而言毫无用处，但我们还是不得不对整个栈全部扫描一遍，这是对时间和资源的一种浪费。

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

​ 我们知道，一个线程意味着一个栈，一个栈由多个栈帧组成，一个栈帧对应着一个方法，一个方法里面可能有多个安全点。 gc 发生时，程序首先运行到最近的一个安全点停下来，然后更新自己的 OopMap ，记下栈上哪些位置代表着引用。枚举根节点时，递归遍历每个栈帧的 OopMap ，通过栈中记录的被引用对象的内存地址，即可找到这些对象（ GC Roots ）。

​ 通过上面的解释，我们可以很清楚的看到使用 OopMap 可以避免全栈扫描，加快枚举根节点的速度。但这并不是它的全部用意。它的另外一个更根本的作用是，可以帮助 HotSpot 实现准确式 GC （个人感觉这才是 OopMap 被设计出来的根本原因，提高 GC Roots Enumeration 速度更像是一个“意外的惊喜”）。

总结oopMap的作用

• 可以避免全栈扫描，加快枚举根节点的速度
• 可以帮助HotSpot实现准确式GC

安全点

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

​ 并不需要一发生改变就去更新这个映射表。只要这个更新在GC发生之前就可以了。所以OopMap只需要在预先选定的一些位置上记录变化的OopMap就行了。这些特定的点就是SafePoint（安全点）。由此也可以知道，程序并不是在所有的位置上都可以进行GC的，只有在达到这样的安全点才能暂停下来进行GC。

安全点的选择我引用周志明老师书里的一句话:安全点位置的选取基本上是以“是否具有让程序长时间执行的特征”为标准进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而长时间执行，“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。
如何让程序在要进行GC的时候都跑到最近的安全点上停顿下来，有两种方法:1.抢断式中断，2.主动式中断

​ 抢断式中断:当发生gc的时候执行的所有线程全部堵塞,然后将没到达安全点的线程再运行到安全点,这时到达安全点的线程还是在被堵塞着,这样的方式无疑是可用性非常低的,所以目前都是主动式，设置一个标志，当程序运行到安全点时就去轮训该位置，发现该位置被设置为真时就自己中断挂起

安全区域

周志明老师书中:

​ 在使用Safepoint似乎已经完美地解决了如何进入GC的问题，但实际上情况却并不一定。Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但如果程序在“不执行”的时候呢？所谓程序不执行就是没有分配CPU时间，典型的例子就是处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，JVM也显示不太可能等待线程重新分配CPU时间。对于这种情况，就需要安全区域（SafeRegin）来解决了。

​ 在安全区域中可以说这里面的线程都是安全的,不会导致引用关系发生变化,可以做任何事情,包括GC

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

RememberedSet

​ RememberedSet 用于处理这类问题：比如说，新生代 gc （它发生得非常频繁）。一般来说， gc 过程是这样的：首先枚举根节点。根节点有可能在新生代中，也有可能在老年代中。这里由于我们只想收集新生代（换句话说，不想收集老年代），所以没有必要对位于老年代的 GC Roots 做全面的可达性分析。但问题是，确实可能存在位于老年代的某个 GC Root，它引用了新生代的某个对象，这个对象你是不能清除的。那怎么办呢？

​ 仍然是拿空间换时间的办法。事实上，对于位于不同年代对象之间的引用关系，虚拟机会在程序运行过程中给记录下来。对应上面所举的例子，“老年代对象引用新生代对象”这种关系，会在引用关系发生时，在新生代边上专门开辟一块空间记录下来，这就是 RememberedSet 。所以“新生代的 GC Roots ” + “ RememberedSet 存储的内容”，才是新生代收集时真正的 GC Roots 。然后就可以以此为据，在新生代上做可达性分析，进行垃圾回收。

​ 我们知道， G1 收集器使用的是化整为零的思想，把一块大的内存划分成很多个域（ Region ）。但问题是，难免有一个 Region 中的对象引用另一个 Region 中对象的情况。为了达到可以以 Region 为单位进行垃圾回收的目的， G1 收集器也使用了 RememberedSet 这种技术，在各个 Region 上记录自家的对象被外面对象引用的情况。