本文介绍了Java中判断对象存活的两种算法：引用计数和可达性分析。引用计数法简单高效，但无法处理循环引用问题。可达性分析算法通过GCRoots确定对象生死，涉及的GCRoots包括虚拟机栈、方法区等。此外，文章讨论了四种引用类型，并指出即使对象在可达性分析中被标记为死亡，仍可能通过finalize()方法复活。最后，讨论了方法区的回收，重点是废弃常量和无用类型的标准。
目录
概述：
两种判断对象是否存活的算法
一.引用计数算法
原理：
在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是死了。
引用计数算法（Reference Counting）虽然占用了一些额外的内存空间来进行计数，但它的原理简单，判定效率也很高在大多数情况下它都是一个不错的算法。
劣势：
如果对象间互相引用就会导致死循环无法回收对象。在Java 领域，至少主流的Java虚拟机里面都没有选用引用计数算法来管理内存，主要原因是，这个看似简单 的算法有很多例外情况要考虑，必须要配合大量额外处理才能保证正确地工作，譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。
二.可达性分析算法
原理：
通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连， 或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。
可作为GC Roots的对象包括以下几种：
1、在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的
2、参数、局部变量、临时变量等。
3、在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
4、在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。·在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
5、Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如 NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
6、所有被同步锁（synchronized关键字）持有的对象。
7、反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等
这些是固定的，也有根据用户所选用的垃圾收集器以及当前回收的内存区域不 同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。
三.再谈引用
何为引用：
无论通过引用计数法判断对象的引用量，还是可达性分析算法判断对象是否引用链可达，判定对象是否存活都和“引用”离不开关系。
引用分类：
强引用：
只要引用关系存在永远不会回收。
软引用：（适合做缓存）
还有用但非必须，只有当发生内存溢出的时候才会被回收。
弱引用：
也是用来描述非必须的对象，只存在到下一次垃圾回收之前，只要垃圾收集，就给他回收了。
虚引用（幽灵引用或幻影引用）：
几乎没有任何作用，只能起到一个对象被回收时通知一下的作用。（基本上没有使用场景）
四.生存还是死亡？
即使在可达性分析中被判定死亡，它仍然不一定会死亡。
即使在可达性分析中被判定死亡，它仍然不一定会死亡。要真正判定一个对象的死亡，它仍然需要经过至少两次标记过程。当发现没有与GC Roots相连接的引用链，那它将会被第一次标记。随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过那么虚拟机将这两种情况都视为“没有必要执行”。如果这个对象被判定为确有必要执行finalize()方法，通过这个方法重新与引用链上的任何一个对象建立关联，那在第二次标记时它将被移出“即将回收”的集合。
五.回收方法区
回收的内容：
如何判定一个类型是否属于“不再被使用的类"：
java虚拟机被允许对满足下面三个条件的类进行回收，被允许并不是一定要进行回收，对于类型是否要进行回收，HotStop提供特殊的了参数进行判断。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
