不止一次，我們都萌發(fā)過(guò)想對(duì)運(yùn)行中程序的底層狀況一探究竟的念頭。產(chǎn)生這種需求的原因可能是運(yùn)行緩慢的服務(wù)、Java虛擬機(jī)（JVM）崩潰、掛起、死鎖、頻繁的JVM暫停、突然或持續(xù)的高CPU使用率、甚至于可怕的內(nèi)存溢出(OOME)。好消息是現(xiàn)在已有許多工具能幫你得到Java虛擬機(jī)運(yùn)行過(guò)程中的不同參數(shù)，這些信息有助于你了解其內(nèi)部狀況，從而診斷上述的各種情況。

在這篇文章中，我將介紹一些優(yōu)秀的開(kāi)源工具。其中一些是JVM自帶的，另一些則是第三方工具。我將從最簡(jiǎn)單的工具開(kāi)始介紹，逐漸過(guò)渡到一些比較復(fù)雜的工具。本文的目的是幫助你找到合適的調(diào)試診斷工具，這樣當(dāng)程序出現(xiàn)執(zhí)行異常、緩慢或根本不能執(zhí)行時(shí)，手頭隨時(shí)有可用的工具。

好了，讓我們出發(fā)。

相關(guān)廠商內(nèi)容

“雙11”背后淘寶、京東、一號(hào)店的技術(shù)支撐

率先在國(guó)內(nèi)落地的全球化云服務(wù)，深度了解Windows Azure

利用開(kāi)發(fā)測(cè)試云實(shí)現(xiàn)精益創(chuàng)業(yè)、快速迭代

Windows Azure自管理服務(wù)實(shí)現(xiàn)近乎零停機(jī)維護(hù)

Windows Azure專區(qū)上線，全面了解云服務(wù)

相關(guān)贊助商

Windows Azure專區(qū)上線，全面了解云服務(wù)精彩呈現(xiàn)！

如果程序出現(xiàn)不正常的高內(nèi)存負(fù)載、頻繁無(wú)響應(yīng)或內(nèi)存溢出，通常最好的分析切入點(diǎn)是查看內(nèi)存對(duì)象。幸好JVM內(nèi)置了工具“jmap”，讓它天生就能完成這種任務(wù)。

Jmap（借助JPM的一點(diǎn)幫助）

Oracle將jmap描述為一種“輸出進(jìn)程、核心文件、遠(yuǎn)程調(diào)試服務(wù)器的共享對(duì)象內(nèi)存映射和堆內(nèi)存細(xì)節(jié)”的程序。本文將使用jmap打印一張內(nèi)存統(tǒng)計(jì)圖。

為了運(yùn)行jmap，你需要知道被調(diào)試程序的PID（進(jìn)程標(biāo)識(shí)符）。得到PID的簡(jiǎn)單辦法是使用JVM提供的jps，它能列出機(jī)器上每一個(gè)JVM進(jìn)程及其PID。jps輸出結(jié)果如下圖：

圖1：jps命令的終端輸出

為了打印內(nèi)存統(tǒng)計(jì)圖，我們需要打開(kāi)jmap控制臺(tái)程序，并輸入程序的PID和“-histo:live”選項(xiàng)。如果不添加這個(gè)選項(xiàng)，jmap將完整導(dǎo)出該程序的堆內(nèi)存,這不是我們想要的結(jié)果。所以，如果想得到上圖中“eureka.Proxy”程序的內(nèi)存統(tǒng)計(jì)圖，我們應(yīng)該用如下命令來(lái)運(yùn)行jmap：

jmap –histo:live 45417

上述命令輸出如下：

（點(diǎn)擊圖片可以放大）

圖2：命令jmap -histo:live的輸出結(jié)果顯示了堆中現(xiàn)有對(duì)象的個(gè)數(shù)

結(jié)果中每行顯示了當(dāng)前堆中每種類類型的信息，包含被分配的實(shí)例個(gè)數(shù)及其消耗的字節(jié)數(shù)。

