GC算法选型取决于应用特征：新生代用复制算法（适配朝生暮死对象），老年代依需求选标记-清除（重吞吐）或标记-整理（重低延迟），现代收集器如G1/ZGC采用混合策略，引用类型影响存活判定，最终需结合GC日志调优。

选对 GC 算法不是看谁“最新”或“最炫”，而是看它能不能匹配你的应用特征——比如对象生命周期、吞吐量要求、延迟敏感度和堆内存结构。JVM 默认按分代设计组织内存，不同代用不同算法，不是非此即彼的单选题，而是协同配合的整体策略。

新生代回收：复制算法是主流选择

新生代里对象“朝生暮死”，90%以上在一次 Minor GC 后就不可达。复制算法天然适配这种场景：只复制存活对象，清空原区域，无碎片、效率高、STW 时间短。

• Eden 区满即触发 Minor GC，存活对象从 Eden + 一个 Survivor 区复制到另一个 Survivor 区
• 对象年龄达阈值（默认15）或 Survivor 区放不下时，直接晋升老年代
• 大对象（如长数组）可能直接分配到老年代，避免在 Survivor 区反复复制

老年代回收：标记-清除 vs 标记-整理需权衡

老年代对象存活率高、空间大、GC 频率低。这里没有绝对优劣，只有适用差异：

• 标记-清除适合对停顿时间不敏感、且能接受内存碎片的应用（如后台批处理），回收快但易产生碎片，可能触发频繁 Full GC
• 标记-整理适合响应敏感型服务（如 Web API），通过移动对象消除碎片，但移动成本高、STW 更长，尤其在大堆下明显
• G1 和 ZGC 等现代收集器在老年代采用增量式标记+局部回收，本质是混合策略，兼顾吞吐与延迟

引用类型决定对象“存活弹性”

GC 不仅看可达性，还看引用强度。强引用对象只要被持有就不会回收；软引用在内存不足时释放，适合缓存；弱引用在下次 GC 就回收，适合临时映射；虚引用则纯粹用于跟踪回收时机。

• 用 SoftReference 做图片/数据缓存，系统压力大时自动腾空间，避免 OOM
• 用 WeakReference 管理监听器或缓存键，防止内存泄漏（如 HashMap 的 key 是普通对象易导致泄漏）
• 避免在业务逻辑中滥用 System.gc()，它只是建议，且会引发不必要的 Full GC

实际选型要看运行时表现，不是配置参数

算法效果最终体现在 GC 日志里：Minor GC 频率、每次耗时、晋升速率、Full GC 次数、停顿峰值。比如：

• 如果发现老年代增长快、Minor GC 后大量对象晋升，说明对象过早进入老年代，可调大新生代或降低晋升阈值
• 如果 Full GC 频繁且老年代使用率居高不下，可能是内存泄漏，也可能是当前算法无法应对负载模式
• ZGC 在超大堆（>4TB）和亚毫秒级停顿要求下优势明显，但小堆（