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 2012

BEA 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

………………………

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

步骤＃1 –监视GC线程CPU利用率

调查的第一步是监视并确定：

• 通过Linux top -H 命令显示的每个GC工作线程标识本机线程ID。
  
• 确定每个GC工作线程的CPU％。
  

步骤＃2 –生成和分析JVM线程转储

在Linux的顶部-H的同时 ，产生2个或3 JVM线程转储通过kill快照-3 <JavaPID>。

• 打开JVM线程转储，然后找到JVM GC工作线程。
  
• 现在，通过查看本机线程ID（tid属性），将“ top -H”输出数据与JVM Thread Dump数据相关联。
  

正如您在我们的示例中看到的那样，这种分析确实使我们能够确定我们所有的GC工作线程每个都使用大约20％的CPU。 这是由于当时发生了重大收藏。 请注意，启用verbose：gc也是非常有用的，因为它将允许您将此类CPU峰值与次要和主要集合相关联，并确定JVM GC进程对服务器总体CPU利用率的贡献程度。

参考： Java EE支持模式博客上的JCG合作伙伴 Pierre-Hugues Charbonneau提供的Linux上的HotSpot GC线程CPU占用空间 。

翻译自: https://www.javacodegeeks.com/2013/04/hotspot-gc-thread-cpu-footprint-on-linux.html