选垃圾回收器本质是权衡吞吐量与停顿时间，需按业务场景匹配：电商下单、支付等响应敏感服务应优先控stw，g1（jdk9+默认，4–64gb堆，p99≤200ms）为稳态首选，zgc和shenandoah适用于亚毫秒级低延迟需求。
选垃圾回收器，本质是权衡吞吐量和停顿时间——这两个指标通常此消彼长。没有“最好”的回收器，只有“最适合当前业务场景”的那一个。
看业务对响应速度有多敏感
电商下单、支付、秒杀接口这类服务，用户能感知到几百毫秒的卡顿，甚至直接放弃操作。这时候必须优先控制 STW（Stop-The-World）时间。
- CMS（已废弃，仅作历史参考）曾主打并发标记，但存在浮动垃圾和 Full GC 风险；
- G1 在 JDK 9+ 成为主流低延迟选择，支持设定 -XX:MaxGCPauseMillis=200 这类目标，适合堆内存 4–64GB、P99 延迟要求 ≤ 200ms 的中大型服务；
- ZGC（JDK 11 引入，JDK 15+ 生产就绪）和 Shenandoah（JDK 12 引入）真正实现亚毫秒级停顿（通常
看任务是否追求单位时间处理量
日志归档、报表生成、ETL 数据清洗等后台任务，不与用户直接交互，更看重“一小时内能跑完多少批次”，此时吞吐量是第一目标。
- Parallel GC（即吞吐量优先回收器）仍是 JDK 8 默认、JDK 17 以前的推荐选择，通过 -XX:+UseParallelGC 启用，多线程并行回收新生代，老年代也并行（Parallel Old）；
- 它在多核 CPU + 中等堆（2–16GB）下表现稳定，STW 时间可能达 100–500ms，但总运行时间最短；
- 注意：别强行把它用在 Web API 服务上——哪怕 QPS 只有 50，一次 300ms 的 GC 也可能触发下游超时熔断。
看堆内存大小和部署环境
小堆、大堆、容器化、云原生，直接影响回收器可行性。
- 堆 ≤ 1GB：Serial GC 足够，轻量无开销，适合嵌入式、CLI 工具或单机脚本；
- 堆 4–32GB：G1 是平衡之选，兼顾可控停顿与较好吞吐，且支持弹性 Region 划分；
- 堆 ≥ 64GB 或容器内存限制严格（如 Kubernetes limit=8Gi）：ZGC 更可靠——它不随堆增大而显著增加停顿，且可配合 -XX:+UseZGC -XX:SoftRefLRUPolicyMSPerMB=1000 控制软引用回收策略；
- 注意：CMS 和 SerialOld 在 JDK 14+ 已被彻底移除，G1 在 JDK 21 成为默认，ZGC 在 JDK 21 支持分代（ZGenerationalZGC），进一步提升中小对象回收效率。
看监控和调优能力是否跟得上
越先进的回收器，配置和诊断门槛越高。
- Parallel GC 参数少、行为可预测，-XX:GCTimeRatio=99 就能明确吞吐目标；
- G1 需关注 -XX:InitiatingHeapOccupancyPercent（触发并发标记的堆占用阈值）、-XX:G1HeapRegionSize（影响大对象分配），日志需开启 -Xlog:gc*,gc+phases:file=gc.log；
- ZGC 要依赖 JFR（Java Flight Recorder）做停顿归因，常见瓶颈是“Mark Stack Overflow”或“Relocate Timeout”，需结合 -XX:+UnlockExperimentalVMOptions -XX:+ZUncommitDelay=30000 等调优；
- 建议上线前做基线压测：相同流量下对比 GC 频次、总暂停时间、Prometheus 中 jvm_gc_pause_seconds_count 指标走势。
