2012-07-08 88 views
0

问题 - 解析XML字符串时,内存利用率在我的程序中不断增长。将字符串XML解析为Java对象时的OutOfMemory

我有一个XML流中活过来一个TCP端口上。
我使用Netty拉出xml数据,然后使用XStream将XML字符串反序列化/解组为Java对象树。

当我使用NetBeans轮廓监视内存的消耗,我看到越来越多的HEAP随着时间的推移,最后JVM抛出内存溢出异常。 我追踪了调用堆栈,并附上了我的一个测试实例的截图。

内存消耗似乎发生时,我反序列化/解组XML字符串转换成Java对象。

我已经试过内的XStream不同的解析器做解析 - XPP3,KXML,STAX。我甚至尝试过使用JAXB而不是XStream来解组。 无论使用何种解析器,问题都会持续存在。

我已经尝试了所有这些不同的解析器,但迄今为止我有同样的问题。

xstream1 = new XStream(new KXml2Driver()); 
    xstream2 = new XStream(new StaxDriver()); 
    xstream3 = new XStream(new JDomDriver()); 
    xstream4 = new XStream(new Xpp3Driver()); 

就像我刚才提到的,我甚至尝试过使用JAXB解组而不是XStream ...仍然是同样的问题。

如果你看看附加的图像,它的这个Arrays.copyOfRange调用在char []下面,显示出来...... 不管它是哪个解析器,这个调用总是出现在trace的顶部。

我完全失去了关于如何解决或处理这个问题

PLS注 - 我不是从文件中读取XML。我得到一个包含小XML块的实时数据流。我提取各块将其转换成Java对象进行进一步的处理

感谢 一个 Allocation Stack Trace from Memory Consumption data pulled using Netbeans Profiler

回答

1

好,上证你告诉我们,最简单的解释是,你的JVM的堆太小。尝试添加一个“-Xmx”选项,如manual entryjava命令所述。

如果不工作,那么你就需要在采取从深层次看你的应用程序是这样做的:

  • 是否有这些“小” XML块大小的上限?你会得到一个比你允许的更大的块吗?

  • 是您的应用程序的处理保持的东西从每块在长期生活在内存中的数据结构?你可以在数据结构的大小上设置一个上限吗?也许通过扔东西? (或通过使用“弱引用”,以便GC将它们扔出去?)

  • 您的应用程序是否泄漏内存?

+0

A)没有上限B)我不保留任何有意...除非有错误。 C)这就是我想知道的,事情只是指出了我提到的这个解析区域,内存似乎正在发生。 – FatherFigure 2012-07-08 06:50:16

+0

如果您没有保留任何数据,那么很难在XML解析或其他任何内容中看到您如何泄漏内存。但无论如何,有方法可以追踪存储泄漏。例如:http://www.oracle.com/technetwork/java/javase/memleaks-137499.html#gbywf – 2012-07-08 06:57:35

+0

我的应用程序确实有内存泄漏 - 修复后可以正常工作。 – FatherFigure 2012-07-13 02:16:29

1

上面的答案是可靠的。我只会补充说内存中的对象图可能很昂贵。如果我理解你的描述,你有一个XML流,其中包含一些小的XML块?SAX解析可能是您的答案,以及流水线方法。当SAX解析器找到每个工作块时,它将它传递给下游进程,而不必将所有对象拉入内存。

+0

如果我们假设组块的大小确实很小并且有一个有限的大小,那么假设相应的DOM将会很小(偏)并且是有界的,这并不是一种延伸。在这种情况下,转换为SAX解析器需要很多工作......与增加堆大小相比。 – 2012-07-08 06:49:30

+0

伙计 - 正如我在文章中提到的,我已经尝试过,STAX,XPP3,KXML2和JDOM ....所有给我同样的问题...我想相信它在我自己的代码泄漏,但堆栈跟踪我在剖析器中看到指出完全不同的地方。我很难将其映射回我自己的代码。我目前正在切换到使用另一种解决方案 - 放弃XML,只是序列化/反序列化我的客户端和服务器之间的Java数据对象。如果这也给我一个内存泄漏,那么我可以尝试和追踪我自己的代码中的内存泄漏 – FatherFigure 2012-07-08 06:54:09

+0

我认为你可能误解了剖析器的输出。解析器发生失败的事实并不意味着解析器正在泄漏内存。 – 2012-07-08 07:03:04