深入理解JVM（3）—垃圾回收

Java内存分为五个部分，其中程序计数器、虚拟机栈、本地方法栈三个区域是线程私有的，随线程生而生，随线程灭而灭。方法区和Java堆的分配和回收则是动态的，内存的回收也是针对这部分内存的。

1、如何确定对象已死？

要对对象进行回收，就需要判断对象是否已经“死去”（即接下来程序不再使用它或者很长一段时间不再使用它）。常用的方法是：

（1）引用计数算法

给对象添加一个引用计数器，每当有地方使用它，就将计数器加1，不再使用时，计数器减1,当对象的引用计算器值为0时，表明不再有地方使用它，就表示该对象”已死”。

由于引用计数器很难解决对象间相互引用的情况，如对象A引用对象B，而对象B同时又引用了A，当两对象失效时，两者的引用计数器由于存在相互引用仍互不为0无法被回收，所以Java虚拟机并没有采用引用计数算法来管理内存。

但是引用计数方法简单，效率也高，在大部分情况下有着很好的应用，如Python语言、FlashPlayer等。

（2）可达性分析算法

在主流商业程序语言，如Java、C#的主流实现中，都是通过可达性分析来判断对象是否存活的。算法思想是，从被称作“GC Roots”的对象开始向下搜寻对象，所走过的路径称为引用链，若对象与“GC Roots”间没有引用链存在时说明该对象已死。如下图，对象5,6,7之间存在相互引用，但由于它们没有到GC Roots的引用链存在，故可以判定为可回收对象。



在Java语言中，可作为GC Roots的对象包括：

Ⅰ、虚拟机栈（栈帧中的局部变量表）中引用的对象

Ⅱ、方法区中类静态属性引用的对象

Ⅲ、方法区常量引用的对象

Ⅳ、本地方法引用的对象

2、生存还是死亡？

通过可达性分析标记的不可达对象，也不一定会被回收。判断对象是否真正死亡，至少需要两次标记过程：首先在可达性分析中没有发现引用链，将会对对象进行第一次标记并判断此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者虚拟机已经调用过finalize()方法，那么就可以判断“没有必要执行”。

当对象被判断“没有必要执行”finalize()方法时，就会将对象放置在F-Queue队列中，并在稍后由一个虚拟机创建的Finalizer线程去执行它。第二次标记是GC对F-Queue队列进行标记，此时，对象要想存活，则必须在finalize()方法中实现自救—重新与引用链关联，如把自己（this关键字）赋值给某个类变量或者对象的成员变量，这样在GC进行第二次标记时就会将该对象移除“即将回收”集合，从而避免被回收。例如：

/**
*代码演示了两点：
*1、对象可以在GC时自救；
*2、其自救机会只有一次，因为一个对象的finalize()方法最多被系统调用一次
*/
public class FinalizeEscape {

public static FinalizeEscape FC = null;

@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("finalize method invoke");
//通过赋值进行自救，只能利用finalize()自救
FC = this;
}

public static void main(String[] args) throws Exception {
FC = new FinalizeEscape();
//第一次自救成功
FC = null;
System.gc();
Thread.sleep(500);
if(FC != null)
System.out.println("i am alive");
else
System.out.println("i am dead");
//由于finalize()已经被调用一次，故这次自救失败了
FC = null;
System.gc();
Thread.sleep(500);
if(FC != null)
System.out.println("i am alive");
else
System.out.println("i am dead");
}
}

3、方法区的回收

方法区中的垃圾回收主要是废弃字面量及无用类。判断字面量是否废弃与判断堆中对象十分相似。例如，若常量池中存在字符串“abc”，而系统中并没有任何String对象的值为“abc”的，也就是没有任何对象引用它，那么它就可以被回收了。无用类的判定稍微复杂点，需要满足：

（1）该类的所有对象实例已经被回收；

（2）加载该类的ClassLoader已经被回收；

（3）该类的类对象Class没有在任何地方被引用，无法使用反射来访问该类的方法。

当方法区中的类满足以上条件时，就可以对无用类进行回收了。

4、垃圾收集算法

（1）标记-清除算法

