说说垃圾回收算法？
完整答案应从可达性、回收基本算法、分代假设讲到收集器目标，并用日志和业务指标验证选择。
直接结论
垃圾回收先确定对象是否仍可从 GC Roots 可达，再回收不可达对象占用的堆空间。常见基本思想包括标记-清除、复制和标记-整理；现代 HotSpot 收集器会组合这些思想，并依据吞吐量、暂停时间、堆大小和硬件条件做不同权衡。不能把某个收集器简单等同于一种算法，也不存在对所有业务都最优的 GC。回答最后应落到目标：先定义延迟 SLO、吞吐和内存预算，再选收集器并通过 GC 日志验证。
原理与步骤
标记-清除无需移动所有存活对象，但可能产生碎片；复制把存活对象迁移到另一空间，分配快但需要预留空间；标记-整理在标记后压缩存活对象，减少碎片但移动成本更高。分代收集利用大多数对象朝生夕灭的经验，把新对象和长寿命对象用不同频率处理。不同收集器还需处理并发标记期间引用变化、写屏障、停顿阶段和回收集合，具体阶段应以目标 JDK 的官方调优文档和日志名称为准。
工程场景
批处理服务通常更关心单位时间完成量，可容忍较长暂停；交互式 API 更关注高分位延迟；大堆服务则要关注并发回收开销、回收是否跟得上分配速度以及容器内存边界。实践顺序是先使用合理默认值，开启统一 GC 日志，观察分配速率、暂停分布、晋升、堆占用恢复和 CPU，再调整堆或收集器。频繁 Full GC 可能来自内存泄漏、分配突增、堆过小或本地资源压力，不能只靠扩大堆掩盖。
验证与边界
验证需要结合应用级 p95/p99、吞吐、CPU、RSS 和 GC 日志，压测负载必须接近真实对象生命周期。平均暂停很低不代表尾延迟达标；堆内占用稳定也不代表没有直接内存或线程栈问题。System.gc 的行为可受配置影响，finalization 也不应作为资源释放机制。收集器名称、默认选择和可用特性会随 JDK 变化，所以回答要注明版本，并把原理、官方支持范围与本机实测分开。
答题练习
- 1可达性决定存活
- 2三类基本回收思想
- 3以延迟吞吐和内存目标选型
常见错误
- 把收集器和单一算法画等号
- 只看平均暂停或只会调大堆
可能追问
- 如何从 GC 日志定位问题
- 低延迟与高吞吐如何权衡
来源记录
- 原始来源
- 小林coding
- 来源页面
- 微众银行 Java 面试
- 最近收录
- 2026-07-05
- 官方复核
- Oracle Java 官方文档