本文將提供完整的根本原因分析詳細信息以及解決影響Oracle Weblogic Server 10.0生產環境的Java堆內存泄漏（Apache OpenJPA泄漏）的方法。 這篇文章還將演示在管理javax.persistence.EntityManagerFactory生命周期時遵循Java Persistence API最佳實踐的重要性。

環境規格

• Java EE服務器 ：Oracle Weblogic Portal 10.0
• 操作系統 ：Solaris 10
• JDK ：Oracle / Sun HotSpot JVM 1.5 32位@ 2 GB容量
• Java Persistence API ：Apache OpenJPA 1.0.x（JPA 1.0規范）
• RDBMS ：Oracle 10g
• 平臺類型 ：Web門戶

故障排除工具

• Quest Foglight for Java（ Java堆監視）
• MAT（Java 堆轉儲分析 ）

問題描述與觀察

生產中斷后，最初由Weblogic生產支持團隊報告了此問題。 最初的根本原因分析練習確實揭示了以下事實和觀察結果：

• 約2周的流量后，定期觀察到生產中斷。
• 失敗是由于Java堆（OldGen）耗盡所致，例如OutOfMemoryError：在Weblogic日志中發現Java堆空間錯誤。
• 在一段時間后從Foglight監視工具檢查了Java堆OldGen的空間利用率以及Java冗長的GC歷史數據后，確認了Java堆內存泄漏。

發現上述問題后，決定移至RCA的下一個階段，并對受影響的Weblogic（JVM）實例執行JVM 堆轉儲分析 。

JVM堆轉儲分析

**現在可以在此處獲得解釋以下JVM堆轉儲分析的視頻。 為了產生一個
JVM堆轉儲受支持的團隊確實使用了HotSpot 1.5 jmap實用程序，該實用程序生成了大約1.5 GB的堆轉儲文件（heap.bin）。 然后使用Eclipse Memory Analyzer Tool分析了堆轉儲文件。 現在，讓我們回顧一下堆轉儲分析，以便我們了解OldGen內存泄漏的根源。

MAT提供了一個初始的泄漏可疑報告，這對于突出您的高內存貢獻者非常有用。 對于我們的問題案例，MAT能夠識別出泄漏嫌疑人，造成了將近600 MB的泄漏或占OldGen空間總容量的40％。

至此，我們找到了一個java.util.LinkedList實例，該實例使用了將近600 MB的內存，并已加載到我們的應用程序父類加載器之一（@ 0x7e12b708）。 下一步是了解泄漏的對象以及保留的來源。 MAT允許您檢查應用程序的任何類加載器實例，為您提供檢查加載的類和實例的功能。 只需提供地址（例如0x7e12b708）來搜索所需的對象，然后通過選擇帶有外向引用的“列表對象”>檢查加載的類和實例。

從上面的快照中您可以看到，該分析非常有啟發性。 我們發現內存保留源中有一個org.apache.openjpa.enhance.PCRegistry實例； 罪魁禍首是實現為LinkedList的_listeners字段。 供您參考，Apache OpenJPA PCRegistry在內部用于跟蹤已注冊的具有持久性的類。 在Apache OpenJPA 1.0.4版中暴露_listeners字段的PCRegistry源代碼的片段下面。

/*** Tracks registered persistence-capable classes.** @since 0.4.0* @author Abe White*/ public class PCRegistry {// DO NOT ADD ADDITIONAL DEPENDENCIES TO THIS CLASSprivate static final Localizer _loc = Localizer.forPackage(PCRegistry.class);// map of pc classes to meta structs; weak so the VM can GC classesprivate static final Map _metas = new ConcurrentReferenceHashMap(ReferenceMap.WEAK, ReferenceMap.HARD);// register class listenersprivate static final Collection _listeners = new LinkedList();

現在的問題是，為什么這種內部數據結構的內存占用空間如此之大，并且隨著時間的推移可能會泄漏？ 下一步是深入研究_listeners LinkedLink實例，以便檢查泄漏的對象。

最后，我們發現泄漏的對象實際上是我們的應用程序用來對Oracle數據庫執行各種查詢的JDBC和SQL映射定義（元數據）。 對JPA規范，OpenJPA文檔和源代碼的回顧確實確認了根本原因與javax.persistence.EntityManagerFactory的錯誤使用有關，例如缺少關閉新創建的EntityManagerFactory實例。

如果仔細查看上面的代碼快照，您將意識到close（）方法確實負責清理最近使用的元數據存儲庫實例。 這也確實引起了另一個問題，為什么我們要一遍又一遍地創建這樣的Factory實例……調查的下一步是對我們的應用程序代碼執行代碼遍歷，尤其是圍繞JPA EntityManagerFactory和EntityManager對象的生命周期管理。

根本原因和解決方案

該應用程序代碼的代碼演練確實表明該應用程序在每個單個請求上都創建了EntityManagerFactory的新實例，并且沒有正確關閉它。

public class Application {@Resourceprivate UserTransaction utx = null;// Initialized on each application request and not closed!@PersistenceUnit(unitName = "UnitName")private EntityManagerFactory emf = Persistence.createEntityManagerFactory("PersistenceUnit"); public EntityManager getEntityManager() {return this.emf.createEntityManager();}public void businessMethod() {// Create a new EntityManager instance via from the newly created EntityManagerFactory instance// Do something...// Close the EntityManager instance} }

JPA EntityManagerFactory的此代碼缺陷和改進程序的使用引起了OpenJPA _listeners數據結構內元數據存儲庫實例的泄漏或積累，這是從早期JVM堆轉儲分析中展示的。 該問題的解決方案是通過Singleton模式集中管理線程安全javax.persistence.EntityManagerFactory的管理和生命周期。 最終解決方案的實現如下：

• 每個應用程序類加載器僅創建和維護一個javax.persistence.EntityManagerFactory靜態實例，并通過Singleton Pattern實現。
• 為每個應用程序請求創建并處置EntityManager的新實例。

請閱讀Stackoverflow上的 討論 ，因為我們實現的解決方案非常相似。 在將解決方案實施到我們的生產環境之后，不再觀察到Java堆OldGen內存泄漏。

參考： OpenJPA：我們的JCG合作伙伴 Pierre-Hugues Charbonneau在Java EE支持模式和Java教程博客上的內存泄漏案例研究 。

翻譯自: https://www.javacodegeeks.com/2013/03/openjpa-memory-leak-case-study.html

總結

以上是生活随笔為你收集整理的OpenJPA：内存泄漏案例研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。