面试题：Java性能调优之垃圾回收相关

Question

在Java编程中，常见的垃圾回收器有哪些？它们各自适用于什么样的场景？如果在一个高并发且对响应时间要求较高的Web应用中，你会选择哪种垃圾回收器并说明原因。

Answer 1

常见垃圾回收器及其适用场景

1. Serial 回收器
   • 适用场景：适用于单 CPU 环境下的客户端应用，因为它在进行垃圾回收时会暂停所有用户线程（Stop - The - World），但简单高效，内存占用小。
2. ParNew 回收器
   • 适用场景：是 Serial 回收器的多线程版本，适用于多 CPU 环境，常与 CMS 回收器配合使用，作为 CMS 的初始标记和并发标记后的重新标记阶段的垃圾回收器。
3. Parallel Scavenge 回收器
   • 适用场景：主要关注系统的吞吐量，适用于后台运算而不需要太多交互的任务，比如科学计算、数据挖掘等。通过调整参数可以控制吞吐量。
4. Parallel Old 回收器
   • 适用场景：Parallel Scavenge 的老年代版本，同样关注吞吐量，适合在注重吞吐量以及 CPU 资源较为稀缺的情况下使用，与 Parallel Scavenge 搭配使用。
5. CMS（Concurrent Mark Sweep）回收器
   • 适用场景：适用于对响应时间要求高的应用，如 Web 应用。它尽可能地减少垃圾回收时的停顿时间，在垃圾回收过程中，大部分时间可以与用户线程并发执行，但会产生“浮动垃圾”，并且对 CPU 资源要求较高。
6. G1（Garbage - First）回收器
   • 适用场景：适用于堆内存较大，对响应时间有一定要求的应用。它可以预测垃圾回收的停顿时间，将堆内存划分为多个大小相等的 Region，根据垃圾回收收益动态地确定每个 Region 的回收顺序。

高并发且对响应时间要求较高的 Web 应用选择

在高并发且对响应时间要求较高的 Web 应用中，优先选择 CMS 回收器。原因如下：

1. 响应时间优先：CMS 回收器的设计目标就是尽量减少垃圾回收时的停顿时间，在垃圾回收过程中大部分时间与用户线程并发执行，这对于需要快速响应的 Web 应用至关重要，可以减少用户等待时间，提升用户体验。
2. 高并发适应性：虽然 CMS 对 CPU 资源要求较高，但在高并发场景下，它能够更好地处理并发请求，而不会像 Serial 或 Parallel 系列回收器那样长时间暂停所有用户线程，导致请求堆积。尽管 G1 回收器也能预测停顿时间，但在 JDK 7 及之前，CMS 在这类场景下经过了更多实践验证，相对更成熟。如果是 JDK 8 及之后，G1 回收器也是一个很好的选择，它兼顾了响应时间和吞吐量，且在大堆内存下表现出色。