linux. websphere部署内存溢出,websphere内存溢出问题.doc

websphere内存溢出问题

内容提要：用户在使用WebSphere Application Server(以下简称WAS)运行自己应用的时候经常会碰到Out OfMemory的问题(简称OOM问题)，其中很大一部分的情况是Java堆空间碎片问题引起的OOM问题。IBM JDK1.4.2的版本中JDK对GC的行为做出了一定的改进。其中一些JDK参数的引进可以改善Java堆空间的碎片问题。本文首先会给出IBM JDK1.4.2中对于K簇(k-cluster)和P簇(p-cluster)工作模式的解释。然后在此基础上介绍JDK1.4.2为解决碎片问题采取的新算法。最后，给出WAS中为改善Java堆空间碎片问题使用的JDK运行参数。正文：一、K簇和P簇在Java堆空间中分配的内存对象通常是可以移动，如果垃圾回收程序(garbagecollector)决定重新序列化堆空间的时候，可以四处移动这些对象。然而，有些对象永远或者临时无法移动。这些固定不动的对象就是常说的pin对象(pinnedobject)。在IBM JDK 1.4.2中，垃圾回收程序首先会分配一个K簇作为堆空间底部的第一个对象。K簇是专门用来存储“类块”(classblock)的区域。K簇可以容纳1280个类块条目。每个类块的大小是256个字节。紧接着垃圾回收程序会分配一个P簇作为堆空间中的第2个对象。P簇是用来存储pin对象的区域。第一个P簇的默认大小为16KB。当K簇满了的情况下，垃圾回收程序在P簇中继续分配类块。当P簇满了的情况下，垃圾回收程序会分配一个大小为2KB的新P簇。由于这些新的P簇可以被分配到任何地方而且又不能被移动，这就造成了碎片的问题。

二、pinnedFreeList算法为了解决这些问题，IBM JDK1.4.2版本中起用了pinnedFreeList来改变P簇的分配方法。方法的关键是在每一次GC(garbagecollection)后，垃圾回收程序从未分配列表的底部分配一些存储区并把它们串到pinnedFreeList上。分配P簇的请求将从pinnedFreeList分配空间，而其他分配内存的请求将从堆的未分配列表上分配。无论堆的未分配列表或者pinnedFreeList被耗尽，垃圾回收程序都会造成一次分配失败并且引起GC。这种方法确保所有的P簇被分配在堆空间尽可能低的位置。垃圾回收程序按照如下的算法确定给pinnedFreeList分配多少存储空间：● 初始分配的空间是50KB● 如果不是初始分配并且pinnedFreeList为空，那么垃圾回收程序会比较50KB和从上一次GC到现在总共分配P簇大小5倍的数值，按照较大的数值分配● 如果不是初始分配并且pinnedFreeList不为空，那么垃圾回收程序会比较P簇溢出设定值(默认为2K)和从上一次GC到现在总共分配P簇大小5倍的数值，按照较大的数值分配这一算法在应用需要加载很多类的情况下会增大pinnedFreeList的大小。这样可以避免由于pinnedFreeList耗尽引起的分配失败。同时算法在分配很少P簇的情况下会减少pinnedFreeList的大小。这样可以避免pinnedFreeList占用过多的堆空间。buildPinnedFreeList函数利用上面的算法构建pinnedFreeList。这个函数在如下地方会被调用：● 在初始化簇(initializeClusters)时● 在堆空间扩展(expandHeap)结束时● 在gc0_locked结束时垃圾回收程序通过调用nextPinnedCluster函数在pinnedFreeList中分配P簇。这个函数的工作方式类似于nextTLH工作方式：总是从pinnedFreeList获取下一个空的块。如果pinnedFreeList空了，会产生manageAllocFailure。在realObjCAlloc里，如果在P簇中没有空间了，垃圾回收程序就会调用nextPinnedCluster函数分配一个新的P簇。在初始化簇(initializeClusters)时，垃圾回收程序调用nextPinnedCluster，nextPinnedCluster会分配一个50K大小的初始P簇，因为pinnedFreeList中唯一的空余块的大小是50K。空余块的大小等于50K是因为pinnedFreeList在初始状态下被设置为50K。

三、调整Java运行参数对于一个大的Java应用，比如：WAS，默认的K簇可能不足以分配所有的类块。在IBM JDK1.4.2版本中，可以通过使用-Xk和-Xp命令行参数来设定K簇和P簇的大小，例如：-Xknnnn其中nnnn代表K簇中可以容纳的类块的最大数目。通过添加Java的运行是参数-Dibm