jvm垃圾收集机制详解（下）

上一篇传送门：jvm垃圾收集机制详解（中）

三、HotSpot虚拟机的垃圾收集实现

根据之前的讲解，java分析对象是否需要被回收是通过对对象的可达性分析来确定的，而可达性分析是通过识别对象是否链接到GC Roots对象决定的。那么很显然，我们需要通过遍历所有的GC Roots节点，然后剩下的没有链接到GC Roots节点的对象就是我们要回收的对象的。那么问题就来了，GC Roots节点那么多，还有重复的GC Roots节点链接到同一对象，那么难道说每次我们进行垃圾收集的时候都要耗费大量时间去遍历一遍吗？

HotSpot虚拟机是我们现在使用的主流java虚拟机，让我们看看它是如何做的：

1.遍历GC Roots时要停顿

我们先不谈如何去解决遍历耗时间的问题，先来思考一个问题：在遍历进行的时候对象是否还在进行更改或者其它操作？

答案是显而易见的，这就好像你的女朋友在你屋子里帮你扫地，你需要停下手里的工作给她让地方，而且不能女朋友一边在扫地，你一边往地上去扔垃圾，那样恐怕就要挨大嘴巴子了。对象也是这样，每当进行垃圾回收的时候都要停下，停下的时间很短，这段时间里保存一个快照来存储自身的状态信息。

2.使用OopMap保存信息

为了解决每次垃圾回收都要遍历去获得回收对象位置的问题，jvm使用了一种叫做OopMap的数据结构来保存对象的引用，在类加载完成的时候，jvm就将对象存储位置偏移量什么的计算出来，存储到OopMap中，当需要垃圾回收的时候直接就可以精确“制导”，一下子就能找到对象的位置

3.安全点

那么，我们应该在什么时候停止运行呢？是一得到垃圾回收的指令就马上去停止吗？
当然不是，那样估计就该出大乱子了，我们应该选取一个安全的状态去停止然后根据OopMap去更改OopMap中的信息或者进行垃圾回收，这种安全的状态叫做“安全点”，也就是你和你的女朋友有个约定，当我把手里的工作进行到百分之多少的时候我就停下来，你就来打扫卫生，我不会给你捣乱。
程序不是在所有的地方都能停止下来进行GC（垃圾回收），而是必须要当运行到安全点的时候才能停下来进行垃圾回收，那么问题又来了，垃圾回收是一个线程，当我们现在有多个线程的时候，每个线程运行的程序都有它们自己分别的安全点，我们要等待所有线程都运行到安全点才能停下来进行垃圾回收，由于每个线程的安全点都在程序的不同位置，会不会造成线程1运行到安全点时线程2还没有到安全点，导致线程1必须停在当前位置等待线程2运行到安全点呢？

针对这种问题，我们必须为安全点做一些辩解了，安全点在一个程序中有很多很多，而且，安全点的选择也是有讲究的，jvm会依照“既不能太少以至于当GC等待时间过长，也不能太多增加程序运行时的负荷”来选取安全点，安全点是以“是否具有让程序长时间执行的特征”为标准选定的。而且因为每条指令的执行时间都非常短暂，因此刚刚我们担心的问题根本不会出现。

4.安全区

现在我们有这样一种情况：一个线程处于sleep状态或者阻塞状态，现在这个线程没法运行自己到安全点，如果恰好在这时需要GC，那么是不是就意味着GC永远也没法进行垃圾回收成功了？

当然不是，对于一些程序没有分配cpu时间片来执行的情况（例如上面说的sleep和阻塞情况），在这种情况下，程序已经没法再去给GC捣乱，没法去更改自身的信息了，还要个卵的安全点？也就是说，现在女朋友给你下了迷药，你已经趴在桌子上睡死过去了，那么女朋友当然就可以不用顾及你，直接开始打扫卫生了。我们把这种情况下的程序称为处于安全区中的程序，当程序进入到了安全区的时候，会标记自己已经进入了安全区，当这段时间要进行GC的时候，GC不会去管处于安全区中的线程程序，当线程要离开的时候，必须检查GC是否已经完成了遍历GC Roots或者整个GC过程，如果完成了，线程就可以顺利退出安全区，否则就必须等待完成才可以出去。

至此，我们就完成了对垃圾回收的讲解，还有很多没讲的是关于各种不同垃圾回收器的具体区别和优缺点，这个就要读者朋友们自己慢慢学习了。

我也好希望能有个帮我揽走所有家务活的女朋友，不过倒是不希望她为了打扫房间给我下迷药。。。

• 参考书籍：《深入理解Java虚拟机》