Java如何判断对象存亡？

一时失言乱红尘 2022-12-27 01:47 58阅读 0赞

### 写在前面的话 ###

读者您好，本人目前同时在经营CSDN和微信公众号，希望小伙伴们能够给予支持，关注一下我的微信公众号，公众号是每天都会推送新文章，CSDN不定期发表新文章。

文末有公众号二维码，可以扫码关注，或者微信直接搜索“波波Tea”，带哪吒头像的那个就是我，谢谢！

### 1、引言 ###

在堆里面存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（“死去”即不可能再被任何途径使用的对象）了。

下面介绍两种判断对象是否存活的算法。

### 2、引用计数法 ###

引用计数法判断对象是否存活的算法是这样的：

*  在对象中添加一个引用计数器
 *  每当有一个地方引用它时，计数器值就加一
 *  当引用失效时，计数器值就减一
 *  任何时刻计数器为零的对象就是不可能再被使用的

引用计数算法（Reference Counting）虽然占用了一些额外的内存空间来进行计数，但它的原理简单，判定效率也很高，在大多数情况下它都是一个不错的算法。也有一些比较著名的应用案例，例如微软COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、Python语言以及在游戏脚本领域得到许多应用的Squirrel中都使用了引用计数算法进行内存管理。

但是，在Java领域，至少主流的Java虚拟机里面都没有选用引用计数算法来管理内存，主要原因是，这个看似简单的算法有很多特殊情况要考虑，必须要配合大量额外处理才能保证正确地工作。

比如仅仅依靠单纯的引用计数法就很难解决对象之间相互循环引用的问题。什么是对象之间的循环引用？仔细看下面这块代码，你品，你细品。

public class ObjectDeadJudge {
        public Object instance;
        public static void main(String[] args) {
            ObjectDeadJudge ra = new ObjectDeadJudge();
            ObjectDeadJudge rb = new ObjectDeadJudge();
            ra.instance = rb;
            rb.instance = ra;
            ra = null;
            rb = null;
        }
    }

当ra和rb都指向null之前，他们在内存中的关系图是这样的：

![02b281fee6702f8a502d8aab3ae660b5.png][]

此时，对象ObjectDeadJudge\_A和ObjectDeadJudge\_B的引用数都为2。

当ra和rb都指向null之后，他们在内存中的关系图是这样的：

![d14defd4cc4282a30e57443b53e3f20a.png][]

此时，对象ObjectDeadJudge\_A和ObjectDeadJudge\_B的引用数都为1。

事实上这两个对象已经不可能再被访问，但是由于它们互相引用着对方，导致它们的引用计数都不为零，引用计数算法也就无法回收它们。

### 3、可达性分析算法 ###

当前主流的商用程序语言（Java、C\#）的内存管理子系统，都是通过可达性分析（Reachability Analysis）算法来判定对象是否存活的。

这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

如下图所示，对象object 5、object 6、object 7虽然互有关联，但是它们到GC Roots是不可达的，因此它们将会被判定为可回收的对象。

![6eb7c16dd11fa4b58e5df630576192fd.png][]

**在Java技术体系里面，固定可作为GC Roots的对象包括以下几种：**

*  在虚拟机栈（栈帧中的本地变量表）中引用的对象，比如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
 *  在方法区中类静态属性引用的对象，比如Java类的引用类型静态变量。
 *  在方法区中常量引用的对象，比如字符串常量池（String Table）里的引用。
 *  在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
 *  Java虚拟机内部的引用，如基本数据类型对应的Class对象，
 *  一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
 *  所有被同步锁（synchronized关键字）持有的对象。
 *  反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

注意：这里所说的引用的对象，指的就是引用，只不过把引用也当成一个对象罢了

**那么问题来了：**

*  选择这些对象的依据是什么？
 *  为什么他们可以作为GC roots?
 *  到底GC Roots是什么？他们存放在哪里？是引用还是对象？是放在堆里的还是方法栈还是哪个地方？
 *  最后虚拟机会回收GC Roots吗？

**对于这些问题，我的解释是：**

*  GC Roots其实不是一组对象，而是一组指针，这些指针是tracing gc的trace起点。
 *  tracing gc必须以当前存活的对象集为Roots，因此必须选取确定存活的引用类型对象。GC管理的区域是Java堆，而虚拟机栈、方法区和本地方法栈不被GC所管理，因此选用这些区域内引用的对象作为GC Roots，是不会被GC所回收的。
 *  其中虚拟机栈和本地方法栈都是线程私有的内存区域，只要线程没有终止，就能确保它们中引用的对象的存活。而方法区中类静态属性引用的对象是显然存活的。常量引用的对象在当前可能存活，因此，也可能是GC roots的一部分。

除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。

比如分代收集和局部回收（Partial GC），如果只针对Java堆中某一块区域发起垃圾收集时（如最典型的只针对新生代的垃圾收集），必须考虑到内存区域是虚拟机自己的实现细节（在用户视角里任何内存区域都是不可见的），更不是孤立封闭的，所以某个区域里的对象完全有可能被位于堆中其他区域的对象所引用，这时候就需要将这些关联区域的对象也一并加入GC Roots集合中去，才能保证可达性分析的正确性。

目前最新的几款垃圾收集器无一例外都具备了局部回收的特征，为了避免GC Roots包含过多对象而过度膨胀，它们在实现上也做出了各种优化处理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hsXzE4MDM_size_16_color_FFFFFF_t_70][]

[02b281fee6702f8a502d8aab3ae660b5.png]: /images/20221120/af8f0b9b0fb646728f3ecf62635c7bf3.png
[d14defd4cc4282a30e57443b53e3f20a.png]: /images/20221120/5e93744ea2254261ad593b20bec264ed.png
[6eb7c16dd11fa4b58e5df630576192fd.png]: /images/20221120/1f33a82021fb4c3f99d0aab1d854db7c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hsXzE4MDM_size_16_color_FFFFFF_t_70]: /images/20221120/15a50d320ffa4821a76f7baf1c51115b.png