单例对象无法被回收的原因 - gc回收机制

最新推荐文章于 2024-05-19 00:53:05 发布

zjf1165

最新推荐文章于 2024-05-19 00:53:05 发布

阅读量2.8k

点赞数 2

CC 4.0 BY-SA版权

文章标签： jvm 单例回收机制

本文链接：https://blog.youkuaiyun.com/zjf1165/article/details/83008572

深入解析Java中单例对象为何难以被垃圾回收机制处理，探讨可达性算法、GCRoots概念，以及类卸载条件对单例持久存在的影响。

单例对象无法被回收的真正原因要从java垃圾回收器开始说起

JAVA垃圾对象判断准则

Java中判断一个对象是否可以被回收是根据“可达性”来判定的。

可达性：
以一系列的称为 “GC Roots”的对象作为起始点，然后向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，即可视为垃圾。

GC Roots点包含：

虚拟机栈（栈帧中的本地变量表）中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI（即一般说的Native方法）引用的对象。

垃圾回收算法

标记-清除算法

算法分为标记和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，它的标记过程就是使用可达性算法进行标记的。

主要缺点有两个：

效率问题，标记和清除两个过程的效率都不高
空间问题，标记清除之后会产生大量不连续的内存碎片

在这里插入图片描述

复制算法

算法将可用内存按照容量分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后把已使用过的内存空间一次清理掉。

优点：
内存分配时不用考虑内存碎片问题，只要一动堆顶指针，按顺序分配内存即可，实现简单，运行高效

缺点：
代价是将内存缩小为原来的一半
在这里插入图片描述

分代收集算法

一般把Java堆分为新生代（新生代又被分为Eden区、From Survivor区和To Survivor区）和老年代，根据各个年代的特点（对象存活周期）采用最合适的收集算法。
在新生代中，每次垃圾收集时有大批对象死去，只有少量存活，主要选用复制算法。而老年代对象存活率高，主要使用标记整理算法。

上述内容摘录自：垃圾收集器与内存分配策略

新生代和老年代垃圾回收机制

由于新生代中java对象大多都是朝生夕灭的、而老年代中java对象的生命周期一般比较长，因此其垃圾回收机制不同，新生代中的GC被称为Minor GC，老年代的GC被称为Major GC /Full GC，Full GC（也是Major GC）会清理整个堆空间，包括年轻代和永久代。

对象分配及GC回收机制简单描述如下：

对象首先在Eden区中分配，而当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC，将存活下来的对象复制到From Survivor区，复制的所以对象年龄各自+1，清除垃圾对象
下一次发生Minor GC时，jvm会将Eden区存活的对象和From Survivor区中存活的对象复制到To Survivor区，复制的所以对象年龄各自+1，清除垃圾对象
再次发生Minor GC时，重复2操作，只是将From Survivor区和To Survivor区对调，即将Eden区和To Survivor区中存活的对象复制到From Survivor区中，并增加年龄和清除垃圾
再次发生Minor GC时，重复2、3操作
当minor GC发生时，如果survivor空间中的对象年龄（默认为 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设置阈值）超过了晋升的年龄限定，对象会被复制到年老代

另外，大对象的分配直接在老年代，其中大对象是指需要大量连续内存空间的Java对象，例如很长的字符串、数组等

如果对上述描述不理解可以看下：通过图文给你讲明白java GC的实现原理文章

触发JVM进行Full GC的情况及应对策略：

调用System.gc时，系统建议执行Full GC，但是不必然执行
老年代空间不足
方法区空间不足
CMS GC时出现promotion failed和concurrent mode failure
统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间
堆中分配很大的对象