自2007年以来，我一直在使用JRockit。我发现它比Hotspot速度慢，但在诊断和分析问题上总是更好。 从去年夏天开始，我一直在为一家国际电信系统供应商工作。 我们在HP OpenCall Convergent Communication Platform之上为电信运营商设计和实施各种产品。 我是开源和自由软件的迷，但是该平台仅在JRockit VM上运行 。 我们已经对其进行了调整，以实现低延迟并且运行非常酷，但是我们遇到了各种问题，在JRockit的帮助下，我们为故障排除提供了很多帮助。

我将在此处描述JRCMD的一些有用命令。 JRCMD是一个小型命令行工具，可用于与正在运行的JRockit实例进行交互。

摘要：

1. 获取线程转储
2. 内存利用率
3. 基于类的堆内存分析
4. 虚拟机状态
5. 创建飞行记录
6. 产生堆转储

细节：

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来分析此文件。 一般提示：

1. 您必须小心最后两个命令，因为它们非常有用，但需要JVM提供额外的资源。 避免在交通繁忙时执行它们，除非您确实需要它们。 请记住，如果JVM处于非常“ 困难 ”的状态，则将不允许此类操作。
2. MAT是一个很棒的工具，我喜欢它。 但是，如果要做好充分的准备，则还必须使用Hotspot的默认安装中存在的VisualVM。 这意味着VisualVM始终存在，并且您不需要额外的图形工具即可检查简单的内容。 我遇到过这样的情况，我无法访问互联网，并且禁止使用笔记本电脑。

希望您会发现这些详细信息有用。

参考： JRockit –来自我们的JCG合作伙伴 Adrianos Dadis的Java，Integration和源博客优点的 JRCMD有用命令 。