當前位置:首頁 » 工具五金 » java堆內存查看工具在哪裡
擴展閱讀
中國石油燃油寶有什麼用 2024-11-02 14:24:58

java堆內存查看工具在哪裡

發布時間: 2024-08-27 22:03:34

A. java內存查看與分析


業界有很多強大的java profile的工具,比如Jporfiler,yourkit,這些收費的東西我就不想說了,想說的是,其實java自己就提供了很多內存監控的小工具,下面列舉的工具只是一小部分,仔細研究下扒陵jdk的工具,還是蠻有意思的呢:)
1:gc日誌輸出
在jvm啟動參數中加入 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimestamps -XX:+PrintGCApplicationStopedTime,jvm將會按照這些參數順序輸出gc概要信息,詳細信息,gc時間信息,gc造成的應用暫停時間。如果在剛才的參數後面加入參數 -Xloggc:文件路徑,gc信息將會輸出到指定的文件中。其他參數還有
-verbose:gc和-XX:+PrintTenuringDistribution等。
2:jconsole
jconsole是jdk自帶的一個內存分析工具,它提供了圖形界面。可以查看到被監控的jvm的內存信息,線程信息,類載入信息,MBean信息。
jconsole位於jdk目錄下的bin目錄,在windows下是jconsole.exe,在unix和linux下是jconsole.sh,jconsole可以監控本地應用,也可以監控遠程應用。 要監控本地應用,執行jconsole pid,pid就是運行的java進程id,如果不帶上pid參數,則執行jconsole命令後,會看到一個對話框彈出,上面列出了本地的java進程,可以選擇一個進行監控。如果要遠程監控,則要在遠程伺服器的jvm參數里加入一些東西,因為jconsole的遠程監控基於jmx的,關於jconsole詳細用法,請見專門介紹jconsle的文章,我也會在博客里專門詳細介紹jconsole。
3:jviusalvm
在JDK6 update 7之後,jdk推出了另外一個工具:jvisualvm,java可視化虛擬機,它不但提供了jconsole類似的功能,還提供了jvm內存和cpu實時診斷,還有手動mp出jvm內存情況,手動執行gc。
和jconsole一樣,運行jviusalvm,在jdk的bin目錄下執行jviusalvm,windows下是jviusalvm.exe,linux和unix下是jviusalvm.sh。滲此租
4:jmap
jmap是jdk自帶的jvm內存分析的工具,叢兆位於jdk的bin目錄。jdk1.6中jmap命令用法:
Usage:
jmap -histo pid
(to connect to running process and print histogram of java object heap
jmap -mp:mp-options pid
(to connect to running process and mp java heap)
mp-options:
format=b binary default
file=file mp heap to file
Example: jmap -mp:format=b,file=heap.bin pid
jmap -histo pid在屏幕上顯示出指定pid的jvm內存狀況。以我本機為例,執行該命令,屏幕顯示:
num #instances #bytes class name
----------------------------------------------
1: 24206 2791864 constMethodKlass
2: 22371 2145216 [C
3: 24206 1940648 methodKlass
4: 1951 1364496 constantPoolKlass
5: 26543 1282560 symbolKlass
6: 6377 1081744 [B
7: 1793 909688 constantPoolCacheKlass
8: 1471 614624 instanceKlassKlass
9: 14581 548336 [Ljava.lang.Object;
10: 3863 513640 [I
11: 20677 496248 java.lang.String
12: 3621 312776 [Ljava.util.HashMap$Entry;
13: 3335 266800 java.lang.reflect.Method
14: 8256 264192 java.io.ObjectStreamClass$WeakClassKey
15: 7066 226112 java.util.TreeMap$Entry
16: 2355 173304 [S
17: 1687 161952 java.lang.Class
18: 2769 150112 [[I
19: 3563 142520 java.util.HashMap
20: 5562 133488 java.util.HashMap$Entry
Total 239019 17140408
為了方便查看,我刪掉了一些行。從上面的信息很容易看出,#instance指的是對象數量,#bytes指的是這些對象佔用的內存大小,class name指的是對象類型。
再看jmap的mp選項,這個選項是將jvm的堆中內存信息輸出到一個文件中,在我本機執行
jmap -mp:file=c:mp.txt 340
注意340是我本機的java進程pid,mp出來的文件比較大有10幾M,而且我只是開了tomcat,跑了一個很簡單的應用,且沒有任何訪問,可以想像,大型繁忙的伺服器上,mp出來的文件該有多大。需要知道的是,mp出來的文件信息是很原始的,絕不適合人直接觀看,而jmap -histo顯示的內容又太簡單,例如只顯示某些類型的對象佔用多大內存,以及這些對象的數量,但是沒有更詳細的信息,例如這些對象分別是由誰創建的。那這么說,mp出來的文件有什麼用呢?當然有用,因為有專門分析jvm的內存mp文件的工具。
5:jhat
上面說了,有很多工具都能分析jvm的內存mp文件,jhat就是sun jdk6及以上版本自帶的工具,位於jdk的bin目錄,執行 jhat -J -Xmx512m [file] ,file就是mp文件路徑。jhat內置一個簡單的web伺服器,此命令執行後,jhat在命令行里顯示分析結果的訪問地址,可以用-port選項指定埠,具體用法可以執行jhat -heap查看幫助信息。訪問指定地址後,就能看到頁面上顯示的信息,比jmap -histo命令顯示的豐富得多,更為詳細。
6:eclipse內存分析器
上面說了jhat,它能分析jvm的mp文件,但是全部是文字顯示,eclipse memory analyzer,是一個eclipse提供用於分析jvm 堆mp的插件,它的分析速度比jhat快,分析結果是圖形界面顯示,比jhat的可讀性更高。其實jvisualvm也可以分析mp文件,也是有圖形界面顯示的。
7:jstat
如果說jmap傾向於分析jvm內存中對象信息的話,那麼jsta就是傾向於分析jvm內存的gc情況。都是jvm內存分析工具,但顯然,它們是從不同維度來分析的。jsat常用的參數有很多,如 -gc,-gcutil,-gccause,這些選項具體作用可查看jsat幫助信息,我經常用-gcutil,這個參數的作用不斷的顯示當前指定的jvm內存的垃圾收集的信息。
我在本機執行 jstat -gcutil 340 10000,這個命令是每個10秒鍾輸出一次jvm的gc信息,10000指的是間隔時間為10000毫秒。屏幕上顯示如下信息(我只取了第一行,因為是按的一定頻率顯示,所以實際執行的時候,會有很多行):
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
額怎麼說呢,要看懂這些信息代表什麼意思,還必須對jvm的gc機制有一定的了解才行啊。其實如果對sun的 hot spot jvm的gc比較了解的人,應該很容易看懂這些信息,但是不清楚gc機制的人,有點莫名其妙,所以在這里我還是先講講sun的jvm的gc機制吧。說到gc,其實不僅僅只是java的概念,其實在java之前,就有很多語言有gc的概念了,gc嘛就是垃圾收集的意思,更多的是一種演算法性的東西,而跟具體語言沒太大關系,所以關於gc的歷史,gc的主流演算法我就不講了,那扯得太遠了,扯得太遠了就是扯淡。sun現在的jvm,內存的管理模型是分代模型,所以gc當然是分代收集了。分代是什麼意思呢?就是將對象按照生命周期分成三個層次,分別是:新生代,舊生代,持久代。對象剛開始分配的時候,大部分都在新生代,當新生代gc提交被觸發後了,執行一次新生代范圍內的gc,這叫minor gc,如果執行了幾次minor gc後,還有對象存活,將這些對象轉入舊生代,因為這些對象已經經過了組織的重重考驗了哇。舊生代的gc頻率會更低一些,如果舊生代執行了gc,那就是full gc,因為不是局部gc,而是全內存范圍的gc,這會造成應用停頓,因為全內存收集,必須封鎖內存,不許有新的對象分配到內存,持久代就是一些jvm期間,基本不會消失的對象,例如class的定義,jvm方法區信息,例如靜態塊。需要主要的是,新生代里又分了三個空間:eden,susvivor0,susvivor1,按字面上來理解,就是伊甸園區,倖存1區,倖存2區。新對象分配在eden區中,eden區滿時,採用標記-復制演算法,即檢查出eden區存活 的對象,並將這些對象復制到是s0或s1中,然後清空eden區。jvm的gc說開來,不只是這么簡單,例如還有串列收集,並行收集,並發收集,還有著名的火車演算法,不過那說得太遠了,現在對這個有大致了解就好。說到這里,再來看一下上面輸出的信息:
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
S0:新生代的susvivor0區,空間使用率為5462%
S1:新生代的susvivor1區,空間使用率為0.00%(因為還沒有執行第二次minor收集)
E:eden區,空間使用率42.87%
O:舊生代,空間使用率43.52%
P:持久帶,空間使用率86.24%
YGC:minor gc執行次數1792次
YGCT:minor gc耗費的時間5.093毫秒
FGC:full gc執行次數33
FGCT:full gc耗費的時間7.670毫秒
GCT:gc耗費的總時間12.763毫秒
怎樣選擇工具
上面列舉的一些工具,各有利弊,其實如果在開發環境,使用什麼樣的工具是無所謂的,只要能得到結果就好。但是在生產環境里,卻不能亂選擇,因為這些工具本身就會耗費大量的系統資源,如果在一個生產伺服器壓力很大的時候,貿然執行這些工具,可能會造成很意外的情況。最好不要在伺服器本機監控,遠程監控會比較好一些,但是如果要遠程監控,伺服器端的啟動腳本要加入一些jvm參數,例如用jconsloe遠程監控tomcat或jboss等,都需要設置jvm的jmx參數,如果僅僅只是分析伺服器的內存分配和gc信息,強烈推薦,先用jmap導出伺服器端的jvm的堆mp文件,然後再用jhat,或者jvisualvm,或者eclipse內存分析器來分析內存狀況。