高吞吐量与低延迟是互斥目标下的业务取舍：吞吐优先选Parallel GC，延迟敏感选G1，超低延迟大堆用ZGC/Shenandoah，小内存场景Serial GC仍不可替代。
高吞吐量和低延迟不是并列选项，而是互斥目标下的业务取舍。选错回收器，轻则浪费资源，重则引发超时或雪崩。
吞吐量优先：Parallel GC 是默认且高效的选择
批处理、ETL、报表生成、离线计算等任务，核心诉求是单位时间完成最多工作，能接受单次几百毫秒甚至秒级停顿。
- Parallel GC 全程 STW，但无并发协调开销，多线程并行效率高，天然适配多核 CPU
- 开启 -XX:+UseParallelGC 即启用，无需复杂调参；堆大于 8GB 且 CPU ≥8 核时，建议设 -XX:ParallelGCThreads=物理核数×5/8，避免线程争抢
- G1 在纯吞吐场景反而可能拖慢整体进度——它的 Region 管理、并发标记等机制带来额外开销，不必要
- 可通过 -XX:GCTimeRatio=99 明确要求 GC 时间占比 ≤1%，强化吞吐导向
延迟敏感：G1 是当前最稳妥的平衡点
Web API、网关、实时推荐、交易系统等服务，用户对卡顿极其敏感，需把 P99 停顿控制在 200ms 内（理想值 10–50ms）。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- G1 不承诺硬实时，但能以可预测方式逼近软实时目标；生产推荐从 -XX:MaxGCPauseMillis=200 起步，设太低（如 50ms）会引发频繁并发标记和混合回收，反而加剧抖动
- 必须配合 -XX:G1HeapRegionSize 调整大对象阈值，防止 Humongous 分配打乱节奏
- 用 -Xlog:gc*:file=gc.log 观察每次 Evacuation Pause 的实际耗时分布，重点关注长尾而非平均值
- 堆小于 4GB 时不推荐 G1，其 Region 管理开销可能高于 Serial 或 Parallel
超低延迟大堆场景：ZGC / Shenandoah 有明确前提
金融行情、实时风控、内存数据库等要求停顿稳定在 10ms 内、堆常达数十 GB 甚至 TB 级。
立即学习“Java免费学习笔记（深入）”；
- ZGC 要求 Linux 64-bit + JDK 17+（生产强烈建议），Shenandoah 在 JDK 16+ 才默认启用
- “停顿与堆大小无关”成立的前提是：分配速率稳定、无突发大对象潮、元空间/Reference 处理不积压
- 真实瓶颈常不在 GC 本身，而在安全点同步、类卸载卡顿等“非 GC 停顿”，需结合 -XX:+PrintSafepointStatistics 排查
- 两者都不支持关闭压缩指针（-XX:-UseCompressedOops）的大堆（>4TB），这点极易忽略
小内存或资源受限系统：Serial GC 依然不可替代
堆 ≤1GB、单核或双核 CPU、请求量低的后台工具、嵌入式 Java 应用。
- 单线程回收，无同步/通信开销，内存占用最小
- 几十毫秒级 STW 对业务完全无感
- 只需 -XX:+UseSerialGC，开箱即稳，别强行上 G1 或 ZGC
- 在容器内存配额紧张（如 512MB）时，Serial 的确定性比并发回收器更可靠
