Java 內存堆棧分析，是我們在分析線上問題常用的手段。線上會遇到一些問題從日誌上無法分析的疑難問題。我們可以分析一些JVM內存，來看看問題到底出在哪裏了。在生產環境上一般不允許我們使用一些例如JMX或是JProfile(我也是剛剛瞭解到)這類的工具。這類工具通常使用在開發測試中解決性能瓶頸和理解問題用到。今天我介紹一下我用過的一些工具，他們都不是在線分析工具，都需要先收集JVM內存消息導入到文件中，然後我們再分析。我主要介紹一下用法，因爲分析的過程，是根據現網現象結合dump消息綜合思考的過程，這個我也再學習中，目前沒有一個系統的概念。
分析棧內存（stack）：jstack/kill -3 + IBM Thread and Monitor Dump Analyzer for Java （點擊下載）
分析堆內存(heap)： jmap + jhat。
我們通常是從棧信息入手來進行分析。下面我詳細介紹一下他們具體是使用方法：jstack是java自帶的一個分析工具，我們可以在java的安裝目錄找到：$JAVA_HOME/bin 中找到。kill -3和jstack效果一樣，只不過他會將棧信息打印到tomcat的catalina.out 文件中去。
使用方法在命令的usage裏面的介紹非常明確了，我就不去介紹啦。我這裏舉個例子：
- 我們先查詢一下java進程，因爲jstack要根據java進程號來打印stack信息：
javaps -ef|grep java -
找到進程pid之後，將stack信息記錄到stack.out文件中： jstack -l 31155 > stack.out
-
我們再用IBM Thread and Monitor Dump Analyzer for Java這個工具來分析。這裏可以清晰的看到線程數狀態統計，和每個線程的狀態。
具體的分析方法我們可以看看這篇文章。http://jameswxx.iteye.com/blog/1041173
jmap + jhat。這個兩個命令也是java自帶的，在$JAVA_HOME/bin中你也可以找到他們兩個。基本使用方法是：
-
先打印heap信息：jmap -dump:live,format=b,file=heap.bin 注意這個文件一般會很大。要看應用服務。
-
使用jhat分析：jhat -J-mx1024M heap.bin 這個命令會啓動一個Server服務，默認的端口是7000。其中-mx是設置最大使用多少內存，如果你要分析的heap文件很大的話，這個值要配置很大，不然會包內存異常的錯誤。
我們主要看這個兩個部分：Show instance counts for all classes (excluding platform)Show heap histogram平臺外的對象信息，和對象heap樹狀圖，這個樹狀圖包括所有對象的個數已經佔有大小，佔用的大小是bytes。
我在以前處理現網問題是時候，用到過一次。我們在巡檢的時候發現，有個服務(Tomcat服務)在一個月前就不上報自己的狀態給管理臺了，我讓一線維護查詢這個Tomcat是不是就沒啓動：
ps -ef|grep java
根據一線的反饋，這個Tomcat的進程還在，應該是啓動的，但是爲什麼不上報自己的狀態呢？我們又讓一線反饋一下這個服務的監控頁面（能查詢JDBC連接字符串，打印Spring Bean，打印一些和數據庫同步的業務參數）是否顯示正常，結果發現這個頁面一直無法打開，瀏覽器一直處於緩衝的那種狀態。這下90%可以確定Tomcat僵死了。
分析一下問題根因。先讓一線反饋jstack消息，我們沒有發現什麼問題。後來又讓他們反饋jmap消息，這個文件打印出來會很大（900M~2G）根據我們配置的JVM內存參數來定的，不過好的是壓縮比很大，RAR壓縮一下就幾兆了。所以jmap命令會非常消耗服務器IO性能，一般不要在業務高峯用。我們用jhat分析map打印的heap消息發現，有個平臺外的HTTP連接實例被創建了2百多萬個，一直沒有被釋放掉。這個應該就是問題的原因啦。經過定位發現根因，應該是一線在開局實施的時候，修改了Tomcat裏面web.xml中的session-timeout參數，將他改成了555555，也就是說session超時時間是555555分鐘。