Java GC通过可达性分析（从GC Roots出发）判断堆中对象是否存活，分代回收：Minor GC清理新生代，Full GC清理全堆及元空间；采用复制、标记-清除、标记-整理算法组合，不同收集器侧重吞吐量或低延迟。
Java垃圾回收（GC）机制是JVM自动管理堆内存的核心功能，它负责识别并回收不再使用的对象，释放内存空间，避免内存泄漏和溢出。它不处理栈、方法区或本地方法栈中的内存——这些区域的生命周期与线程或类加载周期绑定，天然具备确定性。GC真正聚焦的是堆中动态分配、生命周期不可预知的对象。
怎么判断一个对象该被回收
关键在于“是否还活着”，主流用的是可达性分析算法，不是引用计数法。
- 从一组固定起点（GC Roots）出发，比如：虚拟机栈里正在用的局部变量、方法区的静态变量、常量池里的字符串、JNI调用中本地方法持有的对象
- 顺着所有引用链往下找，能触达的对象就是存活的；找不到的，就被标记为可回收
- 引用计数法虽然简单，但解决不了循环引用（如A.instance = B; B.instance = A），所以JVM没采用它
什么时候触发回收：分代是核心逻辑
基于“弱分代假说”（大多数对象朝生夕灭）和“强分代假说”（活久的对象更可能继续活），堆被划分为新生代和老年代，回收时机和方式不同：
-
Minor GC（Young GC）：Eden区满时触发，只清理新生代。频率高、停顿短。存活对象会进入Survivor区，多次幸存后晋升到老年代
-
Major GC / Old GC：仅CMS收集器支持单独清理老年代；其他场景下，“Major GC”常被误用，实际多指Full GC
-
Full GC：回收整个堆（新生代+老年代）+ 方法区（元空间）。触发条件包括：老年代空间不足、显式调用System.gc()（不推荐）、元空间耗尽、CMS并发失败等。停顿时间长，应尽量避免
怎么回收：三种基础算法 + 分代组合
每种算法适配不同内存区域的特点：
-
复制算法：用于新生代。把Eden和一个Survivor中的存活对象复制到另一个Survivor，清空原区域。高效、无碎片，但浪费一半空间（现代默认Eden:S0:S1 = 8:1:1）
-
标记-清除：先标记存活对象，再清除未标记的。适合老年代初期，但容易产生内存碎片，影响大对象分配
-
标记-整理：在标记-清除基础上，把存活对象往一端移动，再清理边界外内存。解决碎片问题，但移动成本高，适用于老年代
常见回收器与选择倾向
不同收集器是上述算法的具体实现，侧重不同目标：
-
Serial / Serial Old：单线程，适合客户端小应用
-
ParNew + CMS：曾是主流低延迟组合（CMS已废弃）
-
P
arallel Scavenge + Parallel Old：追求吞吐量优先，适合后台批处理
-
G1：面向服务端，可预测停顿时间，混合回收（新生代+部分老年代）
-
ZGC / Shenandoah：超低延迟（亚毫秒级STW），依赖读屏障、染色指针等新机制，适合金融、实时系统
基本上就这些。理解GC，重点不在背参数，而在于看清“对象怎么死”“什么时候动”“怎么动得又快又稳”。调优本质是根据业务特征，在吞吐、延迟、内存占用之间做取舍。
