2012-07-08 90 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