部署Drools Business-Central至Wildfly时遭遇OutOfMemoryError求助

针对你遇到的多线程OutOfMemoryError问题，即使调整了基础JVM内存参数仍未解决，可按以下步骤排查处理：

1. 确认JVM参数是否实际生效 #

很多时候内存参数未生效是问题根源，执行以下命令验证：

• 找到Wildfly进程ID：jps -l
• 查看进程实际JVM参数：jcmd <进程ID> VM.flags
  检查输出中是否包含你设置的-Xmx2048m、-XX:MaxMetaspaceSize=256m等参数。如果未生效，需确认：
  • Wildfly启动脚本（如standalone.sh/standalone.bat）中是否正确配置了JAVA_OPTS，部分环境需要修改standalone.conf（Linux）或standalone.conf.bat（Windows）文件中的参数，而非直接设置系统环境变量。
  • 是否存在其他配置文件覆盖了你的JAVA_OPTS设置。

2. 定位内存溢出的具体类型 #

OutOfMemoryError分堆内存、元空间、直接内存等多种类型，仅调整堆和元空间可能无法覆盖所有场景：

• 启用自动堆转储，添加JVM参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/your/dump/path，下次溢出时会自动生成堆转储文件。
• 使用Memory Analyzer Tool（MAT）打开堆转储文件，分析：
  • 哪些对象占用了大量堆内存（比如Jaeger的上报队列、未释放的数据库连接、Drools规则引擎的缓存对象）。
  • 是否存在内存泄漏（比如对象长期被引用无法GC）。

3. 针对具体线程的优化方案 #

Jaeger RemoteReporter线程 #

该线程负责Jaeger追踪数据上报，若队列堆积会占用大量内存：

• 若不需要追踪功能，直接关闭Jaeger：在Drools Business-Central配置中禁用Jaeger，或在Wildfly中移除Jaeger相关依赖。
• 调整Jaeger上报配置：减小队列大小（reporter.max-queue-size）、缩短刷新间隔（reporter.flush-interval），避免数据堆积。

MySQL连接清理线程 #

该线程异常通常指向数据库连接泄漏或连接池配置不合理：

• 检查Wildfly数据源配置，确保连接池参数合理：设置max-pool-size为合适值（比如20-50，避免过多连接占用内存）。
• 启用连接泄漏检测：在数据源配置中添加以下内容：

  <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
      <background-validation>true</background-validation>
      <background-validation-millis>60000</background-validation-millis>
      <track-statements>true</track-statements>
  </validation>
  

• 排查应用代码，确保所有数据库连接、Statement、ResultSet都被正确关闭（建议用try-with-resources语法）。

Wildfly核心线程（MSC、default Accept） #

这些线程异常通常与应用加载或请求处理有关：

• 检查Drools Business-Central的依赖，移除冗余或冲突的Jar包，减少类加载对元空间的占用。
• 调整Wildfly线程池配置：修改standalone.xml中default HTTP线程池的max-threads参数，避免过多请求堆积导致内存占用过高。

4. 调整JVM内存参数至更合理值 #

Drools Business-Central本身内存消耗较大，尝试升级参数：

JAVA_OPTS="-Xms2048m -Xmx4096m -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/your/dump/path"

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