Który wątek Javy blokuje procesor?

Określenie, który wątek Java zużywa najwięcej CPU w serwerze produkcyjnym.

Większość (jeśli nie wszystkie) wydajnych systemów robiących cokolwiek ważnego będzie używać więcej niż 1 wątku Javy. A kiedy coś szaleje, a zużycie procesora jest na 100%, trudno jest określić, który wątek(y) jest/są przyczyną tego. Tak myślałem. Dopóki ktoś mądrzejszy ode mnie nie pokazał mi, jak to się robi. A tutaj pokażę Ci, jak to zrobić, a Ty też możesz zadziwić swoją rodzinę i przyjaciół swoim geekiem skills.

Aplikacja Testowa

Aby to przetestować, potrzebujemy aplikacji testowej. Więc dam ci jedną. Składa się z 3 klas:

Klasa, która robi coś intensywnego dla CPU (computing MD5 hashes)
• Klasa LightThread, która robi coś nie tak intensywnego na procesor (liczenia i uśpienia).
• a StartThreads Klasa uruchamiająca 1 procesor i kilka lekkich wątków.

Oto kod dla tych klasy:

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();
        }
}

Zakładając, że nigdy nie widziałeś tego kodu i masz tylko PID uciekającego procesu Javy, który uruchamia te klasy i zużywa 100% CPU.

Zacznijmy klasę StartThreads.

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

Na tym etapie uruchomiony proces Java powinien zajmować 100 cpu. W moim topie widzę:

U góry naciśnij Shift-H, który włącza wątki. Strona podręcznika dla Góry mówi:

   -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.

A teraz w moim top z włączonym wyświetlaczem wątków i Zobacz też:

I mam java proces z PID 28294. Pozwala uzyskać zrzut stosu tego procesu za pomocą 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

Z mojej góry widzę, że PID górnego wątku to 28938. I 28938 W hex jest 0x710A. Zauważ, że w zrzucie stosu każdy wątek ma nid, który jest wyświetlany w hex. I tak się składa, że 0x710A jest id wątku:

"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)

I dlatego możesz potwierdzić, że wątek, który uruchamia klasę HeavyThread, zużywa najwięcej CPU.

W sytuacjach read world, prawdopodobnie będzie to grupa wątków, które zużywają pewną część CPU i te wątki połączone razem doprowadzą do procesu Java przy użyciu 100% CPU.

Podsumowanie

• Run top
• naciśnij Shift-H, aby włączyć widok wątków
• Pobierz PID wątku z najwyższym procesorem
• Konwertuj PID na HEX
• Get stack dump of java process
• poszukaj wątku z pasującym PID HEX.

Jvmtop może pokazać ci najważniejsze wątki:

    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%

Po prostu uruchom JVisualVM, połącz się z aplikacją i użyj widoku wątku. Ten, który pozostaje ciągle aktywny, jest Twoim najbardziej prawdopodobnym winowajcą.

Spójrz na wtyczkę Top Threads dla JConsole.

Jeśli używasz systemu Windows, spróbuj Process Explorer . Otwórz okno dialogowe właściwości procesu, a następnie wybierz kartę wątki.

Zrób zrzut wątku. Poczekaj 10 sekund. Zrób kolejny zrzut nici. Powtórz jeszcze raz. Sprawdź zrzuty wątków i sprawdź, które wątki są przyklejone w tym samym miejscu lub przetwarzają to samo żądanie. Jest to ręczny sposób robienia tego, ale często przydatny.

Czy uruchamiasz Javę 6 na komputerze wielordzeniowym?

Są szanse, że cierpisz na problem, który właśnie opisałem w artykule o głodzie wątku.

Zobacz Synchronized vs. Lock vs. fair Lock .

Polecam spojrzeć na Arthas Narzędzie open source firmy Alibaba.

Zawiera kilka przydatnych poleceń, które mogą pomóc w debugowaniu kodu produkcyjnego:

• Dashboard : przegląd procesu Java
• SC : Search Class Loaded by Your JVM
• Jad : Dekompilacja Klasy Do Kodu Źródłowego
• Watch : Zobacz wejście i wyniki wywołania metody
• Trace : Znajdź wąskie gardło swojego Wywołanie Metody
• Monitor : Wyświetl Statystyki Wywołania Metody
• Stack : wyświetla stos wywołań metody
• Tt : tunel czasowy wywołania metody

Przykład deski rozdzielczej:

Jest to rodzaj hakerskiego sposobu, ale wydaje się, że można odpalić aplikację w debugerze, a następnie zawiesić wszystkie wątki, i przejść przez kod i dowiedzieć się, który z nich nie blokuje na lock lub I/O wywołania w jakiejś pętli. Czy to jest to, co już próbowałeś?

Opcją, którą możesz rozważyć, jest odpytywanie wątków o odpowiedź z poziomu aplikacji. Za pomocą ThreadMXBean możesz odpytywać użycie procesora w wątkach z poziomu aplikacji Java i sprawdzać ślady stosu obrażających wątków.

Opcja ThreadMXBean pozwala na zbudowanie tego rodzaju monitorowania w aplikacji na żywo. Ma znikomy wpływ i ma wyraźną zaletę, że możesz sprawić, że zrobi dokładnie to, co chcesz.

Jeśli podejrzewasz, że VisualVM jest dobrym narzędziem, spróbuj (ponieważ to robi) dowiedzieć się, że wątki pomagają tylko w ogólnym kierunku, dlaczego zużywa tyle CPU.

Jednak, jeśli to tak oczywiste, chciałbym przejść od razu do korzystania z profilera, aby dowiedzieć się, dlaczego zużywasz tyle CPU.