基于JavaEE平台的WebSphere应用系统内存溢出浅析 下载本文

内容发布更新时间 : 2024/5/17 12:52:41星期一 下面是文章的全部内容请认真阅读。

龙源期刊网 http://www.qikan.com.cn

基于JavaEE平台的WebSphere应用系统内存溢出浅析

作者:余 涛

来源:《硅谷》2009年第22期

[摘要]内存溢出(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负责

龙源期刊网 http://www.qikan.com.cn

的,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堆大小影响着垃圾回收的执行频率和每次执行的时间。增大堆大

龙源期刊网 http://www.qikan.com.cn

小意味着会支持更多对象创建,由于大堆要用较长时间进行填充,在垃圾回收发生前应用程序会运行较长时间,所以系统吞吐率会增大。但是,较大堆也会用较长时间进行压缩,从而导致垃圾回收时间也较长。在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){