php内存溢出常见原因_基于JavaEE平台的WebSphere应用系统内存溢出浅析

　　[摘要]内存溢出(OOM)是很常见的WebSphere应用程序性能问题,它往往会导致系统响应速度变慢甚至服务器宕机。以一个基于JavaEE平台的ERP系统开发实践为背景,从应用程序和java虚拟机配置两个方面对OOM问题进行分析,并提出解决方案,从而改善系统性能。
　　[关键词]JavaEEWebSphereOOM
　　中图分类号:TP3文献标识码:A文章编号:1671-7597(2009)1120053-02
　　
　　一、引言
　　
　　JavaEE(java Enterprise Edition)即Java平台企业版,是建立在Java SE平台基础上的企业级平台开发标准,它利用Java平台来简化企业解决方案的开发、部署和管理等相关复杂问题。
　　WebSphere是IBM研发的,所提供的一个集成软件平台,它包含编写、运行和监视随需应变的Web应用程序和跨平台解决方案所需要的整个中间件基础设施。WebSphere应用程序服务器(WAS)是整个基础设施的基础,所有其他产品都在它之上运行。
　　基于JavaEE的WebSphere应用日益广泛,但随着数据量不断增大、业务负载不断加重,性能问题可能就会暴露出来,相继出现客户响应速度慢、服务器内存不足、服务器CPU使用率100%等等瓶颈。
　　本文结合作者实际研发的一个ERP系统开发作为实践背景,主要分析内存溢出问题。
　　
　　二、内存溢出
　　
　　内存溢出(Out Of Memory,或简称OOM)是指应用系统中无法回收内存或使用的内存过多,导致程序运行所需内存大于虚拟机提供的最大内存。在Java中,内存管理是有JVM负责的,JVM一般采取堆(heap)的方式管理内存。Java堆是一个运行时数据区,类的实例从堆中分配空间。Java程序可以通过各种语句建立内存对象,但内存的释放是由垃圾回收器(Garbage Collection或简称GC)完成的。GC是全自动地检测并移除不在使用的数据对象。垃圾回收器通常由一定的条件按触发,在WebSphere用中主要是内存分配失败(Allocation Failure或简称AF)。由于不同的JVM实现者可能使用不同的算法来管理GC,同时不同类型的应用程序在不同的GC策略下也有所差异,因此笔者将针对Linux平台上,基于JDK1.5的IBM JVM来讨论内存溢出问题。
　　WAS服务器宕机后一般会自动产生javacore文件和Thread dump文件,或者手工生成,在Linux操作系统下可以采用命令kill -3 Java进程号生成。借助IBM工具IBM Thread and Monitor Dump Analyzer for Java分析javacore文件,图一是当java堆耗尽时显示的结果:
　　分析结果里面以灰色字体显示出java堆耗尽信息,在Garbage Collec
　　tion History里面也会提示对象分配失败信息:
　　J9AllocateObject() returning NULL!则表示Java堆分配对象未成功完成,将抛出OutOfMemoryError异常。
　　内存溢出可能由以下原因造成:
　　(1)一次性加载到内存的数据量过于庞大,使得Java堆空间耗尽;
　　(2)配置参数指定的JVM堆最大值太小;
　　(3)内存泄漏(Memory Leak)问题。
　　
　　三、内存溢出的解决
　　
　　内存溢出问题排查是比较棘手的,但还是有章可循的,以下结合笔者研发的ERP系统,介绍如何对内存溢出问题进行分析与解决。
　　
　　(一)JVM参数设置
　　WebSphere应用服务器是一个基于Java的进程,必须在一定的Java虚拟机环境下才能运行。在大多数的情况下,JVM堆大小影响着垃圾回收的执行频率和每次执行的时间。增大堆大小意味着会支持更多对象创建,由于大堆要用较长时间进行填充,在垃圾回收发生前应用程序会运行较长时间,所以系统吞吐率会增大。但是,较大堆也会用较长时间进行压缩,从而导致垃圾回收时间也较长。在WebSphere服务器JVM参数调优中,最重要的就是初始堆大小(-Xms)和最大堆大小(-Xmx)。通过这两个参数来限制内存堆的大小以满足Java应用程序的需求,合理的设置-Xms和-Xmx参数,对系统性能的提高具有重要的作用。最大堆也不能设置过大,尽管它最初通过延迟垃圾回收改进性能,但当垃圾回收时会运行较长时间。如何才能设置合理的-Xms与-Xmx参数,需要不断的观察与分析。通过IBM工具PMAT(PMAT工具解析JAVA SDK的详细垃圾回收日志,并提供统计信息,图标,分析并推荐java堆配置)对native_stderr.log日志进行分析。前提条件是WebSphere服务器开启详细垃圾回收(垃圾回收信息将默认记录在native_stderr.log日志文件中)。下面以笔者参与的ERP系统为例,来分析如何设置JVM的-Xmx与-Xms值。图三是显示的某时间段内垃圾回收的部分信息:
　　Used Tenured(After):指垃圾回收器进行垃圾回收之后,在堆的tenured区域中已经被使用的字节数。Free Tenured(After):指垃圾回收器进行垃圾回收之后,在堆的tenured区域中可用的字节数。Total Tenured(After):指垃圾回收器进行垃圾回收之后,堆的tenured区域的总字节数。
　　图四是对应的java堆Tenured区域的相关变化曲线,其中灰色曲线表示的是Total Tenured(After),黑色曲线表示的是Used Tenured(After)。
　　通过PMAT对native_stderr.log的分析,将java最大堆(-Xmx)设置成1024M,最小堆(-Xms)设置成512M,可以满足java应用程序的要求。目前,该系统在生产线上性能较好。
　　
　　(二)内存泄漏
　　内存泄漏原因有很多,一般来说,从数据库连接池、线程池中获取连接与释放连接比较容易造成内存泄漏。笔者参与的ERP系统采用的是c3p0连接池,hibernate3.0作为持久层。在利用hibernate开发DAO模块时,为了避免session的频繁创建和销毁以及提高系统性能,采用ThreadLocal模式来管理session比较合理。下面是获取session的核心代码:
　　public static final ThreadLocal
　　session =new ThreadLocal();
　　public static Session currentSession()
　　throws HibernateException{
　　Session s=session.get();
　　if(s==null){
　　s=sessionFactory.openSession();//打开连接
　　session.set(s);}return s;}
　　session的关闭问题是最头疼的事情,如果在DAO层就把session关闭,因为hibernate存在lazy loading,那么在应用层内把关系结合都初始化(违背hibernate设计初衷,对性能有较大影响),否则hibernate就会抛session already closed Exception;如果session不关闭,那么就必定会造成内存泄漏。笔者结合系统的运行环境以及系统访问量,采用的是open session in view模式来解决这种矛盾。将session绑定到当前线程,当某个新线程开启时,就自动在数据库连接池中获取连接,在线程结束后就自动释放连接。下面是核心代码:
　　public void doFilter(ServletRequestarg0,
　　ServletResponse arg1,FilterChain arg2)
　　throws IOException,ServletException{
　　//自动获取连接
　　HiberanteSessionFacory.currentSession();
　　try{
　　arg2.doFilter(arg0,arg1);
　　}finally{//自动释放连接
　　HibernateSessionFactory.closeSession();
　　}}
　　
　　(三)数据分页显示
　　对数据库查询中,尽量避免一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出,同时一次获取全部数据,速度也较慢。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
　　
　　四、结束语
　　
　　高性能是一个应用能成为企业级应用的重要前提,往往性能问题通常都比较复杂,一旦出现就不易解决。在系统开发中,应尽量避免可能造成的性能瓶颈。本文介绍了性能问题中的一个方面,即内存溢出,从三个方面进行分析,提出了在开发过程中如何避免内存溢出。
　　
　　参考文献:
　　[1]孙磊、孙静、楼亭、涂子琰等编著,《构建高性能WebSphere企业级应用》,电子工业大学出版社.
　　[2](美)文纳斯著,《深入java虚拟机》,机械工业出版社.
　　[3](美)尼尔森等著,《J2EE应用与IBM WebSphere》,电子工业出版社.
本文为全文原貌 未安装PDF浏览器用户请先下载安装 原版全文