Java 垃圾回收 (GC) 全面解析！

大家好，这里是架构资源栈！点击上方关注，添加“星标”，一起学习大厂前沿架构！

在 Java 的世界里，垃圾回收（Garbage Collection, GC） 是开发者绕不开的话题。它默默守护着程序的内存安全，但稍有疏忽就可能引发内存泄漏、卡顿甚至系统崩溃。

本篇文章从对象的“生死判定”到垃圾回收算法的演进，再到Stop-The-World 与 SafePoint 的原理，一文带你彻底搞懂 Java 的 GC 机制！

💡 哪些区域需要 GC？

垃圾收集主要针对 堆 和 方法区。

而这三大线程私有区域：

程序计数器

虚拟机栈

本地方法栈

由于随线程的生命周期自动释放，不需要 GC 介入。

🔍 如何判断对象是否可以被回收？

Java 中，几乎所有的对象实例都在堆中分配。GC 要做的第一件事就是判断哪些对象“已经死了”。

🧮 引用计数算法（Reference Counting）

思路很简单：每个对象维护一个引用计数器，引用加 1，释放减 1，计数为 0 时认为对象“无主”。

但问题来了：

public class Test {

public Object instance = null;

public static void main(String[] args) {

Test a = new Test();

Test b = new Test();

a.instance = b;

b.instance = a;

a = null;

b = null;

doSomething();

}

}

两个对象互相引用，即使外部都已断开，它们的引用计数永远不为 0，造成内存泄漏。

👉 因此 Java 并不采用引用计数算法！

🔗 可达性分析算法（Reachability Analysis） ✅

这是 Java 真正使用的算法。

从一组称为 GC Roots 的对象出发，沿着对象引用链遍历，能到达的对象就是存活的，不能到达的就是“垃圾”。

典型 GC Roots 包括：

虚拟机栈中引用的对象

JNI（Native 方法）中的引用

类的静态属性引用

常量池引用

活跃线程的引用

💾 方法区的回收机制

方法区主要用于存放类信息、常量、静态变量等元数据。因为内容稳定，回收频率远低于堆内对象。

主要清理目标：

废弃常量

无用类的卸载

类的卸载需要满足三个条件：

该类所有实例都已被回收。

加载该类的 ClassLoader 被回收。

该类对应的 Class 对象没有任何引用。

在动态代理和反射频繁使用的场景下，类卸载尤为关键。

🧹 对象“复活”？finalize() 机制揭秘

Java 提供了 finalize() 方法，类似 C++ 析构函数（但不推荐使用！）。

回收流程：

GC 扫描发现对象不可达，第一次标记。

判断是否实现了 finalize() 方法，如果有，放入 F-Queue。

单独的线程异步执行 finalize()，此时对象有机会“自救”，如重新与其他对象建立引用。

第二次 GC 扫描，如果仍不可达，则真正回收。

⚠️ finalize 的问题：

不确定是否会被调用

性能开销大

无法保证调用顺序

👉 最好用 try-finally 或 AutoCloseable 替代！

🧵 四种引用类型：谁能活得久？

Java 在 JDK 1.2 之后扩展了引用的概念，按照“生存能力”强弱分为：

引用类型

被回收时机

适用场景

存活时间

强引用

永不回收

一般对象引用

JVM 停止时终止

软引用

内存不足时回收

内存敏感缓存

内存不足时终止

弱引用

GC 时立即回收

临时缓存、Map

GC 后即终止

虚引用

不可通过引用访问对象

监控、哨兵机制

GC 后即终止

代码示例：

Object obj = new Object();

SoftReference