如何在高并发场景下优化 JVM 回收策略

在高并发场景下，JVM的垃圾回收（GC）常常成为性能瓶颈。你会发现年轻代迅速填满，Young GC频繁触发，更糟糕的是，有时会突然爆发完全不可控的Full GC，直接导致请求延迟飙升甚至服务卡顿。那么，优化的核心到底是什么？其实不是追求“零GC”，而是要让GC变得更可预测、更轻量，更好地贴合业务的节奏。

优先选用G1收集器并设定合理的停顿目标

从实践来看，G1收集器已经成为高并发生产环境的主流选择，特别适合堆内存超过4GB的服务。它的工作机制是把堆划分为多个Region，然后按需回收那些垃圾最多、空间最空的区域，这样就能在大堆下依然有效控制停顿时间。

具体操作上，启用G1很简单：-XX:+UseG1GC。但关键的步骤在于明确设定停顿目标，比如-XX:MaxGCPauseMillis=50，建议根据你的SLA在20到100毫秒之间调整。千万别依赖G1的“尽力而为”默认行为——设置明确的停顿目标后，G1会据此动态调整新生代大小、并发线程数和回收频率，这才是发挥其性能的关键。

合理分配堆内存与分代比例

这里要厘清一个常见的误区：堆内存不是越大越好。堆太大并不等于性能好，堆太小又会导致频繁GC。重点在于匹配对象的生命周期特征。

一个实用的建议是把初始堆和最大堆设为相同值，例如-Xms4g -Xmx4g，这样可以避免运行时因扩容引发的抖动。新生代的大小也值得认真权衡：它不宜过大（比如超过堆的60%），否则Young GC单次扫描范围过大，耗时上升；也不宜过小（比如低于25%），否则对象容易过早晋升老年代，加重Mixed GC的压力。对于G1，推荐显式控制新生代比例：-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=50。

规避晋升风暴与内存泄漏

高并发场景下，一个常见的陷阱是短生命周期的对象因为Survivor区过小或年龄阈值过低，直接跳过年轻代晋升到老年代，从而引发频繁的Mixed GC甚至Full GC。这就是所谓的“晋升风暴”。

如何应对？第一，留意GC日志中的Age分布和Promotion Failure记录，这些是早期预警信号。第二，适当增大Survivor区的占比，比如设置-XX:SurvivorRatio=6（即Eden:Survivor = 6:1:1）。第三，限制晋升年龄，例如-XX:MaxTenuringThreshold=6，防止对象过早晋升。更重要的是，配合监控工具（如jstat、Prometheus加JVM Exporter）持续识别那些长期存活的对象，排查缓存未清理、静态集合滥用等潜在的内存泄漏点。

配合应用层做协同优化

JVM GC从来不是孤立环节。一个高并发系统，必须从代码和架构层面主动减轻GC压力。

一个有效的手段是对象复用：使用对象池（比如Netty的ByteBuf池）或ThreadLocal缓存临时对象，避免频繁创建和销毁。同时，有意识地减少临时对象的生成，比如避免在循环内进行字符串拼接、包装类的使用以及Stream中间操作。此外，异步写日志、批量处理消息，都能有效降低单位时间内的对象创建速率。值得一提的是，线程池的配置也需要与GC协同考虑——线程数过多会导致栈内存占用升高，进而拖慢GC Roots的扫描速度。