选对垃圾回收器比调参更重要：serial适合小内存单核场景，停顿可控但吞吐低；parallel追求高吞吐，停顿较长；cms低延迟但易碎片，g1兼顾吞吐与停顿；zgc/shenandoah面向超大堆与极致低延迟。
选对垃圾回收器，比调参更重要。它不是“越新越好”，而是看你的应用卡在哪——是停顿敏感、吞吐量优先，还是堆大到传统方案扛不住。
小内存、单核或后台任务用 Serial
单线程、简单高效，回收时会 Stop-the-World，但开销极低。适合嵌入式设备、小型工具类程序，或者资源受限的测试环境。JDK 8 以前 Client 模式默认就是它；4 核 4GB 以下服务器也常默认启用。不需要高并发响应，也不追求吞吐，它反而更稳。
- 启动参数：
-XX:+UseSerialGC - 新生代 + 老年代都用单线程，无并发压力，CPU 占用几乎可忽略
- 不适合 Web 服务、API 接口等对响应延迟有要求的场景
高吞吐后端服务首选 Parallel（吞吐量优先）
多线程并行回收，目标是让 JVM 尽可能多地运行用户代码。它不介意偶尔来一次稍长的停顿，只要整体单位时间处理的任务最多。典型如批处理、定时任务、离线计算等。
- 启动参数：
-XX:+UseParallelGC（新生代）+-XX:+UseParallelOldGC（老年代） - 吞吐量 = 用户代码运行时间 /（用户代码时间 + GC 时间），它会主动调大堆、延长 GC 间隔来提升该比值
- 停顿时间不可控，可能达数百毫秒，不适合实时交互类系统
低延迟 Web 服务倾向 CMS 或 G1
CMS 曾是低停顿首选，通过并发标记清除减少 STW 时间，但易产生碎片、并发失败时触发 Full GC。G1 取代了它：按 Region 划分堆，可预测停顿（比如设定 -XX:MaxGCPauseMillis=200），兼顾吞吐与响应。
- CMS 参数：
-XX:+UseConcMarkSweepGC（JDK 9+ 已废弃） - G1 参数：
-XX:+UseG1GC，默认在 JDK 9+ 成为服务端默认收集器 - 适合电商接口、消息推送、中大型 Spring Boot 应用等对 P99 延迟敏感的场景
超大堆（数十 GB 以上）且延迟严苛选 ZGC 或 Shenandoah
ZGC 和 Shenandoah 都把 STW 控制在 10ms 内，且停顿时间基本不随堆大小增长。它们靠读屏障、染色指针、并发移动对象等技术实现“几乎不停顿”。ZGC 要求 JDK 11+，Shenandoah 从 JDK 12 开始内置。
- ZGC 参数：
-XX:+UseZGC；Shenandoah：-XX:+UseShenandoahGC - 适用于金融交易系统、实时风控、大型游戏服务器、云原生微服务集群
- 需要更多 CPU 资源支撑并发操作，小堆（
特殊用途：Epsilon 和调试场景
Epsilon 是个“不回收”的回收器，只分配不清理，用于性能压测、内存泄漏定位或短生命周期进程（如 CLI 工具）。它不解决 OOM，但能帮你看清真实内存增长曲线。
- 参数：
-XX:+UseEpsilonGC - 不能用于长期运行服务，一旦堆满直接 OOM
- 配合 JFR（Java Flight Recorder）做内存行为分析很有效
