Java堆里面存放着几乎所有的对象实例，垃圾收集器在回收内存之前，首先要确定这些对象是否还活着（能够被使用），然后再决定是否回收这些对象占用的内存。
判断对象是否存活大致有以下几种算法：
一、引用计数算法 （Reference Counting）
引用计数算法思路大致是这样的：给每个对象设置一个引用计数器，对象每次被引用时计数器加1，引用失效时减1，当计数器为零的时候，则判断这个对象是可以被回收的。
客观地说，这个算法实现简单，判定效率也很高，在大部分情况下是一个不错的算法。但是主流的Java虚拟机并没有使用这种算法，最主要的原因是因为它不能很好地解决对象间相互循环引用的难题。
二、可达性分析算法
这个对象的基本思路是，通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索过程所经过的路径被称为“引用链”，当一个对象到GC Roots没有任何引用链相连，则认为这个对象是不可用的（图论里把这种情况称为不可达）。如图所示，object5 6 7虽然互相有关联，但是它们到GC Roots是不可达的，因此认为它们都是可回收的对象。
在Java语言中，能作为GC Roots的对象包括以下几种：
1、虚拟机栈（栈帧中的本地变量表）中引用的对象
2、方法区中类静态属性引用的对象
3、方法区中常量引用的对象
4、本地方法栈中JNI（即一般说的native方法）引用的对象
三、再谈引用
不管使用什么算法，判断对象是否存活都与引用有关。为了适应各种场景，我们不希望对象只有被引用和没被引用两种状态。我们希望能描述这样一类对象：当内存还足够时，保留在内存空间中；如果内存空间在垃圾回收后还是很紧张，则可以抛弃这些对象。很多系统的缓存功能都是建立在这个场景上的。
Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用和虚引用，这四种引用类型强度依次减弱。进一步了解Java对象的四种引用类型
四、生存还是死亡
即使在可达性算法分析中不可达的对象，也并非立即被判定为可回收，这时候它们暂时处于等待执行阶段，真正判定一个对象死亡，至少要经过两次标记过程：
1、没有与GC Roots连接的引用链，此时会被第一次标记并进入筛选阶段；
2、判定是否有必要执行finalize()方法，当对象没有覆盖finalize方法或者finalize方法被虚拟机调用过，这种情况视为没有必要执行；如果对象被判定为有必要执行finalize方法，那么它会被放置在一个叫做F-Queue的队列中，并等待finalizer线程来处理。finalize方法是对象逃离被回收命运的最后机会，如果想拯救自己，需要再次将自己与引用链上任何一个对象建立连接，那么在第二次标记时会被移除F-Queue。需要注意的是，任何一个对象的finalize方法都只会被系统自动调用一次。
五、回收方法区
尽管在方法区内（Hotspot虚拟机中的永久代）进行垃圾收集的性价比比较低，这并不意味着方法区就没有垃圾收集机制。
永久代的垃圾回收主要分为两部分：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常相似，以常量池的回收为例，假如一个字符串“abc”进入了常量池，但是没有任何String对象引用这个常量，也没有任何地方引用这个常量，如果此时发生内存回收，这个常量就很有可能被清理出常量池。常量池中的类、方法、字段的符号引用也与此类似。
判断一个“废弃常量”比较简单，但是判断一个类是否是无用类则相对复杂许多。需要同时满足三个条件：
1、该类所有的实例都已经被回收，也就是Java堆中不存在任何该类实例
2、加载类的ClassLoader被回收
3、该类对应的java.lang.Class对象没有在任何地方被引用，无法通过反射访问到该类的方法
虚拟机可以对满足这三个条件的无用类进行回收。
