WORTHY BLOG

外观

由 Spring 动态注册引发的 JVM 堆内与堆外双重内存泄露

约 1434 字大约 5 分钟

2026-01-21

1. 背景与问题现象

近日，生产环境某核心服务节点（Pod）频繁触发容器重启（OOMKilled），同时运维监控平台发出内存预警。该服务部署于 Kubernetes 环境，基于 Java 8 运行。

在介入排查后，我们观察到以下典型的监控异常特征：

  1. “阶梯状”内存增长：内存使用曲线呈现明显的单调递增趋势。在业务低峰期（10:00 - 12:00），单节点内存占用从 3.4GB 缓慢攀升至 4.5GB，且无回落迹象。
  2. 缺乏 GC 回收特征：正常的 Java 应用内存曲线应呈“锯齿波”（Sawtooth Pattern），但该节点的内存曲线只升不降，表明 GC 无法有效回收内存。
  3. 断崖式重启：当内存触及容器 Limit 限制时，出现垂直下跌（Pod 被 Kill 并重启）。

本文将详细记录从现象确认到根因定位的完整排查路径。

2. 现场诊断：从 jstat 到手动 GC

为进一步确认内存泄露的性质（是堆内泄露还是堆外泄露），我们通过 kubectl exec 进入容器内部，使用 JDK 自带工具进行现场勘查。

2.1 运行时指标分析

执行 jstat -gcutil <pid> 1000 10 对 GC 及其内存占比进行采样（每秒一次）：

Bash

S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT
0.00  30.59  15.35  81.69  92.73  82.88  817    18.306   7     6.351
...

关键指标解读：

  • Old Gen (O) = 81.69%：老年代水位极高，作为业务低峰期，这极不正常。
  • Metaspace (M) = 92.73%：元空间（方法区）告急，暗示加载了异常数量的类（Class）。
  • GC 频率：采样期间未发生 GC，系统看似“静止”，实则危机四伏。

2.2 伪泄露验证（手动 GC）

为了排除“内存只是分配了但还没来得及回收”的可能性，我们执行了 jcmd <pid> GC.run 强制触发 Full GC。

结果对比：

  • 老年代：仅从 81.69% 降至 68.85%。
  • 元空间：从 92.73% 降至 91.79%（几乎无效）。
  • 副作用：单次 Full GC 导致应用停顿（STW）长达 11.6秒。

初步结论：确认存在真实的内存泄露。老年代中近 70% 的对象是“存活”的，且元空间存在严重的类加载泄露。

3. 深度分析：Heap Dump 与支配树

我们导出了堆转储快照（heap.hprof），并使用 Eclipse Memory Analyzer (MAT) 进行离线分析。

3.1 寻找“内存霸主” (Dominator Tree)

打开 MAT 的 Dominator Tree 视图，按 Retained Heap（深堆）排序，问题一目了然：

  • Top 1 对象：java.util.concurrent.ConcurrentHashMap
  • 内存占比：47.11% (约 131 MB)
  • 内部元素：包含了大量 com.company.module.handler.BusinessServletHandler 类型的对象。

3.2 溯源引用链 (Incoming References)

仅仅知道 Map 大是不够的，关键是谁持有了这个 Map。通过 List Objects with incoming references 功能，我们锁定了持有者：

  • 持有者 Class：org.springframework.beans.factory.support.DefaultListableBeanFactory
  • 持有者 Field：singletonObjects

真相大白：

这个导致内存溢出的 ConcurrentHashMap 并非业务代码中定义的缓存，而是 Spring 容器核心的单例池（Singleton Pool）。

4. 根因分析 (Root Cause Analysis)

结合 MAT 分析与代码审查，我们还原了故障发生的完整逻辑链条：

4.1 代码逻辑缺陷

在业务模块（com.company.module.buss）中，存在一段处理动态规则的逻辑。开发人员为了让动态生成的 Handler 对象能够使用 Spring 的依赖注入功能，在每次请求处理过程中，调用了类似 applicationContext.registerSingleton() 的方法。

4.2 双重泄露机理

  1. 堆内存泄露 (Heap Leak)：
    • Spring 的设计原则是“单例 Bean 生命周期与容器一致”。
    • 业务代码不断向 singletonObjects 注册新的、名字不重复的 Bean。
    • Spring 容器忠实地持有了这些对象，导致它们永远无法被 GC 回收，最终撑爆老年代。
  2. 元空间泄露 (Metaspace Leak)：
    • MAT 显示这些泄露对象带有 $$EnhancerBySpringCGLIB 后缀。
    • 这意味着这些 Bean 被 AOP 切面代理了。
    • CGLIB 的机制是动态生成字节码并加载为新的 Class。
    • 注册 1 万个 Bean，就生成了 1 万个 CGLIB 代理类。由于 Class 对象难以卸载，导致元空间迅速耗尽。

5. 解决方案

5.1 短期修复

针对该业务场景，我们对代码进行了如下重构：

  • 移除动态注册：废除运行期向 Spring 容器注册 Bean 的逻辑。
  • 无状态化改造：将 Handler 改造为无状态的单例（Singleton），在系统启动时通过 @Bean 仅注册一次。
  • 参数传递：将原本绑定在对象属性上的请求上下文数据，改为通过方法参数（Method Arguments）传递。

5.2 长期治理建议

  1. 规范使用 Spring 容器：严禁在 Request 级别的处理逻辑中操作 ApplicationContext 的注册接口。
  2. 监控补盲：增加对 Metaspace 使用率的独立告警（阈值建议设为 80%），以及对 Full GC 频率的监控。
  3. 参数调优：虽然不能解决根本问题，但建议将 -XX:MaxMetaspaceSize 显式调大（如 512MB），以增加系统鲁棒性。

6. 总结

本次故障是一次典型的“误用框架机制”引发的性能事故。它提醒我们：

  1. 警惕“视觉欺骗”：业务低峰期内存不下降，往往比高峰期内存飙升更可怕。
  2. 关注元空间：当堆内存和元空间同时告警时，往往意味着存在大量的动态类生成（如 CGLIB、Groovy、反射）。
  3. 敬畏单例：Spring 的单例池是存放长期存活对象的场所，绝不能作为临时对象的“垃圾桶”。