java系統性能分析

netstat -ano | findstr 31900

 

注意最後是pid

堆棧的做用：

　線程死鎖分析
　輔助CPU太高分析
　線程資源不足分析
　性能瓶頸分析
　關鍵線程異常退出

Windows：在運行java的控制檯上按ctrl+break組合鍵 _ usefull?

wait() —— 會釋放監視鎖
sleep() —— 與鎖操做無關,繼續保持監視鎖

Found one Java-level deadlock:

 

第三步：預處理前兩個獲取的堆棧信息，去掉處於sleeping或waiting的狀態的線程。
例如以下線程處於wait或者sleep狀態，
這種線程是不消耗CPU的，所以這些線程能夠直接忽略掉，重點關注其它線程：

第五步：對比預處理後的1，2堆棧信息，找出處於busy狀態的線程，該類線程多是致使cpu高佔用率的可疑線程。
例如

同一個線程在第二個堆棧信息中仍處於活躍狀態

兩次打印堆棧該線程一直在運行，說明該線程已運行了5分鐘，請在代碼中檢查該線程是否屬於長時間運行線程？若是屬於暫態線程，如此長時間運行說明可能有死循環等致使的CPU太高

常見架構和設計問題：
不恰當的線程同步
不良的架構（同步／異步使用不當）
併發設計不當－資源搶佔致使的資源競爭, 鏈接池和線程池等應用不當等
效率低下的通訊方式
數據庫鏈接等競爭資源參數設置不當
內存泄漏/不恰當的虛擬機運行參數
緩慢的磁盤/網絡 IO

… …
常見編碼問題
String +，getByte()的不恰當使用：不少時侯可使用StringBuf
過大的同步範圍
ＳＱＬ語句設計不當

可以發現的性能問題：
(1) 資源爭用
(2) 鎖的粒度過大
(3) sleep的濫用

適用場合：
識別只有在高負載的時候纔出現的性能瓶頸。
多線程場合

不適用的場合：
單操做單線程下的代碼段耗時分析,如一次界面點擊，感受遲緩。

方法：　Java 命令行中增長 –verbose:gc 運行參數

能夠調節的JVM 垃圾回收參數
IBM JDK：主要參數： -Xconcurrentbackground –Xconcurrentlevel, 以及堆大小。
SUN，HP JDK 主要是 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction

.
常見的內存泄露
（1） 全局HashMap等容器，在對象不須要後沒有及時從容器中remove掉
特別是在拋出異常的時候，必定要確保remove方法執行到。

（2） Runnable對象new了就必須使用線程來Run等

 

?? 能夠按照以下思路分析GC輸出,可以初步比較準確地判斷系統是否存在內存泄漏:
?? (1) 首先要確保系統已經穩定運行(如初使化等已經完成等) (這個條件很重要)
?? (2) 而後取一個時間段的GC 輸出做爲分析數據，只分析FULL GC的行，以垃圾回收後的值爲分析對象
?? (3) 而後根據GC分析內存的使用狀況:
?????? A. 若是當前使用內存持續增加, 而垃圾回收後內存也持續增加, 有一直增加到Xmx設置的內存的趨勢,
那麼這個時侯基本上就能夠判定有內存泄漏問題了.
?????? B. 若是當前使用內存增加到一個值以後,又能回落, 達到一個動態平衡, 那麼就沒有內存泄漏的狀況.

 

（1） 只有FULL GC的行纔有分析價值
（2） 只須要檢查徹底垃圾後剩餘的內存值是否一直再增大。

OptimizeIt
snoop抓包工具/ethereal

 阿薩德發是否