當(dāng)應(yīng)用程序性能受到損害時，大多數(shù)開發(fā)人員都驚慌失措，這在情理之中。跟蹤 Java 應(yīng)用程序瓶頸來源一直以來都是很麻煩的，因?yàn)?Java 虛擬機(jī)有黑盒效應(yīng)，而且 Java 平臺分析工具一貫就有缺陷。

　　然而，隨著 Java 5 中 JConsole 的引入，一切都發(fā)生了改變。JConsole 是一個內(nèi)置 Java 性能分析器，可以從命令行或在 GUI shell 中運(yùn)行。它不是完美的，但是當(dāng)尖頭老板來問你關(guān)于性能的問題時，用它來應(yīng)對還是綽綽有余的——這比查詢 Papa Google 要好得多。

　　在本期 5 件事 系列中，我將向您展示 5 個方法，使您可以輕松地使用 JConsole（或者，它更高端的 “近親” VisualVM ）來監(jiān)控 Java 應(yīng)用程序性能和跟蹤 Java 中的代碼。

　　1. JDK 附帶分析器

　　許多開發(fā)人員沒有意識到從 Java 5 開始 JDK 中包含了一個分析器。JConsole（或者 Java 平臺最新版本，VisualVM）是一個內(nèi)置分析器，它同 Java 編譯器一樣容易啟動。如果是從命令行啟動，使 JDK 在 PATH 上，運(yùn)行 jconsole 即可。如果從 GUI shell 啟動，找到 JDK 安裝路徑，打開 bin 文件夾，雙擊 jconsole。

　　當(dāng)分析工具彈出時（取決于正在運(yùn)行的 Java 版本以及正在運(yùn)行的 Java 程序數(shù)量），可能會出現(xiàn)一個對話框，要求輸入一個進(jìn)程的 URL 來連接，也可能列出許多不同的本地 Java 進(jìn)程（有時包含 JConsole 進(jìn)程本身）來連接。

　　使用 JConsole 進(jìn)行工作

　　在 Java 5 中，Java 進(jìn)程并不是被設(shè)置為默認(rèn)分析的，而是通過一個命令行參數(shù) — -Dcom.sun.management.jmxremote — 在啟動時告訴 Java 5 VM 打開連接，以便分析器可以找到它們；當(dāng)進(jìn)程被 JConsole 撿起時，您只能雙擊它開始分析。

　　分析器有自己的開銷，因此最好的辦法就是花點(diǎn)時間來弄清是什么開銷。發(fā)現(xiàn) JConsole 開銷最簡單的辦法是，首先獨(dú)自運(yùn)行一個應(yīng)用程序，然后在分析器下運(yùn)行，并測量差異。（應(yīng)用程序不能太大或者太小；我最喜歡使用 JDK 附帶的 SwingSet2 樣本。）因此，我使用 -verbose:gc 嘗試運(yùn)行 SwingSet2 來查看垃圾收集清理，然后運(yùn)行同一個應(yīng)用程序并將 JConsole 分析器連接到它。當(dāng) JConsole 連接好了之后，一個穩(wěn)定的 GC 清理流出現(xiàn)，否則不會出現(xiàn)。這就是分析器的性能開銷。

　　2. 遠(yuǎn)程連接進(jìn)程

　　因?yàn)?Web 應(yīng)用程序分析工具假設(shè)通過一個套接字進(jìn)行連通性分析，您只需要進(jìn)行少許配置來設(shè)置 JConsole（或者是基于 JVMTI 的分析器，就這點(diǎn)而言），監(jiān)控/分析遠(yuǎn)程運(yùn)行的應(yīng)用程序。

　　如果 Tomcat 運(yùn)行在一個名為 “webserve” 的機(jī)器上，且 JVM 已經(jīng)啟動了 JMX 并監(jiān)聽端口 9004，從 JConsole（或者任何 JMX 客戶端）連接它需要一個 JMX URL “service:jmx:rmi:///jndi/rmi://webserver:9004/jmxrmi”。

　　基本上，要分析一個運(yùn)行在遠(yuǎn)程數(shù)據(jù)中心的應(yīng)用程序服務(wù)器，您所需要的僅僅是一個 JMX URL。更多關(guān)于使用 JMX 和 JConsole 遠(yuǎn)程監(jiān)控和管理的信息，參見 參考資料。）

　　3. 跟蹤統(tǒng)計(jì)

　　JConsole 有許多對收集統(tǒng)計(jì)數(shù)據(jù)有用的選項(xiàng)卡，包括：

