在程序设计的世界里，内存管理始终是开发者绕不开的核心课题。对于 C/C++ 程序员而言，手动分配与释放内存是日常工作的一部分，却也常常因疏忽导致内存泄漏或野指针等致命问题。而 Java 凭借其自动化垃圾回收机制，将开发者从繁琐的内存管理中解放出来，这一特性不仅降低了程序出错的概率，更成为 Java 语言在企业级应用中广泛普及的重要基石。
垃圾回收的核心使命
Java 垃圾回收（Garbage Collection，简称 GC）的本质，是通过虚拟机自动识别并回收不再被使用的对象所占用的内存空间。这一过程如同办公室的保洁系统：当某些文件（对象）不再被任何人（程序）需要时，保洁人员（GC 机制）会定期清理它们，释放存储空间（内存）供新的文件使用。
在 Java 中，所有对象都存储在堆内存中，而堆内存的大小是有限的。如果只分配内存而不释放，最终会导致内存溢出（OutOfMemoryError），程序崩溃。垃圾回收机制的存在，正是为了动态维持内存的平衡 —— 既保证程序运行时的内存需求，又避免无效对象长期占用资源。
值得注意的是，垃圾回收并非 Java 独有的特性，但其实现的成熟度和效率，在主流编程语言中处于领先地位。从 JDK 1.0 时代的简单回收算法，到如今 JDK 21 的 ZGC、Shenandoah 等低延迟收集器，Java 垃圾回收机制的演进史，也是内存管理技术不断突破的发展史。
如何判定 “垃圾”：对象存活的判断标准
要进行垃圾回收，首先需要明确一个关键问题：如何判断一个对象已经 “死亡”（即不再被使用）？Java 虚拟机采用可达性分析算法来解决这个问题，这一算法比早期的引用计数法更为可靠。
可达性分析算法的核心思想是：以一系列被称为 “GC Roots” 的对象作为起点，从这些起点出发，沿着引用链遍历所有可访问的对象。所有能被 GC Roots 直接或间接引用的对象，被视为 “存活对象”；反之，无法通过任何引用链连接到 GC Roots 的对象，则被判定为 “垃圾对象”，等待被回收。
那么，哪些对象可以作为 GC Roots？主要包括以下几类：
- 虚拟机栈中局部变量表引用的对象（如当前正在执行的方法中的参数、局部变量等）；
- 方法区中类静态属性引用的对象（如类的 static 变量）；
- 方法区中常量引用的对象（如字符串常量池中的引用）；
- 本地方法栈中 JNI（即通常所说的 Native 方法）引用的对象；
- 虚拟机内部的引用（如基本数据类型对应的 Class 对象、异常对象 NullPointerException 等）。
在可达性分析的基础上，对象的 “死亡” 并非一蹴而就，而是要经历两次标记过程。第一次标记针对不可达对象，随后虚拟机会检查该对象是否重写了 finalize () 方法：如果没有重写，或 finalize () 方法已经被执行过，则该对象被判定为真正的垃圾；如果对象重写了 finalize () 且尚未执行，它会被放入一个名为 F-Queue 的队列中，由虚拟机自动创建的 Finalizer 线程执行 finalize () 方法。在 finalize () 方法中，对象有机会重新与引用链建立连接（如将自己赋值给某个类变量），从而逃脱被回收的命运。但这只是理论上的可能，在实际开发中，不建议依赖 finalize () 方法进行资源释放，因为其执行时机不确定，且可能导致对象延迟回收。
垃圾回收算法：从理论到实践
确定了需要回收的对象后，接下来的问题是如何高效地回收内存。Java 虚拟机发展至今，衍生出多种垃圾回收算法，每种算法都有其适用场景和优缺点。
标记 - 清除算法（Mark-Sweep）
这是最基础的垃圾回收算法，分为 “标记” 和 “清除” 两个阶段：首先标记出所有需要回收的对象，然后统一回收这些对象占用的内存。其优点是实现简单，但存在两个明显缺陷：一是标记和清除过程效率不高，尤其是当堆中对象数量较多时；二是会产生大量不连续的内存碎片，当需要分配大对象时，可能因找不到足够大的连续内存而不得不提前触发另一次垃圾回收。
复制算法（Copying）
为解决标记 - 清除算法的内存碎片问题，复制算法应运而生。它将堆内存按容量划分为大小相等的两块，每次只使用其中一块。当这块内存用完时，就将存活的对象复制到另一块内存中，然后清空当前使用的内存块。这种算法的优点是实现简单、运行高效，且不会产生内存碎片，因为存活对象被整齐地复制到新的内存区域。
但复制算法的代价是内存利用率低—— 实际可用内存仅为总容量的一半。不过，在对象存活率较低的场景（如新生代），这种算法非常高效。当前主流的虚拟机都采用复制算法回收新生代，只是对其进行了优化：将新生代分为一块较大的 Eden 区和两块较小的 Survivor 区（通常比例为 8:1:1），每次使用 Eden 区和其中一块 Survivor 区。当回收时，将 Eden 区和 Survivor 区中存活的对象复制到另一块 Survivor 区，最后清空 Eden 区和已使用的 Survivor 区。这样，每次只有 10% 的内存被浪费，大大提高了内存利用率。
标记 - 整理算法（Mark-Compact）
复制算法在对象存活率较高时会频繁进行复制操作，效率大幅下降。因此，针对老年代（对象存活率高），标记 - 整理算法被广泛采用。该算法的标记过程与标记 - 清除算法相同，但后续步骤并非直接清除垃圾对象，而是将所有存活对象向内存空间的一端移动，然后清理掉边界以外的内存。这种算法既避免了内存碎片，又不需要牺牲一半的内存空间，但代价是增加了对象移动的成本。
分代收集算法（Generational Collection）
当前商用虚拟机的垃圾回收都采用 “分代收集” 算法，它并非一种新的独立算法，而是结合了上述几种算法的特点，根据对象的存活周期将内存划分为不同区域（通常是新生代和老年代），对不同区域采用不同的回收策略。
- 新生代：对象存活时间短，存活率低，适合采用复制算法。每次回收只需复制少量存活对象，效率极高。
- 老年代：对象存活时间长，存活率高，且没有额外的内存空间进行分配担保，因此采用标记 - 清除或标记 - 整理算法。
分代收集算法的核心依据是 “弱分代假说”：绝大多数对象都是朝生夕灭的。这一假说在实际应用中得到了验证，使得分代收集能够以较低的成本实现高效的垃圾回收。
垃圾收集器：算法的具体实现
垃圾回收算法是内存回收的方法论，而垃圾收集器则是算法的具体实现。自 Java 诞生以来，虚拟机团队开发了多种垃圾收集器，以适应不同的应用场景。
Serial 收集器
Serial 收集器是最基础、历史最悠久的收集器，它采用单线程进行垃圾回收。在回收过程中，必须暂停所有用户线程（即 “Stop The World”，STW），直到回收完成。虽然 STW 会导致程序卡顿，但 Serial 收集器简单高效，对于内存较小的客户端应用（如桌面程序），其性能表现足够优秀。
Parallel 收集器
Parallel 收集器是 Serial 收集器的多线程版本，它通过多线程并行回收来提高效率，但其回收过程仍需 STW。Parallel 收集器更关注吞吐量（吞吐量 = 用户线程运行时间 /(用户线程运行时间 + 垃圾回收时间)），适合后台计算等对响应时间要求不高的场景。
CMS 收集器
CMS（Concurrent Mark Sweep）收集器是一种以低延迟为目标的收集器，它几乎是 Java 虚拟机中第一款真正意义上的并发收集器。CMS 收集器的工作过程分为四个阶段：初始标记（STW，标记 GC Roots 直接关联的对象）、并发标记（与用户线程同时运行，标记所有可达对象）、重新标记（STW，修正并发标记期间因用户线程操作导致的标记变动）、并发清除（与用户线程同时运行，清除垃圾对象）。
由于并发标记和并发清除阶段不需要 STW，CMS 收集器的延迟较低，但也存在明显缺点：内存占用高（需要额外线程支持并发）、CPU 敏感（并发阶段会占用一部分 CPU 资源）、无法处理浮动垃圾（并发清除阶段产生的新垃圾，需等到下一次回收），以及采用标记 - 清除算法导致的内存碎片问题。
G1 收集器
G1（Garbage-First）收集器是 JDK 9 之后的默认收集器，它颠覆了传统的分代模型，将堆内存划分为多个大小相等的独立区域（Region），每个 Region 可以根据需要扮演 Eden 区、Survivor 区或老年代。G1 的核心思想是 “优先回收价值最大的 Region”（即回收后能获得最多内存的区域），从而在保证吞吐量的同时，实现可控的延迟。
G1 收集器的工作过程包括初始标记、并发标记、最终标记和筛选回收四个阶段，其中初始标记和最终标记需要 STW，但时间很短。它采用标记 - 整理算法处理 Region 内部的对象，避免了内存碎片；同时通过 Region 的设计，实现了对垃圾回收范围的精确控制，能够有效减少 STW 时间。
新一代收集器：ZGC 与 Shenandoah
随着大数据、微服务等场景对低延迟的要求越来越高，JDK 11 引入了 ZGC，JDK 12 引入了 Shenandoah，这两款收集器的目标是实现亚毫秒级的 STW 时间，即使在 TB 级内存的堆中也能保持高效回收。
ZGC 和 Shenandoah 通过创新的技术（如颜色指针、读屏障等），将大部分回收操作与用户线程并发执行，大幅缩短了 STW 时间。它们不依赖分代模型，能够应对各种对象存活周期的场景，代表了 Java 垃圾回收技术的未来发展方向。
垃圾回收的调优与实践
尽管 Java 的垃圾回收机制实现了自动化，但在实际开发中，仍需根据应用特点进行合理调优，以避免性能问题。
首先，需要合理设置堆内存大小。堆内存过小会导致垃圾回收频繁触发，影响吞吐量；过大则会增加单次回收时间，且可能浪费系统资源。可以通过 - Xms（初始堆大小）和 - Xmx（最大堆大小）参数设置堆的范围，通常建议将两者设置为相同值，避免堆大小动态调整带来的开销。
其次，选择合适的垃圾收集器。对于桌面应用或小规模服务，Serial 收集器足够高效；对于吞吐量优先的后台任务，Parallel 收集器是更好的选择；对于 Web 服务等对延迟敏感的应用，G1 收集器更为合适；而在超大内存场景下，ZGC 或 Shenandoah 将展现出优势。
此外，还可以通过监控工具（如 JConsole、VisualVM、JProfiler 等）观察垃圾回收的频率、耗时等指标，结合应用的 GC 日志（通过 - XX:+PrintGCDetails 等参数开启），分析是否存在内存泄漏或回收效率低下的问题。例如，若老年代内存持续增长，且 Full GC 频率越来越高，则可能存在内存泄漏，需要通过工具定位泄漏点。
值得注意的是，垃圾回收调优的首要目标是满足应用的性能需求（如延迟、吞吐量），而非盲目追求 “零 GC”。在大多数情况下，JVM 的默认参数已经能够提供良好的性能，过度调优反而可能引入新的问题。
结语：平衡与进化的艺术
Java 的垃圾回收机制，本质上是在自动化与性能、吞吐量与延迟之间寻找平衡的艺术。从早期的 Serial 收集器到如今的 ZGC，每一次技术突破都源于对应用场景的深刻理解和对效率极限的不断探索。
对于开发者而言，理解垃圾回收机制不仅能帮助我们写出更高效的代码（如避免创建不必要的临时对象、合理使用对象池等），更能在遇到内存问题时快速定位根源。但同时也应牢记：Java 设计垃圾回收机制的初衷，是让开发者专注于业务逻辑而非内存管理。因此，在大多数情况下，我们应信任 JVM 的自动回收能力，只在必要时进行针对性调优。
随着硬件技术的发展和应用场景的扩展，Java 垃圾回收机制仍在持续进化。未来，我们有理由相信，它将在低延迟、高吞吐量、大内存支持等方面带来更多惊喜，为 Java 生态的持续繁荣提供坚实的技术支撑。