如何避免 Mule 应用程序中的内存泄漏？

Question

为了避免Mule 应用程序中的内存泄漏，是否必须考虑一些特殊的事情？

如何避免 Mule 应用程序中的内存泄漏？

例如; 我们真的必须删除流变量吗？哪些内容必须由 Mule 应用程序的开发人员显式完成，哪些内容由Mule 运行时和JVM GC （自动）完成？

Answer 1

确定内存泄漏嫌疑的一个好方法是在您开始看到主要 GC 后内存回收量下降后立即进行（所有节点的）堆转储。有多种工具可以帮助分析内存泄漏。

该主题中有一篇很棒的博客文章。本文总结了一些与内存泄漏相关的问题，例如以下发现：

发现：池化内存管理器通常会占用 10% 的 JVM 堆并使用它而不释放。 修复：切换 Grizzly 内存管理器实现 HeapMemoryManager。请注意，HeapMemoryManager 是默认实现，出于性能考虑，Grizzly 推荐使用 HeapMemoryManager；尽管如此，Mule 将 PoolMemoryManager 实现视为默认实现。

Wrapper.conf 更改：

wrapper.java.additional.<XX>=-Dorg.glassfish.grizzly.DEFAULT_MEMORY_MANAGER=org.glassfish.grizzly.memory.HeapMemoryManager

发现：异步日志记录被广泛使用，并且观察到相关 Log4J 占用了大量 JVM 内存。256*1024 插槽的默认设置显然太高了。由于此 RingBuffer 不会增长或收缩，因此将每个槽分配为单独的对象 (RingBufferLogEvent)（每个槽保存一个日志事件）的高固定大小可能会占用大量内存。

修复：在wrapper.conf或log4j2.xml中将Log4J RingBuffer大小减少到128

wrapper.java.additional.<XX>=-DAsyncLoggerConfig.RingBufferSize=128

或者，在 log4j2.xml 中：

<AsyncLogger name="DebugLog" level="info" includeLocation="true" ringBufferSize="128">

由于聚合器组件使用默认的 HazelCast 实现（分割聚合器模式）而导致内存泄漏。

发现：堆分析指出特定流程中使用的拆分器聚合器组件中使用的默认 HazelCast 对象存储实现占用了内存。看起来好像商店没有适当地过期。

修复：编写自定义对象存储实现（PartitionedInMemoryObjectStore 的子类）并显式定义条目的 TTL (TimeToLive)。

@Override 
public void expire(int entryTTL, int maxEntries, String partitionName) throws ObjectStoreException
{
    super.expire(entryTTL, maxEntries, partitionName);
    if (getPrivatePartitionSize(partitionName) == 0) {
disposePartition(partitionName);
    }
}

参考： https: //dzone.com/articles/enduring-black-fridays-with-mulesoft-apis