第6講-虛擬機性能監(jiān)控與故障處理工具之可視化工具ppt課件

1、第6講-虛擬機性能監(jiān)控與缺點處置工具之可視化工具軟件工程系 潘正軍主要內(nèi)容大綱JConsole：Java監(jiān)視與管理控制臺VisualVM：多合一缺點處置工具本節(jié)內(nèi)容引入JDK中除了提供大量的命令行工具外，還有兩個功能強大的可視化工具：JConsole和VisualVM，這兩個工具是JDK的正式成員，沒有被貼上“unsupported and experimental的標(biāo)簽。其中JConsole是在JDK 1.5時期就曾經(jīng)提供的虛擬機監(jiān)控工具，而VisualVM在JDK 1.6 Update7中才初次發(fā)布，如今曾經(jīng)成為SunOracle主力推進的多合一缺點處置工具 ，并且曾經(jīng)從JDK中分別出來成

2、為可以獨立開展的開源工程。為了防止本節(jié)的講解成為對軟件闡明文檔的簡單翻譯，預(yù)備了一些代碼樣例，都是特意編寫的“反面教材。后面將會運用這兩款工具去監(jiān)控、分析這幾段代碼存在的問題，算是本節(jié)簡單的實戰(zhàn)分析。讀者可以把在可視化工具察看到的數(shù)據(jù)、景象，與前面兩章中講解的實際知識相互印證。一、JConsole：Java監(jiān)視與管理控制臺JConsoleJava Monitoring and Management Console是一種基于JMX的可視化監(jiān)視、管理工具。它管理部分的功能是針對JMX MBean進展管理，由于MBean可以運用代碼、中間件效力器的管理控制臺或者一切符合JMX規(guī)范的軟件進展訪問，所以

3、本節(jié)將會著重引見JConsole監(jiān)視部分的功能。1.JConsole：啟動JConsole 1.啟動JConsole 經(jīng)過JDK/bin目錄下的“jconsole.exe啟動JConsole后，將自動搜索出本機運轉(zhuǎn)的一切虛擬機進程，不需求用戶本人再運用jps來查詢了，如下圖。雙擊選擇其中一個進程即可開場監(jiān)控，也可以運用下面的“遠程進程功能來銜接遠程效力器，對遠程虛擬機進展監(jiān)控。1.JConsole：啟動JConsole從前面的圖可以看出，筆者的機器如今運轉(zhuǎn)了Eclipse和JConsole。雙擊它進入JConsole主界面，可以看到主界面里共包括“概述、“內(nèi)存、“線程、“類、“VM摘要、“MB

4、ean6個頁簽，如以下圖所示。2.JConsole：內(nèi)存監(jiān)控內(nèi)存監(jiān)控“內(nèi)存頁簽相當(dāng)于可視化的jstat命令，用于監(jiān)視受搜集器管理的虛擬機內(nèi)存Java堆和永久代的變化趨勢。我們經(jīng)過運轉(zhuǎn)代碼清單4-8中的代碼來體驗一下它的監(jiān)視功能。運轉(zhuǎn)時設(shè)置的虛擬機參數(shù)為：-Xms100m -Xmx100m -XX：+UseSerialGC，這段代碼的作用是以64KB/50毫秒的速度往Java堆中填充數(shù)據(jù)，一共填充1000次，運用JConsole的“內(nèi)存頁簽進展監(jiān)視，察看曲線和柱狀指示圖的變化。3.JConsole：案例演示源碼3.JConsole：案例演示源碼3.JConsole：案例運轉(zhuǎn)可視化結(jié)果3.JCon

5、sole：案例運轉(zhuǎn)控制臺結(jié)果3.JConsole：案例運轉(zhuǎn)結(jié)果分析 程序運轉(zhuǎn)后，在“內(nèi)存頁簽中可以看到內(nèi)存池Eden區(qū)的運轉(zhuǎn)趨勢呈現(xiàn)折線狀，如上圖所示。而監(jiān)視范圍擴展至整個堆后，會發(fā)現(xiàn)曲線是一條向上增長的平滑曲線。并且從柱狀圖可以看出，在1000次循環(huán)執(zhí)行終了，運轉(zhuǎn)了System.gc后，雖然整個新生代Eden和Survivor區(qū)都根本被清空了，但是代表老年代的柱狀圖依然堅持峰值形狀，闡明被填充進堆中的數(shù)據(jù)在System.gc方法執(zhí)行之后依然存活。筆者的分析到此為止，現(xiàn)提兩個小問題供讀者思索一下，答案稍后給出。1虛擬機啟動參數(shù)只限制了Java堆為100MB，沒有指定-Xmn參數(shù)，能否從監(jiān)控圖中