本例中，我請(qǐng)同事有意給程序增加了一處明顯的內(nèi)存泄露。請(qǐng)?zhí)貏e注意位于第8行的類，CelleData。將它與下圖顯示的4分鐘后截屏進(jìn)行比較：

（點(diǎn)擊圖片可以放大）

圖3：jmap的輸出表明CelleData類的對(duì)象數(shù)目增加了

請(qǐng)注意CelleData類現(xiàn)在已經(jīng)變?yōu)橄到y(tǒng)中第二多的類，短短4分鐘內(nèi)已經(jīng)增加了631,701個(gè)額外實(shí)例。等待約一小時(shí)后，我們觀察到如下結(jié)果：

（點(diǎn)擊圖片可以放大）

圖4：程序執(zhí)行1小時(shí)后jmap的輸出結(jié)果，顯示超過(guò)2千5百萬(wàn)個(gè)CelleData類實(shí)例

現(xiàn)在有超過(guò)2千5百萬(wàn)個(gè)CelleData類實(shí)例，占用了超過(guò)1GB內(nèi)存！我們可以確認(rèn)這是一個(gè)內(nèi)存泄露。

這類數(shù)據(jù)信息的好處是，不僅非常有用而且對(duì)于很大的JVM堆也能快速反饋結(jié)果。我曾經(jīng)試過(guò)檢測(cè)一個(gè)運(yùn)行頻繁并且占用17GB堆內(nèi)存的程序，使用jmap能夠在1分鐘內(nèi)生成程序的性能統(tǒng)計(jì)圖。

需要注意的是，jmap不是運(yùn)行分析工具，在生成統(tǒng)計(jì)圖時(shí)JVM可能會(huì)暫停，因此當(dāng)生成統(tǒng)計(jì)圖時(shí)需要確認(rèn)這種暫停對(duì)程序是可接受的。以我的經(jīng)驗(yàn)，通常在調(diào)試一個(gè)嚴(yán)重bug時(shí)需要生成這種統(tǒng)計(jì)圖，這種情況下，這些1分鐘的暫停對(duì)程序來(lái)說(shuō)是可接受的。這里，我們引出了下一個(gè)話題 - 半自動(dòng)的運(yùn)行分析工具VisualVM。

VisualVM

另一個(gè)包含于JVM中的工具是VisualVM，它的開(kāi)發(fā)者將它描述為“一種集成了多個(gè)JDK命令行工具的可視化工具，它能為您提供輕量級(jí)的運(yùn)行分析能力”。這樣看來(lái)，VisualVM是另一種你最有可能用到的事后分析工具，一般是錯(cuò)誤已出現(xiàn)或性能問(wèn)題已經(jīng)用傳統(tǒng)方法（客戶抱怨大多屬于此類）發(fā)現(xiàn)。

繼續(xù)之前的示例程序和它嚴(yán)重的內(nèi)存泄露問(wèn)題，在程序執(zhí)行30分鐘后，VisualVM幫我們繪制了如下圖表：

圖5：程序初始運(yùn)行的VisualVM 內(nèi)存圖

從這個(gè)圖表，我們可以清晰地看到截止到7:00pm，運(yùn)行僅僅10分鐘后，程序已經(jīng)消耗掉超過(guò)1GB的堆空間。又過(guò)了23分鐘，JVM已經(jīng)到了它啟動(dòng)參數(shù)–Xmx3g最大值，導(dǎo)致程序響應(yīng)緩慢，系統(tǒng)響應(yīng)緩慢（持續(xù)的垃圾回收）和數(shù)量驚人的內(nèi)存溢出錯(cuò)誤。

借助jmap，我們定位了這種內(nèi)存消耗攀升的原因。修復(fù)后，我們讓程序重新運(yùn)行于VisualVM的嚴(yán)格監(jiān)測(cè)之下，觀察到下面的情況：

圖6：修復(fù)內(nèi)存泄露問(wèn)題后的VisualVM內(nèi)存圖

