Spring Boot 1.5.8生产环境内存泄漏问题排查求助

针对你遇到的生产环境内存溢出问题——抛出GC overhead limit exceeded和BeanCreationException，且MAT分析发现多个本该单例的AnnotationConfigApplicationContext实例未被回收，结合Consul配置依赖的背景，我整理了以下逐步排查的方向：

一、深挖ApplicationContext实例的强引用链 #

• 用MAT的Path to GC Roots功能（选择“exclude weak references”），精准定位持有这些上下文实例的对象。常见的泄漏点包括：
  • 未清理的ThreadLocal变量：如果某个线程局部变量持有上下文引用，且线程被线程池复用（比如Tomcat的工作线程），会导致上下文一直无法被回收。
  • 静态集合类：比如自定义的缓存容器不小心把上下文实例存进去，忘记清理。
  • 第三方库的回调/监听器：某些组件注册了上下文的监听器，但在上下文销毁时没有注销，导致强引用残留。
• 检查代码中手动创建上下文的逻辑：有没有地方调用new AnnotationConfigApplicationContext()后，没在finally块或者异常分支调用close()方法？尤其是配置加载失败重试的场景，很容易留下未销毁的上下文。
• 排查单例Bean的依赖错误：比如某个单例Bean错误地注入了prototype类型的ApplicationContext，或者通过ApplicationContextAware获取上下文后，把它存在了静态变量里。

二、结合Consul配置依赖的针对性排查 #

• 核对Consul客户端版本：Spring Boot 1.5.x对应的Spring Cloud Edgware版本，确保spring-cloud-starter-consul-config的版本和Spring Boot版本适配。旧版本的Consul配置客户端存在已知的上下文泄漏bug——比如配置刷新时，旧的上下文实例没被正确销毁就被新实例替换，导致残留。
• 检查配置刷新的异常日志：生产环境中如果Consul配置频繁变更，或者刷新过程中抛出BeanCreationException，可能会打断上下文的销毁流程，导致旧实例被滞留。去日志里搜ContextRefresher或者refresh相关的报错，看是否有频繁的刷新失败。
• 排查Consul监听器的注销逻辑：如果你们自定义了Consul配置变更的监听器，要确认在ApplicationContext关闭时，有没有调用Consul客户端的注销方法，避免监听器持有上下文引用。

三、生产环境特有的场景排查 #

• 对比本地和生产的JVM参数：生产环境的堆内存设置、GC策略（比如是否用了CMS而本地用ParallelGC）、是否开启了内存泄漏检测参数？有些泄漏只有在长时间运行、高并发或者特定GC策略下才会显现。
• 检查线程池的引用：生产环境中是否有自定义线程池，或者异步任务（比如@Async）中捕获了ApplicationContext？如果线程池的核心线程一直存活，就会一直持有上下文引用。
• 排查生产环境独有的第三方组件：比如监控工具、APM代理、日志框架，这些组件可能在生产环境中会创建额外的上下文实例，或者通过字节码增强持有上下文引用。

四、验证与临时修复手段 #

• 配置自动堆转储：在生产环境的JVM参数中添加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/app/heapdump.hprof，下次OOM时自动生成堆转储，对比之前的dump看泄漏的上下文是否有一致的引用链，缩小排查范围。
• 临时限制上下文创建：在代码中给手动创建上下文的逻辑加日志计数，统计生产环境中上下文创建的次数，确认是否有异常的频繁创建。
• 尝试升级依赖：如果怀疑是版本bug，先升级到Spring Boot 1.5.x的最新稳定版（1.5.22.RELEASE）和对应的Spring Cloud Edgware SR6版本，修复已知的内存泄漏问题。

内容的提问来源于stack exchange，提问作者Vinit89