一个客户使用了若干年ODM，系统中部署了大量业务规则，当月末业务量集中时，规则服务器性能会面临较大压力，应用服务器JVM经常发生Full GC，甚至导致OutOfMemory，严重影响业务运行。
我们以此为例来看看如何用结构化的方式来处理此类性能问题。
Step 1 - 确认问题
首先我们来看一下该客户的GC日志，确认问题：
从GC日志中可以观察到如下现象：
- Full GC每隔几秒就会发生一次
- 每次Full GC持续时间为4-5秒
- 年老代和持久代的内存使用90％以上
- Full GC之后，年老代中的内存占用依然很高
可以推测JVM中确实存在大量被引用的年老代对象，无法被GC回收。
Step 2 - 代码review
接下来我们review了客户的规则应用架构和规则设计主要涵盖规则项目，对象模型，规则书写，规则刘设计，服务调用集成等方面，没有发现明显的可能导致内存泄漏的设计问题。
客户使用EJB实现远程规则服务调用，虽然这不是一个推荐的最佳实践，但一般不至于导致内存问题。
Step 3 - 内存分析
既然review代码无法找到明显问题，我们必须深入分析一下Java进程的heapdump文件，了解是否存在内存泄漏，以及到底是什么对象占用了大量的内存。
以下为测试服务器上重现的heapdump分析图：
可以看到在内存中大小为55,401,558 bytes的ruleset对象中包含30,016,942bytes的IlrTranslationDebugSupport对象，根据命名判断也应该是供Debug所用。值得注意的是，该对象在测试环境中尺寸不大，因为测试中仅使用了6个规则服务。 在生产环境中，会有数十个规则集加载到规则引擎中，导致的内存消耗也将非常可观。生产环境服务器的heapdump分析显示改类对象所占用内存达到500M以上，这会直接导致full GC的发生。
Step 4 - 解决方案
登陆RES，并选中对应规则集，查看ruleset.bom.enabled属性是否被设为true，将其设为false可以防止规则引擎生成IlrTranslationDebugSupport对象。
该属性主要用于监控用途，解释如下：
修改完所有相关规则集对应属性设置后，进行测试并观察heapdump， IlrTranslationDebugSupport对象应该不会再出现，IlrRuleset对象内存占用有明显下降（大约40%）。
结论
以上解决方案可以有效降低规则服务器内存消耗，此外，还有一些额外的建议可以帮助客户改善性能：
1. 使用POJO方式或其他轻量级的远程调用技术集成规则服务
2. 使用ODM8的Decision Engine特性
这两个建议同样适用于大部分ODM的设计场景，我会在其他文章中详细讲解。
注：本文发布于http://decisionrule.com/zh/2015/02/memory-performance-optimization/, 转载请注明出处。