Heapspace问题-如何解决？

Question

我们有一个apache 实例(版本3.3.1)，它运行我们的bpel流(使用ApacheOD1.3.5 )和一些骆驼代码(用于路由)。问题是，使用的服务器进程的堆空间不断增加。最终它耗尽了空间并坠毁了。因此，我们不得不每7-8天重新开始这个过程。(这很烦人)

该进程当前的jvm内存配置如下

-Xms512M -Xmx2048M -XX:PermSize=512m -XX:MaxPermSize=1024m

我们有另一个具有相同内存配置的servicemix实例，但是在较小的负载下运行，在超过分配的堆空间之前运行了大约20-22天。显然，这个负载越小，它的扩展运行就越好。

我的问题

1. 有没有人在上面提到的apache版本中遇到过类似的问题？ (在初始级别上，我希望确定它是与容器相关的泄漏还是与应用程序相关的问题)
2. 你如何着手解决这个问题？我是否可以申请一个方法来找出这个问题呢？如果是的话，谁能列出其中所涉及的步骤呢？ (网络上可用的解决内存泄漏的文章似乎更多地强调导致内存泄漏的理论，而不是应该采取的解决方法)

需要你的想法，建议和建议。

谢谢,

阿伦·乔利

Answer 1

通常，当我们面对这个问题时，我们会生成一个堆转储文件，堆转储是Java进程在某个时间点的内存的快照。持久化此数据有不同的格式，根据格式的不同，它可能包含不同的信息，但通常快照包含有关触发快照时堆中的java对象和类的信息。

生成堆转储文件的方法很多，但在您的示例中，您可以在发生OutOfMemoryError时添加这些参数来自动生成堆转储文件：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=[HeapDirPath]

因此，这个文件将允许您找出填充整个空间的对象是什么，然后您将很容易地找出导致内存泄漏的代码。

您可以使用Eclipse memory Analyzer来分析这种转储文件。

Answer 2

在我的经验中，ServiceMix 3的这种类型的内存问题常常表明您的流中的一个组件或端点的MEP处理存在问题。一些JBI组件、端点和服务保留了一个挂起的交换列表，因此如果某些消息交换模式未能正确终止，这些交换将永远不会从列表中删除。

解决这一问题的最佳方法是采取堆转储(例如使用jmap)，然后查看其中的MessageExchange实现实例。您可能会发现一堆非常类似的MessageExchanges保存在内存中。有了这些之后，就可以查看exchange属性，找出是哪个端点/组件导致了问题。

在后来的ServiceMix 3.x版本中也存在一些问题，可能是造成这一问题的原因。一定要对3.4.1版本进行检查，或者查看最新版本的发行说明。