Analyse von 90% der threads in java.lang.Thread.Status: WARTEN (Parkplatz)

Thread-Anzahl in meinem tomcat application server ist wachsenden jeden Tag.

Als ich genommen haben, thread-dump-Analyse.

Ich fand heraus, dass von 430 threads 307 threads sind mit diesem status.

Beispiel stacktrace

"pool-283-thread-1" #2308674 prio=5 os_prio=0 tid=0x000000000a916800 nid=0x1101 waiting on condition [0x00002aec87f17000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000006d9929ec0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"pool-282-thread-1" #2307106 prio=5 os_prio=0 tid=0x000000000a4fb000 nid=0x78e3 waiting on condition [0x00002aec87e16000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000006d8ca7bf8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

Umgebung

JDK: jdk1.8.0_60
OS: Linux
Tomcat: tomcat-7.0.65

Nicht sicher, ob dies das Problem verursacht.

Jede Hilfe dankbar, auf diese.

  • Solche threads erscheinen, um einen thread-pool warten auf einen task in eine Warteschlange. Ich denke, du musst uns erzählen, wie Sie setup, thread-pool und Warteschlange.
  • Haben Sie zufällig mal einen shutdown auf einem threadpool - /ExecutorService?
InformationsquelleAutor Patan | 2016-10-17
  1. 17

    Dies ist typisch Ressourcen-Leck. Sie verwenden irgendeine Art von ExecutorService irgendwo in Ihrer Anwendung, und Sie werden nicht schließen, dass der pool nach der Arbeit getan wird, zu Fäden zu erwarten, für immer.

    Sollten Sie rufen ExecutorService#shutdown() zu schließen pool und freigeben/kündigen Ihre threads nach der Arbeit ist getan.

    Threads Namen wie pool-282-thread-1 pool-283-thread-1 schlägt vor, dass, werden Sie wahrscheinlich mit single-thread-Pools executor (wegen pool keine. groß-und thread-Nein. ist nur 1). Die Idee hinter ExecutorService ist die Wiederverwendung von threads, die untätig sind etwas mehr Arbeit zu tun. So insteed der createing neue ExecutorService jeder Zeit, die Sie brauchen, um einige hintergrund arbeiten, sollten Sie lieber teilen single-Instanz und verwenden Sie es in Ihrem Antrag.

    InformationsquelleAutor Antoniossss
Schreibe einen Kommentar