如你所見(jiàn)，程序的內(nèi)存曲線（啟動(dòng)參數(shù)仍然為–Xmx3g）有了明顯改善。

除了內(nèi)存圖像工具，VisualVM還提供了一個(gè)采樣器和一個(gè)輕量級(jí)的剖析器（Profiler）。

VisualVM采樣器能周期采樣程序CPU和內(nèi)存的使用情況。得到的統(tǒng)計(jì)數(shù)據(jù)類似jmap的反饋，此外，你還可以通過(guò)采樣得到方法調(diào)用對(duì)CPU的占用情況。它讓你能快速了解周期采樣過(guò)程中的方法執(zhí)行次數(shù)：

（點(diǎn)擊圖片可以放大）

圖7：VisualVM方法執(zhí)行時(shí)間表

VisualVM剖析器無(wú)需對(duì)程序周期采樣就可以提供類似采樣器的反饋信息，它還可以收集程序在整個(gè)正常執(zhí)行過(guò)程中的統(tǒng)計(jì)數(shù)據(jù)（通過(guò)操縱程序源代碼的字節(jié)碼）。從剖析器得到的這種統(tǒng)計(jì)數(shù)據(jù)比從采樣器而來(lái)的更精確和實(shí)時(shí)。

（點(diǎn)擊圖片可以放大）

圖8：VisualVM剖析器的輸出

但是，你必須考慮的另一方面是該剖析器屬于一種“暴力”分析工具。它的檢測(cè)方法本質(zhì)上是重新定義程序執(zhí)行中的大多數(shù)類和方法，結(jié)果必然會(huì)明顯減緩程序執(zhí)行速度。例如，上述程序運(yùn)行部分的常規(guī)分析，大約要35秒。開(kāi)啟VisualVM的內(nèi)存剖析器后，導(dǎo)致程序完成相同分析要31分鐘。

我們需要清楚的是VisualVM并非功能齊全的剖析器。它無(wú)法在你的產(chǎn)品JVM上持續(xù)運(yùn)行，不會(huì)保存分析數(shù)據(jù)，無(wú)法指定閾值，也不會(huì)在超過(guò)閾值時(shí)發(fā)出警報(bào)。要想更多的了解功能齊全的剖析器的目標(biāo)。下面，讓我們看看BTrace，這個(gè)功能齊全的開(kāi)源java代理程序。

BTrace

想象一下，如果能收集JVM當(dāng)前的任何信息，那么你感興趣的信息有哪些？我猜想問(wèn)題列表會(huì)將因人而異，因情形而異。就個(gè)人來(lái)說(shuō)，我通常感興趣的是以下的問(wèn)題：

• 程序?qū)Χ选⒎嵌选⒂谰帽４鎱^(qū)（Permanent Generation），以及JVM包含的不同內(nèi)存池（新生對(duì)象區(qū)、長(zhǎng)期對(duì)象區(qū)、存活空間等）的內(nèi)存使用情況
• 當(dāng)前程序的線程數(shù)量，以及哪種類型線程正在被使用（單獨(dú)計(jì)數(shù)）
• JVM的CUP負(fù)載
• 系統(tǒng)平均負(fù)載/系統(tǒng)CPU使用總和
• 對(duì)程序中的某些類和方法，我需要了解它們被調(diào)用次數(shù)，各自平均執(zhí)行時(shí)間和整體平均時(shí)間
• 對(duì)SQL調(diào)用的調(diào)用計(jì)數(shù)及執(zhí)行次數(shù)
• 對(duì)硬盤和網(wǎng)絡(luò)操作的調(diào)用計(jì)數(shù)及執(zhí)行次數(shù)

利用BTrace可以采集到所有以上信息，你可以使用BTrace腳本定義需要采集的數(shù)據(jù)。方便的是，BTrace腳本就是普通Java類，包含一些特殊注解來(lái)定義BTrace在什么地方及如何跟蹤你的程序。BTrace腳本會(huì)被BTrace編譯器-btracec編譯成標(biāo)準(zhǔn)的.class文件。

