Java垃圾回收通过分代收集、可达性分析、算法协同与引用类型四方面实现自动化内存管理：新生代用复制算法，老年代用标记-清除或整理；从GC Roots遍历判定存活对象；G1、ZGC等收集器平衡停顿与吞吐；软/弱/虚引用提供回收控制粒度。
Java 垃圾回收通过算法实现自动化内存管理，核心在于“自动识别无用对象 + 按策略释放空间”，不依赖开发者手动干预。它不是靠定时清理或随机扫描，而是基于对象生命周期特征与引用关系，用可预测、可优化的算法模型完成判断与回收。
分代收集：按对象存活时间差异化处理
这是现代 JVM（如 HotSpot）默认采用的基础策略，源于“弱分代假说”——98% 的对象朝生夕死。堆被划分为新生代（Eden + 两个 Survivor 区）和老年代，回收器据此分配不同强度的算法：
- 新生代使用复制算法：每次 GC 只需扫描 Eden 和一个 Survivor 区，把存活对象复制到另一个 Survivor 区，原区域直接清空。效率高、无碎片、适合短命对象。
- 老年代使用标记-清除或标记-整理算法：对象存活率高，复制成本大，改用标记所有存活对象，再统一清除或压缩整理，兼顾空间利用率与碎片控制。
- 对象在新生代经历多次 GC（默认 15 次）仍存活，就会晋升到老年代；大对象也可能直接分配进老年代。
可达性分析：精准判定对象是否该回收
JVM 不靠引用计数（易被循环引用干扰），而是从一组“GC Roots”出发做深度遍历：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- GC Roots 包括：虚拟机栈中正在使用的局部变量、方法区的静态变量、常量池中的常量、JNI 引用的对象、活跃线程等。
- 从这些根节点出发，沿着引用链能到达的对象视为“存活”，其余即为垃圾。
- 这个过程确保了逻辑严谨性——哪怕对象被多个地方间接引用，只要路径可达就不会误收；反之，即使有强引用字段，若整条链已脱离 Roots，也会被正确回收。
算法协同与收集器演进：平衡停顿、吞吐与响应
单一算法难以满足所有场景，JVM 提供多种垃圾收集器，本质是不同算法组合+并发/并行机制的工程实现：
立即学习“Java免费学习笔记（深入）”；
- Serial / Parallel：侧重吞吐量，用单线程或多线程暂停应用（Stop-The-World）完成标记-清除或复制，适合后台批处理。
- CMS（已弃用）：尝试以并发标记降低停顿，但容易产生碎片且失败时退化为 Serial Old，稳定性差。
- G1：将堆划为多个 Region，优先回收垃圾最多的区域（Garbage-First），支持可控停顿时间目标，兼顾吞吐与延迟。
- ZGC / Shenandoah：使用读屏障+并发标记/移动，几乎消除 STW，适用于超大堆（TB 级）和低延迟敏感系统。
引用类型参与回收决策：增强控制粒度
Java 定义了四种引用类型，让开发者能在语义层面影响 GC 行为：
- 强引用：new 出来的对象默认就是强引用，只要它可达，GC 绝对不碰。
- 软引用：内存不足时才回收，适合做缓存（如图片缓存），由 JVM 自主判断时机。
- 弱引用：下一次 GC 就回收，适合构建非强制依赖的映射（如 WeakHashMap）。
- 虚引用：无法获取对象实例，仅用于在对象被回收时收到通知，配合 ReferenceQueue 实现资源清理钩子。
