降低Java应用延迟的关键是控制GC导致的“Stop-the-World”暂停；核心思路是让GC更少停、更短停、更可预测；ZGC或Shenandoah适用于亚毫秒级暂停场景。
降低Java应用延迟，关键在于控制垃圾回收（GC）引发的“Stop-the-World”暂停。这些暂停会直接打断业务线程，使请求响应停滞，对金融交易、实时风控、游戏服务等场景尤为敏感。核心思路不是消除GC，而是让GC更少停、更短停、更可预测。
选对垃圾收集器是前提
不同GC在延迟表现上差异显著，不能沿用默认或历史惯性配置：
- ZGC 或 Shenandoah：适用于要求亚毫秒级暂停（
-
G1 GC：适合堆大于4GB、P99延迟目标在20–200ms之间的中大型服务。启用
-XX:+UseG1GC -XX:MaxGCPauseMillis=100可设定软目标，JVM会动态调整年轻代大小与混合回收节奏来逼近该值。 - 避免使用 Parallel GC 和 CMS：Parallel GC虽吞吐高，但单次Full GC可能达数秒；CMS已被JDK 14废弃，其并发失败易触发Serial Full GC，造成不可控长停顿。
减少GC频率与对象分配压力
延迟不仅来自单次暂停时长，也来自暂停发生频次。高频Young GC本身虽快，但累积效应仍会抬升P99延迟抖动：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 复用对象，避免在高频路径（如Netty ChannelHandler、HTTP Filter）中频繁创建短生命周期对象。例如用ThreadLocal缓存
SimpleDateFormat或ByteBuffer，而非每次new。 - 预设集合初始容量。如
new ArrayList(expectedSize)，防止扩容时数组复制带来的临时对象与内存抖动。 - 慎用字符串拼接。循环内用
StringBuilder替代+，避免隐式生成多个String中间对象。 - 检查日志框架（如Logback）是否开启DEBUG级别且含大量占位符计算——这些逻辑实际执行却未输出，白白消耗CPU与内存。
调优堆结构与晋升行为
对象过早晋升到老年代，会加剧Full GC风险；晋升过晚，则Young GC过于频繁。需平衡新生代占比与对象存活时间：
立即学习“Java免费学习笔记（深入）”；
- 用
-Xms与-Xmx设为相同值（如-Xms8g -Xmx8g），避免运行时堆伸缩触发额外GC。 - 对G1，可通过
-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent微调年轻代范围（默认5%–60%），配合jstat -gc观察Eden耗尽速率与YGC间隔。 - 监控对象晋升大小：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps中关注tenuring threshold及每次YGC后进入老年代的字节数。若持续有大对象直接分配到老年代（如大数组），考虑用-XX:PretenureSizeThreshold（仅限Parallel GC）或改用对象池。
用工具定位真实瓶颈
凭经验调参容易误判。必须依赖数据驱动：
- 开启JFR（Java Flight Recorder）：
-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr，分析GC事件的时间分布、停顿原因（如Reference Processing、Remark）、各代内存水位变化。 - 用
jstat -gc -t <pid> 1000持续采样，观察YGC/FGC次数、耗时、堆使用率趋势。若YGC间隔稳定在10s以上且Eden使用率长期低于30%，说明堆偏大或对象存活率低，可适度减小堆。 - 结合Arthas或JMC查看热点方法中对象分配点（Allocation Profiling），定位“谁在疯狂new”。比如某个DTO构造器每秒创建5万实例，优化后延迟毛刺消失。
