Drools内存泄漏排查求助：Kubernetes微服务堆内存异常问题

1. 该现象是否属于内存泄漏？ #

不属于内存泄漏。内存泄漏的核心是不再被业务使用的对象无法被GC回收，导致内存持续增长，而你遇到的是首次加载后内存稳定、后续重复测试不再增长的情况——这是Drools的正常设计行为：

• Drools加载规则时，会将编译后的org.drools.core.base.mvel.MVELCompilationUnit对象缓存到KieBase的内部结构中，避免重复执行高开销的规则编译操作。
• 这些缓存对象是KieContainer/KieBase运行必需的常驻内存对象，并非无用对象，手动GC无法释放是正常的，因为它们仍被活跃的KieBase实例引用。

2. 如何进一步排查？ #

• 确认KieContainer生命周期：检查代码中KieContainer是否为全局单例。如果每次处理请求都新建KieContainer，会重复加载kjar并生成多份编译缓存，导致内存异常增长。必须保证KieContainer仅初始化一次，全局复用。
• 分析引用链细节：用MAT工具查看MVELCompilationUnit对象的GC引用链，确认它们是否被KnowledgeBaseImpl的compilations缓存持有。如果引用链指向多个KieBase实例，说明存在重复加载kjar的问题。
• 验证规则加载逻辑：检查外部kjar的加载逻辑，是否存在每次请求都重新加载kjar的情况。正常应该是启动时加载一次，或在kjar更新时触发重载，而非每次请求都加载。
• 长期内存监控：持续运行服务并监控堆内存变化，如果内存稳定在首次加载后的水平，说明是正常缓存；如果内存缓慢持续增长，再排查是否存在KieBase/KieSession未正确回收的泄漏场景。
• 热更新场景检查：如果存在kjar热更新逻辑，检查旧的KieContainer/KieBase是否被彻底释放（比如是否还有业务代码持有旧实例的引用），避免新旧实例同时占用内存。

3. 是否需要调整规则实例化/执行方式？ #

需要调整，优化方向如下：

• 启用KieSession池化：Stateful KieSession的创建和销毁涉及规则引擎初始化、资源绑定等开销，1000条规则的场景下开销更明显。使用会话池可以复用已创建的Session，减少对象创建销毁的内存波动，同时提升性能。
• 评估使用Stateless KieSession：如果业务场景中每个用户仅执行两次规则就销毁Session，且不需要维护会话状态，可以替换为Stateless KieSession。它更轻量，执行完成后自动释放资源，无需手动销毁，能降低内存管理复杂度。
• 优化规则编译与缓存：
  • 确保kjar是预编译状态，避免服务启动时的实时编译开销。
  • 检查Drools的缓存配置（如drools.compiler.cache.enabled），确保编译缓存的行为符合预期，避免不必要的缓存占用。
• 拆分规则集：如果1000条规则可以按业务场景拆分，拆分为多个KieBase，按需加载，减少单个KieBase的缓存内存占用。

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