天天看點

JVM監控工具介紹jstack, jconsole, jinfo, jmap, jdb, jstat u               jps 的用法 u               jstack 的用法 u               jstat 的用法

jstack -- 如果java程式崩潰生成core檔案,jstack工具可以用來獲得core檔案的java stack和native stack的資訊,進而可以輕松地知道java程式是如何崩潰和在程式何處發生問題。另外,jstack工具還可以附屬到正在運作的java程式中,看到 當時運作的java程式的java stack和native stack的資訊, 如果現在運作的java程式呈現hung的狀态,jstack是非常有用的。目前隻有在Solaris和Linux的JDK版本裡面才有。

jconsole – jconsole是基于Java Management Extensions (JMX)的實時圖形化監測工具,這個工具利用了内建到JVM裡面的JMX指令來提供實時的性能和資源的監控,包括了Java 程式的記憶體使用,Heap size, 線程的狀态,類的配置設定狀态和空間使用等等。

jinfo – jinfo可以從core檔案裡面知道崩潰的Java應用程式的配置資訊,目前隻有在Solaris和Linux的JDK版本裡面才有。

jmap – jmap 可以從core檔案或程序中獲得記憶體的具體比對情況,包括Heap size, Perm size等等,目前隻有在Solaris和Linux的JDK版本裡面才有。

jdb – jdb 用來對core檔案和正在運作的Java程序進行實時地調試,裡面包含了豐富的指令幫助您進行調試,它的功能和Sun studio裡面所帶的dbx非常相似,但 jdb是專門用來針對Java應用程式的。

jstat – jstat利用了JVM内建的指令對Java應用程式的資源和性能進行實時的指令行的監控,包括了對Heap size和垃圾回收狀況的監控等等。

jps – jps是用來檢視JVM裡面所有程序的具體狀态, 包括程序ID,程序啟動的路徑等等。 

jstatd

啟動jvm監控服務。它是一個基于rmi的應用,向遠端機器提供本機jvm應用程式的資訊。預設端口1099。

執行個體:jstatd -J-Djava.security.policy=my.policy

my.policy檔案需要自己建立,内如如下:

grant codebase "file:$JAVA_HOME/lib/tools.jar" {

 permission java.security.AllPermission;

};

這是安全政策檔案,因為jdk對jvm做了jaas的安全檢測,是以我們必須設定一些政策,使得jstatd被允許作網絡操作

上面的操作沒有通過,出現:

Could not create remote object

access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write)

java.security.AccessControlException: access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write)

        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)

        at java.security.AccessController.checkPermission(AccessController.java:546)

        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)

        at java.lang.System.setProperty(System.java:727)

        at sun.tools.jstatd.Jstatd.main(Jstatd.java:122)

create in your usr/java/bin the jstatd.all.policy file, with the content must be

  1. grant codebase "file:${java.home}/../lib/tools.jar" {  
  2. permission java.security.AllPermission;  
  3. }; 

jps

列出所有的jvm執行個體

執行個體:

jps

列出本機所有的jvm執行個體

jps 192.168.0.77

列出遠端伺服器192.168.0.77機器所有的jvm執行個體,采用rmi協定,預設連接配接端口為1099

(前提是遠端伺服器提供jstatd服務)

輸出内容如下:

[email protected]:~/data/ebook/java/j2se/jdk_gc$ jps

6286 Jps

6174  Jstat

jconsole

一個圖形化界面,可以觀察到java程序的gc,class,記憶體等資訊。雖然比較直覺,但是個人還是比較傾向于使用jstat指令(在最後一部分會對jstat作詳細的介紹)。

jinfo (linux下特有)

觀察運作中的java程式的運作環境參數:參數包括Java System屬性和JVM指令行參數

執行個體:jinfo 2083

其中2083就是java程序id号,可以用jps得到這個id号。

輸出内容太多了,不在這裡一一列舉,大家可以自己嘗試這個指令。

jstack (linux下特有)

可以觀察到jvm中目前所有線程的運作情況和線程目前狀态

jstack 2083

輸出内容如下:

JVM監控工具介紹jstack, jconsole, jinfo, jmap, jdb, jstat u               jps 的用法 u               jstack 的用法 u               jstat 的用法

jmap (linux下特有,也是很常用的一個指令)

觀察運作中的jvm實體記憶體的占用情況。

參數如下:

-heap :列印jvm heap的情況

