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

是否有一些特殊的事情必须考虑以避免内存泄漏

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

---

比如,；我们真的必须删除流变量吗？Mule应用程序的开发人员必须明确完成哪些工作，以及和的（自动）完成哪些工作？

一般建议

• 会话变量

对于具有多个端点的应用程序，与多个或多个端点相比，更喜欢更少、更小的会话变量 每次消息通过时，会话作用域都被序列化和反序列化 端点，甚至是VM端点。因此，如果一个应用程序有很多端点，那么它将涉及很多端点 序列化/反序列化。使用越来越少的会话变量有助于将此最小化 头顶

• 有效载荷格式

在性能方面，并非所有格式都是相同的。一些有效负载格式允许更快的速度 比其他人更容易访问数据。Bean有效负载对于Mule应用程序来说往往是最快的。如果是的话 考虑到其他因素，一个可行的选择是在Java对象中创建有效负载

• 数据提取

Mule表达式语言（MEL）可用于从消息中提取数据 性能方面，允许MEL提取数据可能比使用脚本语言更好。 脚本语言是动态类型化的。有些甚至在运行时进行解释。这些因素 会产生可能降低性能的开销

• 流引用

流引用是在应用程序中实现流通信的一种令人愉快的直接方式。 流引用比VM端点更适合于流之间的通信。流动 引用将消息注入目标流，而无需中间步骤。虽然 VM连接器是内存中的协议。它模拟序列化和 反序列化部分消息。这一现象在会议范围内尤为显著。作为 这样，流引用在流间通信方面优于VM端点 因为前者避免了序列化和反序列化产生的不必要的开销

可以在wrapper.conf中为Mule设置JVM和GC标志。

人们很容易对特定的Java虚拟机（JVM）或垃圾收集产生热情 （GC）方法。JRockit与热点、平行标记和扫描（MS）与G1

• MuleSoft使用标准Oracle JVM HotSpot。热点是 支持良好，易于为各种目的定制。 MuleSoft的性能测试强调吞吐量，因此 并行GC。HotSpot也很容易优化响应时间。这个 以下各节中的提示显示了如何校准的热点 吞吐量或响应时间
• 将初始堆大小和最大堆大小指定为相同的值。 这可以通过设置MaxMetaspaceSize=MetaspaceSize和 MaxNewSize=新闻大小。这样做可以避免JVM需要 在运行时动态分配额外内存。旗帜是 在wrapper.conf中设置
  e、 g。 wrapper.java.additional.16=-XX:NewSize=1365m wrapper.java.additional.17=-XX:MaxNewSize=1365m wrapper.java.additional.18=-XX:MetaspaceSize=256m wrapper.java.additional.19=-XX:MaxMetaspaceSize=256m wrapper.java.additional.20=-Xms=2048m wrapper.java.additional.21=-Xmx=2048m

• 至少有两个原因可以解释这样的动态再分配 妨碍表演。首先，JVM对每个堆执行主要GC 调整大小。完整GC会在一段时间内停止所有线程。那就行了 即使使用并发标记和扫描（CMS）。世界停止 在其他条件相同的情况下，应始终最小化。这是 对于优先考虑低响应时间的应用程序尤其重要。 当内存紧张时，动态堆大小调整会产生第二个问题。 假设JVM在运行时和系统运行时增加堆大小 没有足够的可用内存页。作为一个 结果，内核所选进程的某些页面可能会被调出 到磁盘。由于磁盘容量增加，这种情况会导致速度减慢 木卫一

垃圾收集 HotSpot配备了三种规范化垃圾收集（GC）机制。这些是 串行、并行和并发标记和扫描（CMS）。18垃圾优先（G1）最近得到了应用 添加到列表中。19默认情况下，JVM在具有2个或更多物理层的计算机上使用并行GC 处理器和2 GB或更多物理内存

并行GC是HotSpot JVM中的默认垃圾收集算法。触发时，它使用 多个线程扫描、移动和收集堆中无法访问的对象。 CMS GC（并发标记扫描） 并发标记和扫描（CMS）GC旨在通过运行 大多数清理阶段与应用程序线程同时进行，因此它提供了更多 控制影响应用程序响应时间的失速时间。 下面是一个示例，演示如何将JVM设置为使用CMS以及其他选项。设定 下面是Mule的wrapper.conf文件。第6节“示例配置文件”提供了额外的 设置标志的上下文

wrapper.java.additional.22=-XX:+UseConcMarkSweepGC
wrapper.java.additional.23=-XX:CMSInitiatingOccupancyFraction=65
wrapper.java.additional.24=-XX:UseCMSInitiatingOccupancyOnly

标志-XX:CMSInitiatingOccupancyFraction指定总堆的百分比 用法。当达到该百分比时，JVM将触发CMS GC。40到40的值 70通常足以满足在Mule上运行的应用程序。如果该值太低，可能会导致 过度、过早的收集。通常建议从相对较高的值开始 -XX:CMSInitiatingOccupancyFraction，并根据需要减少它，以优化最少的CMS 最佳表现的活动。 指定-XX:+指定-XX时仅使用CMSinitiatingOccupancy： +CMSInitiatingOccupancyFraction。否则，JVM将尝试动态调整该值 对于-XX:+CMSInitiatingOccupancyFraction。变化的值为undesi

wrapper.java.additional.4=-XX:+PrintGCApplicationStoppedTime
wrapper.java.additional.5=-XX:+PrintGCDetails
wrapper.java.additional.6=-XX:+PrintGCDateStamps
wrapper.java.additional.7=-XX:+PrintTenuringDistribution
wrapper.java.additional.8=-XX:ErrorFile=%MULE_HOME%/logs/err.log
wrapper.java.additional.9=-Xloggc:%MULE_HOME%/logs/gc.log
wrapper.java.additional.10=-XX:+HeapDumpOnOutOfMemoryError

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

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

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

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