停顿时间过长主因是GC策略不匹配应用节奏，非堆过大；应启用G1并配置-XX:+UseG1GC、-XX:MaxGCPauseMillis=200、-Xms4g -Xmx4g等关键参数，结合GC日志验证调优效果。
停顿时间过长，核心不是堆太大，而是 GC 策略没对上应用节奏。G1 是当前最稳妥的选择，但光开 -XX:+UseG1GC 不够，得配准几个关键参数，并配合日志验证。
优先启用 G1 并设好目标停顿
G1 的设计目标就是可控停顿，但默认不启用（JDK 8 需显式加），且目标值不设等于白开：
- 必须加上：
-XX:+UseG1GC - 设一个务实的目标值：
-XX:MaxGCPauseMillis=200（常见范围 150–250ms；设太低如 50，反而引发更频繁回收） - 堆大小要固定：
-Xms4g -Xmx4g（避免动态扩容干扰 G1 区域规划，也防止老年代突然膨胀）
控制对象晋升节奏，减少老年代压力
很多长停顿源于大量对象“挤”进老年代，触发混合回收甚至退化 Full GC：
- 调低晋升年龄：
-XX:MaxTenuringThreshold=6（默认 15，短生命周期业务用 6–8 更合理） - 给 Survivor 区留足空间：
-XX:SurvivorRatio=6（Eden:Survivor = 6:1:1，防过早溢出） - 限制大对象直入老年代：
-XX:PretenureSizeThreshold=1048576（即 1MB，按实际最大业务对象微调） - 提前启动并发标记：
-XX:InitiatingHeapOccupancyPercent=40（默认 45，略下调可抢出回收窗口）
优化 Region 与混合回收行为
Region 大小和混合回收策略直接影响疏散（Evacuation）效率，尤其在老年代对象多、跨区引用复杂时：
立即学习“Java免费学习笔记（深入）”；
- 按堆大小设 Region：
-XX:G1HeapRegionSize=2m（4–8GB 堆常用 1–2MB；16GB 可试 4MB；必须是 2 的幂） - 让 Mixed GC 更聚焦：
-XX:G1MixedGCLiveThresholdPercent=85（只回收存活率 ≥85% 的 Region，省下资源干更有价值的事） - 预留缓冲空间防退化：
-XX:G1ReservePercent=15（防止 Mixed GC 中因无空闲 Region 而直接 Full GC）
必须开启日志并看真实数据
所有调优不看日志都是拍脑袋。重点不是平均停顿，而是毛刺和阶段耗时分布：
- JDK 10+ 推荐：
-Xlog:gc*,gc+phases:file=gc.log:time,uptime,tags - JDK 8/9 可用：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/path/gc.log - 重点关注：日志中
G1 Evacuation Pause (mixed)的耗时、每次回收的老年代 Region 数、是否有Concurrent Mode Failure或Full GC - 辅助验证：
jstat -gc -h10 <pid> 1000持续观察 YGC/FGC 频次与各区内存变化趋势
