drools规则引擎因为内存泄露导致的内存溢出

进入这个问题之前，先了解一下drools：

在很多行业应用中比如银行、保险领域，业务规则往往非常复杂，并且规则处于不断更新变化中，而现有很多系统做法基本上都是将业务规则绑定在程序代码中。

主要存在的问题有以下几个方面：

1） 当业务规则变更时，对应的代码也得跟着更改，每次即使是小的变更都需要经历开发、测试验证上线等过程，变更成本比较大。
2） 长时间系统变得越来越难以维护。
3） 开发团队一般是由一个熟悉业务的BA（业务分析人员）和若干个熟悉技术的开发人员组成，开发人员对业务规则的把握能力远不及BA，但实际上却承担了将业务规则准确无误实现的重任。
4） 系统僵化，新需求插入困难。
5） 新需求上线周期较长。
能否让我们的业务系统更灵活一点呢？
思路：将业务规则从技术实现中提取出来，实现技术和业务分离，开发人员处理 技术、业务分析人员定义业务规则，各自做自己所擅长的事情。
方案：目前已经有比较成熟的开源产品支持，它就是Drools，我们将业务规则定义在DataBase或者BRMS(Business Rule Management System)中，通过管理DB或者BRMS实现业务逻辑的动态改变。
什么时候应该使用规则引擎？
虽然规则引擎能解决我们的许多问题，但我们还需要认真考虑一下规则引擎对我们的项目本身是否是合适的。需要关注的点有：
1)我的应用程序有多复杂?
对于那些只是把数据从数据库中传入传出，并不做更多事情的应用程序，最好不要使用规则引擎。但是，当在Java中有一定量的商业逻辑处理的话，可以考虑Drools的使用。这是因为很多应用随着时间的推移越来越复杂，而Drools可以让你更轻松应对这一切。
2) 我的应用的生命周期有多久？
如果我们应用的生命周期很短，也没有必要使用Drools，使用规则引擎将会在中长期得到好处。
3) 我的应用需要改变吗？
这个答案一般情况下是肯定的，“这世界唯一不变的只有变化”，我们需求也是这样的，无论是在开发过程中或是在开发完成以后，Drools能从频繁变化的需求中获得好处。
规则引擎是基于规则的专家系统的核心部分，主要由三部分组成：规则库(Knowledge base)+Working Memory(Fact base)+推理机(规则引擎)，规则引擎根据既定事实和知识库按照一定的算法执行推理逻辑得到正确的结果。
Drools 是一个基于Charles Forgy's的RETE算法的，易于访问企业策略、易于调整以及易于管理的开源业务规则引擎，符合业内标准，速度快、效率高。
业务分析人员或审核人员可以利用它轻松查看业务规则，从而检验是否已编码的规则执行了所需的业务规则。

Drools是一个基于java的规则引擎，开源的，可以将复杂多变的规则从硬编码中解放出来，以规则脚本的形式存放在文件中，使得规则的变更不需要修正代码重启机器就可以立即在线上环境生效。

drools的基本工作过程：通常而言我们使用一个接口来做事情，首先要传进去参数，其次要获取到接口的实现执行完毕后的结果，而drools也是一样的，我们需要传递进去数据，用于规则的检查，调用外部接口，同时还