常見的Java問題排查方法(3)

　　java.lang.OutOfMemoryError: PermGen Space，當碰到這個現象時，可以通過調整permgen size來試試，如果放大了一點后還是不斷的消耗，則可以通過btrace來跟蹤下裝載class的現象，腳本類似如下：

　　?

　　還有一種OOM是native OOM，就是物理內存被耗光，對于這種現象，解決起來會麻煩一些，從經驗上來說，Native OOM有很大概率是由于錯誤使用Deflater/Inflater造成的，所以在碰到這類現象時，可以先用btrace跟進下看看使用了Deflater/Inflater的有沒有顯式去調用end方法;另外一種常見的原因是使用Direct ByteBuffer的場景(例如NIO框架等)，如使用了Direct ByteBuffer的對象是比較長存活的，當其被轉到舊生代后，在fgc沒觸發前，其實其占用的JVM堆外內存是不會被釋放的，在這種情況下，可以做的一個嘗試是先強制執行幾次fgc(jmap -histo:live)，然后看看堆外內存的使用是不是下降了，如果下降了則說明是這個問題，對于這類問題，可以用的一個解決方案是增加一個啟動參數：-XX:MaxDirectMemorySize=500m來實現當Direct ByteBuffer使用到500m后主動觸發fgc來回收(到底設置成多大應用可以自己調整)。

　　如上面兩招都沒用，則需要掛上google perf-tools來跟蹤下看看到底是哪里在malloc，不過這里看到的是c堆棧上的東西，因此需要自己想辦法根據這個對應到java的代碼上去。

　　關于native OOM，這篇文章里有一些具體排查的case。

　　除了OOM外，還有可能會碰到GC頻繁的問題(有很多同學會問我，到底什么算頻繁，我覺得基本上如果每隔10s或更短時間就來一次cms gc或full gc才算得上吧)。

　　GC頻繁的現象出現時，如果發現cms gc或full gc后，存活的對象始終很多，這種情況下可以通過jmap -dump來獲取下內存dump文件，然后通過MAT/btrace來定位到具體的原因。

　　如cms gc或full gc頻繁，但觸發時old還有空閑空間，這種情況下有可能會是由于悲觀策略造成，具體可以看看這篇文章里的幾個cases，這種情況下通常的解決方法可以是調大old或減小young。

　　如不是悲觀策略造成的，對于采用cms gc的情況，還有可能是cms gc的碎片問題造成的，這種情況下可以通過強制執行下jmap -histo:live來觸發fgc，不過悲催的是cms gc的碎片問題是無解的，暫時只能靠強制觸發fgc等來避免在高峰期時出現問題。

　　對于cms gc而言，還有可能會出現promotion failed或concurrent mode failure問題，具體也可以看看上面那篇文章的cases。

　　Java進程crash或退出

　　Java進程crash或無故退出也是會碰到的現象，對于進程crash，默認情況下jdk會生成hs_err[pid].log的文件，core dump打開的話也會生成core dump文件，當進程crash發生時，可以先看看hs_err[pid].log，如沒找到此文件，但有core dump文件，有可能的原因是代碼中出現了無限遞歸或死循環，可通過jstack

原文轉自：http://bluedavy.me/?p=445