哪個 Java 線程正在占用 CPU？

Question

假設您的 Java 程序占用了 100% 的 CPU。 它有 50 個線程。 你需要找出哪個線程是有罪的。 我還沒有找到可以提供幫助的工具。 目前我使用以下非常耗時的例程：

1. 運行jstack <pid> ，其中 pid 是 Java 進程的進程 ID。 找到它的簡單方法是運行 JDK- jps包含的另一個實用程序。 最好將 jstack 的輸出重定向到一個文件。
2. 搜索“可運行”線程。 跳過那些在套接字上等待的（出於某種原因，它們仍然被標記為可運行）。
3. 重復第 1 步和第 2 步幾次，看看您是否可以找到一個模式。

或者，您可以附加到 Eclipse 中的 Java 進程並嘗試一個一個掛起線程，直到遇到占用 CPU 的線程。 在單 CPU 機器上，您可能需要先降低 Java 進程的優先級才能四處移動。 即便如此，由於超時，Eclipse 通常無法附加到正在運行的進程。

我本來希望 Sun 的visualvm工具可以做到這一點。

有人知道更好的方法嗎？

Answer 1

確定生產服務器中哪個 Java 線程消耗最多的 CPU。

大多數（如果不是全部）生產系統做任何重要的事情都會使用 1 個以上的 Java 線程。 當某些事情變得瘋狂並且您的 CPU 使用率達到 100% 時，很難確定是哪個線程導致了這種情況。 或者我是這么想的。 直到有人比我更聰明向我展示了如何做到這一點。 在這里，我將向您展示如何做到這一點，您也可以用自己的極客技能讓您的家人和朋友驚嘆不已。

測試應用程序

為了測試這一點，我們需要一個測試應用程序。 所以我會給你一個。 它由3個類組成：

• 一個執行 CPU 密集型（計算 MD5 哈希）的HeavyThread類
• 一個LightThread類，它做一些不那么 CPU 密集型的事情（計數和睡眠）。
• 一個StartThreads類，用於啟動 1 個 cpu 密集型線程和幾個輕量級線程。

下面是這些類的代碼：

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.UUID;

/**
 * thread that does some heavy lifting
 *
 * @author srasul
 *
 */
public class HeavyThread implements Runnable {

        private long length;

        public HeavyThread(long length) {
                this.length = length;
                new Thread(this).start();
        }

        @Override
        public void run() {
                while (true) {
                        String data = "";

                        // make some stuff up
                        for (int i = 0; i < length; i++) {
                                data += UUID.randomUUID().toString();
                        }

                        MessageDigest digest;
                        try {
                                digest = MessageDigest.getInstance("MD5");
                        } catch (NoSuchAlgorithmException e) {
                                throw new RuntimeException(e);
                        }

                        // hash the data
                        digest.update(data.getBytes());
                }
        }
}


import java.util.Random;

/**
 * thread that does little work. just count & sleep
 *
 * @author srasul
 *
 */
public class LightThread implements Runnable {

        public LightThread() {
                new Thread(this).start();
        }

        @Override
        public void run() {
                Long l = 0l;
                while(true) {
                        l++;
                        try {
                                Thread.sleep(new Random().nextInt(10));
                        } catch (InterruptedException e) {
                                e.printStackTrace();
                        }
                        if(l == Long.MAX_VALUE) {
                                l = 0l;
                        }
                }
        }
}


/**
 * start it all
 *
 * @author srasul
 *
 */
public class StartThreads {

        public static void main(String[] args) {
                // lets start 1 heavy ...
                new HeavyThread(1000);

                // ... and 3 light threads
                new LightThread();
                new LightThread();
                new LightThread();
        }
}

假設您從未見過此代碼，並且您擁有運行這些類並消耗 100% CPU 的失控 Java 進程的 PID。

首先讓我們啟動StartThreads類。

$ ls
HeavyThread.java  LightThread.java  StartThreads.java
$ javac *
$ java StartThreads &

