Drools ZipKieModule保留堆值过高问题排查求助

现象是否正常？ #

这种ZipKieModule的高堆占用不正常。正常情况下，Drools加载KieModule时会缓存规则相关的静态资源（如编译后的规则文件、依赖类信息），堆占用应保持稳定且不会持有业务请求的负载数据。尤其是zipEntries中出现业务负载的情况，说明存在资源泄漏或对象引用异常的问题。

后续排查方向 #

• 确认KieContainer的全局单例性：检查代码中是否在Kafka Streams的处理逻辑（如Processor/Transformer）内重复创建KieContainer或KieBase。正确做法是在Spring Boot启动时初始化唯一的全局KieContainer实例，所有规则执行复用该实例，避免重复加载KieModule导致资源堆积。
• 排查无状态会话的对象绑定：检查规则执行时是否通过insert()传入了大体积业务对象，且这些对象被KieSession或内部缓存意外持有。可在执行完execute()后，用堆分析工具追踪业务对象的引用链，确认是否最终指向ZipKieModule的zipEntries。
• 深入分析堆转储中的ZipEntries内容：用MAT等工具查看zipEntries中的Guava模块是单实例还是多重复实例：
  • 如果是多重复实例：说明KieModule被多次加载，大概率是KieContainer重复初始化导致。
  • 如果包含业务负载：追踪负载对象的引用路径，确认是否是自定义类加载器、规则中的静态引用或会话缓存导致对象无法被GC回收。
• 检查Drools配置参数：
  • 关闭不必要的类加载器缓存：设置KieBaseConfiguration的drools.classLoaderCacheEnabled=false，避免类加载器及关联资源无法释放。
  • 确认规则编译策略：确保规则仅在应用启动时编译一次，而非每次执行时重新编译（可通过日志排查是否有频繁的规则编译输出）。
• 验证Kafka Streams任务的并发影响：Kafka Streams会根据分区数创建多个任务，检查是否每个任务都初始化了独立的KieContainer。应确保KieContainer是Spring单例，被所有任务共享。
• 隔离测试空负载场景：移除业务负载，仅执行空规则或简单规则，观察堆占用是否下降。若下降，说明问题与业务对象的持有有关；若仍高，则聚焦Drools自身的模块加载逻辑排查。

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