为了避免Mule Applications 中的内存泄漏，是否有一些特殊的事情必须考虑？ ?
我们如何避免 Mule 应用程序中的内存泄漏？
例如；我们真的必须删除流变量吗？什么必须由 Mule 应用程序的开发人员明确完成，什么由 Mule Runtime 自动完成。和 JVM GC ?
最佳答案
找到内存泄漏嫌疑人的一个好方法是在您开始看到主要 GC 后内存回收下降后立即进行(所有节点的)堆转储。有多种工具可以帮助分析内存泄漏。
有a great blog post在主题中。这总结了一些与内存泄漏相关的问题，例如以下发现:
发现:池化内存管理器通常会占用 10% 的 JVM 堆并与其一起使用而不释放。 修复:切换 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 objectstore 实现在特定流程中使用的拆分器聚合器组件中使用。似乎商店没有适当过期。
修复:编写了自定义对象存储实现(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
关于memory-leaks - 如何避免 Mule 应用程序中的内存泄漏？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49382294/