hotspot線程模型

以下問題將測試您對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………………………

現在，讓我們通過一個簡單的示例將所有這些原理放在一起。

步驟＃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

hotspot線程模型

總結

以上是生活随笔為你收集整理的hotspot线程模型_Linux上的HotSpot GC线程CPU占用空间的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。