选垃圾回收器本质是将业务sla转化为gc行为约束：停顿敏感型服务（如web api）须用g1/zgc控stw在毫秒级，吞吐敏感型（如etl）宜用parallel gc保高吞吐，小内存容器场景serial gc更轻量，且必须结合gc日志与真实压测验证。
选垃圾回收器，本质是把业务 SLA 转成 GC 行为约束：停顿不能超时、吞吐不能掉线、内存不能溢出。不是看参数多不多，而是看哪项指标一破，用户或系统就直接报警。
看核心 SLA 是停顿时间还是吞吐量
停顿时间敏感型服务（如 Web API、支付回调、实时搜索）要求 P99 响应 ≤ 200ms，那单次 GC STW 就必须压在 50ms 内甚至更低。这类系统不能用 Parallel GC——它不控停顿，只保吞吐；G1 是稳妥选择，设 -XX:MaxGCPauseMillis=200 可引导它做区域级精细回收；若 SLA 卡在 10ms 级（比如行情推送、风控决策），ZGC 或 Shenandoah 更合适，它们的 STW 和堆大小无关，基本恒定在亚毫秒到几毫秒。
吞吐量敏感型服务（如日终对账、ETL 清洗、报表生成）更在意“单位时间干完多少活”，允许单次暂停 300–800ms。Parallel GC 正是为此设计：-XX:+UseParallelGC 启用后，多线程并行回收年轻代和老年代，CPU 利用率拉满；配合 -XX:GCTimeRatio=99（即 GC 时间占比 ≤1%），能稳住整体吞吐目标。
看内存与硬件是否匹配 SLA 要求
SLA 再严，也得落在物理资源上。容器环境常限 512MB–2GB 内存，又跑着 Spring Boot 网关这类长期稳态服务，这时候硬上 G1 或 ZGC 反而坏事——G1 的 Region 管理开销、ZGC 的染色指针内存占用，在小堆下不成比例地放大。反而 -XX:+UseSerialGC 更轻量，STW 通常仅几毫秒，且无并发线程调度干扰。
大堆（≥8GB）+ 多核（≥8 核）才真正释放 G1 价值；ZGC 生产可用需 JDK15+，且依赖 OS 支持（Linux ≥4.14、x86-64/AArch64）。若 SLA 要求低延迟但运行在旧内核或 ARM 小板上，Shenandoah 往往是更现实的选择。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
看 GC 日志是否真实守住 SLA
参数设得再准，不验证就是纸上谈兵。上线前必须压测，并开启结构化日志：-Xlog:gc*:file=gc.log:time,tags,level（JDK11+）。重点盯三件事：
- 停顿是否突破阈值：比如 SLA 要求 ≤200ms，但日志里反复出现 320ms 的 Mixed GC
- 吞吐是否坍塌：GCTimeRatio 设为 99，结果 GC 时间占比却升到 8%，说明晋升过快或对象存活率高
- 内存是否失衡：老年代使用率持续爬升、Minor GC 间隔越来越短，预示着 Full GC 风险临近
发现异常不是立刻调参，而是回溯业务行为——是不是某接口突然返回超大 JSON 导致对象驻留老年代？是不是缓存没设 TTL，让短期数据变成长期对象？
别忽略容器与 JDK 版本的实际限制
很多团队 SLA 定得漂亮，但忘了 JVM 是否“看得见”资源上限。Kubernetes 里配了 2GB 内存 limit，若没加 -XX:+UseContainerSupport（JDK10+ 默认开启，但旧版本或定制镜像可能关闭），JVM 仍按宿主机内存算堆，默认分配过大，极易触发 OOMKill。
JDK8 默认 Parallel，JDK11+ 默认 G1，但默认 ≠ 适配。电商大促前把网关从 Parallel 换成 G1 是常见动作，因为 G1 在中等堆下对延迟更友好；而批处理任务从 G1 换回 Parallel，往往能提升 5–10% 吞吐——前提是压测验证过停顿仍在容忍范围内。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
