电商大促的 JVM 调优复盘——一次 Full GC 频繁触发的完整排查与根治一、故障现场双十一流量洪峰下的 Full GC 风暴2025 年双十一大促的零点刚过 8 分钟监控大盘突然告警订单服务的 P99 响应时间从日常的 80ms 飙升到 3200ms与此同时 CPU 使用率从 35% 跳涨到 92%。初步判断是 JVM 层面出了问题。登录到生产服务器后通过jstat -gcutil确认了问题的性质Full GC 每隔 1525 秒触发一次每次耗时 1.83.2 秒老年代使用率始终在 96%~99% 之间徘徊。这是一个典型的背靠背 Full GC场景——每次 Full GC 结束后老年代剩余空间极少新涌入的请求对象迅速再次填满老年代触发下一次 Full GC形成恶性循环。这台服务器的 JVM 配置是堆内存 8G-Xms8g -Xmx8g新生代 2G老年代 6G使用 G1 垃圾回收器-XX:UseG1GCGC 日志已开启但未配置 GC 历史分析工具。应用基于 Spring Boot 3.2使用 JDK 21 运行属于订单核心服务承接了全站下单、支付回调、库存扣减等流量。故障持续了 22 分钟期间订单超时率飙升至 7.6%直到运维临时扩容了 4 台机器才勉强稳住。事后复盘这是一次典型的隐性内存问题在流量放大下集中暴露的案例。二、排查路径从 GC 现象到根因的逐层下钻排查过程分为五个阶段阶段一GC 日志回顾。将收集的 GC 日志导入 GCViewer发现一个关键模式每次 Young GC 后有大约 180MB~220MB 的对象被晋升到老年代。对于 6G 的老年代这个晋升量意味着只需要 30 次左右 Young GC 就能打满老年代。但问题的根因不在于晋升量本身而在于这些对象为什么没有被 Young GC 回收掉。阶段二堆 Dump 比对。在 Full GC 前后分别抓取了堆 Dump。比对发现Full GC 之后仍有约 1.2G 的内存被占用且这些对象都是可达的即它们并非内存泄漏而是存活时间过长导致晋升。进一步用 MAT 的 Dominator Tree 分析占大头的三个对象类型是OrderContext及相关引用链380MB应请求结束即释放ConcurrentHashMap$Node缓存条目420MB持续增长byte[]序列化缓冲区260MB频繁分配大数组阶段三ThreadLocal 泄漏定位。OrderContext之所以无法被回收是因为它在 Tomcat 线程的ThreadLocal中被引用而 Spring Boot 默认使用 Tomcat 线程池线程不会销毁ThreadLocal不清理则对象永远不会被 GC。阶段四缓存膨胀分析。业务代码中有一处商品详情缓存ConcurrentHashMapkey 是商品 SKU IDvalue 是完整的商品 JSON。大促期间运营临时上架了 8 万个 SKU 的限时秒杀商品缓存没有设置最大容量和淘汰策略导致内存暴涨。阶段五大对象创建。订单服务在序列化订单快照时使用new byte[65536]创建固定大小缓冲区但实际序列化后的订单数据平均只有 12KB造成大量空间浪费。三、修复方案三管齐下的根治手段针对上述三个根因实施了以下修复/** * 修复1: 在 Filter 中统一清理 ThreadLocal * 确保每个请求结束后释放线程本地对象 */ Component public class ThreadLocalCleanupFilter implements Filter { private static final ListThreadLocal? THREAD_LOCALS_TO_CLEAN List.of( OrderContextHolder.getThreadLocal(), UserSessionHolder.getThreadLocal(), TraceContextHolder.getThreadLocal() ); Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { try { chain.doFilter(request, response); } finally { // 统一清理确保无论请求成功或异常都执行清理 for (ThreadLocal? threadLocal : THREAD_LOCALS_TO_CLEAN) { try { threadLocal.remove(); } catch (Exception ignored) { // 单个清理失败不影响其他 ThreadLocal } } } } }/** * 修复2: 使用 Caffeine 替代无界 ConcurrentHashMap * 设置最大容量和基于大小的淘汰策略 */ Configuration public class CacheConfig { Bean(productDetailCache) public CacheString, ProductDetail productDetailCache() { return Caffeine.newBuilder() // 最大条目数按每个对象 2KB 估算限制 1GB 内存 .maximumSize(500_000) // 写入后 10 分钟过期 .expireAfterWrite(10, TimeUnit.MINUTES) // 开启弱引用JVM 内存紧张时可主动回收 .weakValues() .recordStats() .removalListener((key, value, cause) - { if (cause RemovalCause.SIZE) { log.warn(缓存条目因容量限制被淘汰, key: {}, key); } }) .build(); } }/** * 修复3: 使用自适应缓冲区替代固定大小数组 * 按需分配减少内存浪费 */ Component public class OrderSnapshotSerializer { /** * 序列化订单快照使用 ByteArrayOutputStream 自动扩容 * 替代固定 64KB 缓冲区 */ public byte[] serialize(OrderSnapshot snapshot) { try (ByteArrayOutputStream bos new ByteArrayOutputStream(4096)) { ObjectOutputStream oos new ObjectOutputStream(bos); oos.writeObject(snapshot); oos.flush(); return bos.toByteArray(); } catch (IOException e) { throw new SerializationException(订单快照序列化失败, orderId: snapshot.getOrderId(), e); } } }除了代码层面的修复也对 JVM 参数进行了调整将新生代从 2G 扩大到 4G-XX:NewSize4g -XX:MaxNewSize4g降低对象过早晋升的概率设置-XX:MaxGCPauseMillis200让 G1 在延迟敏感场景下更激进地回收启用-XX:PrintAdaptiveSizePolicy观察新生代大小自适应策略是否合理四、验证结果与监控长效机制修复上线后在压测环境用 3 倍日常流量做了 2 小时的验证Full GC 次数从原方案的每 20 秒 1 次降为2 小时内 0 次老年区使用率稳定在 35%~55%P99 响应时间从 3200ms 恢复至 75ms甚至略优于日常因为扩大了新生代堆内存实际占用从 7.8GB 下降到 4.2GB更重要的是建立了一套GC 监控与预防机制GC 日志持久化所有核心服务统一输出 GC 日志到 ELK设定 Full GC 频率和耗时的告警阈值堆 Dump 自动采集当老年代使用率超过 85% 且持续 5 分钟时自动触发堆 DumpThreadLocal 使用规范新增 Code Review 检查项——所有 ThreadLocal 必须在 finally 块中 remove缓存容量 Review大促前 2 周对所有缓存的 capacity 和淘汰策略做专项 Review五、从这次事故学到的最重要的东西这次 Full GC 风暴表面上是一次内存问题根子上是一次容量规划不足和代码质量欠债的集中爆发。三个问题——ThreadLocal 未清理、缓存无界、大对象创建——在日常流量下都不会触发可见的性能退化但在流量放大 3~5 倍的大促场景下退化曲线是指数级的。最深刻的教训不是某个具体的调优参数而是一个判断大促前的压测不能只验证功能正确性必须验证资源消耗的线性度。如果一条资源消耗曲线在 QPS 增长时出现非线性跳跃那么即使当前水位安全也意味着系统已经进入了高风险区间。这次事故后团队把 JVM 监控纳入日常值班巡检并要求所有核心服务在大促前输出一份《JVM 健康度报告》包含内存分布、GC 频率、线程池利用率、堆外内存占用四个维度的基线数据和峰值预测。这是从被动救火走向主动防火的关键一步。