IBM JDK的Java堆空间的碎片问题
IBM的JDK容易产生堆碎片的问题，在这篇中我也有牵涉到，今天再次看到，就拿出来老生常谈一下，顺便内容扩充一下。本文大部分内容参考
【IBM内存碎片类问题，不可不看】JVM申请内存失败并频繁GC问题的分析思路
问题描述
通常情况下，对于Java虚拟机出现，只需要配置heap最大最小值，以及maxPermSize，但是这种情况仅限于SUN的Java虚拟机。对于IBM的JVM，情况就完全不一样。
对于Sun的JVM来说，它的GC策略默认是复制、分代算法。也就是说，它会将heap分成不同的几个区，譬如Solaris JVM中最上面有两个大小相等的区。GC时刻，将一个区的存活对象复制到另外一个对等区，垃圾对象就算遗弃了。这样在heap里面，就不存在碎片问题。另外Sun的JVM有单独的方法区，也就是Permanent Generation，方法区中保存的一般是Class对象，而不是普通的实例对象，也就是JVM的元数据。
IBM的JVM默认GC策略并没有采取复制、分代。这个可以从GC日志分析出来。它不像Sun的JVM那样，有个单独的方法区，它的方法区就放在Java Heap里面。在IBM的JVM里面，这些对象一般分配在称为k-cluster和p-cluster里（cluster又是属于Heap），而后者一般是临时在heap里面申请。并且，这些cluster是不能GC，或是被移动重排的（Compact过程）。这就导致Java Heap里面就如同蜂窝，但不同的蜂孔又不能合并，于是，当我们程序里面产生一个大对象，譬如2M的数组(数组必须分配在连续的内存区)时，就没有可分配空间了，于是就报告OOM。这些不能被移动的cluster之间的空隙就称为所谓的碎片。此时，JVM的Heap利用率可能不到50%。
k-cluster能够存放1280个类对象，第一个p-cluster大小为16K，默认存放类似于JNI对象和线程对象等不能移动的对象(pinned),然后k-cluster中存放不下的类对象也会放在p-cluster中，第一个p-cluster满了之后，后续的p-cluster大小只有2K，一个类对象大小是256字节
举一个例子
假设我们的系统一共要生成11280个类对象(可能没这么多class，但是同一个class由不同的classloader加载的话，尤其是使用了Spring、Hibernate这些框架的情况下，这些框架经常通过反射创建实例，所以导致Class对象的数量大大增加)，那么除了k簇中存放的1280个之外，其余10000个要放到p簇中。假设初始的16k的p簇中存放的完全是线程和JNI对象，也就是说我们的类对象要用后来申请的2k一个的p簇来存放。
那么一共需要 10000*256/2048 ==1250个p簇
假设我们的堆大小为1G，那么堆内碎片的平均大小是1G/1250，也就是不到1M。这个时候你申请1M以上的内存，就有很大的可能会遇到碎片问题造成的AF。
解决方法
对于IBM的JDK，设置恰当的最大堆和最小堆，设置-Xk和-Xp避免碎片问题，如果程序需要分配大对象较多，那么调整一下LOA的大小（判断标准是gc日志里大量AF是由于分配大于64K内容而产生的，gc日志的分析方法可以看这篇）。
参考参数：-Xk22000 -Xp64k,16K -Xloratio0.2（注意X都为大写）
对于1.5之后的JDK，如果采用默认的optthruput策略或者optavgpause策略，那么也是要设置-Xk和-Xp避免碎片问题，对于gencon策略，因为是分代回收的方式，理论不需要设置-xk -xp参数了，但是IBM没有独立的Permanent Generation，所以一切的调整还是要根据gc日志来。
附Avoiding Java heap fragmentation with Java SDK V1.4.2. 翻译版
如何在IBM JDK 1.4.2的环境中避免Java堆空间的碎片问题
内容提要：
用户在使用WebSphere Application Server(以下简称WAS)运行自己应用的时候经常会碰到Out Of Memory的问题（简称OOM问题），其中很大一部分的情况是Java堆空间碎片问题引起的OOM问题。IBM JDK 1.4.2的版本中JDK对GC的行为做出了一定的改进。其中一些JDK参数的引进可以改善Java堆空间的碎片问题。
本文首先会给出IBM JDK 1.4.2中对于K簇(k-cluster)和P簇(p-cluster)工作模式的解释。然后在此基础上介绍JDK 1.4.2为解决碎片问题采取的新算法。最后，给出WAS中为改善Java堆空间碎片问题使用的JDK运行参数。
正文：
一、K簇和P簇
在Java堆空间中分配的内存对象通常是可以移动，如果垃圾回收程序（garbage collector）决定重新序列化堆空间的时候，可以四处移动这些对象。然而，有些对象永远或者临时无法移动。这些固定不动的对象就是常说的pin对象（pinned object）。
在IBM JDK 1.4.2中，垃圾回收程序首先会分配一个K簇作为堆空间底部的第一个对象。K簇是专门用来存储“类块”（class block）的区域。K簇可以容纳1280个类块条目。每个类块的大小是256个字节。紧接着垃圾回收程序会分配一个P簇作为堆空间中的第2个对象。P簇是用来存储pin对象的区域。第一个P簇的默认大小为16KB。
当K簇满了的情况下，垃圾回收程序在P簇中继续分配类块。当P簇满了的情况下，垃圾回收程序会分配一个大小为2KB的新P簇。由于这些新的P簇可以被分配到任何地方而且又不能被移动，这就造成了碎片的问题。
二、pinnedFreeList算法
为了解决这些问题，IBM JDK 1.4.2版本中起用了pinnedFreeList来改变P簇的分配方法。方法的关键是在每一次GC（garbage collection）后，垃圾回收程序从未分配列表的底部分配一些存储区并把它们串到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 JDK 1.4.2版本中，可以通过使用-Xk和-Xp命令行参数来设定K簇和P簇的大小，例如：
-Xknnnn
其中nnnn代表K簇中可以容纳的类块的最大数目。通过添加Java的运行是参数-Dibm.dg.trc.print=st_verify 可以在GC的详细信息中得到合适nnnn的值，例如：
<GC(VFY-SUM): pinned=4265(classes=3955/freeclasses=0) dosed=10388 movable=1233792 free=5658>
pinned和classes的数值可以为-Xk的正确数值提供参考。一般推荐使用classes（3955）数值的110%左右，所以在这个例子中-Xk4200是一个合适的设置。
尽管，pinned和classes的数值之间的差值给pCluster的初始大小提供了线索。但是，因为每一个对象可能有不同的大小，所以很难预测P簇所需要的大小和P簇溢出的大小。用户可以通过-Xp命令行参数-Xp设定P簇的初始大小和溢出大小。例如：
-Xpiiii[K][,oooo[K]]
其中，iiii代表P簇的初始大小，单位是KB，oooo是可选的，代表溢出P簇（后续的P簇）的大小。iiii和oooo的默认值为16KB和2KB。
如果用户的应用确实遇到了堆空间碎片的问题，可以考虑打开GC的详细信息并使用-Dibm.dg.trc.print=st_verify参数，并从分析值中得到合适的-Xk值。如果问题依旧存在，可以考虑试验加大P簇的初始大小和溢出大小。
另，从1.3.1 SR7之后的JVM版本，就能使用-Xp -Xk参数了，JVM的版本可以通过java -version或者systemout.log每次启动开头看到
Because this new pCluster can be allocated anywhere in the heap and must be pinned, it can cause fragmentation problems. The pinned objects effectively deny the GC the ability to combine free space during heap compaction and could result in a heap that contains a lot of free space but in relatively small discrete amounts, so that an allocation that appears to be well below the total free heap space will fail. To solve this problem, release 1.3.1 at SR7, and later, provides command-line options to specify the kCluster (-Xk), pCluster (-Xp) and pCluster overflowsize (-Xp). Use these options to set the initial sizes of the ’clusters’ to be large enough to avoid fragmentation issues.
最及时的声音