解决JVM垃圾回收延迟尖峰需从GC选型、堆结构、对象生命周期和运行环境四方面协同优化：优先选用G1（4–16GB堆）或ZGC/Shenandoah（>16GB且亚十毫秒停顿），固定堆大小、扩大新生代、避免大对象直入老年代，结合GC日志、jstat、JFR精准定位瓶颈，并在代码层减少临时对象创建、复用资源、引入缓存淘汰与内存泄漏排查。
解决 JVM 垃圾回收引起的延迟尖峰，核心是控制 Stop-The-World（STW）时间，尤其要避免 Full GC 或长时 Minor GC 导致的毫秒级甚至秒级卡顿。这不是单纯调参数就能搞定的事，得从 GC 选型、堆结构、对象生命周期和运行环境四方面协同优化。
选对垃圾收集器，匹配业务延迟敏感度
不同收集器设计目标差异巨大，选错会放大问题：
- Web 接口、实时推送等低延迟场景，禁用 ParallelGC（默认吞吐量优先，Full GC 停顿可达数秒）；改用 G1 或 ZGC
- G1 更适合 4–16GB 堆，通过 -XX:+UseG1GC -XX:MaxGCPauseMillis=200 设定目标停顿，JVM 会动态调整回收节奏
- 堆 > 16GB 且要求亚十毫秒停顿，可评估 ZGC（JDK 11+）或 Shenandoah（JDK 12+），它们真正实现并发标记与移动
- 若仍在用 CMS，注意它已废弃（JDK 14 起移除），且需搭配 -XX:+UseCMSInitiatingOccupancyOnly 才能稳定触发，否则阈值会被 JVM 动态覆盖
合理配置堆与分区，减少对象过早晋升
延迟尖峰常源于老年代频繁回收，而根本原因是对象太快进入老年代：
- 设置 -Xms 和 -Xmx 相等（如 -Xms8g -Xmx8g），避免堆动态扩容带来的额外 GC 压力
- 新生代不宜过小：G1 下可通过 -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=60 扩大 Eden 区占比，缓解 Minor GC 频率
- 避免大对象直接进老年代：用 -XX:G1HeapRegionSize=1M（或 2M）配合业务最大对象尺寸，防止单个对象占满 Region 强制晋升
- 检查是否存在“隐式大对象”，比如日志拼接字符串、缓存中未分片的集合，这类对象虽未显式 new byte[1MB]，但实际占用超 Region 一半也会直入老年代
用监控定位真实瓶颈，不靠猜测
很多所谓“GC 尖峰”其实不是 GC 本身的问题，而是误判：
- 开启详细 GC 日志：-Xlog:gc*,gc+heap=debug,gc+age=trace:single-gc.log:time,tags,level（JDK 10+），重点关注 Pause、Evacuation、Mixed GC 的耗时分布
- 用 jstat -gc
每 1 秒采样，观察 YGC 次数、FGC 次数、堆各区域使用率变化趋势；若 FGC 频繁但老年代回收量极小，可能是元空间泄漏或类加载器未释放 - JFR（Java Flight Recorder）录制 5 分钟典型负载，分析 “Garbage Collection” 事件中的 pause time、reason（如 Allocation Failure、Metadata GC Threshold）、以及 concurrent phase 是否被阻塞
- 注意容器环境陷阱：Docker 中若未配 -XX:+UseContainerSupport（JDK 10+ 默认开启），JVM 可能读错 cgroup 内存上限，导致堆设为 8G，实际只给 4G，引发频繁 GC
代码与架构层面减少 GC 压力
再好的 GC 参数也救不了高频临时对象创建：
- 避免在循环或高频接口中构造 String、ArrayList、LocalDateTime 等短生命周期对象；复用 ThreadLocal 缓存格式化器、JSON 解析器等
- 消息推送类场景（如 WebSocket 批量下发），把 30 个独立消息合并为单次批量处理，减少线程池任务数和对象分配频次
- 缓存策略加淘汰机制：用 Caffeine 替代无界 HashMap，设置 maximumSize 和 expireAfterWrite，防止长期存活对象堆积老年代
- 排查内存泄漏：用 MAT 或 Eclipse Memory Analyzer 分析 heap dump，重点看 dominated heap 中排前三的对象类型及其 GC Roots 引用链