BTrace腳本包含許多部分，正如下圖所示。如果需要了解下圖腳本的詳細(xì)內(nèi)容，請(qǐng)點(diǎn)擊該鏈接或訪問(wèn)BTrace項(xiàng)目網(wǎng)站。

由于BTrace僅僅是一個(gè)代理，記錄結(jié)果后，它的任務(wù)就算完成了。除了文本輸出，BTrace并不具備動(dòng)態(tài)展現(xiàn)被收集信息的功能。缺省情況下，BTrace腳本輸出結(jié)果將在btrace.class文件所在位置生成一個(gè)名為BTrace腳本名.class.btrace的text文件。

我們可以通過(guò)給BTrace設(shè)置一個(gè)額外參數(shù)，讓它按某時(shí)間間隔循環(huán)記錄日志。切記，它最多能在100個(gè)日志文件間循環(huán)，當(dāng)達(dá)到*.class.btrace.99，它將覆蓋*.class.btrace.00文件。若讓循環(huán)間隔在一個(gè)合理數(shù)字（如，每7.5秒）內(nèi)，你就有充足時(shí)間來(lái)處理這些輸出。只要在java代理的輸入?yún)?shù)中加上fileRollMilliseconds=7500，就可以實(shí)現(xiàn)日志循環(huán)。

BTrace一大缺點(diǎn)是它比較原始，難以定義它的輸出格式。你也許非常希望有一種更好的方式來(lái)處理BTrace的輸出和數(shù)據(jù)，比如可以用一種一致的圖形用戶界面來(lái)展示。你可能還需要比較不同時(shí)間點(diǎn)的數(shù)據(jù)和超出閾值能發(fā)送警告。一個(gè)新的開(kāi)源工具EurekaJ，就此應(yīng)運(yùn)而生。

（點(diǎn)擊圖片可以放大）

圖9：激活方法分析時(shí)必需的BTrace腳本

EurekaJ

我最初開(kāi)發(fā)EurekaJ是在2008年。那時(shí)，我正在尋找一種具有我需要功能的開(kāi)源剖析器，但沒(méi)有找到。于是，我開(kāi)始開(kāi)發(fā)自己的工具。開(kāi)發(fā)過(guò)程中，我涉獵了大量不同的技術(shù)并參考了許多架構(gòu)模型，直到EurekaJ第一個(gè)版本發(fā)布。你可以從項(xiàng)目網(wǎng)站上了解更多的EurekaJ歷史，查看源代碼或下載并試著安裝自己的版本。

EurekaJ提供了兩個(gè)主要應(yīng)用：

一個(gè)基于java的管理器程序，可以接收傳入的統(tǒng)計(jì)數(shù)據(jù)并一致地以可視化視圖展現(xiàn)出來(lái)

一個(gè)解析BTrace輸出的代理程序，將其轉(zhuǎn)化為JSON格式并輸入到EurekaJ管理程序的REST接口

EurekaJ接受兩種類型的輸入數(shù)據(jù)格式。EurekaJ代理期望BTrace腳本的輸出被格式化為逗號(hào)分隔的文件（這點(diǎn)在BTrace中可很容易做到），而EurekaJ管理程序期望它的輸入符合它的JSON REST接口格式。這意味著你能通過(guò)代理程序或直接經(jīng)由REST接口來(lái)傳遞度量數(shù)據(jù)。

借助EurekaJ管理程序，我們可以在一張圖上分組顯示多個(gè)統(tǒng)計(jì)數(shù)據(jù)、可以定義閾值和給接收者發(fā)出警報(bào)。我們還可以方便的查看收集到的實(shí)時(shí)數(shù)據(jù)或歷史數(shù)據(jù)。

