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

解决内存泄漏问题的一个好方法是在看到大型主GC之后内存回收下降之后立即进行（所有节点的）堆转储。有多种工具可以帮助您分析内存泄漏。

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

结果：池内存管理器通常会抢占JVM堆的10％并与之一起生存而不释放。修复：切换Grizzly内存管理器实现HeapMemoryManager。请注意，HeapMemoryManager是默认实现，由Grizzly建议使用，以提高性能。尽管，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