JVM Thread DUMP 
Windows 下用Ctrl-Break,Unix 下用 kill -3 <pid> 的命令讓JVM輸出 thread dump。
每隔幾秒 thread dump 一次，多做幾次，分析比較。

Thread Dump分析
1 找出這幾次Thread dump 文件中，有哪些 Java Thread 處于長時間等待狀態，很有可能就是問題之所在。
2 如果Java 線程等在某些不可能出錯的地方，如 java.lang.XXX/java.util.XXX對象的某個方法，則很有可能是因為出現了 OutOfMemoryError 異常，原因不外乎是JVM 堆內存過小或出現內存泄漏。
3 對于死鎖，最直接的表現就是至少兩個線程長時間等待相互持有的對象（每個線程所持有的對象和它當前等待的對象都可以從 dump 中看到）。
4 對于死循環，要輔助CPU占用率確定；如果發現CPU至少一顆使用率為100%，并且有線程長時間位于用戶代碼處，則很有可能是死循環引起。

多線程缺陷排查
對于Java死鎖問題很少出現，多線程訪問變量時沖突很常見。
一般出在多線程共享同一對象實例如全局Map，Servlet,Interceptor，或如多線程同時訪問某個靜態方法，而此靜態方法不巧又訪問另一個靜態變量。
這類問題自測發現不了，在并發壓力測試時才能發現。如果代碼的入口檢查做得好，多半會拋出一些莫名其妙的異常；要不然就會出現正常運行但數據庫記錄不對的情況。
對這種問題，并無多好的辦法解決，主要還是靠看異常堆棧和靜態代碼分析來解決。


內存泄漏排查
一般用商用輔助工具排查，但有可能出現在JVM heap dump 模式下，運行極度緩慢的情況。
笨笨曾經用過一個非常簡單的工具，效果不錯，它可以做到在不影響jvm 執行速度的情況下，做heap dump，然后對dump出的文件進行排序，檢查即可。