所有收集到的數(shù)據(jù)排序成一種邏輯樹(shù)結(jié)構(gòu)，其結(jié)構(gòu)由BTrace腳本作者指定。我建議BTrace腳本的作者對(duì)相關(guān)統(tǒng)計(jì)數(shù)據(jù)分組，這樣，當(dāng)它們顯示在EurekaJ中時(shí)會(huì)更容易理解和觀察。例如，我個(gè)人喜歡對(duì)統(tǒng)計(jì)數(shù)據(jù)進(jìn)行如下的邏輯分組：

圖10：EurekaJ演示程序的統(tǒng)計(jì)分組示例

圖例

一種需要采集的重要信息是程序運(yùn)行時(shí)的平均系統(tǒng)負(fù)載。要是你正面對(duì)一個(gè)運(yùn)行緩慢的程序，那么缺陷可能并不在程序自身，而是隱藏到應(yīng)用駐留的主機(jī)某處。我曾經(jīng)在調(diào)試運(yùn)行緩慢的應(yīng)用時(shí)偶爾發(fā)現(xiàn)，真正的根源是病毒掃描程序。如果不進(jìn)行測(cè)量分析，這種事情會(huì)很難被發(fā)現(xiàn)。考慮到這一點(diǎn)，我們需要能夠在一張圖中顯示系統(tǒng)平均負(fù)載和進(jìn)程加載后產(chǎn)生的負(fù)載。下圖顯示了一個(gè)運(yùn)行EurekaJ 演示程序的Amazon EC2虛擬服務(wù)器的2小時(shí)平均負(fù)載（該應(yīng)用登錄的用戶名和密碼都是‘user’）。

（點(diǎn)擊圖片可以放大）

圖11：顯示平均系統(tǒng)負(fù)載的EurekaJ圖表

圖中，黃色和紅色的線條表示警戒閾值。一旦圖形超過(guò)黃線的次數(shù)超過(guò)預(yù)設(shè)的最小警戒次數(shù)時(shí)，則測(cè)量結(jié)果到達(dá)“警告”狀態(tài)。類似，若突破紅線，測(cè)量結(jié)果就到達(dá)“危險(xiǎn)”或“錯(cuò)誤”狀態(tài)。每當(dāng)發(fā)生狀態(tài)轉(zhuǎn)換，EurekaJ都會(huì)發(fā)送一封郵件給之前注冊(cè)的收件人。

在上面的情形中，好像有周期性的事件每20分鐘發(fā)生一次，從平均負(fù)載圖上顯示的波峰可以看到這一點(diǎn)。首先你要確定的是這個(gè)波峰確實(shí)由你的程序產(chǎn)生，而非其他原因。我們也可以通過(guò)測(cè)量進(jìn)程的CPU負(fù)載來(lái)確認(rèn)這點(diǎn)。在EurekaJ樹(shù)菜單中，選擇兩個(gè)測(cè)量點(diǎn)后，兩個(gè)圖表結(jié)果會(huì)一起快速成像顯示出來(lái)，其中一個(gè)位于另一個(gè)下面。

（點(diǎn)擊圖片可以放大）

圖12：同時(shí)顯示多個(gè)圖表

在上面的例子中，我們清楚地看到進(jìn)程CUP占用和系統(tǒng)負(fù)載存在必然的聯(lián)系。

許多應(yīng)用需要在程序無(wú)響應(yīng)或不可用時(shí)及時(shí)發(fā)出警告。下圖是一個(gè)Confluence（Atlassian的企業(yè)級(jí)Wiki軟件）的例子。這個(gè)例子中，程序內(nèi)存占用快速上升，直到產(chǎn)生程序內(nèi)存溢出。這時(shí)，Confluence無(wú)法處理接收到的請(qǐng)求，同時(shí)日志文件記錄了各種奇怪的錯(cuò)誤。