在這個階段，一個正在運行的 Java 進程應該占用 100 個 cpu。 在我的頂部，我看到：

在頂部按 Shift-H 打開線程。 top 的手冊頁說：

   -H : Threads toggle
        Starts top with the last remembered 'H' state reversed.  When
        this  toggle is On, all individual threads will be displayed.
        Otherwise, top displays a  summation  of  all  threads  in  a
        process.

現在在我的頂部打開線程顯示，我看到：

我有一個 PID 為28294的java進程。 讓我們使用jstack獲取此進程的堆棧轉儲：

$ jstack 28924
2010-11-18 13:05:41
Full thread dump Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode):

"Attach Listener" daemon prio=10 tid=0x0000000040ecb000 nid=0x7150 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" prio=10 tid=0x00007f9a98027800 nid=0x70fd waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-3" prio=10 tid=0x00007f9a98025800 nid=0x710d waiting on condition [0x00007f9a9d543000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at LightThread.run(LightThread.java:21)
    at java.lang.Thread.run(Thread.java:619)

"Thread-2" prio=10 tid=0x00007f9a98023800 nid=0x710c waiting on condition [0x00007f9a9d644000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at LightThread.run(LightThread.java:21)
    at java.lang.Thread.run(Thread.java:619)

"Thread-1" prio=10 tid=0x00007f9a98021800 nid=0x710b waiting on condition [0x00007f9a9d745000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at LightThread.run(LightThread.java:21)
    at java.lang.Thread.run(Thread.java:619)

"Thread-0" prio=10 tid=0x00007f9a98020000 nid=0x710a runnable [0x00007f9a9d846000]
   java.lang.Thread.State: RUNNABLE
    at sun.security.provider.DigestBase.engineReset(DigestBase.java:139)
    at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:104)
    at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:538)
    at java.security.MessageDigest.update(MessageDigest.java:293)
    at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:197)
    - locked <0x00007f9aa457e400> (a sun.security.provider.SecureRandom)
    at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:257)
    - locked <0x00007f9aa457e708> (a java.lang.Object)
    at sun.security.provider.NativePRNG$RandomIO.access$200(NativePRNG.java:108)
    at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:97)
    at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
    - locked <0x00007f9aa4582fc8> (a java.security.SecureRandom)
    at java.util.UUID.randomUUID(UUID.java:162)
    at HeavyThread.run(HeavyThread.java:27)
    at java.lang.Thread.run(Thread.java:619)

"Low Memory Detector" daemon prio=10 tid=0x00007f9a98006800 nid=0x7108 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread1" daemon prio=10 tid=0x00007f9a98004000 nid=0x7107 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x00007f9a98001000 nid=0x7106 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x0000000040de4000 nid=0x7105 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x0000000040dc4800 nid=0x7104 in Object.wait() [0x00007f9a97ffe000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00007f9aa45506b0> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
    - locked <0x00007f9aa45506b0> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x0000000040dbd000 nid=0x7103 in Object.wait() [0x00007f9a9de92000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00007f9aa4550318> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:485)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
    - locked <0x00007f9aa4550318> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x0000000040db8800 nid=0x7102 runnable 

"GC task thread#0 (ParallelGC)" prio=10 tid=0x0000000040d6e800 nid=0x70fe runnable 

"GC task thread#1 (ParallelGC)" prio=10 tid=0x0000000040d70800 nid=0x70ff runnable 

"GC task thread#2 (ParallelGC)" prio=10 tid=0x0000000040d72000 nid=0x7100 runnable 

"GC task thread#3 (ParallelGC)" prio=10 tid=0x0000000040d74000 nid=0x7101 runnable 

"VM Periodic Task Thread" prio=10 tid=0x00007f9a98011800 nid=0x7109 waiting on condition 

JNI global references: 910

從我的頂部我看到頂部線程的 PID 是28938 。 而28938十六進制是0x710A 。 請注意，在堆棧轉儲中，每個線程都有一個以十六進制顯示的nid 。 碰巧0x710A是線程的 id：

