java垃圾回收器选择应匹配应用特征与性能目标，而非追求最新；jdk 8默认parallel gc，jdk 9起g1为默认，jdk 17+推荐zgc/shenandoah；响应敏感服务选低延迟回收器，批处理等重吞吐场景宜用parallel gc；需结合配置与压测验证效果。
Java 垃圾回收器的选择，核心是匹配应用的运行特征和性能目标，而不是追求“最新”或“最热门”。JDK 版本、堆大小、延迟敏感度、吞吐量要求、是否使用大内存或容器环境，都会直接影响回收器效果。
看 JDK 版本和默认策略
JDK 8 默认用 Parallel GC（吞吐量优先），JDK 9 开始 G1 成为默认，JDK 17+ 推荐 ZGC 或 Shenandoah（低延迟场景）。但默认不等于最适合——比如一个批处理服务跑在 JDK 17 上，用 Parallel GC 可能比 ZGC 更稳更快。
- JDK 8：重点考虑 Parallel、CMS（已废弃）、G1；CMS 不再维护，生产环境避免使用
- JDK 11+：G1 稳定成熟，适合大多数中大型应用（堆 4–64GB）
- JDK 17+：ZGC（毫秒级停顿，支持 TB 级堆）、Shenandoah（低延迟，对 CPU 更友好）可评估启用
按应用类型和 SLA 选型
响应时间敏感的服务（如 API 网关、实时交易）优先考虑低暂停回收器；后台计算、ETL 等对吞吐量要求高、可容忍秒级停顿的，Parallel GC 往往更高效。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 要求 GC 停顿
- 停顿可接受 50–200ms，堆 4–32GB → G1 是均衡选择，调优空间大
- 纯吞吐量优先（如离线任务），且停顿不敏感 → Parallel GC 启动快、CPU 利用率高
- 堆
结合部署环境做验证
容器（如 Kubernetes）中运行时，要显式设置 -Xmx 和 -Xms，并通过 -XX:+UseContainerSupport（JDK 10+ 默认开启）让 JVM 正确读取 cgroup 内存限制。否则 G1/ZGC 可能因误判堆可用内存而频繁回收。
- 在容器里禁用 Swap，避免 GC 触发不可控交换
- 用 -Xlog:gc*:file=gc.log 记录详细日志，配合 GCViewer 或 gceasy.io 分析停顿分布与原因
- 压测时观察：不是只看平均停顿，更要关注 P99/P999 停顿、晋升失败频率、并发标记耗时
别跳过基础调优就换回收器
很多“GC 问题”其实源于对象生命周期设计或内存泄漏，而非回收器本身。换回收器前先确认：
- 是否存在大量短生命周期大对象（如反复生成大 byte[]）？考虑对象池或流式处理
- 是否有未关闭的资源或静态集合持续 hold 对象？用 MAT 或 jcmd + jhat 检查内存快照
- 年轻代是否太小导致过早晋升？适当增大 -Xmn 或用 -XX:NewRatio 控制比例
- G1 中 Region 大小是否合理？大对象（> Region 的 50%）会直接进老年代，引发碎片和 Mixed GC 频繁
不复杂但容易忽略：合适的 GC 器 = 匹配场景 + 正确配置 + 持续监控。上线前至少用真实流量压测 30 分钟，对比不同回收器下的 P99 延迟和吞吐变化，比看文档更可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
