Linux上的HotSpot GC线程CPU占用空间

以下问题将测试您对Linux操作系统上运行的Java应用程序的垃圾回收和高CPU故障排除的知识。当调查过多的GC和/或CPU利用率时，此故障排除技术尤其重要。它将假定您没有访问高级监视工具的能力，例如Compuware dynaTrace甚至JVisualVM。将来会介绍使用此类工具的未来教程，但请确保您首先掌握基本的故障排除原理。

题：

在Linux OS上，如何在运行时监视和计算每个Oracle HotSpot或JRockit JVM垃圾回收（GC）线程使用了多少CPU％？

回答：

在Linux OS上，Java线程被实现为本机线程，这导致每个线程是一个单独的Linux进程。这意味着您可以使用top -H 命令（“线程”切换视图）监视HotSpot JVM创建的任何Java线程的CPU％。

也就是说，根据您使用的GC策略和服务器规范，HotSpot＆JRockit JVM将创建一定数量的GC线程，这些线程将执行旧空间和旧空间的收集。通过生成JVM线程转储，可以轻松识别此类线程。如下面的示例所示，Oracle JRockit JVM确实创建了4个GC线程，标识为“（GC Worker Thread X）”。

===== FULL THREAD DUMP ===============Fri Nov 16 19:58:36 2012BEA JRockit(R) R27.5.0-110-94909-1.5.0_14-20080204-1558-linux-ia32"Main Thread" id=1 idx=0x4 tid=14911 prio=5 alive, in native, waiting-- Waiting for notification on: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[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:474)at weblogic/t3/srvr/T3Srvr.waitForDeath(T3Srvr.java:730)^-- Lock released while waiting: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[fat lock]
at weblogic/t3/srvr/T3Srvr.run(T3Srvr.java:380)
at weblogic/Server.main(Server.java:67)at jrockit/vm/RNI.c2java(IIIII)V(Native Method)-- end of trace"(Signal Handler)" id=2 idx=0x8 tid=14920 prio=5 alive, in native, daemon"(GC Main Thread)" id=3 idx=0xc tid=14921 prio=5 alive, in native, native_waiting, daemon"(GC Worker Thread 1)" id=? idx=0x10 tid=14922 prio=5 alive, in native, daemon"(GC Worker Thread 2)" id=? idx=0x14 tid=14923 prio=5 alive, in native, daemon"(GC Worker Thread 3)" id=? idx=0x18 tid=14924 prio=5 alive, in native, daemon"(GC Worker Thread 4)" id=? idx=0x1c tid=14925 prio=5 alive, in native, daemon………………………

现在，让我们通过一个简单的示例将所有这些原理放在一起。