這裡先說下分析前的準備工作：
1， 如果你的linux機器是沒有界面操作的，那麼你得在操作終端這邊安裝xmanager,否則可以跳過以下2-5。測試方法可以直接拍入oclock測試。
2， 以下2-5示範的是實作操作終端機器通過xmanager來擷取界面操作支援的。
3， 你需要在服務端配置環境變量DISPLAY，本人用戶端的ip位址是(10.192.33.200),是以在服務端的配置環境變量如以下示例：
[[email protected] ~]$ echo $DISPLAY
10.192.33.200:0.0
4，你需要在終端操作機器上面安裝xmanager，安裝好了以後你可以看到如下啟動快捷鍵，點選Xmanager –Passive,打開用戶端監聽：
服務端運作oclock測試是否可以支援界面操作，如果正常可以看到如下：
5， 至此xmanager圖形界面操作部分完成。
6， 首先把運作工具上傳至伺服器的目錄。
6.1，下面列舉的是分析javacore的必要jar包和配置檔案，可以通過下載下傳擷取。
[[email protected]]$ ls jca*
jca396.jar jca.properties.xml
6.2，下面列舉的是分析heapdump的必要jar包，可以通過下載下傳擷取。
[[email protected]]$ ls ha404*
ha404.jar
7, 上傳需要分析的javacore和heapdump檔案到指定的分析目錄，可以通過指令生成擷取（http://blog.csdn.net/w5222949/article/details/8362990），或者是當機的生産伺服器上拿到。
[[email protected]]$ 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
[[email protected]]$ ls heap*
heapdump.20130115.150913.21636.0004.phd
7， 對應的分析伺服器上面最後有對應于生産環境的was環境，尤其是jdk版本，這個很重要，IBM自身帶的jdk才能加載足夠大的記憶體來打開heapdump檔案，如果用的是sun的jdk的話估計就有問題了。
8， 這裡先運作下jca工具分析javacore。
[[email protected]]$ ~/IBM/WebSphere/AppServer/java/bin/java -Xmx10000M -jar jca396.jar
9， 可以看到終端機畫面，然後打開需要分析的javacore檔案。
10， 點選小紅框圈住的明細比對：
這裡上面的最主要檢視的是裡面帶褐色小方框的線程，這個辨別表示的是block的狀态，線程阻塞，如果幾個javacore裡面顯示的都是同一個線程bolck，那表示這個線程就存在阻塞情況，需要對右邊對應的堆棧資訊好好分析，結合java代碼看看問題出現在那。
另一個就是分析綠色辨別的，表示的是運作狀态，如果某個通訊或者連接配接的運作狀态過多，一旦有逾時，也有可能導緻線程池相關的一些問題，如下圖：
11， 下面分析下heapdump檔案
[[email protected]]$ ~/IBM/WebSphere/AppServer/java/bin/java -Xmx10000M -jar ha404.jar
12， 這裡由于檔案比較大打開會比較費時，需要耐心等待，這裡也許會報錯：
這個需要設定下伺服器的字元集為GBK，重新打開dump檔案。
如下操作：
[[email protected]]$ set|grep UTF-8
LANG=en_US.UTF-8
[[email protected]]$ LANG=en_ZH.GBK
[[email protected]]$ set|grep GBK
LANG=en_ZH.GBK
13， 字元集設定完成以後，再按上面的運作方式打開dump檔案：
得到最後導緻記憶體使用過高的都是hashmap的線程導緻的。