"Thread-0" prio=10 tid=0x00007f9a98020000 nid=0x710a runnable [0x00007f9a9d846000]
   java.lang.Thread.State: RUNNABLE
    at sun.security.provider.DigestBase.engineReset(DigestBase.java:139)
    at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:104)
    at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:538)
    at java.security.MessageDigest.update(MessageDigest.java:293)
    at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:197)
    - locked <0x00007f9aa457e400> (a sun.security.provider.SecureRandom)
    at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:257)
    - locked <0x00007f9aa457e708> (a java.lang.Object)
    at sun.security.provider.NativePRNG$RandomIO.access$200(NativePRNG.java:108)
    at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:97)
    at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
    - locked <0x00007f9aa4582fc8> (a java.security.SecureRandom)
    at java.util.UUID.randomUUID(UUID.java:162)
    at HeavyThread.run(HeavyThread.java:27)
    at java.lang.Thread.run(Thread.java:619)

因此，您可以確認運行HeavyThread類的線程正在消耗大部分 CPU。

在讀取世界的情況下，可能是一堆線程占用了 CPU 的一部分，這些線程放在一起將導致 Java 進程使用 100% 的 CPU。

概括

• 跑頂
• 按 Shift-H 啟用線程視圖
• 獲取 CPU 最高的線程的 PID
• 將 PID 轉換為十六進制
• 獲取java進程的堆棧轉儲
• 查找具有匹配 HEX PID 的線程。

Answer 2

jvmtop可以顯示消耗最高的線程：

    TID NAME                                 STATE     CPU    TOTALCPU
     25 http-8080-Processor13                RUNNABLE  4.55%     1.60%
 128022 RMI TCP Connection(18)-10.101.       RUNNABLE  1.82%     0.02%
  36578 http-8080-Processor164               RUNNABLE  0.91%     2.35%
 128026 JMX server connection timeout   TIMED_WAITING  0.00%     0.00%

Answer 3

嘗試查看Visual VM的Hot Thread Detector 插件——它使用 ThreadMXBean API 來獲取多個 CPU 消耗樣本以查找最活躍的線程。 它基於Bruce Chapman 的等效命令行，這也可能有用。

Answer 4

只需運行 JVisualVM，連接到您的應用程序並使用線程視圖。 保持持續活躍的那個是你最有可能的罪魁禍首。

Answer 5

查看 JConsole 的Top Threads插件。

Answer 6

如果您在 Windows 下運行，請嘗試Process Explorer 。 打開進程的屬性對話框，然后選擇線程選項卡。

Answer 7

我建議看看阿里巴巴開源的Arthas工具。

它包含一堆有用的命令，可以幫助您調試生產代碼：

• 儀表板：Java 進程概覽
• SC ：由您的 JVM 加載的搜索類
• Jad ：將類反編譯為源代碼
• 觀看：查看方法調用輸入和結果
• 跟蹤：找到方法調用的瓶頸
• Monitor : 查看方法調用統計
• 堆棧：查看方法的調用堆棧
• Tt : 方法調用的時間隧道

儀表板示例：

Answer 8

使用ps -eL或top -H -p <pid> ，或者如果您需要實時查看和監控，請運行 top（然后移 H），以獲取與 java 進程關聯的輕量級進程（LWP aka 線程） .

root@xxx:/# ps -eL
PID LWP TTY TIME CMD
 1 1 ? 00:00:00 java
 1 7 ? 00:00:01 java
 1 8 ? 00:07:52 java
 1 9 ? 00:07:52 java
 1 10 ? 00:07:51 java
 1 11 ? 00:07:52 java
 1 12 ? 00:07:52 java
 1 13 ? 00:07:51 java
 1 14 ? 00:07:51 java
 1 15 ? 00:07:53 java
…
 1 164 ? 00:00:02 java
 1 166 ? 00:00:02 java
 1 169 ? 00:00:02 java