你可能希望當(dāng)程序運(yùn)行導(dǎo)致內(nèi)存溢出時(shí)，程序能立刻拋出一個(gè)OOME（內(nèi)存溢出錯(cuò)誤），然而，事實(shí)上JVM不會(huì)拋出OOME直到它發(fā)覺(jué)垃圾回收過(guò)于緩慢。結(jié)果，程序沒(méi)有完全崩潰，又過(guò)了2小時(shí)，Java仍然沒(méi)有拋出OutOfMemoryError，甚至兩小時(shí)后程序依然在“運(yùn)行”（意味著JVM進(jìn)程仍然在運(yùn)行）。顯然，這時(shí)任何進(jìn)程監(jiān)測(cè)工具都不能發(fā)現(xiàn)程序已經(jīng)“停止”。

（點(diǎn)擊圖片可以放大）

圖13：EurekaJ堆圖顯示內(nèi)存溢出錯(cuò)誤的一種可能情形

注意最后幾個(gè)小時(shí)的執(zhí)行情況，圖表揭示了下面的度量指標(biāo)。

（點(diǎn)擊圖片可以放大）

圖14：前面圖表放大后的效果

EurekaJ使我們可以設(shè)置程序的堆內(nèi)存警告，個(gè)人建議最好如此。若程序持續(xù)占用堆內(nèi)存超過(guò)95%-98%（取決于堆的大小），幾乎可以肯定，程序存在內(nèi)存問(wèn)題，要么用–Xmx參數(shù)為程序分配更多的堆，要么優(yōu)化程序使其使用更少內(nèi)存。同時(shí)，EurekaJ未來(lái)版本計(jì)劃增加統(tǒng)計(jì)數(shù)據(jù)不足的警報(bào)。

最后的圖表示例展示了一個(gè)包含4個(gè)不同程序內(nèi)存使用的圖表組。這種類型的圖表組可方便用來(lái)比較一個(gè)程序不同部分的、或甚至不同程序之間、服務(wù)器之間的數(shù)據(jù)。下圖的這4個(gè)程序有不同的內(nèi)存需求和內(nèi)存占用模式。

如下圖示，不同程序有不同的內(nèi)存曲線。這些曲線非常依賴一些實(shí)際情況，比如使用的架構(gòu)、緩存數(shù)量、用戶數(shù)、程序負(fù)載等。我希望通過(guò)下圖說(shuō)明你需要掌握程序在正常和高負(fù)載下執(zhí)行情況的重要性，因?yàn)檫@將直接關(guān)系到如何定義報(bào)警閾值。

（點(diǎn)擊圖片可以放大）

圖15：EurekaJ圖組會(huì)將圖像彼此疊加在一起

注意性能干擾 – 讓非熱點(diǎn)區(qū)不受影響！

你使用的每一種測(cè)量方法似乎都會(huì)引起系統(tǒng)性能干擾。一些數(shù)據(jù)的測(cè)量可以被認(rèn)為“無(wú)干擾”（或“忽略不計(jì)”），然而另外一些數(shù)據(jù)的測(cè)量可稱得上代價(jià)昂貴。非常重要的一點(diǎn)是，要知道你需要BTrace測(cè)量什么。因此，你要將這種分析工具對(duì)程序的性能干擾減少到最小。關(guān)于這點(diǎn)，請(qǐng)參考下面的3條原則：

• 基于“采樣”的度量通常可被認(rèn)為“無(wú)影響”。采樣CPU負(fù)載、進(jìn)程CPU負(fù)載、內(nèi)存使用和每5-10秒的線程計(jì)數(shù)，其帶來(lái)的額外一兩個(gè)毫秒的影響可被忽略。在我看來(lái)，你應(yīng)該經(jīng)常收集這類統(tǒng)計(jì)數(shù)據(jù)，它們對(duì)你來(lái)說(shuō)不會(huì)有什么損耗。
• 對(duì)長(zhǎng)時(shí)間運(yùn)行的任務(wù)的測(cè)量也可被認(rèn)為“無(wú)影響”。通常，它僅會(huì)對(duì)每個(gè)被測(cè)量方法帶來(lái)1700-2500納秒的影響。如果你正測(cè)量這些對(duì)象的執(zhí)行時(shí)間：SQL查詢、網(wǎng)絡(luò)流量、硬盤讀寫或一個(gè)預(yù)期范圍在40毫秒（磁盤存取）到1秒（Servlet處理）之間的Servlet處理過(guò)程，那么對(duì)這些對(duì)象每個(gè)增加額外的2500納秒左右的時(shí)間也是可接受的。
• 絕對(duì)不要對(duì)循環(huán)內(nèi)執(zhí)行的方法進(jìn)行測(cè)量

