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

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

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


內(nèi)存泄漏排查
一般用商用輔助工具排查，但有可能出現(xiàn)在JVM heap dump 模式下，運(yùn)行極度緩慢的情況。
笨笨曾經(jīng)用過(guò)一個(gè)非常簡(jiǎn)單的工具，效果不錯(cuò)，它可以做到在不影響jvm 執(zhí)行速度的情況下，做heap dump，然后對(duì)dump出的文件進(jìn)行排序，檢查即可。