Аналитик Java Thread Dump.3 сомнительных предмета - PullRequest
Новая
       19

Аналитик Java Thread Dump.3 сомнительных предмета

0 голосов
/ 13 ноября 2018

Вот сценарий, в котором команда top показывает процесс Java, который потребляет> 100% ЦП и только 20% памяти

JVisualVM показывает около 800M из 1024M (макс.) Использованной памяти, но просматривает сводку объектов в памяти через JVisualVM, и это выглядит в большей степени в соответствии с тем, что команда top показывает примерно на 20%. Нажав кнопку «Сбор мусора», он ничего не делает, и фактически он, кажется, никогда не запускается, поскольку после этого никогда не включается снова.

В настоящее время просматривается дамп потока Java со следующими ссылками. В прошлом, когда была блокировка, я видел адрес потока в одном потоке, на который ссылаются в другом потоке, но не видел его в этом сценарии.

Вместо этого существует ряд потоков «WAITING», в которых адрес «ожидания включен ...», кажется, совпадает с «заблокированным» адресом в том же потоке * того же *. Следующее показывает 5 примеров этого и задается вопросом, считается ли это «нормальным» или это вызывает беспокойство.

Если это проблема, как поток в конечном итоге ожидает себя? 

"Java Sound Event Dispatcher" #85 daemon prio=6 os_prio=0 tid=0x00007f5330065000 nid=0x2eab in Object.wait() [0x00007f5360524000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c30e9470> (a com.sun.media.sound.EventDispatcher)                       <-------Wating on       0x00000000c30e9470
    at java.lang.Object.wait(Object.java:502)
    at com.sun.media.sound.EventDispatcher.dispatchEvents(EventDispatcher.java:182)
    - locked <0x00000000c30e9470> (a com.sun.media.sound.EventDispatcher)                           <-------Locked (same)   0x00000000c30e9470
    at com.sun.media.sound.EventDispatcher.run(EventDispatcher.java:222)
    at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
    - None

"WORKER THREAD: 4" #84 prio=6 os_prio=0 tid=0x00007f5300009800 nid=0x2ea0 in Object.wait() [0x00007f5305b57000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c30e96c0> (a geh.client.econtrol.interappcomm.Worker)               <-------Wating on       0x00000000c30e96c0
    at java.lang.Object.wait(Object.java:502)
    at geh.client.econtrol.interappcomm.Worker.run(WebServer.java:382)
    - locked <0x00000000c30e96c0> (a geh.client.econtrol.interappcomm.Worker)                   <-------Locked (same)   0x00000000c30e96c0
    at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
    - None

"WORKER THREAD: 3" #83 prio=6 os_prio=0 tid=0x00007f5300007800 nid=0x2e9f in Object.wait() [0x00007f5305c58000]  
   java.lang.Thread.State: WAITING (on object monitor) 
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c30ea0b8> (a geh.client.econtrol.interappcomm.Worker)           <---------Same waiting on / locked ID 
    at java.lang.Object.wait(Object.java:502)
    at geh.client.econtrol.interappcomm.Worker.run(WebServer.java:382)
    - locked <0x00000000c30ea0b8> (a geh.client.econtrol.interappcomm.Worker)
    at java.lang.Thread.run(Thread.java:748)

"CacheCleanUpThread" #24 daemon prio=5 os_prio=0 tid=0x00007f534c026000 nid=0x2e54 in Object.wait() [0x00007f5361a2d000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c02612d8> (a com.sun.deploy.cache.CleanupThread)            <---------Same waiting on / locked ID 
    at java.lang.Object.wait(Object.java:502)
    at com.sun.deploy.cache.CleanupThread.run(Unknown Source)
    - locked <0x00000000c02612d8> (a com.sun.deploy.cache.CleanupThread)

   Locked ownable synchronizers:
    - None

"CacheMemoryCleanUpThread" #21 daemon prio=5 os_prio=0 tid=0x00007f534c024000 nid=0x2e53 in Object.wait() [0x00007f5361b2e000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000c0194180> (a java.lang.ref.ReferenceQueue$Lock)             <---------Same waiting on / locked ID 
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
    - locked <0x00000000c0194180> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
    at com.sun.deploy.cache.MemoryCache$LoadedResourceCleanupThread.run(Unknown Source)

   Locked ownable synchronizers:
    - None

Ниже показано количество потоков, использующих адрес [0x0000000000000000]. Почему используется [0x0000000000000000] и является ли это признаком проблемы? 

"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00007f53d80e1800 nid=0x2e48 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f53d80cc000 nid=0x2e47 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f53d80ca000 nid=0x2e46 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f53d80c8000 nid=0x2e45 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f53d80c5000 nid=0x2e44 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f53d80c3000 nid=0x2e43 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

Дамп потока также показывает множество потоков GC. Необычно ли видеть столько потоков GC? 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f53d8020800 nid=0x2e38 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f53d8022800 nid=0x2e39 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f53d8024000 nid=0x2e3a runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f53d8026000 nid=0x2e3b runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00007f53d8028000 nid=0x2e3c runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00007f53d8029800 nid=0x2e3d runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00007f53d802b800 nid=0x2e3e runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00007f53d802d800 nid=0x2e3f runnable

Еще один элемент, на который следует обратить внимание, - это каталог / tmp, заполненный на 100%, который, я подозреваю, использует процесс GC .... возможно ??? После очистки каталога / tmp это не помогло. Интересно, не удалось ли процессу GC исправить себя после очистки каталога.

Использование http://fastthread.io не помечало ничего необычного.

...