-histo: 列印jvm heap的直方圖。其輸出資訊包括類名,對象數量,對象占用大小。

-histo:live : 同上,但是隻答應存活對象的情況

-permstat: 列印permanent generation heap情況

指令使用:

jmap -heap 2083

可以觀察到New Generation(Eden Space,From Space,To Space),tenured generation,Perm Generation的記憶體使用情況

輸出内容:

JVM監控工具介紹jstack, jconsole, jinfo, jmap, jdb, jstat u               jps 的用法 u               jstack 的用法 u               jstat 的用法

jmap -histo 2083 | jmap -histo:live 2083

可以觀察heap中所有對象的情況(heap中所有生存的對象的情況)。包括對象數量和所占空間大小。

輸出内容:

JVM監控工具介紹jstack, jconsole, jinfo, jmap, jdb, jstat u               jps 的用法 u               jstack 的用法 u               jstat 的用法

寫個腳本,可以很快把占用heap最大的對象找出來,對付記憶體洩漏特别有效。

jstat

最後要重點介紹下這個指令。

這是jdk指令中比較重要,也是相當實用的一個指令,可以觀察到classloader,compiler,gc相關資訊

具體參數如下:

-class:統計class loader行為資訊

-compile:統計編譯行為資訊

-gc:統計jdk gc時heap資訊

-gccapacity:統計不同的generations(不知道怎麼翻譯好,包括新生區,老年區,permanent區)相應的heap容量情況

-gccause:統計gc的情況,(同-gcutil)和引起gc的事件

-gcnew:統計gc時,新生代的情況

-gcnewcapacity:統計gc時,新生代heap容量

-gcold:統計gc時,老年區的情況

-gcoldcapacity:統計gc時,老年區heap容量

-gcpermcapacity:統計gc時,permanent區heap容量

-gcutil:統計gc時,heap情況

-printcompilation:不知道幹什麼的,一直沒用過。

一般比較常用的幾個參數是:

jstat -class 2083 1000 10 (每隔1秒監控一次,一共做10次)

輸出内容含義如下:

Loaded Number of classes loaded.
Bytes Number of Kbytes loaded.
Unloaded Number of classes unloaded.
Bytes Number of Kbytes unloaded.
Time Time spent performing class load and unload operations.

jstat -gc 2083 2000 20(每隔2秒監控一次,共做10)

輸出内容含義如下:

S0C Current survivor space 0 capacity (KB).
EC Current eden space capacity (KB).
EU Eden space utilization (KB).
OC Current old space capacity (KB).
OU Old space utilization (KB).
PC Current permanent space capacity (KB).
PU Permanent space utilization (KB).
YGC Number of young generation GC Events.
YGCT Young generation garbage collection time.
FGC Number of full GC events.
FGCT Full garbage collection time.
GCT Total garbage collection time.

輸出内容:

JVM監控工具介紹jstack, jconsole, jinfo, jmap, jdb, jstat u               jps 的用法 u               jstack 的用法 u               jstat 的用法

如果能熟練運用這些指令,尤其是在linux下,那麼完全可以代替jprofile等監控工具了,誰讓它收費呢。呵呵。

用指令的好處就是速度快,并且輔助于其他指令,比如grep gawk sed等,可以組裝多種符合自己需求的工具。

u               jps 的用法

用來檢視 JVM 裡面所有程序的具體狀态 , 包括程序 ID ,程序啟動的路徑等等。 與 unix 上的 ps 類似,用來顯示本地的 java 程序,可以檢視本地運作着幾個 java 程式,并顯示他們的程序号。

[[email protected] ~]# jps

25517 Jps

25444 Bootstrap

u               jstack 的用法

如果 java 程式崩潰生成 core 檔案, jstack 工具可以用來獲得 core 檔案的 java stack 和 native stack 的資訊,進而可以輕松地知道 java 程式是如何崩潰和在程式何處發生問題。另外, jstack 工具還可以附屬到正在運作的 java 程式中,看到當時運作的 java 程式的 java stack 和 native stack 的資訊 , 如果現在運作的 java 程式呈現 hung 的狀态, jstack 是非常有用的。目前隻有在 Solaris 和 Linux 的 JDK 版本裡面才有。

[[email protected] bin]# jstack 25444

Attaching to process ID 25917, please wait...

Debugger attached successfully.

Client compiler detected.

JVM version is 1.5.0_08-b03