　　Memory：在 JVM 垃圾收集器中針對各個堆跟蹤活動。

　　Threads：在目標(biāo) JVM 中檢查當(dāng)前線程活動。

　　Classes：觀察 VM 已加載類的總數(shù)。

　　這些選項(xiàng)卡（和相關(guān)的圖表）都是由每個 Java 5 及更高版本 VM 在 JMX 服務(wù)器上注冊的 JMX 對象提供的，是內(nèi)置到 JVM 的。一個給定 JVM 中可用 bean 的完整清單在 MBeans 選項(xiàng)卡上列出，包括一些元數(shù)據(jù)和一個有限的用戶界面來查看數(shù)據(jù)或執(zhí)行操作。（然而，注冊通知是在 JConsole 用戶界面之外。）

　　使用統(tǒng)計(jì)數(shù)據(jù)

　　假設(shè)一個 Tomcat 進(jìn)程死于 OutOfMemoryError。如果您想要弄清楚發(fā)生了什么，打開 JConsole，單擊 Classes 選項(xiàng)卡，過一段時間查看一次類計(jì)數(shù)。如果數(shù)量穩(wěn)定上升，您可以假設(shè)應(yīng)用程序服務(wù)器或者您的代碼某個地方有一個 ClassLoader 漏洞，不久之后將耗盡 PermGen 空間。如果需要更進(jìn)一步的確認(rèn)問題，請看 Memory 選項(xiàng)卡。

　　4. 為離線分析創(chuàng)建一個堆轉(zhuǎn)儲

　　生產(chǎn)環(huán)境中一切都在快速地進(jìn)行著，您可能沒有時間花費(fèi)在您的應(yīng)用程序分析器上，相反地，您可以為 Java 環(huán)境中的每個事件照一個快照保存下來過后再看。在 JConsole 中您也可以這樣做，在 VisualVM 中甚至?xí)龅酶谩?/p>

　　先找到 MBeans 選項(xiàng)卡，在其中打開 com.sun.management 節(jié)點(diǎn)，接著是 HotSpotDiagnostic 節(jié)點(diǎn)。現(xiàn)在，選擇 Operations，注意右邊面板中的 “dumpHeap” 按鈕。如果您在第一個（“字符串”）輸入框中向 dumpHeap 傳遞一個文件名來轉(zhuǎn)儲，它將為整個 JVM 堆照一個快照，并將其轉(zhuǎn)儲到那個文件。

　　稍后，您可以使用各種不同的商業(yè)分析器來分析文件，或者使用 VisualVM 分析快照。

　　5. JConsole 并不是高深莫測的

　　作為一個分析器實(shí)用工具，JConsole 是極好的，但是還有更好的工具。一些分析插件附帶分析器或者靈巧的用戶界面，默認(rèn)情況下比 JConsole 跟蹤更多的數(shù)據(jù)。

　　JConsole 真正吸引人的是整個程序是用 “普通舊式 Java ” 編寫的，這意味著任何 Java 開發(fā)人員都可以編寫這樣一個實(shí)用工具。事實(shí)上，JDK 其中甚至包括如何通過創(chuàng)建一個插件來定制 JConsole 的示例（參見 參考資料）。建立在 NetBeans 頂部的 VisualVM 進(jìn)一步延伸了插件概念。

　　如果 JConsole（或者 VisualVM，或者其他任何工具）不符合您的需求，或者不能跟蹤您想要跟蹤的，或者不能按照您的方式跟蹤，您可以編寫屬于自己的工具。如果您覺得 Java 代碼很麻煩，Groovy 或 JRuby 或很多其他 JVM 語言都可以幫助您更快完成。

　　您真正需要的是一個快速而粗糙（quick-and-dirty）的由 JVM 連接的命令行工具，可以以您想要的方式確切地跟蹤您感興趣的數(shù)據(jù)。

　　結(jié)束語

　　Java 性能監(jiān)控不止于 JConsole 或 VisualVM — 在 JDK 中隱藏著一整套工具，只是大多數(shù)開發(fā)人員并不知道。 本系列 中的下一篇文章將深入探究一些實(shí)驗(yàn)性的命令行工具，可以幫助您挖掘更多的您所需要的性能數(shù)據(jù)。因?yàn)檫@些工具通常只關(guān)注特殊數(shù)據(jù)，比一個完整的分析器更小更輕巧，所以它們的性能開銷要小一些。