介绍下垃圾收集机制（在什么时候，对什么，做了什么）。

前面介绍了Java内存结构和HotSpot虚拟机在堆内存中管理对象的过程。不过，在Java程序中对象的创建是非常频繁的，而内存的大小又是有限的，为了内存的重复利用，就需要对内存中的对象进行垃圾收集。其实，这也是Java和C++的一个区别，在Java中可以进行自动的垃圾收集，而C和C++中需要程序员手动回收不再使用的对象。

Java中的垃圾收集是虚拟机要考虑的问题。那么以虚拟机的角度考虑，如果要收集虚拟机内存中的垃圾，需要考虑哪些问题呢？

· Java虚拟机中的内存分为程序计数器、虚拟机栈、本地方法栈、Java堆和方法区等几部分，在哪些部分回收内存呢？

· 确定了要回收的内存，内存中必然存在着很多内容，如何判定这些内容就是不需要的垃圾了呢？

· 程序不断运行，垃圾收集不可能也随着程序一直运行，那什么时候进行垃圾收集操作呢？

· 最重要的问题是，怎么回收？

Java的垃圾收集机制是一个挺复杂的过程，涉及到的内容也很多，上面的问题一个一个解决。

1、回收区域

在前面几篇中可以知道，Java内存中的程序计数器、虚拟机栈和本地方法栈是线程私有的，线程结束也就没了。其中程序计数器负责指示下一条指令，栈中的栈帧随着方法的进入和退出不停的入栈出栈。每一个栈帧的大小在编译时就基本已经确定。所以这几个区域就不需要考虑内存回收，因为方法结束或线程停止，内存就回收了。

和上述三个区域不同的是，Java堆和方法区是线程共享的。在Java堆中存放着所有线程在运行时创建的对象，在方法区中存放着关于类的元数据信息。我们在程序运行时才能确定需要加载哪些类的元数据信息到方法区，创建哪些对象到堆中，也就是说，这部分的内存分配和回收都是动态的。也因为这样，这两个部分是垃圾收集器所关注的地方。

2、谁才是垃圾？

首先考虑一下存放对象的Java堆。

程序中创建的对象绝大多数都会在Java堆中，而程序的运行也会创建大量的对象。但这些对象并不总是使用，这样就产生了一些不会再使用的垃圾。这些垃圾占据着宝贵的内存空间，所以需要回收这些空间。不过，怎么才能确定堆中的对象是垃圾呢？

一种常见的算法是引用计数算法，它基于这样的考虑，给对象添加一个引用计数器，每当有一个地方引用它时，计数器的值就加1；当引用实效时，计数器的值就减1。当计数器的值为0时，对象就不可能再被使用。

引用计数算法实现简单，判定效率也高。不过，主流的Java虚拟机中并没有使用引用计数算法来管理内存，因为这个算法很难解决对象之间相互循环引用的问题。

考虑下面的代码：

public class ReferenceCountingGC {

public Object instance=null;

private static final int _1mb=1024*1024;

@SuppressWarnings("unused")

private byte[] bigSize=new byte[2*_1mb];

public static void testGC() {

ReferenceCountingGC objA=new ReferenceCountingGC();

ReferenceCountingGC objB=new ReferenceCountingGC();

objA.instance=objB;

objB.instance=objA;

objA=null;

objB=null;

System.gc();

}

public static void main(String[] args) {

ReferenceCountingGC.testGC();

}

}

00036. 

ReferenceCountingGC类中有一个实例对象，在测试代码中构造的两个对象objA和objB在instance实例对象上互相引用。这样，每个对象的引用计数都是2，当两个对象都赋值为null时，引用计数减1变为1，按照引用计数算法这不是垃圾。但是，很明显这两个对象已经不能再被访问到了，这就是垃圾。实际上，运行之后Java虚拟机将这两个对象作为垃圾回收掉了。

那么Java中使用的是什么方法呢？是可达性分析算法（Reachability Analysis）。

可达性分析算法的基本思想是通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，即从GC Roots到这个对象不可达，就说明这个对象是不可用的。如下图，左面的四个对象都有引用链到GC Roots，因此是可用的；右面的三个对象到GC Roots不可达，所以是不可用的。

在Java中，下面几种对象可以作为GC Roots：

· 虚拟机栈（栈帧中的本地变量表）中引用的对象；

· 方法区中类静态属性引用的对象；

· 方法区中常量引用的对象；

· 本地方法栈中JNI（即Native方法）引用的对象；

