使用類似 Memory Analyzer的工具生成并分析JVM heap dump快照。
#FormatImgID_11#
Java并發(fā)性
Java并發(fā)性可以定義為程序同時執(zhí)行多個任務的能力。對于大型的Java EE系統(tǒng)，這意味著執(zhí)行多個用戶的業(yè)務功能的同時，實現(xiàn)最佳的吞吐量和性能的能力。
無論是硬件能力還是JVM穩(wěn)定狀況，Java并發(fā)性問題可能引起程序的癱瘓，嚴重影響程序的整體性能和可用性。
Thread Lock Contention
當您評估Java應用程序的并發(fā)線程的穩(wěn)定狀況時，你會經(jīng)常遇到Thread lock contention的問題，這是目前最常見的Java并發(fā)問題。
例如：Thread lock contention會觸發(fā)non-stop，它會嘗試將一個缺少Java類(ClassNotFoundException的)加載到默認的JDK 1.7 ClassLoader。
如果您在成熟的技術環(huán)境中遇見像Thread Dump analysis這樣的問題，我們強烈建議您積極面對它。這個問題的根源通常不同于之前的Java synchronization to legitimate IO blocking或者其他的non-thread safe calls。Lock contention問題往往是另一個問題的“癥狀”。
Java-level Deadlocks
真正的Java-level deadlocks是不太常見的，它同樣可以極大程度地影響應用程序的性能和穩(wěn)定性。當遇到兩個或多個線程永遠阻塞的時候，就會觸發(fā)這樣的問題。這種情況不同于其他常見的那種“day-to-day”線程問題，例如 lock contention、threads waiting alt="物聯(lián)網(wǎng)" width="400" height="245" />
Oracle HotSpot 和IBM JVM為大多數(shù)的deadlock detectors情況提供了解決方案，幫助您快速找出造成這種狀況的罪魁禍首的線程。遇到類似lock contention troubleshooting的問題，建議從諸如線程轉(zhuǎn)儲分析為出發(fā)點來解決該問題。
一旦找到造成問題的代碼根源，解決方案涉及l(fā)ock-ordering條件尋址和來自JDK其他可用的并發(fā)編程技術，如java.util.concurrent.locks.ReentrantLock，提供了諸如tryLock()的方法。這種方法給予開發(fā)人員更大的靈活性，也為防止deadlock和thread lock “starvation”提供了更多方式。
Clock Time和CPU Burn
在進行JVM調(diào)優(yōu)的同時，也有必要檢查應用程序的行為，更確切地說是最高clock time和CPU burn的貢獻者。
當Java垃圾回收和線程并發(fā)不再是壓力點，深入到你的應用程序代碼的執(zhí)行模式，并專注于頂級響應時間貢獻者(也叫作clock time)是很重要的。檢查應用程序代碼的消CPU耗和Java 線程(CPU burn)也同樣至關重要。CPU使用率較高(>75%)是不正常的(良好的物理資源的利用率)。因為這往往意味著效率低下和容量問題。對于大型的Java EE企業(yè)應用，保持安全的CPU緩沖區(qū)是必要的，以應對突發(fā)的負載沖擊情況。
摒棄那些傳統(tǒng)的跟蹤方法，如在代碼中加入響應時間“日志”。Java剖析工具和APM解決方案恰恰可以幫助您分析這類型的問題。這種方式更加高效、可靠。對于Java生產(chǎn)環(huán)境缺乏一個強大的APM解決方案。您仍然可以依賴諸如Java VisualVM的工具，通過多個快照進行thread dump分析，并使用OS CPU分析每個線程。
最后的建議是，不要妄圖同時解決所有的問題。列出排在最前面的5個clock time和CPU burn問題，然后尋找解決方案。
Application預算
其他關于Java應用程序性能的重要方面是穩(wěn)定性和可靠性。在有著99.9%典型可用目標的SLA umbrella下，穩(wěn)定和可靠對于程序的操作尤為重要。這些系統(tǒng)應該具有高容錯級別，并對應用和資源進行嚴格的預算，以防止發(fā)生多米諾效應。用這種方法可以防止一些這樣的情況，例如，一個業(yè)務流程使用所有可用的物理，中間件或JVM資源。
Hot Spots
