Wildfly部署的Spring应用空闲时Eden区快速占满问题排查

这种即使停掉所有流量、扩容Eden到11GB还会快速占满的情况，肯定不是常规业务请求导致的，得从后台线程、框架隐式行为甚至JVM本身入手排查。给你一套逐步排查的方案：

1. 先抓堆快照，锁定内存分配的源头 #

这是最关键的一步，直接看到底是什么对象在疯狂占用Eden：

• 在Eden区占用峰值时，用jmap生成堆快照：

  jmap -dump:format=b,file=heap_dump.hprof <你的应用进程ID>
  

• 用Eclipse Memory Analyzer（MAT）或者VisualVM打开快照，重点看「对象分配栈」和「大对象/高频分配对象」。比如如果发现大量org.apache.kafka.common.requests.HeartbeatRequest对象，那大概率是Kafka客户端在搞事情。

2. 先排除Kafka消费者的隐式行为 #

你有200个消费者线程，哪怕没有消息，Kafka客户端也会在后台做很多事：心跳发送、元数据拉取、协调组同步，这些操作都可能创建临时对象。

• 临时停掉所有Kafka消费者容器（不是停外部消息，是直接关闭应用内的消费者），观察Eden区是否还会暴涨。如果停了之后恢复正常，那就要检查：
  • Kafka客户端版本是不是太老？旧版本可能有频繁分配对象的bug；
  • 消费者配置是否合理？比如fetch.min.bytes设得太低，导致频繁空拉取，每次拉取都生成请求/响应对象；
  • 消费者线程数是不是过多？200个线程本身也会带来不少线程本地对象的开销。

3. 排查Quartz的后台活动 #

虽然你的Quartz任务每小时才跑一次，但它的调度线程是一直存活的，而且Quartz自身可能有后台维护任务：

• 临时禁用Quartz，观察内存变化。如果禁用后正常，检查Quartz的配置：
  • 线程池大小是不是太大？有没有线程在空转时频繁分配对象；
  • 作业存储用的是内存还是数据库？如果是内存存储，有没有未清理的旧触发器/作业数据堆积；
  • 有没有自定义的Quartz监听器，在后台持续执行操作？

4. 检查Wildfly与Spring集成的隐式组件 #

Wildfly自带的线程池、连接池，还有Spring和Wildfly整合时的一些Bean，可能在后台默默分配内存：

• 打开Wildfly的管理控制台，监控后台线程的活动情况，看有没有线程持续高负载运行；
• 检查Spring中的异步线程（比如@Async注解的方法），有没有未关闭的异步任务在循环执行，频繁创建对象；
• 查看Wildfly的JTA事务管理器配置，有没有事务相关的对象持续堆积。

5. 排查JVM版本的已知问题 #

你用的OpenJDK 1.8.0_151是比较老的版本了，这个版本有没有已知的内存分配bug？

• 先尝试升级到OpenJDK 1.8的最新补丁版本（比如1.8.0_392），很多旧bug都被修复了；
• 调整GC参数试试，比如改用G1GC：-XX:+UseG1GC，G1对大内存的管理更高效；
• 检查当前的GC参数是否合理，比如-XX:NewRatio是不是设得太小，导致新生代GC频率异常高，看起来Eden区快速被占满。

6. 检查应用自定义的后台线程 #

有没有自己写的后台线程（比如while循环的监控线程、日志收集线程）在持续运行？

• 用jstack <pid>导出线程栈，查看所有存活的线程，找那些处于「RUNNABLE」状态且持续执行的线程，看它们的调用栈里有没有频繁创建对象的代码；
• 检查Spring的@Scheduled任务，有没有漏写的定时任务（比如间隔设成了1秒）在后台疯狂跑。

最后提醒：排查这类问题一定要逐个变量排除，每次只改变一个因素（比如停Kafka、禁用Quartz），观察内存变化，这样才能快速定位根因。

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