6、估計出新生代有多大？2為何執(zhí)行了System.gc之后，上圖可視化結(jié)果中代表老年代的柱狀圖依然顯示峰值形狀，代碼需求如何調(diào)整才干讓System.gc回收掉填充到堆中的對象？3.JConsole：案例問題答案問題1答案：上圖可視化結(jié)果顯示Eden空間為27328KB，由于沒有設(shè)置-XX：SurvivorRadio參數(shù)，所以Eden與Survivor空間比例為默許值8:1，整個新生代空間大約為27328KB125%=34160KB。問題2答案：執(zhí)行完System.gc之后，空間未能回收是由于 ListOOMObjectlist對象依然存活，fillHeap方法依然沒有退出，因此list對象在Sys

7、tem.gc執(zhí)行時依然處于作用域之內(nèi) 。 假設(shè)把System.gc挪動到fillHeap方法外調(diào)用就可以回收掉全部內(nèi)存。4.JConsole：線程監(jiān)控 假設(shè)上面的“內(nèi)存頁簽相當(dāng)于可視化的jstat命令的話，“線程頁簽的功能相當(dāng)于可視化的jstack命令，遇到線程停頓時可以運用這個頁簽進展監(jiān)控分析。前面講解jstack命令的時候提到過線程長時間停頓的主要緣由主要有：等待外部資源數(shù)據(jù)庫銜接、網(wǎng)絡(luò)資源、設(shè)備資源等、死循環(huán)、鎖等待活鎖和死鎖。經(jīng)過下面的代碼清單分別演示一下這幾種情況。4.JConsole：線程監(jiān)控案例演示源碼4.JConsole：線程監(jiān)控案例演示源碼4.JConsole：線程監(jiān)控案例演

8、示源碼4.JConsole：線程監(jiān)控案例-main線程結(jié)果程序運轉(zhuǎn)后，首先在“線程頁簽中選擇main線程，如圖4-7所示。堆棧追蹤顯示BufferedReader在readBytes方法中等待System.in的鍵盤輸入，這時線程為Runnable形狀，Runnable形狀的線程會被分配運轉(zhuǎn)時間，但readBytes方法檢查到流沒有更新時會立刻歸還執(zhí)行令牌，這種等待只耗費很小的CPU資源。4.JConsole：線程監(jiān)控案例-testBusyThread線程結(jié)果接著監(jiān)控testBusyThread線程，如以下圖所示testBusyThread線程不斷在執(zhí)行空循環(huán)，從堆棧追蹤中看到不斷在Monit

9、oringTest.java代碼的23行停留，23行為：whiletrue。這時候線程為Runnable形狀，而且沒有歸還線程執(zhí)行令牌的動作，會在空循環(huán)上用盡全部執(zhí)行時間直到線程切換，這種等待會耗費較多的CPU資源。4.JConsole：線程監(jiān)控案例-testLockThread線程結(jié)果 以下圖顯示testLockThread線程在等待著lock對象的notify或notifyAll方法的出現(xiàn)，線程這時候處于WAITING形狀，在被喚醒前不會被分配執(zhí)行時間。5.JConsole：線程監(jiān)控案例-死鎖演示 testLockThread線程正在處于正常的活鎖等待，只需lock對象的notify或no

10、tifyAll方法被調(diào)用，這個線程便能激活以繼續(xù)執(zhí)行。下面代碼清單演示了一個無法再被激活的死鎖等待。5.JConsole：線程監(jiān)控案例-死鎖演示 testLockThread線程正在處于正常的活鎖等待，只需lock對象的notify或notifyAll方法被調(diào)用，這個線程便能激活以繼續(xù)執(zhí)行。下面代碼清單演示了一個無法再被激活的死鎖等待。5.JConsole：線程監(jiān)控案例-死鎖演示5.JConsole：線程監(jiān)控案例-死鎖案例分析這段代碼開了200個線程去分別計算1+2以及2+1的值，其實for循環(huán)是可省略的，兩個線程也能夠會導(dǎo)致死鎖，不過那樣概率太小，需求嘗試運轉(zhuǎn)很多次才干看到效果。普通的話，帶

