小编Fra*_*ier的帖子

在我的公司,我们正在使用Rythm,因为它的设施和在项目中的易用性.在我们的项目中,我们发送了几封电子邮件(白天发送1000-2000封电子邮件); 电子邮件模板是具有动态语法(Java代码)的Rythm模板.性能似乎很好,它通过了集成测试.

尽管如此,我们已经尝试了几个内存问题,这些问题在3-4天后会导致内存泄漏.分析,我们观察到Rythm是堆中最大的对象(我们的分析大约是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老一代似乎没有增加,或者至少是缓慢增长(即使在一些主要的GC之后它似乎是免费记忆).堆内存似乎很好(测试和分析大约一天),但是在生产到达最大堆后缓慢增加.

我们询问是否有人尝试过此功能(使用rythm并在几天后出现内存泄漏)或者只是提供一些如何在生产环境中使用rythm提高性能的最佳实践.或者欢迎任何关于如何处理深度内存泄漏的想法.

重要说明 [30-09-2015]:我们已经从Rythm更改为FreeMarker作为模板引擎,它似乎(正如我们的监控系统所反映的)内存更稳定,大约是最大内存的20%(-Xmx1024).我们将在本周告知更详细的信息.但似乎Rythm可能会遇到一些内存问题,几天之后它就会导致内存泄漏.

重要说明 [06-10-2015]:经过几天的密集监控后,我们使用FreeMarker作为模板引擎检查了内存是否稳定.我们已经删除了Rythm在我们产品中的所有依赖关系,因为我们的研究反映出它有一个潜在的内存泄漏问题没有解决,在几天之后驱动到OOME堆(在我们的例子中是两天).问题已结束.