我们在Production中有一个 apache servicemix 实例（版本3.3.1 ），它运行我们的bpel流程（使用 apache ode 1.3.5 ）和一些骆驼代码（用于路由）。问题是，servicemix进程的使用的堆空间不断增加。最终它耗尽了空间和崩溃。因此，我们必须每7-8天继续重新启动该过程。 （这非常讨厌）
该过程的当前jvm存储器配置如下 - Xms512M -Xmx2048M -XX：PermSize = 512m -XX：MaxPermSize = 1024m
我们有另一个具有相同内存配置的servicemix实例，但是在负载稍微较小的情况下运行，在超过分配的堆空间之前运行大约20-22天。显然，这个负载较小有助于它延长运行时间。
我的问题
是否有人遇到过与上述apache servicemix版本相同的问题？（在初始阶段，我想确定它是否与容器相关的泄漏或与应用程序相关的问题）< / p>
你如何解决这个问题？有没有一种方法可以申请找出问题？如果是这样，任何人都可以列出相同的步骤吗？ （网上提供的内存泄漏分辨率文章似乎更多地强调导致内存泄漏的理论，而不是解决它应该采用的步骤）
需要你的想法，建议和建议。
谢谢，
Arun Jolly
答案 0 :(得分：1)
通常，当我们遇到此问题时，我们会生成堆转储文件，堆转储是特定时间点Java进程内存的快照。持久化此数据有不同的格式，并且根据格式可能包含不同的信息，但通常快照包含有关触发快照时堆中的Java对象和类的信息。
有很多方法可以生成堆转储文件，但在这种情况下，您可以添加此参数以在OutOfMemoryError发生时自动生成堆转储文件：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=[HeapDirPath]
因此，这个文件可以让你弄清楚填满整个空间的对象是什么，然后你就可以轻松找出造成内存泄漏的代码。
您可以使用Eclipse memory Analyzer来分析此类转储文件。
答案 1 :(得分：1)
根据我的经验，ServiceMix 3的这种类型的内存问题通常表明MEP处理流中的某个组件或端点时出现问题。一些JBI组件，端点和服务保留了挂起的交换列表，因此如果其中一些消息交换模式无法正确终止，那么这些交换将永远不会从列表中删除。
解决此问题的最佳方法是进行堆转储（例如使用jmap），然后查看其中的MessageExchange实现实例。你可能会发现一堆非常相似的MessageExchanges被保存在内存中。获得这些后，您可以查看交换属性以确定导致问题的端点/组件。
还有一些问题在以后的ServiceMix 3.x版本中得到修复，可能是导致此问题的原因。请务必在3.4.1版本上进行操作，或查看最新版本的发行说明。