《Java效能優化權威指南》的邊邊角（2）——理解JVM-系統鎖

本文摘自《Java效能優化權威指南》第6章“Java應用效能分析技巧”，這一章介紹了一些非常實用的應用效能分析技巧。本文節選的是正文裡穿插的一個小TIP。

---

Performance Analyzer中標記為JVM-System條目代表JVM內部消耗的時間。檢視鎖競爭資訊時，該條目代表消耗在JVM內部鎖上的時間或時間百分比。圖6-11中JVM-System所消耗的時間值有些大得出奇。

圖6-11 按獨佔指標排序的Java monitor物件/鎖持有時間

針對這一現象，我們會進一步解釋，逐步澄清大家心中的謎團。第5章曾經提到資料呈現格式的切換，無論是從使用者模式切換到專家模式或是機器模式，都會暴露（顯示）JVM內部的操作並統計到使用者模式下的JVM-System條目中。同樣要注意的是，切換到專家模式或機器模式時，Java monitor物件會以_lwp_mutex、__lwp_cond_wait或__lwp_park的條目顯示較高的競爭。圖6-13顯示了同樣的效能資料，不過這次在Performance Analyzer中是從使用者模式切換到專家模式。

圖6-13 使用者模式切換到專家模式

比較圖6-11和圖6-13表明JVM-System條目劃分為__lwp_condition_wait和__lwp_park操作。__lwp_condition_wait與__lwp_park之和與圖6-11中的JVM-System基本相等。看到這個結果，你的第一印象可能是JVM內部也存在鎖競爭。但選擇__lwp_cond_wait條目，之後選擇“Callers-Callees”選項卡，沿著呼叫棧分析，最後會發現鎖活動的源頭是__lwp_cond_wait，換句話說，這些鎖活動都與JVM-System條目有關，如圖6-14所示。

圖6-14中顯示的5個方法都為JVM的內部方法。我們注意到超過95%的歸因鎖時間消耗在GCTaskManager::get_task(unsigned)方法上。

圖6-14 逆溯__lwp_cond_wait的呼叫函式棧

這個方法是Java HotSpot虛擬機器垃圾收集子系統的一部分。垃圾收集器子系統工作時，會阻塞等待在一個工作佇列中。圖6-14列出的方法代表了Java HotSpot虛擬機器可能阻塞等待的各個工作佇列。例如，VMThread::loop()方法代表Java HotSpot虛擬機器阻塞在一個佇列中等待接受工作。你可以將VMThread想像成Java HotSpot虛擬機器的“核心執行緒”。CompilerBroker::compile_thread_loop()方法代表JIT編譯子系統阻塞等待另一個佇列，諸如此類。瞭解了這些之後，你應該可以接受為什麼我們要忽略使用者模式下JVM-System條目下的內容，不將其統計在熱點鎖競爭的範圍之內的原因了。

《Java效能優化權威指南》的邊邊角（3）——生存代和記憶體洩漏