距離上次介紹Jconsole已經時隔兩週了,這期間因爲工做中要用go來作一個新項目,因此精力都用在入門go上了,不過發現go語言用起來真的挺不錯的,比python感受還好點,你們沒事能夠了解下。
言歸正傳,VisualVM和Jconsole同是圖形化的jvm監控和分析工具,二者在一些基本功能上的使用大同小異,好比內存、線程、jvm環境參數等,可是相對而言VisualVM的功能要稍強於Jconsole,至關於增強版的Jconsole。同是visualVM的一些高級功能是經過安裝插件來拓展,因此更能因需定製。先看下起始頁:java
因爲VisualVM官方已經提供了很完善的使用文檔(一樣是親兒子,Jconsole的文檔就有點寒摻了,並且VisualVM有一部分居然有中文版),因此這裏就不作詳細介紹,只重點看一下的VisualVM兩個方面:python
這個其實沒什麼好介紹的,基本上看圖就明白了。插件能夠進行手工安裝,能夠再插件中心下載*.nbm,在選項「工具—插件—已下載」中選擇安裝,可是做爲一款便捷的圖形化工具,這樣作無心有點費事,其實在"工具—插件"中咱們能夠直接管理已安裝插件,並選擇下載安裝須要的新插件。看圖:
linux
能夠看到VisualVM提供了很豐富的插件,咱們只要選中須要插件,點擊安裝便可(固然,前提是你待聯網了)。好了,就是這麼簡單。 git
這裏使用我寫的一個小的web服務器作示例,介紹和代碼見博客(因爲以後更新,可能github與介紹有必定出入),可運行包見下載(目前win下可直接經過bin下start.bat啓動,因爲start.sh是拷以前一個項目的,暫時有些問題,因此linux下就直接java命令啓動吧),成功啓動後以下: github
而後經過VisualVM打開對應進程,能夠經過概述、監視、線程、visaul GC查看程序當前jvm參數、內存、cpu、線程和gc的各項狀況。咱們這裏重點關注一下VisualVM提供的性能分析工具Profilter,咱們直接打開該選項卡,點擊CPU將開始收集信息並分析。結果你可能發現當時只有ServerTimerTask.run()一項(也可能會有不少項,這主要因爲是實時分析,看你打開時程序在作什麼操做,是個web服務器,因此可能有個定時輪詢的任務一直在執行,因此至少會有這一項,並且包路徑sun.net.httpserver也可能看出這點),爲了儘快看到更多調用信息,咱們直接在瀏覽器打開http://localhost:8888/json/show.do (這是測試項目中測試json數據的路徑),會發現出現不少調用信息,截圖以下: web
能夠看到cpu耗時最多的是log,這其實也好理解,因爲寫代碼的時候幾乎在每一個操做內都打了log,並且還有寫外部log文件的操做,因此耗時較長,從這點看這個程序應該選擇一些關鍵地方打log,好比在調度模塊的起止地方、異常處理模塊裏邊,而沒有必要每一個操做都輸出信息。而第二個則是Exchange.run(),這個更好理解了,因爲程序在http請求接收和相應處理上目前使用jdk的httpserver模塊,而Exchange正是對這些操做的封裝,是web服務器的核心模塊,cpu耗時可能是天然的。第三名若是你看過代碼就明白了,responseToClient方法是將響應數據寫入響應流。其餘的就不一一分析了,其實瞭解了功能和代碼就很容易看明白。
咱們再來看下調用次數,按照調用次數排序後,會發現ServerTimerTask.run()調用次數遠遠高於其餘方法,這個根據前邊說的應該都明白,就不解釋了。同時能夠看一下responseToClient()的調用次數,會發現和你網頁上請求的次數一致。
最後咱們來看一個典型的例子,咱們在方法名過濾器輸入SessionCleanTask,結果以下: json
下邊看下內存的分析,該項裏邊能夠看到每一個對象實時的內存佔用、對象數和年代數,具體分析思路其實和cpu大同小異, 就再也不細說了,看圖:
瀏覽器
好了,VisualVM介紹到此結束,其實其功能要比這強的多,好比dump文件分析和BTrace動態日誌追蹤(經過熱插入日誌代碼分析程序)等,感興趣就自行分析吧,這裏還有一篇介紹VisualVM可供參考。
以後將考慮開始寫類文件結構和類加載部分,不過因爲工做忙起來了,因此速度可能慢些,儘可能一週至少一篇吧。不費話了,沒衣服穿了,出去買件衣服,否則明天木法上班了T_T。服務器