Java GC通过可达性分析算法判断对象是否可回收，从GC Roots出发搜索引用链，不可达对象被回收；流程含标记、清除、整理三阶段；按分代假说区分Minor GC与Full GC。
Java中的垃圾回收机制（Garbage Collection，简称GC）是JVM自动管理堆内存的核心功能，它不依赖程序员手动释放对象，而是通过识别“不再可达”的对象并回收其占用的内存，从而防止内存泄漏和内存溢出。
GC如何判断一个对象该被回收
Java不使用引用计数法（因其无法解决循环引用问题），而是采用可达性分析算法。该算法从一组被称为GC Roots的对象出发，沿着引用链向下搜索：
- 虚拟机栈中正在使用的局部变量所引用的对象
- 方法区中静态变量（static字段）引用的对象
- 方法区中常量池里的常量（如
String.intern()或static final字符串）引用的对象 - 本地方法栈中JNI引用的对象
- 正在运行的Java线程本身（如线程对象、线程本地变量）
只要一个对象到任意GC Root之间存在引用链，它就被视为存活对象；否则即为不可达对象，可被回收。
GC的基本工作流程
主流GC实现通常包含三个逻辑阶段（具体是否执行整理取决于收集器）：
立即学习“Java免费学习笔记（深入）”；
- 标记（Marking）：遍历所有GC Roots，递归标记所有可达对象
- 清除（Sweeping）：回收未被标记的对象所占内存空间
- 整理（Compacting）：将存活对象向内存一端移动，消除碎片（如Serial Old、G1 Mixed GC会做）
注意：不同分代（新生代/老年代）采用不同算法——新生代多用复制算法（高效、无碎片），老年代倾向标记-整理或标记-清除+记忆集优化（如G1、ZGC）。
GC的常见触发条件
GC不是定时执行，而是由JVM根据运行时状态动态决定。主要触发场景包括：
- 堆内存不足：当新对象分配时发现Eden区无足够空间，立即触发Minor GC；若老年代也空间紧张，可能升级为Full GC
- 系统空闲期：JVM在低负载、无应用线程活跃时，可能主动发起GC以提前释放内存
-
显式建议调用：代码中调用
System.gc()或Runtime.getRuntime().gc()，但仅是提示，JVM可忽略 - 元空间/直接内存告警：虽然GC主要针对堆，但元空间（Metaspace）或Direct Buffer耗尽也可能间接触发Full GC来尝试腾挪资源
分代回收与GC类型区分
基于“分代假说”，JVM把堆划分为新生代（Young Gen）和老年代（Old Gen），对应不同回收行为：
- Minor GC：发生在新生代，频率高、停顿短；对象在Eden和Survivor间复制，年龄达标后晋升至老年代
- Major GC / Full GC：清理老年代或整个堆（含方法区/Metaspace），耗时长、影响大；常见诱因包括老年代空间不足、System.gc()、CMS失败、元空间扩容失败等
现代JVM（如JDK 17+）已逐步弱化“Major GC”概念，统一归入Full GC或特定混合回收（如G1的Mixed GC）。
