JVM垃圾回收优化是围绕应用真实行为的持续反馈过程，需先明确停顿时间或吞吐量目标，再选匹配收集器并分析结构化GC日志。
JVM 垃圾回收器的优化不是调几个参数就完事，而是围绕应用真实行为展开的持续反馈过程。核心在于让 GC 适配业务特征——比如 Web 服务要压低停顿，批处理任务则更看重吞吐量。
明确目标：先定指标，再选策略
GC 优化必须从目标出发。高并发 API 服务通常以 停顿时间（Latency） 为第一优先级，目标是把单次 GC 暂停控制在 10ms 内；后台定时任务或数据计算类应用，则更适合追求 吞吐量（Throughput），即最大化用户代码运行时间占比。这两者天然存在权衡，盲目追求“零停顿”或“零 Full GC”反而可能降低整体效率。
- 用
-Xlog:gc*:file=gc.log开启结构化 GC 日志，这是所有分析的起点 - 关注关键字段：
pause time（单次暂停）、gc cause（触发原因）、heap usage before/after（各代使用率变化） - 避免只看“GC 次数”，更要结合每次回收释放的内存大小和耗时判断是否健康
匹配回收器：别让 CMS 或 Parallel 跑在响应敏感场景
不同收集器设计目标差异巨大，硬套会导致反效果。JDK 17+ 默认 G1 已覆盖大多数通用场景，但仍有明确取舍：
-
G1：适合堆大小 4GB–64GB 的中大型应用，通过
-XX:MaxGCPauseMillis=20设定目标停顿，配合-XX:G1HeapRegionSize避免大对象跨区问题 - ZGC：堆大于 64GB 且要求亚毫秒级停顿（-XX:+UseZGC，对代码无侵入
- Serial/Parallel：仅适用于单核 CPU、小内存（
调参不靠猜：聚焦三类关键配置
真正影响 GC 行为的参数其实很有限，优先调整以下三项，比盲目改一堆冷门参数更有效：
立即学习“Java免费学习笔记（深入）”；
-
堆结构比例：用
-XX:NewRatio=2（新生代:老年代 = 1:2）替代固定-Xmn，更适应动态负载；Survivor 区过小会加速晋升，可设-XX:SurvivorRatio=8 -
对象晋升控制：默认年龄阈值 15 容易导致短生命周期对象滞留，若监控发现 Survivor 区长期高水位，可降至
-XX:MaxTenuringThreshold=6 -
大对象直入老年代：频繁分配 >1MB 的缓存对象？加
-XX:PretenureSizeThreshold=1048576，避免在新生代反复复制
诊断先行：别跳过 Heap Dump 和分配速率分析
频繁 Young GC 往往不是堆太小，而是对象创建太快；Full GC 不一定因内存不足，可能是元空间泄漏或 JNI 引用未释放。必须结合工具验证：
- 用
jstat -gc <pid>实时看 Eden 使用率和 GC 频率，确认是否“分配风暴” - 触发一次 Full GC 后执行
jmap -dump:format=b,file=heap.hprof <pid>，用 MAT 分析 dominant class 和 leak suspect - 用
arthas trace定位高频 new 操作的业务方法，从源头减少临时对象
