javacore-heapdump分析示例

这里先说下分析前的准备工作：

1， 如果你的linux机器是没有界面操作的，那么你得在操作终端这边安装xmanager,否则可以跳过以下2-5。测试方法可以直接拍入oclock测试。

2， 以下2-5演示的是实现操作终端机器通过xmanager来获取界面操作支持的。

3， 你需要在服务端配置环境变量DISPLAY，本人客户端的ip地址是(10.192.33.200),所以在服务端的配置环境变量如以下示例：

[was6@ ~]$ echo $DISPLAY

10.192.33.200:0.0

4，你需要在终端操作机器上面安装xmanager，安装好了以后你可以看到如下启动快捷键，点击Xmanager –Passive,打开客户端监听：



 服务端运行oclock测试是否可以支持界面操作，如果正常可以看到如下：



5， 至此xmanager图形界面操作部分完成。

6， 首先把运行工具上传至服务器的目录。

6.1，下面列举的是分析javacore的必要jar包和配置文件，可以通过下载获取。

[was6@tools]$ ls jca*

jca396.jar  jca.properties.xml

6.2，下面列举的是分析heapdump的必要jar包，可以通过下载获取。

[was6@tools]$ ls ha404*

ha404.jar

7,  上传需要分析的javacore和heapdump文件到指定的分析目录，可以通过命令生成获取（http://blog.csdn.net/w5222949/article/details/8362990），或者是宕机的生产服务器上拿到。

[was6@tools]$ ls javacore*

javacore.20130115.150913.21636.0003.txt  javacore.20130115.150913.21636.0005.txt  javacore.20130115.150913.21636.0011.txt  javacore.20130115.150913.21636.0012.txt

[was6@tools]$ ls heap*

heapdump.20130115.150913.21636.0004.phd

7， 对应的分析服务器上面最后有对应于生产环境的was环境，尤其是jdk版本，这个很重要，IBM自身带的jdk才能加载足够大的内存来打开heapdump文件，如果用的是sun的jdk的话估计就有问题了。

8， 这里先运行下jca工具分析javacore。

[was6@tools]$ ~/IBM/WebSphere/AppServer/java/bin/java -Xmx10000M -jar jca396.jar

9， 可以看到终端机画面，然后打开需要分析的javacore文件。



10， 点击小红框圈住的明细比对：



这里上面的最主要查看的是里面带褐色小方框的线程，这个标识表示的是block的状态，线程阻塞，如果几个javacore里面显示的都是同一个线程bolck，那表示这个线程就存在阻塞情况，需要对右边对应的堆栈信息好好分析，结合java代码看看问题出现在那。

另一个就是分析绿色标识的，表示的是运行状态，如果某个通讯或者连接的运行状态过多，一旦有超时，也有可能导致线程池相关的一些问题，如下图：



11， 下面分析下heapdump文件

[was6@tools]$ ~/IBM/WebSphere/AppServer/java/bin/java -Xmx10000M -jar ha404.jar

12， 这里由于文件比较大打开会比较费时，需要耐心等待，这里也许会报错：



这个需要设置下服务器的字符集为GBK，重新打开dump文件。

如下操作：

[was6@tools]$ set|grep UTF-8

LANG=en_US.UTF-8

[was6@tools]$ LANG=en_ZH.GBK

[was6@tools]$ set|grep GBK

LANG=en_ZH.GBK

13， 字符集设置完成以后，再按上面的运行方式打开dump文件：





得到最后导致内存使用过高的都是hashmap的线程导致的。