JAVA中判断一个对象是否死亡的算法有两种：
- 引用计数算法
- 可达性分析算法
一、引用计数算法
所谓引用计数算法就是，给一个对象定义一个引用计数器，每当该对象被引用一次引用计数器就加1，如果一个对象的引用计数器为0，则说明这个对象已死。但是这种算法不是很严谨，因为当两个对象互相引用的时候，如果我将它们设置为null，此时对象是可以被回收的，但是因为它的引用计数器不为0，证明它还没死，没死就不能被回收，如下面的栗子
public class ReferenceCountAlgorithm {
public Object instance = null;
private static final int MB = 1024 * 1024;
// 定义一个2MB的字节数组
private byte[] arraySize = new byte[2 * MB];
public static void main(String[] args) {
// 创建两个对象并互相引用
ReferenceCountAlgorithm refA = new ReferenceCountAlgorithm();
ReferenceCountAlgorithm refB = new ReferenceCountAlgorithm();
refA.instance = refB;
refB.instance = refA;
refA = null;
refB = null;
// 此时两个对象的引用数不为0，但是都为null，看能否被回收？
System.gc();
}
上面代码中两个对象互相引用，所以它们的引用计数器不为0，将两个对象设置为null之后进行GC，查看GC日志：
Java HotSpot(TM) 64-Bit Server VM (25.151-b12) for bsd-amd64 JRE (1.8.0_151-b12), built on Sep 5 2017 19:37:08 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Memory: 4k page, physical 8388608k(187584k free)
/proc/meminfo:
CommandLine flags: -XX:InitialHeapSize=536870912 -XX:MaxHeapSize=536870912 -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
0.097: [GC (System.gc()) 7311K->392K(502784K), 0.0007996 secs]
0.098: [Full GC (System.gc()) 392K->276K(502784K), 0.0034846 secs]
从上面红色部分可以看出GC时将两个对象回收了，所以并不能说明当一个对象的引用计数不为0的时候它就不会被GC.
二、可达性分析算法
所谓可达性算法，就是存活的对象会形成一棵以GC Root为根节点的树，顺着这棵树往下遍历，从根到叶子节点的路径称为引用链，如果一个对象存在这样的引用链能够通过它到达根节点或通过根节点找到它，说明这个对象可达，可达的对象不会被GC。画个图解释一下：
上图中红色圈所代表的对象，它们虽然互相之间有关系，但是因为没有到达GC Root的引用链，就能被GC掉；相反，绿色圈代表的对象因为有到达GC Root的引用链，说明它们是可达的，GC时这些对象就不会被回收；
GC Root的选择依据是：
虚拟机栈中引用的对象；
方法区中的静态属性引用的对象；
方法区中的常量引用的对象；
本地方法栈中引用的对象；
其实，在可达性算法中，一个不可达的对象也并非非死不可，因为它还有一个缓刑期，什么是缓刑期呢？就是延迟处死，当一个对象不可达的时候，并不会马上被GC掉，而是会根据某些条件将它放到一个缓刑队列中，标记它是要延迟处死的对象，那延迟处死到底是什么时候呢？其实一个对象会被标记两次，第一次是看这个对象是否满足加入缓刑队列的条件，这个条件就是该对象是否覆盖了Finalize方法及是否已经被JVM执行过这个方法，如果没有就会被加到缓刑队列中，这是第一次标记；第二次标记就是如果它没有在Finalize方法中自救成功（可以和GC Root进行关联），这时因为Finalize方法已经执行过了，所以会被GC。
所以，一个对象没有引用链不代表它会马上被GC，还要通过判断是否覆盖并执行过Finalize方法来决定是否有必要延迟处死，只有当它没有执行过Finalize方法并且在Finalize方法中自救成功，才能保证不被GC，但是当第二次GC的时候因为执行过Finalize方法，所以已经失去了自救的机会，就会被GC，此时才能证明该对象真的死了！
下面看一个栗子🌰
public class SavedByFinalize {
public static SavedByFinalize sbf = null;
public void isAlive() {
System.out.println("I am alive");
}
protected void finalize() throws Throwable {
super.finalize();
System.out.println("Finalized method is execute");
SavedByFinalize.sbf = this;// 自救
}
public static void main(String[] args) throws Throwable {
sbf = new SavedByFinalize();
/**
* 对象第一次被GC
*/
sbf = null;// 此时可以被回收
System.gc();// 第一次进行垃圾回收，此时因为覆盖了Finalized方法并进行自救，所以gc失败
Thread.sleep(1000);// 因为Finalized优先级低，所以需要等待它执行
if (sbf != null) {
sbf.isAlive();
} else {
System.out.println("I am dead");
}
/**
* 对象第二次被GC
*/
sbf = null;// 此时可以被回收
System.gc();// 第一次进行垃圾回收，此时因为Finalized方法已经执行过了，所以gc成功
Thread.sleep(1000);// 因为Finalized优先级低，所以需要等待它执行
if (sbf != null) {
sbf.isAlive();
} else {
System.out.println("I am dead");
}
}
}
上面的代码中：
- 当第一次进行GC时，虽然对象sbf为null，但是因为它还没有执行过Finalize方法，所以会被加入缓刑队列，因为在执行Finalize方法时自救成功，所以不会被GC；
- 当第二次进行GC时，因为Finalize方法已经执行过，而且对象sbf为nul，所以它会直接被GC；
以上就是判断一个对象是否真的已死的过程！