11、for循環(huán)的版本最多運轉(zhuǎn)23次就會遇到線程死鎖，程序無法終了。呵斥死鎖的緣由是Integer.valueOf方法基于減少對象創(chuàng)建次數(shù)和節(jié)省內(nèi)存的思索，-128，127之間的數(shù)字會被緩存 ，當(dāng)valueOf方法傳入?yún)?shù)在這個范圍之內(nèi)，將直接前往緩存中的對象。也就是說，代碼中調(diào)用了200次Integer.valueOf方法一共就只前往了兩個不同的對象。假設(shè)在某個線程的兩個synchronized塊之間發(fā)生了一次線程切換，那就會出現(xiàn)線程A等著被線程B持有的Integer.valueOf1，線程B又等著被線程A持有的Integer.valueOf2，結(jié)果出現(xiàn)大家都跑不下去的情景。出現(xiàn)線程死鎖之后，點擊

12、JConsole線程面板的“檢測到死鎖按鈕，將出現(xiàn)一個新的“死鎖頁簽，如下圖。5.JConsole：線程監(jiān)控案例-死鎖運轉(zhuǎn)結(jié)果5.JConsole：線程監(jiān)控案例-死鎖結(jié)果分析 運轉(zhuǎn)結(jié)果圖中很明晰地顯示了線程Thread-199在等待一個被線程Thread-149持有Integer對象，而點擊線程Thread-149那么顯示它也在等待一個Integer對象，被線程Thread-89持有，這樣兩個線程就相互卡住，都不存在等到鎖釋放的希望了。二、VisualVM：多合一缺點處置工具VisualVMAll-in-One Java Troubleshooting Tool是到目前為止隨JDK發(fā)布的功能最

13、強大的運轉(zhuǎn)監(jiān)視和缺點處置程序，并且可以預(yù)見在未來一段時間內(nèi)都是官方主力開展的虛擬機缺點處置工具。官方在VisualVM的軟件闡明中寫上了“All-in-One的描畫字樣，預(yù)示著它除了運轉(zhuǎn)監(jiān)視、缺點處置外，還提供了很多其他方面的功能。如性能分析Profiling，VisualVM的性能分析功能甚至比起JProfiler、YourKit等專業(yè)且收費的Profiling工具都不會遜色多少，而且VisualVM的還有一個很大的優(yōu)點：不需求被監(jiān)視的程序基于特殊Agent運轉(zhuǎn)，因此它對運用程序的實踐性能的影響很小，使得它可以直接運用在消費環(huán)境中。這個優(yōu)點是JProfiler、YourKit等工具無法與之媲

14、美的。1.VisualVM：VisualVM啟動1.翻開cmd 運轉(zhuǎn)jvisualvm2.或者找到j(luò)dk的bin目錄，直接翻開jvisualvm2.VisualVM：VisualVM兼容范圍與插件安裝2.VisualVM：VisualVM兼容范圍與插件安裝2.VisualVM：VisualVM插件安裝運用VisualVM的自動安裝功能曾經(jīng)可以找到大多數(shù)所需的插件，在有網(wǎng)絡(luò)銜接的環(huán)境下，點擊“工具“插件菜單，彈出如下圖的插件頁簽，在頁簽的“可用插件中列舉了當(dāng)前版本VisualVM可以運用的插件，選中插件后在右邊窗口將顯示這個插件的根本信息，如開發(fā)者、版本、功能描畫等。2.VisualVM：Vis

15、ualVM插件安裝安裝完插件，選擇一個需求監(jiān)視的程序就進入程序的主界面了，如以下圖所示。根據(jù)讀者選擇安裝插件數(shù)量的不同，看到的頁簽?zāi)軌蚝鸵韵聢D中的有所不同。visualVM主界面例如圖如下：3.VisualVM運用：生成、閱讀堆轉(zhuǎn)儲快照VisualVM中“概述、“監(jiān)視、“線程、“MBeans的功能與前面引見的JConsole差別不大，讀者根據(jù)上文內(nèi)容類比運用即可，下面挑選幾個特征功能、插件進展引見。在VisualVM中生成dump文件有兩種方式，可以執(zhí)行以下任一操作：1.在“運用程序窗口中右鍵單擊運用程序節(jié)點，然后選擇“堆Dump。2.在“運用程序窗口中雙擊運用程序節(jié)點以翻開運用程序標(biāo)簽，然后