尋找程序熱點(diǎn)區(qū)的一個(gè)通用規(guī)則是不要影響非熱點(diǎn)區(qū)域。例如，考慮下面的類：

（點(diǎn)擊圖片可以放大）

圖16：需要測(cè)量的簡(jiǎn)單的數(shù)據(jù)訪問(wèn)接口類

第5行的SQL執(zhí)行時(shí)間可能使readStatFromDatabase方法可能成為一個(gè)熱點(diǎn)。當(dāng)查詢返回相當(dāng)多的數(shù)據(jù)行時(shí)，它無(wú)疑會(huì)成為一個(gè)熱點(diǎn)，這對(duì)13行（程序和數(shù)據(jù)庫(kù)服務(wù)器之間的網(wǎng)絡(luò)流量）和14-16行（結(jié)果集中每行所需處理）會(huì)造成負(fù)面影響。如果從數(shù)據(jù)庫(kù)返回結(jié)果時(shí)間過(guò)長(zhǎng)，該方法也會(huì)成為一個(gè)熱點(diǎn)（在13行）。

方法buildNewStat就其本身來(lái)說(shuō)似乎絕不會(huì)成為一個(gè)熱點(diǎn)。即使被多次執(zhí)行，每次調(diào)用都會(huì)在幾納秒內(nèi)完成。另一方面，若給每次調(diào)用增加了2500納秒的測(cè)量采集干擾，則無(wú)論SQL何時(shí)被執(zhí)行，都勢(shì)必會(huì)讓該方法看起來(lái)像個(gè)熱點(diǎn)。因此，我們要避免測(cè)量它。

（點(diǎn)擊圖片可以放大）

圖17：顯示上面類哪些部分可以被測(cè)量，哪些需要避免

建立完整的運(yùn)行分析

使用EurekaJ建立一個(gè)完整的運(yùn)行分析，需要以下幾個(gè)主要部分：

• 準(zhǔn)備需要監(jiān)測(cè)/操縱的程序
• BTrace - java代理
• 告知BTrace如何測(cè)量的BTrace腳本
• 存儲(chǔ)BTrace輸出的文件系統(tǒng)
• 將BTrace輸出傳輸?shù)紼urekaJ管理器的EurekaJ代理
• 安裝好的EurekaJ管理器（本地安裝或可通過(guò)互聯(lián)網(wǎng)訪問(wèn)的遠(yuǎn)程安裝）

（點(diǎn)擊圖片可以放大）

圖18：使用本文所描述工具對(duì)程序進(jìn)行運(yùn)行分析的概覽圖

關(guān)于這些產(chǎn)品的完整安裝手冊(cè)，請(qǐng)?jiān)L問(wèn)EurekaJ項(xiàng)目網(wǎng)站。

總結(jié)

這篇文章給我們介紹了一些用于程序運(yùn)行分析的開(kāi)源工具，它們不僅能幫我們完成對(duì)運(yùn)行中JVM的深度分析，而且可以幫助我們對(duì)開(kāi)發(fā)、測(cè)試和程序部署進(jìn)行多方位的持續(xù)監(jiān)測(cè)。

希望你已經(jīng)開(kāi)始了解不斷收集度量信息的好處和超過(guò)閾值后及時(shí)報(bào)警能力的重要性。

非常感謝！

總結(jié)

以上是生活随笔為你收集整理的借助开源工具高效完成Java应用的运行分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。