选对gc需匹配业务场景：吞吐量优先用parallel gc，延迟敏感选g1、zgc或shenandoah，内存受限场景需兼顾效率与稳定性。
选对垃圾收集器（GC），关键不是看哪个“最新”或“最火”，而是匹配业务场景的真实需求。高吞吐、低延迟、内存敏感、还是长周期稳定运行——不同目标对应完全不同的GC策略。
看吞吐量优先：适合批处理、后台计算类业务
如果系统以长时间运行的离线任务为主（比如日终结算、报表生成），停顿时间容忍度高，但要求单位时间内完成尽可能多的工作，那就优先考虑吞吐量导向的收集器。
- 推荐使用Parallel GC（JDK8默认，也叫吞吐量收集器），它用多线程并行回收年轻代和老年代，最大化CPU利用率
- 通过-XX:+UseParallelGC启用，配合-XX:MaxGCPauseMillis可设目标暂停时间（但不保证达成），-XX:GCTimeRatio控制GC时间占比
- 注意：它会牺牲单次停顿时间换吞吐，不适合用户强感知的交互型服务
看响应延迟：适合Web API、实时交易等在线服务
用户点击后必须在100ms内返回结果？订单支付链路不能卡顿？这类场景对GC停顿极其敏感，目标是把每次STW（Stop-The-World）压到几十毫秒甚至更低。
- G1 GC（JDK9+默认）是平衡之选：可预测停顿、支持大堆（几十GB）、能设置最大停顿目标（-XX:MaxGCPauseMillis），适合大多数中大型在线应用
- 超低延迟要求（如高频交易、VR/AR后端）可考虑ZGC（JDK11引入）或Shenandoah（JDK12+），它们实现并发标记与移动，停顿基本稳定在10ms以内，且不随堆大小显著增长
- 启用ZGC需明确指定：-XX:+UseZGC，并确保堆不超过4TB（ZGC当前限制），同时JVM需运行在支持的OS和CPU上
看内存效率与稳定性：适合资源受限或长期运行服务
嵌入式设备、容器化部署（如512MB内存限制）、或需要7×24小时不间断运行的网关/中间件，既要避免频繁GC，又要防止内存碎片导致OOM。
- 小堆（Serial GC反而更轻量（尤其Client模式或测试环境），用-XX:+UseSerialGC启用
- 老年代碎片风险高（如长期运行后对象生命周期差异大）：G1和ZGC都内置压缩机制，能主动整理内存；而CMS已废弃，不建议新项目使用
- 容器环境下务必配-XX:+UseContainerSupport（JDK10+默认开启），让JVM正确读取cgroup内存限制，否则GC可能误判可用内存
别跳过验证环节：参数调优必须结合真实负载
理论匹配只是起点，生产环境的表现取决于实际对象分配速率、存活对象比例、晋升行为等动态因素。
- 上线前用真实流量或压测工具模拟，开启GC日志：-Xlog:gc*:file=gc.log:time,tags,level（JDK11+）或-XX:+PrintGCDetails -XX:+PrintGCTimeStamps（旧版）
- 重点关注：Young GC频率与耗时、Full GC是否发生、老年代占用趋势、GC后内存释放是否充分
- 避免盲目调大堆内存——可能拉长单次GC时间；也不要只盯着“停顿短”，还要看吞吐是否达标、CPU是否被GC持续占满
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
