java 内存开发经验_七年开发经验详解JVM的GC 算法-CSDN博客

本文链接：https://blog.csdn.net/weixin_29384861/article/details/114217930

概述

GC 是 JVM 自带的功能，它能够自动回收对象，清理内存，这是 Java 语言的一大优势，但是GC绝不仅伴随着Java，相反，GC历史比Java更悠久。关于GC，我认为有四个问题需要解决：

为什么了解 GC？

哪些内存需要回收？

什么时候回收？

如何回收？

为什么了解 GC

GC 已经比较成熟，绝大部分情况下都“自动化”运行。之所以还需要了解GC，是因为当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

哪些内存需要回收

判定哪些内存需要回收，不是靠 JVM 去猜，也不是随机，而是 JVM 靠一系列算法得到结果，当然，算法也是人写的，虽然不能做到百分之百地符合所有开发者的要求，但这已经是最好的了。下面介绍一种判定内存回收的算法——可达性分析算法，这是我暂时能理解的算法。

可达性分析算法

这个算法的基本思路是通过一系列的称为 “GC Roots” 的对象作为起点，从这些起点开始向下搜索，搜索走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的，也就是待回收的。例如，上图中的 Object 5、Object 6 虽然两者相互关联，但是它们任何一个都和 GC Roots 不可达，所以 Object 5 和 Object 6 将会被判定为可回收的对象。

GC Roots

至于什么是 GC Roots 对象，解释如下：

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

方法区中类静态变量引用的对象

方法区中常量引用的对象

本地方法栈 JNI 引用的变量

什么时候回收

当通过“可达性分析”等算法标记好需要回收的对象后，等待它们的不是即可问斩，而是宣告“缓刑”。最后的回收条件是此对象是否有必要执行 finalize() 方法。

finalize() 方法

当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机都将视作“没有必要执行”。如果这个对象呗判定为有必要执行 finalize() 方法，那么这个对象将会放置在一个叫作 F-Queue 的队列中，这个队列在后期会被某个JVM自动创建的线程执行，如果一个对象在finalize()方法中执行缓慢或者发生了死循环，将可能导致 F-Queue 队列中其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃，幸运的是任何一个对象的 finalize() 方法只会被系统调用一次。

在《深入理解 JVM 虚拟机》中，作者建议尽量避免使用 finalize() 方法，它不是c++ 中的析构函数，更像是java为适应c++程序员而作出的让步。我觉得是finalize()方法是一根鸡肋，一根如果运用不当将会引发灾难的鸡肋，如同 goto 语句。它的运行代价极高，不确定性大，无法保证各个对象的调用顺序。它的功能经常会被误以为类似 try-finally，然而 finalize() 能做的工作， try-finally 都能做，而且做得更好、更及时。

如何回收

标记-清楚法

“标记-清除”(Mark-Sweep)法是最基础的收集算法。算法分为两个阶段——“标记”和“清除”：首先标记出所有需要被回收的对象，在标记完成后统一回收所有标记了的对象，图如篇首。

它有两个不足之处：

效率不高

标记和清除两个过程的效率都不高

产生大量不连续碎片

虽然对象被回收，但是剩下的内存很有可能不连续，在这种情况下，当需要为系统分配一个较大对象时，会因为无法找到足够的连续的内存而不得不提前触发另一次垃圾收集动作。这样，又会造成效率问题

针对上述两个缺点，后面两种算法对此进行了改进。

复制法

“复制”(Copying)是为了解决“标记-清除”的效率不高问题而被发明。它将内存按容量划分为等量的两块。每次只使用其中的一块。当使用的这一块内存用完了，就将还存活的对象复制到另一块(被称作“保留区”)上面，然后再把已使用的内存空间一次清理掉。每次都对整个半区进行回收，再也不用担心内存碎片化问题，图如下所示。