垃圾收集首先要考虑的问题就是哪些内存需要回收。
目标内存区域
Java运行时数据区域中程序计数器、虚拟机栈、本地方法栈三个区域是线程私有的，生命周期跟线程一样。栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈的操作，每一个栈帧分配多少内存基本上是在类结构确定下来时就已知了。因此这几个区域不需要过多考虑回收的问题，方法或者线程结束时，内存自然就跟着回收了。
Java堆和方法区则不一样，一个接口中的多个实现类和一个方法中的多个分支需要的内存都可能是不一样的，只有程序处于运行期间才能知道会创建哪些对象，因而，这部分内存的分配和回收都是动态的。垃圾收集器关注的是这部分内存区域。
判断对象是否存活的算法
垃圾收集器在堆进行回收前要确定哪些对象还是存活的，只有已经死去（不可能再被使用）的对象才能被回收。
引用计数算法
引用计数算法的基本思路是：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值加1；当引用失效时，计数器值减1；任何时刻计数器都为0的对象就是不可能再被使用的。
引用计数算法实现简单，判定效率也很高，在大多数情况下它都是一个不错的算法，应用案例有微软的COM技术、使用ActionScript 3的FlashPlayer、Python、Squirrel等。Java没有使用这种算法来管理内存的主要原因是它很难解决对象之间的相互循环引用的问题。
public class ReferenceCountingGC {
public Object instance;
private byte[] bytes = new byte[2 * 1024 * 1024];
public static void testGC() {
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
System.gc();
}
}
根搜索算法
主流的商用程序语言（Java和C#等）都是使用根搜索算法（GC Roots Tracing）判定对象是否存活的。这个算法的基本思路是：通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
在Java语言中，可作为GC Roots的对象包括下面几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象。
- 方法区中的类静态属性引用的对象。
- 方法区中的常量引用的对象。
- 本地方法栈中JNI（即Native方法）引用的对象。
引用的概念
在JDK 1.2之前，Java中引用的定义很传统：如果reference类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。
这样的定义太绝对，没法描述这样一类对象：当内存空间还足够时，则能保留在内存中；如果内存在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这一的应用场景。因此，在JDK 1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）四种，这四种引用强度依次逐渐减弱。
- 强引用是在程序中普遍存在的，类似“Object obj = new Object()”这类的引用。只要强引用存在，垃圾收集器永远不会回收被引用的对象。
- 软引用用来描述一些还有用，但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。
- 弱引用也是用来描述非必须对象的。当垃圾收集器工作的时候，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引用。
- 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否被虚引用关联，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用的唯一目的就是希望在这个对象被回收时收到一个系统通知。在JDK 1.2之后，提供了PhantomReference类来实现虚引用。
判定对象死亡（可回收）
在根搜索算法中不可达的对象通过finalize()方法还有最后一次逃脱死亡命运的机会。
判定一个对象死亡，至少要经历两次标记过程
- 如果对象在进行根搜索后没发现有与GC Roots相连接的引用链，那它会被第一次标记。
- 标记后如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置到一个名为F-Queue的对列中。
- 稍后虚拟机会自动建立一个低优先级的Finalizer线程去触发对象的finalize()方法，但不承诺会等待它运行结束。
- 最后垃圾收集器将对F-Queue中的对象进行第二次小规模的标记。如果对象有在finalize()方法中将自己重新与引用链上的任何一个对象建立关联，那在第二次标记的时候就会被移除出“即将回收”的集合；如果没有再次建立关联，就彻底宣告死亡了。
对象有必要执行finalize()方法的条件（同时满足）
- 对象有重写了finalize()方法。
- 对象的finalize()方法还没被虚拟机调用过。
finalize()方法运行代价高昂，不确定性大，无法保证各个对象的调用顺序。且finalize()能做的工作，使用try-finally或其他方式可以做得更好，更及时。所以不建议使用这个方法。
回收方法区
根据Java虚拟机规范，方法区（HotSpot虚拟机中的永久代）可以不实现垃圾收集。方法区垃圾收集的性价比一般比较低。在堆中，尤其在新生代中，常规应用进行一次垃圾收集一般可以回收70%～95%的空间，而永久代的垃圾收集效率远低于此。
回收内容
方法区的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量跟回收Java堆中的对象非常类似。判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算“无用的类”：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
- 加载该类的ClassLoader已经被回收。
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
JVM（HotSpot）参数
- -Xnoclassgc：控制是否对无用类进行回收
- -verbose:class：查看类加载和卸载信息
- -XX:+TraceClassLoading：查看类加载信息
- -XX:+TraceClassUnloading：查看类卸载信息（fastdebug版的虚拟机才支持）
应用场景
在下面这些场景中虚拟机需要具备类卸载功能，以保证永久代不会溢出。
- 大量使用反射、动态代理、CGLib等bytecode框架的场景。
- 动态生成JSP和OSGi这类频繁自定义ClassLoader的场景。
