JRockit – JRCMD有用的命令

自2007年以來，我一直在使用JRockit。我發現它比Hotspot速度慢，但在診斷和分析問題上總是更好。從去年夏天開始，我一直在為一家國際電信系統供應商工作。我們在HP OpenCall Convergent Communication Platform之上為電信運營商設計和實施各種產品。我是開源和自由軟件的迷，但是該平臺僅在JRockit VM上運行。我們已經對其進行了調整，以實現低延遲并且運行非常酷，但是我們遇到了各種問題，在JRockit的幫助下，我們為故障排除提供了很多幫助。

我將在此處描述JRCMD的一些有用命令。 JRCMD是一個小型命令行工具，可用于與正在運行的JRockit實例進行交互。

摘要：

獲取線程轉儲
內存利用率
基于類的堆內存分析
虛擬機狀態
創建飛行記錄
產生堆轉儲

細節：

1）獲取線程轉儲 $> jrcmd <pid> print_threads [nativestack = true]

這是通常的SIGQUIT處理程序，可打印所有線程堆棧。您也可以使用經典方式獲得線程：“ $> kill -3 <pid> ”

無論如何，您都會得到如下的線程轉儲：

===== FULL THREAD DUMP ===============Thu Jun 21 11:38:19 2012Oracle JRockit(R) R28.1.4-7-144370-1.6.0_26-20110617-2130-linux-ia32
'http-172.18.57.4-8080-58' id=46791 idx=0x4 tid=17680 prio=5 alive, waiting, native_blocked, daemon-- Waiting for notification on: org/apache/tomcat/util/net/JIoEndpoint$Worker@0x5eef4588[fat lock]at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)at java/lang/Object.wait(J)V(Native Method)at java/lang/Object.wait(Object.java:485)at org/apache/tomcat/util/net/JIoEndpoint$Worker.await(JIoEndpoint.java:415)^-- Lock released while waiting: org/apache/tomcat/util/net/JIoEndpoint$Worker@0x5eef4588[fat lock]at org/apache/tomcat/util/net/JIoEndpoint$Worker.run(JIoEndpoint.java:441)at java/lang/Thread.run(Thread.java:662)[optimized]at jrockit/vm/RNI.c2java(IIIII)V(Native Method)-- end of trace
'(Signal Handler)' id=2 idx=0x8 tid=21213 prio=5 alive, native_blocked, daemon
'(OC Main Thread)' id=3 idx=0xc tid=21214 prio=5 alive, native_waiting, daemon
'(GC Worker Thread 1)' id=? idx=0x10 tid=21215 prio=5 alive, daemon
'(GC Worker Thread 2)' id=? idx=0x14 tid=21216 prio=5 alive, daemon
'(Code Generation Thread 1)' id=4 idx=0x18 tid=21217 prio=5 alive, native_waiting, daemon
'(Code Optimization Thread 1)' id=5 idx=0x1c tid=21218 prio=10 alive, native_waiting, daemon
'(Code Optimization Thread 2)' id=6 idx=0x20 tid=21219 prio=10 alive, native_waiting, daemon
'(VM Periodic Task)' id=7 idx=0x24 tid=21220 prio=10 alive, native_blocked, daemon
'Finalizer' id=8 idx=0x28 tid=21221 prio=8 alive, native_waiting, daemonat jrockit/memory/Finalizer.waitForFinalizees(J[Ljava/lang/Object;)I(Native Method)at jrockit/memory/Finalizer.access$700(Finalizer.java:12)[optimized]at jrockit/memory/Finalizer$4.run(Finalizer.java:189)at java/lang/Thread.run(Thread.java:662)at jrockit/vm/RNI.c2java(IIIII)V(Native Method)-- end of trace
'Reference Handler' id=9 idx=0x2c tid=21222 prio=10 alive, native_waiting, daemonat java/lang/ref/Reference.waitForActivatedQueue(J)Ljava/lang/ref/Reference;(Native Method)at java/lang/ref/Reference.access$100(Reference.java:11)at java/lang/ref/Reference$ReferenceHandler.run(Reference.java:82)at jrockit/vm/RNI.c2java(IIIII)V(Native Method)-- end of trace
...
...

2）內存利用率 $> jrcmd <pid> print_memusage

此命令可以幫助您解決內存不足的錯誤。它分析（概括）由Java進程分配的內存（包括本機代碼）。列：a）內存空間的名稱，b）為該空間映射多少內存，c）額外的詳細信息。示例運行如下：

Total mapped                  2110560KB           (reserved=6044KB)
-              Java heap      1572864KB           (reserved=0KB)
-              GC tables        52620KB          
-          Thread stacks        55060KB           (#threads=306)
-          Compiled code        23872KB           (used=21690KB)
-               Internal          776KB          
-                     OS        23368KB          
-                  Other       257328KB          
-        Java class data       123648KB           (malloced=123375KB #169700 in 29996 classes)
- Native memory tracking         1024KB           (malloced=296KB #8)

3）基于每個類的堆內存分析 $> jrcmd <pid> print_object_summary

按類顯示堆上所有實例的詳細信息，以及內存使用方式變化的差異值。列：a）此類的對象占用的堆的百分比，b）特定類的實例所占用的總大小，c）特定類的實例數，d）第一次調用時的大小變化e）該類的全名。檢查下一個示例運行，在該示例中，類“ org / adrianos / MyDTO”的對象可能存在問題：

--------- Detailed Heap Statistics: ---------
61.1% 939735k  6772960 +939735k [C
16.4% 252243k 10762404 +252243k java/lang/String7.0% 107516k  3947228 +107516k [Ljava/lang/String;4.5% 69265k   369180 +69265k [Ljava/lang/Object;1.6% 24127k   205889 +24127k org/adrianos/MyDTO1.3% 19486k  1247140 +19486k java/lang/Long1.0% 15551k    26621 +15551k [B0.6% 8871k     9700  +8871k [I0.6% 8710k   103896  +8710k [Ljava/util/HashMap$Entry;1537175kB total ------------ End of Detailed Heap Statistics ---

4）VM $> jrcmd <pid> print_vm_state的狀態

此命令產生的輸出類似于在JRockit實例崩潰時通常創建的轉儲文件。它顯示了VM的各種信息，例如java進程的命令行參數，正常運行時間，CPU類型，堆狀態，加載的模塊，libc版本等。請檢查示例運行的下一個摘錄：

Uptime       : 5 days, 16:29:55 on Thu Jun 21 12:02:34 2012
Version      : Oracle JRockit(R) R28.1.4-7-144370-1.6.0_26-20110617-2130-linux-ia32
CPU          : Intel Westmere (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64
Number CPUs  : 8
Tot Phys Mem : 12632571904 (12047 MB)
OS version   : Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Linux version 2.6.18-194.26.1.el5PAE (mockbuild@x86-002.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Fri Oct 29 14:28:58 EDT 2010 (i686)
Thread System: Linux NPTL
LibC release : 2.5-stable
Java locking : Lazy unlocking enabled (class banning) (transfer banning)
State        : JVM is running (Main thread has finished)
Command Line : -Dprogram.name=run.sh -Xms1536M -Xmx1536M -Djava.net.preferIPv4Stack=true -Xverbose:gc,memory -XverboseLog:/tmp/gc-jrockit.log -Xbootclasspath/p: -XXaggressive -XXcompaction:heapParts=1536 -Xgc:genconcon -Xns:150M -XXgcThreads:2 -XXgcTrigger:50 -XXcompaction:internalPercentage=1.0 -XXcompaction:externalPercentage=1.0 -Xmanagement -Djrockit.managementserver.port=4646 -Dcom.sun.management.jmxremote.ssl=false -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/var/lib/OC/imsc/lib/endorsed -Dsun.java.launcher=SUN_STANDARD com.adrianos.Main 
Repository   : /tmp/2012_06_15_19_32_40_21109
java.home    : /usr/java/jrockit-jdk1.6.0_26-R28.1.4-4.0.1.orig/jre
StackOverFlow: 0 StackOverFlowErrors have occured
OutOfMemory  : 0 OutOfMemoryErrors have occured
C Heap       : Good; no memory allocations have failed
GC Strategy  : Mode: pausetime, with strategy: genconcon (basic strategy: genconcon)
GC Status    : OC is not running. Last finished OC was OC#5287.: YC is not running. Last finished YC was YC#16925.
YC Promotion : Last YC successfully promoted all objects
YC History   : Ran 3 YCs before OC#5283.: Ran 3 YCs before OC#5284.: Ran 3 YCs before OC#5285.: Ran 3 YCs before OC#5286.: Ran 3 YCs before OC#5287.: Ran 2 YCs since last OC.
Heap         : 0x5661a000 - 0xb661a000  (Size: 1536 MB)
Compaction   : (no compaction area)
Allocation   : TLA-min: 2048, TLA-preferred: 20480 TLA-waste limit: 2048
NurseryList  : 0x869370d8 - 0x941e0390
KeepArea     : 0x8da6c078 - 0x941e0390
KA Markers   : [ 0x8b4857c8,  0x8da6c078 , 0x941e0390 ]
Forbidden A  : (none)
Previous KA  : 0x8b4857c8 - 0x8da6c078
Previous FA  : (none)
CompRefs     : References are 32-bit.
...
...
Loaded modules:
08048000-08057193  /usr/java/jrockit-jdk1.6.0_26-R28.1.4-4.0.1.orig/bin/java
b7f12000-b7f1262b  /usr/java/jrockit-jdk1.6.0_26-R28.1.4-4.0.1.orig/bin/java
...
...

5）創建飛行記錄 $> jrcmd <pid> start_flightrecording名稱= myrecord1文件名= / var / tmp / myrecord1.jfr持續時間= 60s compress = true設置= / my / path / xxx.jfs

啟動JRockit飛行記錄器記錄，該記錄可以幫助您分析代碼的行為并發現潛在的問題（例如瓶頸）。這對于了解您的線程在做什么非常有用。 JROCKIT_HOME / jre / lib / jfr目錄中有很多模板。

6）產生堆轉儲 $> jrcmd <pid> hprofdump filename = / tmp / jrockit1.hprof

以流行的HPROF格式生成堆轉儲，可用于解決內存泄漏或更好地理解您的代碼。您可以使用出色的Eclipse內存分析器工具（ MAT ）或默認的Java內存分析器VisualVM來分析此文件。 一般提示：

您必須小心最后兩個命令，因為它們非常有用，但需要JVM提供額外的資源。避免在交通繁忙時執行它們，除非您確實需要它們。請記住，如果JVM處于非常“ 困難 ”的狀態，則將不允許此類操作。
MAT是一個很棒的工具，我喜歡它。但是，如果要做好充分的準備，則還必須使用Hotspot的默認安裝中存在的VisualVM。這意味著VisualVM始終存在，并且您不需要額外的圖形工具即可檢查簡單的內容。我遇到過這樣的情況，我無法訪問互聯網，并且禁止使用筆記本電腦。

希望您會發現這些詳細信息有用。

參考： JRockit –來自我們的JCG合作伙伴 Adrianos Dadis的Java，Integration和源博客優點的 JRCMD有用命令。