其实这两种方法都涉及到了对象的引用，也就是说对象是否是垃圾都与引用有关，因此有必要全面的理解一下Java中的引用。

其实Java中的引用一共有四种。这是JDK 1.2 之后对引用概念的扩充，分别是强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference），这四种引用的强度依次逐渐减弱。

（1）强引用

强引用就是程序中普遍存在的，类似“Object obj=new Object()”这类的引用，只要强引用还存在，垃圾回收器就不会回收被引用的对象。

（2）软引用

软引用用来描述一些还有用但不是必须的对象。对于软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。SoftReference类来实现软引用。

（3）弱引用

弱引用也用来描述非必须的对象，但是强度比软引用还弱，被引用的对象只能存活到下一次垃圾收集之前。当下一次垃圾收集器工作时，不论内存是否足够，都会回收这些对象。WeakReference类实现了弱引用。

（4）虚引用

虚引用是最弱的一种引用，也叫幽灵引用或幻影引用。一个对象是否有虚引用存在不会对其生存时间产生影响，也无法通过虚引用来取得一个对象实例。虚引用的唯一目的就是当被虚引用关联的对象被收集器收集时收到一个系统通知。PhantomReference类实现了虚引用。

3、垃圾也有可能变废为宝

垃圾也有可能变废为宝然后再利用呢。其实，即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，要真正认为一个对象是垃圾要收集，至少要经过两次标记过程：如果对象在进行可达性分析后发现不可达，那么就将它进行第一标记并进行一次筛选，筛选的条件是这个对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法，或finalize方法已经被虚拟机执行过了，虚拟机任何没有必要执行finalize方法。

如果这个对象被判定为有必要执行finalize方法，那么这个对象会放置在一个叫做F-Queue的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行。不过虚拟机只是会触发这个方法，但不承诺会等待执行完毕，这是因为，如果一个对象的finalize方法执行缓慢，或发生了死循环，就会导致F-Queue对象中的其他对象处于等待，甚至整个垃圾收集系统崩溃。稍后GC会在F-Queue中的对象进行第二次小规模的标记，如果这时标记为可达，就可以不被收集；如果仍然不可达，那么就被标记为垃圾了。具体的流程图如下：

下面的代码演示了上面所说的内容。

public class FinalizeEscapeGC {

public static FinalizeEscapeGC SAVE_HOOK=null;

public void isAlive(){

System.out.println("yes,i am still alive.");

}

protected void finalize()throws Throwable{

super.finalize();

System.out.println("finalize method executed!"); 

FinalizeEscapeGC.SAVE_HOOK=this;

}

public static void main(String[] args) throws InterruptedException {

SAVE_HOOK=new FinalizeEscapeGC();

SAVE_HOOK=null;

System.gc();

Thread.sleep(500);

if(SAVE_HOOK!=null){

SAVE_HOOK.isAlive();

}else{

System.out.println("no,i am dead.");

}

SAVE_HOOK=null;

System.gc();

Thread.sleep(500);

if(SAVE_HOOK!=null){

SAVE_HOOK.isAlive();

}else{

System.out.println("no,i am dead.");

}

}

}

结果如下：

FinalizeEscapeGC类覆盖了finalize方法，所以在GC将SAVE_HOOK第一次标记为垃圾后的筛选中认为finalize有必要执行。在覆盖的finalize方法中，将自己赋值给了类的变量SAVE_HOOK，成功拯救自己，第一次没有被收集。但是第二次虽然代码相同，但是由于虚拟机已经执行过finalize方法了，GC不认为有必要执行，在第二次标记中也标记为垃圾，所以没有能拯救自己，被当做垃圾收集了。

4、回收方法区

除了Java堆，方法区中也存在垃圾收集。只不过这里的收集效率比较低。

方法区，在HotSpot虚拟机中叫永久代，GC收集两部分内容，废弃常量和无用的类。收集废弃常量与收集Java堆中的对象类似。以常量池中字面量的收集为例，假如一个字符串“ABC”已经在常量池中，但是当前系统中没有任何一个String对象是“ABC”，即没有对象引用常量池中的“ABC”，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，“ABC”就会被清理出常量池。常量池中的其他类（接口）、方法和字段的符号引用也类似。

不过要判断一个类是否无用就麻烦很多了。要同时满足如下三个条件一个类才是无用的类：

1. 该类的所有实例都已经被回收，也就是Java堆中不存在该类的任何的实例；

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

3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问到该类的方法。

满足上面的三个条件，虚拟机就可以回收。不过，对于HotSpot虚拟机来说，是否回收通过-Xnoclassgc参数来设置。