注意 LWP= 輕量級進程； 在 Linux 中，線程與進程相關聯，以便在內核中進行管理； LWP 與父進程共享文件和其他資源。 現在讓我們看看最耗時的線程

 1 8 ? 00:07:52 java
 1 9 ? 00:07:52 java
 1 10 ? 00:07:51 java
 1 11 ? 00:07:52 java
 1 12 ? 00:07:52 java
 1 13 ? 00:07:51 java
 1 14 ? 00:07:51 java
 1 15 ? 00:07:53 java

Jstack是一個用於打印 Java Stack 的 JDK 實用程序； 它打印表單的線程。

熟悉其他很酷的 JDK 工具（ jcmd jstat jhat jmap jstack等 - https://docs.oracle.com/javase/8/docs/technotes/tools/unix/ ）

jstack -l <process id>

堆棧跟蹤中的 nid，Native 線程 id 是連接到 linux 中的 LWT 的那個 ( https://gist.github.com/rednaxelafx/843622 )

“GC task thread#0 (ParallelGC)” os_prio=0 tid=0x00007fc21801f000 nid=0x8 runnable

nid 以十六進制給出； 因此，我們將花費最多時間的線程 id 轉換為 DEC 中的 8,9,10,11,12,13,14,15 = 8,9,A, B,C,D,E,F 中的十六進制。

（請注意，此特定堆棧是從 Docker 容器中的 Java 中獲取的，如果為 1 則有一個方便的過程）讓我們看看具有此 ID 的線程。

“GC task thread#0 (ParallelGC)” os_prio=0 tid=0x00007fc21801f000 nid=0x8 runnable
“GC task thread#1 (ParallelGC)” os_prio=0 tid=0x00007fc218020800 nid=0x9 runnable
“GC task thread#2 (ParallelGC)” os_prio=0 tid=0x00007fc218022800 nid=0xa runnable
“GC task thread#3 (ParallelGC)” os_prio=0 tid=0x00007fc218024000 nid=0xb runnable
“GC task thread#4 (ParallelGC)” os_prio=0 tid=0x00007fc218026000 nid=0xc runnable
“GC task thread#5 (ParallelGC)” os_prio=0 tid=0x00007fc218027800 nid=0xd runnable
“GC task thread#6 (ParallelGC)” os_prio=0 tid=0x00007fc218029800 nid=0xe runnable
“GC task thread#7 (ParallelGC)” os_prio=0 tid=0x00007fc21802b000 nid=0xf runnable

所有 GC 相關的線程； 難怪它占用了大量 CPU 時間； 但是GC在這里是一個問題。

使用 jstat（不是 jstack ！）實用程序來快速檢查 GC。

jstat -gcutil <pid>

Answer 9

進行線程轉儲。 等待 10 秒鍾。 采取另一個線程轉儲。 再重復一次。 檢查線程轉儲並查看哪些線程卡在同一位置或處理同一請求。 這是一種手動方式，但通常很有用。

Answer 10

您是否在多核計算機上運行Java 6？

有可能你遇到了我剛才在一篇關於線程飢餓的文章中描述的問題。

請參閱同步與鎖定與公平鎖定 。

Answer 11

這是一種hacky方式，但似乎您可以在調試器中啟動應用程序，然后掛起所有線程，並檢查代碼並找出哪個沒有阻塞鎖定或I / O 調用某種循環。 或者這就像你已經嘗試過的一樣？

Answer 12

您可以考慮的一個選項是從應用程序中查詢您的線程以獲得答案。 通過ThreadMXBean，您可以從 Java 應用程序中查詢線程的 CPU 使用率，並查詢違規線程的堆棧跟蹤。

ThreadMXBean 選項允許您將這種監控構建到您的實時應用程序中。 它的影響可以忽略不計，並且具有明顯的優勢，您可以讓它完全按照您的意願行事。

Answer 13

如果您懷疑 VisualVM 是一個很好的工具，請嘗試一下（因為它可以做到這一點） 找出線程只會幫助您了解為什么它消耗這么多 CPU 的大致方向。

但是，如果它很明顯，我會直接使用分析器來找出為什么消耗這么多 CPU。