回答
这个面试题主要考查的是你对你们系统的熟悉程度以及垃圾回收器的优劣点和使用场景。比如你可以这样回答:我们线上使用的 G1收集器,因为我们的系统使用的对内存有 32 GB,同时对 GC 的停顿时间有严格要求,而恰好 G1 收集器能够很好地处理大堆内存,且它提供了可预测的 GC 停顿时间,能够在指定的停顿时间目标内回收垃圾,并且能够有效处理大内存堆的碎片问题。
该问题没有标准答案,根据自己应用系统的实际情况来阐述即可。
扩展
常见收集器的使用场景如下表格:
收集器 | 收集类型 | 收集算法 | 优点 | 缺点 | 使用场景 |
---|---|---|---|---|---|
Serial | - 单线程 - 新生代 | 复制算法 | - 实现简单 | - 单线程,不能利用多核CPU - 停顿时间长 | - 小型应用 - 单核CPU,低停顿要求 |
ParNew | - 多线程 - 新生代 | 复制算法 | - 支持多线程并行GC,适合多核CPU,与CMS兼容 | - 停顿时间较长 | 配合CMS使用的多线程新生代收集器 |
Parallel Scavenge | - 多线程 - 新生代 | 复制算法 | - 高吞吐量,适合多核环境,自动调优GC行为 | - 停顿时间较长,响应时间不如其他低停顿收集器 | - 吞吐量优先的场景,如批处理任务,大数据计算 |
Serial Old | - 单线程 - 老年代 | 标记-整理算法 | - 简单可靠,能够避免内存碎片 | - 单线程 - Full GC时停顿时间较长 | - 用于CMS或Parallel Old失败后的Full GC |
Parallel Old | - 多线程 - 老年代 | 标记-整理算法 | - 高吞吐量,适合多核环境 - 标记整理避免内存碎片 | - 停顿时间较长,无法满足低停顿时间要求 | - 吞吐量优先的场景 - 配合Parallel Scavenge使用 |
CMS | - 并发 - 老年代 | 标记-清除算法 | - 低停顿时间 | - 内存碎片问题,可能引发并发模式失败 - Full GC时使用Serial Old,CPU消耗大 | - 低延迟的应用,如Web服务器、在线服务 |
G1 | - 并发 - 新生代 - 老年代 | 标记-复制-整理算法 | - 可预测的停顿时间 - 分区管理 - 内存压缩,减少内存碎片 - 适合大堆内存 | - 调优复杂 - 小内存场景不如其他收集器 | - 大内存应用,响应时间要求严格,线上服务,高并发场景 |