HotSpot VM中的准确式GC、OopMap、Safepoint、抢先式中断、主动式中断、Safe Region和RememberedSet
相关文章
- Java运行时数据区域
- Java对象的创建和内存布局
- 最全JVM的参数总结
文章目录
- 可达性分析
- 保守式GC
- 准确式GC与OopMap
- Safepoint、抢先式中断、主动式中断
- Safe Region
- RememberedSet
首先，我们要了解一下这个主题的背景，为什么会出现这一系列名词。这些名词都是在如何提高GC效率的问题上提出的，具体讲，是如何提高GC Roots扫描效率的问题。
可达性分析
我们知道要判断一个对象是否可以被回收，是通过判断这个对象与GC Roots之间是否存在引用链，这个过程叫做可达性分析。而这个过程中，业务线程是需要停止的，不然在遍历时，引用发生变化，那么分析到的结果就是不准确的。也就是说这个过程需要“Stop the world”。为了提高效率，我们需要这个过程尽可能地快，以减少系统停顿时间。
怎么提高这部分的效率呢？首先在遍历GC Roots的速度能否提高？
保守式GC
在JDK1.0时，Sun公司发布JVM，称为Sun Classic VM，这款虚拟机只支持纯解释器方式来执行java代码，如果想使用JIT编译期就必须进行外挂，但是外挂后解释器就不工作了，总之两者不兼容。不止于此这款JVM，遍历GC Roots时，扫描内存中全局变量和栈上的本地变量表时，并不知道这个位置存的是基本数据类型还是对象引用，需要额外判断，效率很低。Classic VM其使用的是基于句柄的访问方式，每次定位都需要两次定位，其速度就可想而知了，这种方式称为“保守式内存管理”和“保守式GC”。
准确式GC与OopMap
为了解决上面的问题，Sun团队发布了一款叫做Exact VM的虚拟机。它的最大特点是“准确式内存管理”，即虚拟机知道内存中某个位置存储的数据是什么类型，在GC时，只需遍历引用类型即可，并且采用直接引用，其效率提高了一个level。其用来维护哪些地方存有引用的数据结构就叫做“OopMap”。后来HotSpot VM继承了这一技术。
Safepoint、抢先式中断、主动式中断
OopMap存储的是哪些地方存有引用。但是维护这个数据结构太难了，系统在多线程地跑，对象千千万万，时时刻刻引用关系都在发生变化，不管是采用频繁地修改OopMap的值，还没每执行一条指令（只有执行指令，引用关系才会改变）都创建一个OopMap都是不可取的。那么怎么办呢？
HotSpot提出只在某些特殊的位置记录引用信息，这些特殊的位置就被称为“Safepoint”。程序也只会在这些Safepoint才会停下来。GC发生时如何让所有线程都跑到Safepoint停下来呢？有两种方案：抢先式中断和主动式中断。抢先式中断：GC时，把所有线程都中断，如果线程没达到Safepoint，就再启动线程跑到Safepoint后停下来。这种方式频繁地线程切换，性能差，已经没有虚拟机采用了。另一种，主动式中断：当发生GC时，设置一个标记，所有线程在到达Safepoint时判断这个标记，如果中断标记为真就自己中断挂起。
Safe Region
如果线程已经停止了，那要怎么到达Safepoint呢？对于这个问题就需要安全区域（Safe Region）解決。Safe Region指一段代码判断之中，引用关系不会发生变化。在这个区域中发生GC都是安全的。线程停止都会进入到Safe Region中，当线程回复执行，也就是从Safe Region离开时，会先检查系统是否正在GC，是的话会等到GC完成后离开Safe Region。
RememberedSet
我们知道新生代GC会非常频繁，当只想收集新生代，不想收集老年代时，没有必要对位于老年代的 GC Roots 做全面的可达性分析。但问题是可能存在位于老年代的某些GC Roots引用了新生代的某个对象，这时这个对象是不能清除的。那么怎么办呢？
我们可以用一个结构维护老年代引用新生代的情况，这个结构就是“RememberedSet”。
我们知道， G1 收集器使用的是化整为零的思想，把一块大的内存划分成很多个域（ Region ）。但问题是，难免有一个 Region 中的对象引用另一个 Region 中对象的情况。为了达到可以以 Region 为单位进行垃圾回收的目的， G1 收集器也使用了 RememberedSet 这种技术，在各个 Region 上记录自家的对象被外面对象引用的情况。
欢迎关注公众号：
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！