标记-清除（Mark-Sweep）算法是最基础的垃圾回收算法，算法分为标记和清除两阶段。首先对需要回收的对象进行标记（即判断对象死亡的两次标记），当标记完成后对这些对象统一回收。该算法简单容易实现，是回收算法的基础，但是该算法由于标记和清除过程的效率都不高，还易产生空间碎片。算法示意如下：



（2）复制算法

为了提高回收效率，复制算法将内存划分为大小相等的两块，每次只使用其中一块，当此块内存用完了，就将此内存中仍存活的对象复制的另一块内存中，然后将该内存整个回收。该算法实现简单，运行高效，但是对内存使用存在很大的浪费。算法示意如下：



现在的商业虚拟机都采用复制算法来回收新生代。IBM公司的专门研究表明，新生代中的对象有98%都是“朝生夕死”的，所以不需要按上面说的平分内存，而是按约8：1：1的比例划分为Eden区和两块Survivor区，每次使用Eden区和其中一块Survivor区，即使用了90%的内存空间，当内存不足需要回收时，将这两块区域中仍存活的对象复制到另一块Survivor区中，然后回收这两块内存。当然，可能会出现回收时仍存活的对象超过Survivor区的大小，这时候就需要通过内存的分配担保机制将对象复制到老年代中保存。

（3）标记-整理算法

Java堆中老年代的对象存活率比较高，使用复制算法会出现很多的复制操作或分配担保问题，所以针对老年代的特点，提出了“标记-整理（Mark-Compact）”算法。分为标记和整理过程，标记过程跟“标记-清除”算法的标记过程一致，整理过程则是将存放对象移动到同一端，然后直接清除掉端边界外的内存。算法示意如下：



5、Java虚拟机HotSpot处理GC的上下文

（1）枚举GC Roots

前面讲到回收内存的对象存活判定的可达性分析算法，需要从被称为“GC Roots”的对象出发搜寻引用链，但是在很多实际运用中，仅方法区就有数百M，对里面的所有引用进行遍历显然不合理。而且该算法要求分析工作在确保一致性的快照中进行——“一致性”指的是算法在分析期间，系统看起来被冻结在某个时间点上，也即保证分析期间不再出现对象引用关系的变化。因此需要在发生GC时必须停顿所有的Java执行线程。

在GC时，如何快速查询作为”GC Roots”的引用，从而确定对象的存活状态，在HotSpot中是通过一组称为OopMap的数据结构实现的。OopMap可以这样理解，在源代码里面每个变量都是有类型的，但是编译之后的代码就只有变量在栈上的位置了，oopMap就是一个附加的信息，告诉你栈上哪个位置本来是个什么类型。在Java编译时，会在安全点（下面会讲到）记录下栈和寄存器中哪些位置是引用，这样，GC在扫描时就可以直接确定“GC Roots”引用。

（2）安全点

在OopMap的协助下，可以快速地枚举GC Roots，但是由于引起OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，则需要大量额外空间，导致GC成本变高。

为了解决这个问题，Java虚拟机定义了安全点（Safepoint），只有字节码执行到安全点位置，才能暂停启动GC,生成OopMap。安全点的选定要求既不能过少导致GC等待时间太长，也不能太多增加运行时的负荷，安全点主要设置在以下几个位置：

1、循环的末尾；

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

3、可能抛异常的位置 。

如何保证当发生GC时，线程都处于安全点，主要是通过主动式中断来实现的:在安全点设置一个轮询标志，各个线程执行时主动去轮询这个标志，发现中断标志为真的时就自己中断挂起。

（3）、安全区域

安全点可以很好地解决线程执行时进入GC的问题，但对处于睡眠和阻塞状态的线程却无能为力，为了解决这个问题，java虚拟机设置了安全区域（Safe Region），安全区域是指在一段代码片中，引用关系不会变化，在这个区域任何地方都可以发生GC，可以看作为扩展了的安全点。只有当执行的线程进入安全点，非执行态的线程处于安全区域时，才会触发GC。

当线程执行到安全区域后， 首先会标示自己进入了安全区域， 那样， 当在这段时间内发生GC时， 就不用管这样的线程了，当线程要离开该区域时， 要检查系统是否已经完成了根节点枚举（或整个GC过程），如果已完成，则线程继续执行， 否则， 它就必须等待直到收到可以安全离开安全区域的信号。