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

　　?

　　[core dump文件]來提取出java的線程堆棧，從而具體定位到具體的代碼;如有hs_err[pid].log以及core dump文件，則需要具體原因具體排查，這個比較麻煩，常見的可能會有上面的native oom(還有可能是32 bit機器，但java進程已經申請了超過3g的地址空間)，某些代碼jit編譯出問題了(可通過指定某些代碼不讓jit編譯來避免，但會影響性能：-XX:CompileCommand=exclude,類名/方法名)等。

　　在上面的招還無效時，可以嘗試dmesg看看是不是系統出了什么問題或系統主動殺掉過進程(例如內存超出限制等)，仍然沒找到原因的話需要去翻翻應用的日志，看看是不是能找到什么線索，因為有些時候是應用上主動退出了(對于應用主動退出的問題可通過btrace來排查是不是有主動調用過System.exit)。

　　硬件資源未到瓶頸，但吞吐量上不去

　　如在壓測時，出現這個現象時，首先可以看看施加壓力的一端是否真的壓力傳遞到了服務端。

　　如確認，則可以看看從server接到請求的地方開始，是不是處理線程池滿了(例如假設是tomcat，最大的線程數大小是不是已經到了)，如處理線程池滿了，可考慮擴大線程數大小，這個地方的排查其實有點麻煩，需要從接收請求的部分一直到純粹的業務處理部分，看看每步的瓶頸狀況，例如有些時候新建連接這種還有可能是由于系統參數的問題;

　　另外，需要看的就是鎖的狀況，可通過jstack -l來查看，也許是由于鎖競爭激烈造成，在鎖競爭激烈出現時，需要考慮使用j.u.c里的數據結構或使用無鎖算法等來優化。

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