java core xmxcl,一次成功的内存泄漏分析

系统上线后偶有宕机，而且每次都是出现在相同的某两个业务点上，多次对程序进行代码检查，认真分析后，仍旧没有解决问题。

宕机后，产生上G的dump文件和javacore文件，苦于没有分析经验，很久没有找到解决问题的方案。查找资源后，发现两个软件，即 heapAnalyzer   和 jca。前者分析dump文件，后者分析javacore文件。对于 heapAnalyzer   而言，在 windows 环境下，打不开AIX上产生的dump文件(如：heapdump.20090520.092248.430562.phd)，而且本机的windows环境也没有可分配的那么大的内存来启动该软件，迫不得己，直接在生产环境上使用 heapAnalyzer  。文件成功打开，但是分析结果的可读性不强，非 WebLogic 专业人员估计看不太懂，大体的意思就是程序的某个地方加载了大量的对象。如下图所示：

后来使用jca分析javacore文件后，得到解决的办法。原来是因为 JDK 的问题，我们使用的是： J2RE 5.0 IBM J9 2.3 AIX ppc-32 build j9vmap3223-20070201 ，这个SR4的版本有个问题就是，限定了类加载器可加载的类数量，默认为 8192 ，如果超过此限制，就会抛出  OutOfMemory 的错误。郁闷啊，这事都赶上了。

分析javacore：

# cd /home

# ls

Test.class         guest              nmon               startVmstat.sh

Test.java          heapAnalyzer       ojdbc14.jar        startWebLogic.out

classes12.jar      jca                oracle             startWebLogic.sh

dumpfile           jdk64_15           start.log          stop.log

esaadmin           lost+found         start.sh           stop.sh

# cd jca

# ls

jca.properties.xml  license             tdv.cfg

jca37.jar           readme.zip

# java -Xmx1000m -jar jca37.jar

分析结果中，有Process ID，这个应该对应数据库服务器的执行进程，如果时间允许，我们可以通过topas可以看到该进程一直在执行。同时，分析结果还有Current Thread ，就是对应引起错误的应用服务器线程，使用该线程的名称作为关键字在log里搜索，我们可以发现引起错误的原因。

最后，jca会给出分析后的建议，Recommended -Xmxcl setting (only for IBM Java 5.0, up to and including Service Refresh 4 (build date:February 1st ,2007)) : 10,649 or greater。

注意此段描述：

NOTE: Only for Java 5.0 Service Refresh 4 (build date:February 1st, 2007) and older. When you use delegated class loaders, the JVM can create a large number of ClassLoader objects. On IBM Java 5.0 Service Refresh 4 and older, the number of class loaders that are permitted is limited to 8192 by default and an OutOfMemoryError exception is thrown when this limit is exceeded. Use the -Xmxcl parameter to increase the number of class loaders allowed to avoid this problem, for example to 25000, by setting -Xmxcl25000, until the problem is resolved.

郁闷了N久的问题得以解决，哈哈，心情大好。。。

【责编:Jumpinglee】