调优G1收集器应聚焦堆大小、停顿目标和日志诊断三关键点：设固定堆（如-Xms16g -Xmx16g），用-XX:MaxGCPauseMillis引导自适应回收，监控IHOP与Humongous分配定位瓶颈，避免禁用并发标记等误操作。
调优 G1 收集器应对大堆内存应用，核心不是“拼命加参数”，而是尊重 G1 的自适应机制，聚焦堆大小、停顿目标和日志诊断三个关键点。G1 专为大堆（通常 ≥ 4GB）设计，但盲目扩大堆或硬控代际比例反而会破坏其预测式回收能力。
合理设置堆大小与 Region 规模
G1 对堆有隐含适用边界：最小建议堆为 2GB（对应 2048 个 1MB Region），最大支持 64GB（32MB × 2048）。超出 64GB 仍可运行，但 Region 数量固定，单个 Region 过大会导致大对象（>50% Region 大小）增多，易引发疏散失败甚至 Full GC。
- 用 -Xms 和 -Xmx 设为相同值（如
-Xms16g -Xmx16g），避免运行时动态扩容带来的额外开销和 GC 波动 - 不建议手动设 -XX:G1HeapRegionSize，除非确认存在大量 2–8MB 的中等对象且频繁触发 Humongous 分配；默认自动推导更稳妥
- 若堆 ≥ 32GB，可考虑设 Region 为 2MB 或 4MB（需配合
-XX:G1HeapRegionSize=2M），平衡大对象分布与回收粒度
用 MaxGCPauseMillis 引导回收节奏，而非硬控年轻代
G1 的核心优势是通过动态调整年轻代占比来满足停顿目标。强行用 -Xmn 或 -XX:NewRatio 锁死年轻代大小，等于关闭 G1 的自适应引擎，极易导致 Mixed GC 频繁或停顿超标。
- 用 -XX:MaxGCPauseMillis=200（单位毫秒）设定预期停顿上限，G1 会据此自动权衡每次回收的 Region 数量和年轻代大小
- 该值不是保证值，而是启发式目标；设得太低（如 50ms）会导致回收过于保守，老年代堆积加快；设得太高（如 500ms）则失去低延迟意义
- 观察 GC 日志中实际 pause 时间是否持续接近或略超该值，再微调——不是越小越好，而是匹配业务 SLA
监控混合回收与大对象行为，定位真实瓶颈
大堆下问题往往不出在“回收慢”，而出在“不该回收的时候被迫回收”。重点看两类信号：
立即学习“Java免费学习笔记（深入）”；
-
InitiatingHeapOccupancyPercent（IHOP）：默认 45%，即老年代占整堆 45% 就触发 Mixed GC。若 Mixed GC 频繁但老年代存活对象多、回收收益低，可适度提高至 55–60（
-XX:InitiatingHeapOccupancyPercent=60），延后混合回收时机 -
Humongous 分配日志：GC 日志中出现
Humongous allocation或Full GC (G1 Compaction Pause)，说明大对象过多或 Region 不够连续，应检查是否有缓存滥用、ByteBuffer 未复用、日志批量写入等模式 - 启用详细 GC 日志：
-Xlog:gc*,gc+heap=debug,gc+ergo*=trace，重点关注[Mixed GC]的回收收益（reclaimed bytes / time）和Evacuation Failure记录
避免常见误操作
很多调优动作反而加剧问题：
- 禁用并发标记阶段（如设
-XX:ConcGCThreads=1）→ 延长整体 GC 周期，增加 Mixed GC 压力 - 为“省空间”设过小的
-Xms→ JVM 启动后频繁扩容，触发额外 Young GC - 沿用 Parallel GC 习惯调
-XX:SurvivorRatio→ G1 的 Survivor 区由 Region 动态构成，该参数无效 - 忽略应用层对象生命周期 → 比如将短期请求数据长期缓存，直接抬高老年代压力，此时调参治标不治本