16、在“監(jiān)視標(biāo)簽中單擊“堆Dump。3.VisualVM運用：VisualVM堆Dump生成方式一3.VisualVM運用：VisualVM堆Dump生成方式二3.VisualVM運用：VisualVM堆Dump閱讀3.VisualVM運用：VisualVM堆Dump閱讀從堆頁簽中的“摘要面板可以看到運用程序dump時的運轉(zhuǎn)時參數(shù)、System.getProperties的內(nèi)容、線程堆棧等信息，“類面板那么是以類為統(tǒng)計口徑統(tǒng)計類的實例數(shù)量、容量信息，“實例面板不能直接運用，由于不能確定用戶想查看哪個類的實例，所以需求經(jīng)過“類面板進入，在“類中選擇一個關(guān)懷的類后雙擊鼠標(biāo)，即可在“實例里面看見此類中5

17、00個實例的詳細屬性信息?！癘QL控制臺面板中就是運轉(zhuǎn)OQL查詢語句的，同jhat中引見的OQL功能一樣。假設(shè)需求了解詳細OQL語法和運用，可參見本書附錄D的內(nèi)容。4.VisualVM：分析程序性能在Profiler頁簽中，VisualVM提供了程序運轉(zhuǎn)期間方法級的CPU執(zhí)行時間分析以及內(nèi)存分析，做Profiling分析一定會對程序運轉(zhuǎn)性能有比較大的影響，所以普通不在消費環(huán)境中運用這項功能。要開場分析，先選擇“CPU和“內(nèi)存按鈕中的一個，然后切換到運用程序中對程序進展操作，VisualVM會記錄到這段時間中運用程序執(zhí)行過的方法。假設(shè)是CPU分析，將會統(tǒng)計每個方法的執(zhí)行次數(shù)、執(zhí)行耗時；假設(shè)是內(nèi)存

18、分析，那么會統(tǒng)計每個方法關(guān)聯(lián)的對象數(shù)以及這些對象所占的空間。分析終了后，點擊“停頓按鈕終了監(jiān)控過程，如下圖。4.VisualVM：分析程序性能留意在JDK 1.5之后，在Client方式下的虛擬機參與并且自動開啟了類共享這是一個在多虛擬機進程中共享rt.jar中類數(shù)據(jù)以提高加載速度和節(jié)省內(nèi)存的優(yōu)化，而根據(jù)相關(guān)Bug報告的反映，VisualVM的Profiler功能能夠會由于類共享而導(dǎo)致被監(jiān)視的運用程序解體，所以讀者進展Profiling前，最好在被監(jiān)視程序中運用-Xshare：off參數(shù)來封鎖類共享優(yōu)化。圖中是對ThreadDeadLockTest 一段操作的錄制和分析結(jié)果，讀者分析本人的運用

19、程序時，可以根據(jù)實踐業(yè)務(wù)的復(fù)雜程度與方法的時間、調(diào)用次數(shù)做比較，找到最有優(yōu)化價值的方法。5.VisualVM：BTrace動態(tài)日志跟蹤BTrace 是一個很“有趣的VisualVM插件，本身也是可以獨立運轉(zhuǎn)的程序。它的作用是在不停頓目的程序運轉(zhuǎn)的前提下，經(jīng)過HotSpot虛擬機的HotSwap技術(shù) 4 動態(tài)參與本來并不存在的調(diào)試代碼。這項功能對實踐消費中的程序很有意義：經(jīng)常遇到程序出現(xiàn)問題，但排查錯誤的一些必要信息，譬如方法參數(shù)、前往值等，在開發(fā)時并沒有打印到日志之中，以致于不得不停掉效力，經(jīng)過調(diào)試增量來參與日志代碼以處理問題。當(dāng)遇到消費環(huán)境效力無法隨意停頓時，缺一兩句日志導(dǎo)致排錯進展不下去是一件非常郁