Thread 25964: (state = BLOCKED)

Error occurred during stack walking:

sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:134)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:437)

        at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48)

        at sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86JavaThreadPDAccess.java:75)

        at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252)

        at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211)

        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:50)

        at sun.jvm.hotspot.tools.JStack.run(JStack.java:41)

        at sun.jvm.hotspot.tools.Tool.start(Tool.java:204)

        at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)

Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:431)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:109)

Thread 25963: (state = IN_NATIVE)

Error occurred during stack walking:

sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:134)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:437)

        at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48)

        at sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86JavaThreadPDAccess.java:75)

        at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252)

        at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211)

        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:50)

        at sun.jvm.hotspot.tools.JStack.run(JStack.java:41)

        at sun.jvm.hotspot.tools.Tool.start(Tool.java:204)

        at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)

Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:431)

        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:109)

u               jstat 的用法

用以判斷JVM 是否存在記憶體問題呢?如何判斷JVM 垃圾回收是否正常?一般的top 指令基本上滿足不了這樣的需求,因為它主要監控的是總體的系統資源,很難定位到java 應用程式。

Jstat 是JDK 自帶的一個輕量級小工具。全稱“Java Virtual Machine statistics monitoring tool” ,它位于java 的bin 目錄下,主要利用JVM 内建的指令對Java 應用程式的資源和性能進行實時的指令行的監控,包括了對Heap size 和垃圾回收狀況的監控。可見,Jstat 是輕量級的、專門針對JVM 的工具,非常适用。由于JVM 記憶體設定較大,圖中百分比變化不太明顯

一個極強的監視 VM 記憶體工具。可以用來監視 VM 記憶體内的各種堆和非堆的大小及其記憶體使用量。

jstat 工具特别強大,有衆多的可選項,詳細檢視堆内各個部分的使用量,以及加載類的數量。使用時,需加上檢視程序的程序 id ,和所選參數。

文法結構:

Usage: jstat -help|-options

       jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

參數解釋:

Options — 選項,我們一般使用 -gcutil 檢視gc 情況

vmid    — VM 的程序号,即目前運作的java 程序号

interval– 間隔時間,機關為秒或者毫秒

count   — 列印次數,如果預設則列印無數次

S0  — Heap 上的 Survivor space 0 區已使用空間的百分比

S1  — Heap 上的 Survivor space 1 區已使用空間的百分比

E   — Heap 上的 Eden space 區已使用空間的百分比

O   — Heap 上的 Old space 區已使用空間的百分比

P   — Perm space 區已使用空間的百分比

YGC — 從應用程式啟動到采樣時發生 Young GC 的次數

YGCT– 從應用程式啟動到采樣時 Young GC 所用的時間( 機關秒 )

FGC — 從應用程式啟動到采樣時發生 Full GC 的次數

FGCT– 從應用程式啟動到采樣時 Full GC 所用的時間( 機關秒 )

GCT — 從應用程式啟動到采樣時用于垃圾回收的總時間( 機關秒)

執行個體使用1 :

[[email protected] bin]# jstat -gcutil 25444

  S0      S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT

  11.63   0.00    56.46  66.92  98.49 162    0.248    6       0.331    0.579

執行個體使用 2 :

[[email protected] bin]# jstat -gcutil 25444 1000 5

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT

  73.54   0.00  99.04  67.52  98.49    166    0.252     6    0.331    0.583

  73.54   0.00  99.04  67.52  98.49    166    0.252     6    0.331    0.583

  73.54   0.00  99.04  67.52  98.49    166    0.252     6    0.331    0.583

  73.54   0.00  99.04  67.52  98.49    166    0.252     6    0.331    0.583

  73.54   0.00  99.04  67.52  98.49    166    0.252     6    0.331    0.583

我們可以看到,5 次young gc 之後,垃圾記憶體被從Eden space 區(E) 放入了Old space 區(O) ,并引起了百分比的變化,導緻Survivor space 使用的百分比從73.54%(S0) 降到0%(S1) 。有效釋放了記憶體空間。綠框中,我們可以看到,一次full gc 之後,Old space 區(O) 的記憶體被回收,從99.05% 降到67.52% 。

圖中同時列印了young gc 和full gc 的總次數、總耗時。而,每次young gc 消耗的時間,可以用相間隔的兩行YGCT 相減得到。每次full gc 消耗的時間,可以用相隔的兩行FGCT 相減得到。例如紅框中表示的第一行、第二行之間發生了1 次young gc ,消耗的時間為0.252-0.252 =0.0 秒。

