Posted on 2005-12-07 17:07
笨笨 閱讀(7883)
評論(2) 編輯 收藏 所屬分類:
Java
Java 多線程或內(nèi)存泄漏缺陷排查的一些經(jīng)驗
JVM Thread DUMP 基本功
Windows 下用Ctrl-Break,Unix 下用 kill -3 <pid> 的命令讓JVM輸出 thread dump。
每隔幾秒 thread dump 一次，多做幾次，分析比較。
Thread Dump分析的一些經(jīng)驗
1 找出這幾次Thread dump 文件中，有哪些 Java Thread 處于長時間等待狀態(tài)，很有可能就是問題之所在。
2 如果Java 線程等在某些不可能出錯的地方，如 java.lang.XXX/java.util.XXX對象的某個方法，則很有可能是因為出現(xiàn)了 OutOfMemoryError 異常，原因不外乎是JVM 堆內(nèi)存過小或出現(xiàn)內(nèi)存泄漏。
3 對于死鎖，最直接的表現(xiàn)就是至少兩個線程長時間等待相互持有的對象（每個線程所持有的對象和它當(dāng)前等待的對象都可以從 dump 中看到）。
4 對于死循環(huán)，要輔助CPU占用率確定；如果發(fā)現(xiàn)CPU至少一顆使用率為100%，并且有線程長時間位于用戶代碼處，則很有可能是死循環(huán)引起。
多線程缺陷排查
對于Java死鎖問題很少出現(xiàn)，多線程訪問變量時沖突很常見。
一般出在多線程共享同一對象實例如全局Map，Servlet,Interceptor，或如多線程同時訪問某個靜態(tài)方法，而此靜態(tài)方法不巧又訪問另一個靜態(tài)變量。
這類問題自測發(fā)現(xiàn)不了，在并發(fā)壓力測試時才能發(fā)現(xiàn)。如果代碼的入口檢查做得好，多半會拋出一些莫名其妙的異常；要不然就會出現(xiàn)正常運行但數(shù)據(jù)庫記錄不對的情況。
對這種問題，并無多好的辦法解決，主要還是靠看異常堆棧和靜態(tài)代碼分析來解決。
內(nèi)存泄漏排查
一般用商用輔助工具排查，但有可能出現(xiàn)在JVM heap dump 模式下，運行極度緩慢的情況。
笨笨曾經(jīng)用過一個非常簡單的工具，效果不錯，它可以做到在不影響jvm 執(zhí)行速度的情況下，做heap dump，然后對dump出的文件進行排序，檢查即可。
heapprofile(http://www.virtualmachine.de/)