垃圾收集算法

垃圾收集算法

• 标记-清除算法
• 复制算法
• 标记-整理算法
• 分代收集算法

HotSpot的算法实现

• 枚举根节点
• 安全点
• 安全区域

标记-清除算法
最基础的手机算法是”标记-清除“算法，该算法分为标记和清除两个阶段：首先标记处所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
之所以说它是最基础的手机算法，是因为后续的手机算法都是基于这种思路并对其不足进行改进而得打的。
他的不足主要有两个：一是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间随便太多会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
标记清除算法的执行过程如图3-2所示

复制算法
为了解决效率问题，一种称为复制的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只是用其中的一块。当这一块的内存用完了，就将还活着的对象复制到另外一块上面。然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也不用考虑内存碎片等复杂情况，只要一动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一般，未免太高了一点。
复制算法的执行过程如图3-3所示

现在的商业虚拟机都采用这种收集算法来回收新生代，IBM公司的专门研究表明，新生代中的对象98%是朝生夕死的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将的Eden和Survivor中还存活的对象一次性的复制到另外一块Survivor空间上，然后清理掉Eden和刚才使用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1，也就是每次新生代中可用内存空间为整个新生代容量的90%（8+1），只有10%的内存会被浪费掉。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存(老年代)进行分配担保。

标记-整理算法
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会降低。更关键的是，如果不想浪费50%的空间，就需要额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以老年代一般不能直接选用这种方法。
根据老年代的特点，有人提出了另外一种标记整理算法，标记过程仍然与标记清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界意外的内存，标记整理算法的示意图如下所示

分代收集算法

当前商业虚拟机的垃圾收集都采用分代手机算法，这种算法根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的手机算法。
在新生代中，每次垃圾收集都发现有大量对象死去，只有少量存活，那就选择复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高，没有额外空间对他进行分配担保，就必须使用标记清理或者标记整理算法来进行回收。

HotSpot算法实现

枚举根节点
从可达性分析中从GCRoots节点找引用链这个操作为例，可作为GC Roots的节点主要在全局性的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中，现在很多应用仅仅方法区具有几百M，如果逐个检查这里面的引用，那么必然会消耗很多时间。

例外，可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行–这里一致性的意思是指在这个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法保证。这点是导致GC进行时必须停顿所有Java执行进程(Stop the world)的其中一个重要原因，即使是号称几乎不会发生停顿的CMS收集器中，枚举根节点也是必须要停顿的。。

由于目前的主流Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来之后，并不需要一个不漏的检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。在HotSpot的实现中，是使用一组成为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来。在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。
下面的代码清单是HotSpot Client VM生成的一段 String.hashCode() 方法的本地代码，可以看到在0x026eb7a9处的call指令有OopMap记录，他指明了EBX寄存器和栈中偏移量为16的内存区域中各有一个普通对象指针(Ordinary Object Pointer)的引用，有效范围从call指令开始直到0x026eb730(指令流的起始位置)+142(OopMap记录的偏移量) =0x026eb7be,即hlt指令为止

安全点
在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来：可以导致引用关系变化，或者说OomMap内容变化的指令非常多，如果为每一条指令都生成OopMap，那么将会需要大量的额外空间，这样GC的空间成本将会变得很高。

实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只有在特定的位置记录了这些信息，这些位置称为安全点(Safepoint)。即程序执行中并非在所有的地方都能够停下来开始GC，只有在达到安全点时才能暂停。Safepoint的选定既不能太少以至于让GC等待时间太长，也不能过于频繁以至于过分增大运行时的负荷。所以，安全点的选定基本上是以程序”是否具有让程序长时间执行的特征“为标准进行选定的–因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，”长时间执行“的最明显特征就是指令序列复用，例如方法调用，循环跳转，异常跳转等，所以具有这些功能的指令才会产生Safepoint。
对于Safepoint，另一个需要考虑的问题是如何在GC发生时让所有线程(不包括执行JNI调用的线程)都”跑“到最近的安全点上再停顿下来。这里有两种方式可供选择：抢先式中断和主动式中断，其中抢先式中断不需要线程的执行代码去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它跑到安全点上。现在几乎没有虚拟机采用抢先式中断来暂停线程从而相应GC事件。
而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单设置一个标志，各个线程执行时主动去轮训这个标志，发现中断标志为真时就自己中断挂起。轮训标志的地方和安全点时重合的，另外再加上创建对象需要分配内存的地方。
下面的代码中，test指令是HotSpot生成的轮询指令，当需要暂停线程时，虚拟机把0x160100的内存页设置为不可读，线程执行到test指令时就会产生一个自陷异常信号，在预先注册的异常处理器中暂停线程实现等待，这样一条汇编指令便完成安全点轮询和触发线程中断。

安全区域
使用Safepoint并不能完美解决进入GC的问题。Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，如果程序”不执行“的时候呢？所谓的程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这个时候线程无法响应JVM的中断请求，”走“到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间。对应这种情况，就需要安全区域(Safe Region) 来解决。

安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的SafePoint。

在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region，那么，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，他要检查系统是否完成了根节点枚举(或者是整个GC过程)，如果完成了，那线程就继续执行，否则他就必须等待直到收到可以安全离开Safe Region的信号为止。