直接原因是g1回收器高负载下频繁退化为full gc，触发serial gc导致数百毫秒至数秒stw；需三步交叉验证是否真由gc停顿引发超时，并通过调参与排查非参数诱因来稳定mixed gc。
直接原因是 G1 回收器在高负载下频繁退化为 Full GC，触发单线程 Serial GC，造成数百毫秒至数秒的全局停顿（STW），使正在处理的网络请求卡住、超时。这不是“GC慢”，而是回收机制失效——Mixed GC 失效，老年代压力失控，最终被迫兜底执行 Full GC。
确认是否真由 GC 停顿引发超时
不能只看日志里有没有 “Full GC” 字样。需三步交叉验证：
- 查 GC 日志中是否含 Full GC (Ergonomics) 或 Full GC (System.gc())，并记录对应 STW 时间（如
Pause Young (Mixed)后紧接Full GC） - 比对 STW 时间与业务超时阈值：若某次 Full GC 停顿 2800ms，而 Dubbo/HTTP 接口超时设为 3000ms，就高度吻合
- 排除伪装项：Metaspace 满、Direct Buffer 耗尽也会打印 “Full GC”，但实际是元空间或堆外内存问题，可用
jstat -gc <pid></pid>观察 MU（Metaspace Used）和 CCU（Compressed Class Space Used）是否持续上涨
核心调参：让 Mixed GC 稳住老年代
目标不是“减少 GC 次数”，而是确保 Mixed GC 能真正回收老年代 Region，避免退化。以下参数经多个高并发生产环境验证有效：
- -XX:InitiatingHeapOccupancyPercent=35～40：默认 45，若老年代增长快（如每分钟涨 1GB），降到 35 可提前启动并发标记，给 Mixed GC 留出回收窗口
- -XX:G1MixedGCLiveThresholdPercent=85：只回收存活对象比例 ≥85% 的老年代 Region，跳过“太干净”的 Region，集中资源处理真正积压的区域
- -XX:G1HeapRegionSize=16m 或 32m：64GB 堆建议用 32MB；Region 过小（如默认 1MB）会导致大对象（>½ Region）直入老年代，加剧碎片和 Humongous 分配
- -XX:G1ReservePercent=15：预留 15% 堆空间应对晋升突增，防止 Mixed GC 中因无空闲 Region 而直接 Full GC
必须同步排查的非参数诱因
参数再优，若存在以下问题，Full GC 仍会高频发生：
-
对象晋升异常：加
-XX:+PrintGCDetails -XX:+PrintAdaptiveSizePolicy，观察每次 Young GC 后晋升老年代的平均大小；若稳定 > 当前老年代剩余空间，说明 Survivor 区太小或对象年龄阈值（MaxTenuringThreshold）设得太低 -
大对象直入老年代：GC 日志中出现
Humongous allocation，常见于大缓存加载、整文件读取、超长 JSON 反序列化；应改用流式解析（如 Jackson Streaming API）或分块处理 -
内存泄漏迹象：用
jstat -gc <pid> 5000</pid>每 5 秒采样，观察 OU（Old Used）是否阶梯式上升、且多次 Full GC 后不回落 -
显式 System.gc() 调用：检查代码及第三方 SDK（如旧版 Druid 连接池、Netty 工具类），禁用或替换为
Cleaner/PhantomReference
监控与验证手段
调优后必须闭环验证效果：
- 用
jstat -gcutil <pid> 1000</pid>实时观察 YGC/FGC 频次、GCT（总 GC 时间）和 GCU（GC 耗时占比），目标是 FGC=0，GCU - 开启详细 GC 日志：
-Xlog:gc*,gc+heap=debug,gc+ergo*=debug:file=gc.log:time,tags,uptime（JDK10+），重点看 Mixed GC 是否真正执行、回收了多少老年代 Region - 结合链路追踪（如 Sleuth+Zipkin）比对：若某次请求耗时突增 2.7s，且该时间段内恰好发生一次 Full GC，即可锁定根因
