Drools 内存泄漏排查与优化实践指南

陆砚码

2026-10-02 • 👁 1人浏览过

本文深入解析 Kubernetes 环境下 Drools 微服务因 MVELCompilationUnit 大量残留引发的堆内存持续增长问题，结合 MAT、JXRay 和 VisualVM 分析结果，提供可落地的诊断方法、代码级修复建议及云原生替代方案。本文深入解析 kubernetes 环境下 drools 微服务因 `mvelcompilationunit` 大量残留引发的堆内存持续增长问题，结合 mat、jxray 和 visualvm 分析结果，提供可落地的诊断方法、代码级修复建议及云原生替代方案。在基于 Drools 的微服务中，当 Kubernetes Pod 出现堆内存持续上升、手动 GC 无法回收、且 MAT/JXRay 均指向 org.drools.core.base.mvel.MVELCompilationUnit（数量达数万）时，这并非典型的“运行时规则执行泄漏”，而极大概率是 KieContainer 初始化与生命周期管理不当导致的类加载器级资源滞留 ——即：规则编译产物（MVEL 编译单元、反射适配器、类型描述符等）被 KieContainer 的内部缓存长期持有，且未随业务会话释放。 ? 根本原因定位：不是 Session，而是 Container 关键线索在于你提供的日志与代码片段：

public RuleEngine(String groupId, String artifactId, String versionId, String sessionName) {
    this.releaseId = new ReleaseIdImpl(groupId, artifactId, versionId);
    this.sessionName = sessionName;
    this.kieContainer = getKieContainer(); // ← 问题高发点！
    this.globalObjects.put("helper", new CatalogueGlobalHelper());
}

以及测试逻辑：

for (int i = 0; i < 4; i++) {
    KieSession testSession = ruleEngine.getNewSession("XXX"); // ← 每次都新建 Session
    testSession.fireAllRules();
    testSession.dispose(); // ✅ 正确释放 Session
}

✅ KieSession.dispose() 能正确清理会话状态（Working Memory、Agenda 等）； ❌ 但 KieContainer 一旦创建，其内部的 KieBase、KiePackage 及底层 MVEL 编译缓存（MVELCompilationUnit）默认不会自动卸载，尤其当使用 KieServices.newKieContainer(releaseId) 加载外部 kjar 时，Drools 会将编译结果强引用在 KieContainerImpl 的 kieBaseCache 和 compilerCache 中，并关联到 ClassLoader（通常是 URLClassLoader）。若该 ClassLoader 未被回收，所有编译产物将永久驻留堆中。 ? 补充验证：你观察到“首次调用后内存翻倍，后续调用不再增长”，正印证了 KieContainer 的单例加载 + 首次编译开销特性——这不是泄漏，而是预期行为被误用：KieContainer 应全局复用，而非按需重建。 ✅ 正确实践：容器单例 + 会话按需 + 显式清理（如需） 1. KieContainer 必须全局单例（Spring Bean）

@Configuration
public class DroolsConfig {

    @Bean(destroyMethod = "dispose") // ← 关键：注册销毁钩子
    public KieContainer kieContainer() {
        ReleaseId releaseId = new ReleaseIdImpl("com.example", "rules-kjar", "1.2.3");
        return KieServices.Factory.get().newKieContainer(releaseId);
    }

    @Bean
    public RuleEngine ruleEngine(KieContainer kieContainer) {
        return new RuleEngine(kieContainer, "mySession"); // 传入已初始化的 container
    }
}

2. RuleEngine 改为依赖注入 KieContainer，移除 getKieContainer() 内部创建逻辑

public class RuleEngine {
    private final KieContainer kieContainer;
    private final String sessionName;

    public RuleEngine(KieContainer kieContainer, String sessionName) {
        this.kieContainer = kieContainer;
        this.sessionName = sessionName;
    }

    public void fireRules() {
        for (int i = 0; i < 4; i++) {
            try (KieSession session = kieContainer.newKieSession(sessionName)) { // ← 推荐 try-with-resources
                session.fireAllRules();
            } // 自动调用 dispose()
        }
    }
}

3. （可选）主动清理编译缓存（仅限调试/极端场景）

// 在应用关闭前调用（需确保无并发访问）
public void cleanupCompilerCache() {
    if (kieContainer instanceof KieContainerImpl) {
        KieContainerImpl impl = (KieContainerImpl) kieContainer;
        impl.getCompilerCache().clear(); // 清空 MVEL 编译单元缓存
        impl.getKieBaseCache().clear();  // 清空 KieBase 缓存
    }
}

⚠️ 注意：KieContainer.dispose() 仅释放部分资源，不保证卸载 ClassLoader 或清除所有静态缓存。Drools 5.x–7.x 的 KieContainerImpl 内部存在多个 ConcurrentHashMap 缓存，且部分静态字段（如 MVELCompiler 的 classCache）可能跨容器共享。因此，避免频繁重建 KieContainer 是根本解法。 ? 为什么 Session Pool 无效？ Session Pool（如 Apache Commons Pool）仅复用 KieSession 实例，但每个 KieSession 仍共享同一个 KieContainer 的底层编译产物。若 KieContainer 本身已持有了 50,000 个 MVELCompilationUnit，池化 Session 不会减少这些对象——它们早已在容器初始化时被加载并常驻内存。 ? 云原生推荐：迁移到 Kogito（长期演进方向） Drools 7.30+ 官方已将重心转向 Kogito ，其核心优势直击本问题： ✅ 无运行时编译：规则在构建期（Maven 插件）编译为原生 Java 类，彻底消除 MVELCompilationUnit； ✅ 无 KieContainer 概念：规则作为普通 Spring Bean 注入，生命周期由 Spring 容器统一管理； ✅ 天然支持 Quarkus/Native Image ：启动快、内存占用低，完美适配 Kubernetes Serverless 场景。迁移示例（Kogito + Spring Boot）：



    org.kie.kogito
    kogito-spring-boot-starter
    2.0.0.Final

规则文件 src/main/resources/rules/discount.drl 将自动编译为 DiscountRuleUnit，通过 @Inject RuleUnits 即可使用，零配置内存泄漏风险。 ✅ 总结：三步快速止血步骤操作效果1. 诊断确认使用 jcmd VM.native_memory summary 对比 KieContainer 创建前后 native memory 增长；检查 jmap -histo:live 中 MVELCompilationUnit 数量是否稳定排除 JVM 级内存问题2. 代码修复将 KieContainer 改为 Spring @Bean 单例，@PreDestroy 注册 dispose()，KieSession 改用 try-with-resources立即解决 95% 的“伪泄漏”3. 架构升级规划 Kogito 迁移路线图，优先对新规则模块采用 Kogito，旧模块逐步替换彻底告别编译缓存管理负担 ? 最后提醒：永远不要在请求处理链路中动态 new KieContainer(...)。它应是应用启动时的基础设施组件——就像 DataSource 或 RestTemplate，而非每次 HTTP 请求都新建的临时对象。

相关文章