java內存查看與分析詳解

關于java內存查看與分析詳解

　　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 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

　　（to connect to running process and print histogram of java object heap

　　jmap -dump:

　　（to connect to running process and dump java heap）

　　dump-options:

　　format=b binary default

　　file=dump heap to

　　Example: jmap -dump:format=b,file=heap.bin

　　jmap -histo在屏幕上顯示出指定pid的jvm內存狀況。以我本機為例，執行該命令，屏幕顯示：

　　num #instances #bytes class name

　　----------------------------------------------

　　1: 242062791864

　　2: 223712145216 [C3: 242061940648

　　4: 19511364496

　　5: 265431282560

　　6: 63771081744 [B

　　7: 1793 909688

　　8: 1471 614624

　　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

　　Total239019 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的插件，它的分析速度比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 YGCTFGCFGCT GCT

　　54.62 0.00 42.87 43.52 86.24 17925.093337.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 EO P YGC YGCTFGCFGCT GCT

　　54.62 0.00 42.87 43.52 86.24 17925.093337.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的堆dump文件，然后再用jhat，或者jvisualvm，或者eclipse內存分析器來分析內存狀況。

【java內存查看與分析詳解】相關文章：

Java內存區域的使用詳解08-28

查看java對象所占的內存大小的方法09-03

Java內部類詳解及實例分析06-25

Java內存回收07-17

Java的內存模型09-22

查看電腦最大內存的方法10-14

java內存的詳細介紹06-04

Java內存是如何劃分的10-21

分析Java內存分配的棧和堆以及常量池06-24