常駐記憶體區(P) 的使用率,始終停留在98.49% 左右,說明常駐記憶體沒有突變,比較正常。

如果young gc 和full gc 能夠正常發生,而且都能有效回收記憶體,常駐記憶體區變化不明顯,則說明java 記憶體釋放情況正常,垃圾回收及時,java 記憶體洩露的幾率就會大大降低。但也不能說明一定沒有記憶體洩露。

GCT 是YGCT 和FGCT 的時間總和。

以上,介紹了Jstat 按百分比檢視gc 情況的功能。其實,它還有功能,例如加載類資訊統計功能、記憶體池資訊統計功能等,那些是以絕對值的形式列印出來的,比較少用,在此就不做介紹。

[[email protected] bin]# ps -ef | grep java

root     25917     1  2 23:23 pts /2    00:00:05 /usr/local/jdk1.5/bin/java -Djava.endorsed.dirs=/usr/local/jakarta-tomcat-5.0.30/common/endorsed -classpath /usr/local/jdk1.5/lib/tools.jar:/usr/local/jakarta-tomcat-5.0.30/bin/bootstrap.jar:/usr/local/jakarta-tomcat-5.0.30/bin/commons-logging-api.jar -Dcatalina.base=/usr/local/jakarta-tomcat-5.0.30 -Dcatalina.home=/usr/local/jakarta-tomcat-5.0.30 -Djava.io.tmpdir=/usr/local/jakarta-tomcat-5.0.30/temp org.apache.catalina.startup.Bootstrap start

jstat -class pid: 顯示加載 class 的數量,及所占空間等資訊。

執行個體使用3 :

[[email protected] bin]# jstat -class 25917

Loaded  Bytes  Unloaded  Bytes     Time

2629     2916.8       29   24.6     0.90

jstat -compiler pid: 顯示 VM 實時編譯的數量等資訊。

執行個體使用 4 :

[[email protected] bin]# jstat -compiler 25917

Compiled Failed Invalid   Time   FailedType FailedMethod

     768      0       0   0.70             0

jstat –gccapacity : 可以顯示, VM 記憶體中三代( young,old,perm )對象的使用和占用大小,如: PGCMN 顯示的是最小 perm 的記憶體使用量, PGCMX 顯示的是 perm 的記憶體最大使用量, PGC 是目前新生成的 perm 記憶體占用量, PC 是但前 perm 記憶體占用量。其他的可以根據這個類推, OC 是 old 内純的占用量。

[[email protected] bin]# jstat -gccapacity 25917

NGCMN       640.0

NGCMX       4992.0

NGC         832.0

S0C         64.0

S1C         64.0

EC          704.0

OGCMN       1408.0

OGCMX       60544.0

OGC         9504.0

OC          9504.0                  OC 是 old 内純的占用量

PGCMN       8192.0                  PGCMN 顯示的是最小 perm 的記憶體使用量

PGCMX       65536.0                 PGCMX 顯示的是 perm 的記憶體最大使用量

PGC         12800.0                 PGC 是目前新生成的 perm 記憶體占用量

PC          12800.0                 PC 是但前 perm 記憶體占用量

YGC         164

FGC         6

jstat -gcnew pid: new 對象的資訊

[[email protected] bin]# jstat -gcnew 25917

  S0C    S1C    S0U    S1U   TT MTT  DSS      EC       EU     YGC     YGCT

  64.0   64.0   47.4   0.0    2  15   32.0    704.0    145.7    168    0.254

jstat -gcnewcapacity pid: new 對象的資訊及其占用量

[[email protected] bin]# jstat -gcnewcapacity 25917

  NGCMN   NGCMX    NGC    S0CMX  S0C    S1CMX   S1C   ECMX    EC      YGC   FGC

640.0   4992.0   832.0 64.0     448.0 448.0   64.0   4096.0   704.0  168     6

jstat -gcold pid: old 對象的資訊。

[[email protected] bin]# jstat -gcold 25917

   PC       PU        OC          OU       YGC    FGC    FGCT     GCT

  12800.0  12617.6     9504.0      6561.3   169     6    0.335    0.591

jstat -gcoldcapacity pid:old 對象的資訊及其占用量。

[[email protected] bin]# jstat -gcoldcapacity 25917