JVM——垃圾回收机制深入浅出

最新推荐文章于 2024-07-19 17:37:28 发布

风行者TBX

最新推荐文章于 2024-07-19 17:37:28 发布

阅读量82

点赞数

分类专栏： JVM 文章标签： java Powered by 金山文档

本文链接：https://blog.csdn.net/weixin_40646844/article/details/129522824

版权

JVM 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

对象存货判断

1、引用计数算法（JVM中不用）

给对象中添加一个引用计数器，每当有一个地方用它时，计数器值加1,；当引用失效时，计数器值减1；任何时刻计数器为0的对象不能再被使用。缺点：难以解决循环引用问题，objA.instance=objB和objB.instance=objA，除此之外，没有引用。

2、可达性分析算法

这个算法的基本思路就是通过一系列名为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，下图对象object5, object6, object7虽然有互相判断，但它们到GC Roots是不可达的，所以它们将会判定为是可回收对象。

在Java语言里，可作为GC Roots对象的包括如下几种：

a.虚拟机栈(栈桢中的本地变量表)中的引用的对象

b.方法区中的类静态属性引用的对象

c.方法区中的常量引用的对象

d.本地方法栈中JNI（即一般说的Native方法）的引用的对象

为什么选择这几个作为GC Roots？

首先要保证被选作GC Roots的对象是存活的，静态变量的声明周期长，而栈中引用的对象肯定是正在使用的对象（是存活的），因为调用方法时才会压栈。

虚拟机并不需要一个不漏地检查完所有全局性应用（如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表），在HotSpot中，是使用一组称为OopMap的数据结构来达到这个目的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器哪些位置是引用。这些记录信息的特定位置称为安全点（Safepoint），即程序制定时并非所有地方都能停顿下来开始GC，只有在到达安全点才能停顿。

引用

强引用：类似“Object o = new Object()”，只要强引用还存在，就不会被回收；

软引用：用来描述一些有用但非必须的对象。如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存（如果内存够，软引用没有被回收，则可以直接使用，如果内存不够，软引用已经被回收，则重新读取数据（如从数据库中））。(java.lang.ref包)

SoftReference<String> softRef = new SoftReference<String>(str);

弱引用：也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收只被弱引用关联的对象。如果这个对象是偶尔的使用，并且希望在使用时随时就能获取到，但又不想影响此对象的垃圾收集，那么你应该用 Weak Reference 来记住此对象。

虚引用：它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。PhantomReference

finalize()

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程。标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链。

1).第一次标记并进行一次筛选。

筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法，或者finalize方法已经被虚拟机调用过（finalize只会调用一次），虚拟机将这两种情况都视为“没有必要执行”，对象被回收。

2).第二次标记

如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会被放置在一个名为：F-Queue的队列之中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象finalize（）方法中执行缓慢，或者发生死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。

Finalize（）方法是对象脱逃死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize（）中成功拯救自己----只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。

垃圾收集算法

1、标记-清除算法（Mark-Sweep）。首先标记处所有需要回收的对象，在标记完成后统一回收。缺点：标记和清除两个过程都效率低；标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中需要分配大对象时，无法找到足够的连续内存而不得不提取触发GC。

2、复制算法。将可用内存按容量划分成大小相等的两块，每次只使用一块。当这一块使用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存一次清理掉。这样不用考虑内存碎片的问题，只要移动堆顶指针，按顺序分配即可，实现简单、运行高效。缺点：内存缩小为原来的一半。

现代商用虚拟机都采用这种算法回收新生代。而新生代中约98%的对象都是“朝生夕死”，所以不需按1:1划分。HotSpot默认Eden和Survivor是8:1，所以每次可用内存为90%。但我们没法保证每次回收只有不多于10%的对象存活，当Survivor空间不够时，需要依赖其他内存（这里指老年代）进行分配担保（直接进入老年代）。

缺点：如果对象存活率太高，要进行较多复制操作，效率低。且需要额外空间担保，老年代不能选用这种算法。

3、标记-整理算法。

过程与“标记-清除”一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。老年代因为对象存活率高、没有额外空间进行分配担保，必须使用“标记-清理”或“标记-整理”算法。