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即時診斷，還有手動dump出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 -dump:<dump-options> <pid>  (to connect to running process and dump java heap)dump-options: format=b binary default file=<file> dump heap to <file>  Example: jmap -dump:format=b,file=heap.bin <pid>

 

    jmap -histo <pid>在螢幕上顯示出指定pid的jvm記憶體狀況。以我本機為例，執行該命令，螢幕顯示：

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的dump選項，這個選項是將jvm的堆中記憶體資訊輸出到一個檔案中，在我本機執行

jmap -dump:file=c:\dump.txt 340  

注意340是我原生java進程pid，dump出來的檔案比較大有10幾M，而且我只是開了tomcat，跑了一個很簡單的應用，且沒有任何訪問，可以想象，大型繁忙的伺服器上，dump出來的檔案該有多大。需要知道的是，dump出來的檔案資訊是很原始的，絕不適合人直接觀看，而jmap -histo顯示的內容又太簡單，例如只顯示某些類型的對象佔用多大記憶體，以及這些對象的數量，但是沒有更詳細的資訊，例如這些對象分別是由誰建立的。那這麼說，dump出來的檔案有什麼用呢？當然有用，因為有專門分析jvm的記憶體dump檔案的工具。

5：jhat

    上面說了，有很多工具都能分析jvm的記憶體dump檔案，jhat就是sun jdk6及以上版本內建的工具，位於jdk的bin目錄，執行 jhat -J -Xmx512m [file] ，file就是dump檔案路徑。jhat內建一個簡單的web伺服器，此命令執行後，jhat在命令列裡顯示分析結果的訪問地址，可以用-port選項指定連接埠，具體用法可以執行jhat -heap查看協助資訊。訪問指定地址後，就能看到頁面上顯示的資訊，比jmap -histo命令顯示的豐富得多，更為詳細。

6：eclipse記憶體分析器

    上面說了jhat，它能分析jvm的dump檔案，但是全部是文字顯示，eclipse memory analyzer，是一個eclipse提供用於分析jvm 堆dump的外掛程式，網址為 http://www.eclipse.org/mat ,它的分析速度比jhat快，分析結果是圖形介面顯示，比jhat的可讀性更高。其實jvisualvm也可以分析dump檔案，也是有圖形介面顯示的。

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區，空間使用率為54..62%

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的堆dump檔案，然後再用jhat，或者jvisualvm，或者eclipse記憶體分析器來分析記憶體狀況。

java記憶體查看與分析