openjpa_OpenJPA：内存泄漏案例研究

最新推荐文章于 2024-08-07 10:10:40 发布

dnc8371

最新推荐文章于 2024-08-07 10:10:40 发布

阅读量150

点赞数

文章标签： java jvm 大数据编程语言内存泄漏

原文链接：https://www.javacodegeeks.com/2013/03/openjpa-memory-leak-case-study.html

版权

openjpa

本文将提供完整的根本原因分析详细信息以及解决影响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 CLASS

    private static final Localizer _loc = Localizer.forPackage
        (PCRegistry.class);

    // map of pc classes to meta structs; weak so the VM can GC classes
    private static final Map _metas = new ConcurrentReferenceHashMap
        (ReferenceMap.WEAK, ReferenceMap.HARD);

    // register class listeners
    private 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 {
      
       @Resource
       private 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的此代码缺陷和改进程序的使用导致在早期JVM堆转储分析中演示的OpenJPA _listeners数据结构内泄漏或积累了元数据存储库实例。该问题的解决方案是通过Singleton模式集中管理线程安全javax.persistence.EntityManagerFactory的管理和生命周期。最终解决方案的实现如下：