RythmEngine和TemplateClassManager堆的最大对象:内存泄漏问题
在我的公司,我们正在使用Rythm,因为它的设施和在项目中的使用方便。在我们的项目中,我们发送了几封电子邮件(每天1000-2000封电子邮件);电子邮件模板是具有动态语法(Java 代码)的 Rythm 模板。性能似乎很好,它通过了集成测试。
尽管如此,我们已经尝试了几个内存问题,这些问题会在3-4天后导致内存泄漏。分析,我们已经观察到Rythm是堆中最大的对象(我们的分析大约是1天),甚至比ClassLoader或Spring的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之后,似乎也有可用内存)。堆内存似乎很好(测试和分析大约一天),但在达到最大堆后,生产增长缓慢。
我们询问是否有人已经尝试了此功能(使用节奏,几天后出现内存泄漏),或者只是提供一些如何在生产环境中通过节奏提高性能的最佳实践。或者任何如何处理深度内存泄漏的想法都将受到欢迎。
重要说明 [30-09-2015] :我们已从 Rythm 更改为 FreeMarker 作为模板引擎,似乎(正如我们的监控系统所反映的那样)内存更稳定,大约是最大内存的 20% (-Xmx1024)。我们将在本周提供更详细的信息。但是看起来Rythm可能有一些内存问题,它会在几天后导致内存泄漏。
重要说明 [06-10-2015] :经过几天的密集监控,我们使用 FreeMarker 作为模板引擎检查内存是否稳定。我们已经删除了产品中Rythm的所有依赖性,因为正如我们的研究所反映的那样,它有一个潜在的内存泄漏问题没有解决,这个问题在几天后(在我们的例子中是两天)驱动到OOME堆。问题已关闭。