在我的公司,我们正在使用 Rythm,因为它的便利性和在项目中的易用性。在我们的项目中,我们发送了几封电子邮件(每天 1000-2000 封电子邮件);电子邮件模板是具有动态语法(Java 代码)的 Rythm 模板。性能似乎不错,并且通过了集成测试。
尽管如此,我们已经试验了几个内存问题,这些问题会在 3-4 天后导致内存泄漏。Profiling,我们观察到 Rythm 是堆中最大的对象(我们的 profiling 大约需要 1 天),甚至比 Spring 中的 ClassLoader 或 BeanFactory 还要多。
使用堆工具分析器,我们观察到RythmEngine和TemplateClassManager是最大的对象
(Instance) - (retained size bytes)
org.rythmengine.RythmEngine#1 - 10,192,894
org.rythmengine.internal.compiler.TemplateClassManager#1 - 9,223,065
org.springframework.boot.loader.LaunchedURLClassLoader#1 - 6,975,661
java.util.Vector#89 - 6,378,290
java.lang.Object[]#7549 - 6,378,254
org.springframework.beans.factory.support.DefaultListableBeanFactory#1 - 3,741,643
......
我们可以从堆分析工具中看到,这些对象很大,而且似乎随着时间的推移而增加。
和一个 GC 根。
关于内存池:Par Eden 似乎很好,CMS Old Generation 似乎没有增加,或者至少很慢(即使在一些主要的 GC 之后,似乎还有空闲内存)。堆内存看起来不错(测试和分析大约需要一天),但在生产中达到最大堆后会缓慢增加。
我们询问是否有人尝试过此功能(使用 rythm 并在几天后出现内存泄漏),或者只是提供一些如何在生产环境中使用 rythm 提高性能的最佳实践。或者任何关于如何处理深度内存泄漏的想法都将受到欢迎。
重要说明[30-09-2015]:我们已从 Rythm 更改为 FreeMarker 作为模板引擎,并且(正如我们的监控系统所反映的那样)内存似乎更加稳定并且大约是最大内存的 20% (-Xmx1024)。我们将在本周内提供更详细的信息。但似乎 Rythm 可能存在一些内存问题,几天后会导致内存泄漏。
重要提示[06-10-2015]:经过几天的密集监控,我们使用 FreeMarker 作为模板引擎检查了内存是否稳定。我们已经在我们的产品中删除了 Rythm 的所有依赖项,因为正如我们的研究所反映的那样,它有一个潜在的内存泄漏问题没有解决,几天后(在我们的例子中是两天)驱动到 OOME 堆。问题已关闭。