Serial GC 是小内存、单核或嵌入式场景的合理选择，因其内存占用低15–25%、Minor GC停顿稳定在10–50ms、配置极简（仅需-Xms/-Xmx和-XX:+UseSerialGC），适用于堆≤200MB、短生命周期对象多、无强实时交互的轻量环境。
选对垃圾回收器，关键不是看哪个“新”或“强”，而是看业务最不能忍受什么：是几秒的停顿，还是吞吐量掉 5%，又或是容器里多占 200MB 内存。
小内存、单核或开发测试环境用 Serial GC
堆大小通常在 100MB–500MB，CPU 核数 ≤ 1，比如本地启动的 Spring Boot 小服务、脚本工具、单元测试进程。Serial GC 单线程执行，STW 时间短（毫秒级），没有并发开销，也不吃额外内存。虽然吞吐低，但这类场景本来就不拼吞吐。
- 启用参数：-XX:+UseSerialGC
- 不用配任何 pause 或 throughput 目标，它不支持这些调优项
- 避免用于生产 Web 服务或微服务，哪怕堆只有 1GB——多核被浪费，延迟波动大
批处理、离线计算类任务优先 Parallel GC
典型如日志分析、报表生成、ETL 任务。核心诉求是“单位时间处理数据最多”，允许单次 GC 停顿稍长（几百毫秒甚至秒级），只要总运行时间最短。Parallel GC 多线程并行回收，吞吐量在所有 GC 中最高，且对 CPU 和内存都“轻量”。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 启用参数：-XX:+UseParallelGC -XX:+UseParallelOldGC
- 可配合 -XX:MaxGCPauseMillis 设置目标，但注意：它只尽力而为，不保证；设太低反而会降低吞吐
- 适合堆 2GB–32GB、CPU 核数 ≥ 4 的后台作业
Web 服务、API 网关等通用后端推荐 G1 GC
兼顾延迟与吞吐的“均衡型选手”，JDK 9+ 默认，也是当前生产中最广泛落地的 GC。它把堆切分成 Region，能按需控制 Mixed GC 的停顿时间（通常 50–200ms），同时避免 CMS 的碎片和 Full GC 风险。适用于大多数微服务、Spring Cloud 架构。
立即学习“Java免费学习笔记（深入）”；
- 启用参数：-XX:+UseG1GC -XX:MaxGCPauseMillis=100（建议值 50–200）
- 配合 -XX:G1HeapRegionSize 调整 Region 大小（默认 1–4MB），避免大对象频繁触发 Humongous 分配
- 堆建议 ≥ 4GB；小于 2GB 时 Serial 或 Parallel 更稳；大于 64GB 且延迟敏感，考虑 ZGC
超低延迟场景（金融交易、实时风控）上 ZGC
当 P99 延迟必须压到 10ms 以内，且堆经常超过 32GB，ZGC 是目前最可靠的选择。它的 STW 时间恒定在亚毫秒级（通常
- 启用参数：-XX:+UseZGC -XX:+UnlockExperimentalVMOptions（JDK 15+ 生产可用，JDK 17+ 无需 unlock）
- 无需设置 MaxGCPauseMillis——它天生满足亚毫秒目标
- 要求 Linux/x64 或 Windows x64，JDK ≥ 15（推荐 JDK 17/21）；不支持 macOS（仅限实验）
