Java thread dump, не могу найти поток, который блокирует другие

Question

Наше приложение отстает.

Я получаю дамп резьбы, используя jstack util.

Я делаю подготовку данных и сортирую их. И это то, что у меня есть:

198 java.lang.Thread.State: BLOCKED (on object monitor) 

198 - waiting to lock <0x0000000582e56bc8> (a java.lang.Class for com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector) 

198 ниток BLOCKED.

Как я понимаю из waiting to lock <0x0000000582e56bc8>, все они ждут некоторую тему с ID 0x0000000582e56bc8. Странно то, что я не могу найти этот 0x0000000582e56bc8 в выводе дампа потока, я не могу найти то, что все ждут.

Или это неправда? Что это такое 0x0000000582e56bc8?

Вот маленький мир отвала:

"http-thread-pool-8080(790)" daemon prio=3 tid=0x00000001100fa000 nid=0x339a waiting for monitor entry [0xfffffffeec1f6000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
     at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:82) 
     - waiting to lock <0x0000000582e56bc8> (a java.lang.Class for com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector) 

Все 198 других резьбовыми отвалов являются одинаковыми

Update 1. После того, как @Holder комментарий

"http-thread-pool-8080(642)" daemon prio=3 tid=0x0000000110a8c800 nid=0x32ec runnable [0xffffffff05af5000] 
    java.lang.Thread.State: RUNNABLE 
     at java.util.zip.Inflater.inflateBytes(Native Method) 
     at java.util.zip.Inflater.inflate(Inflater.java:256) 
     - locked <0x000000058f2af0c0> (a java.util.zip.ZStreamRef) 
     at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152) 
     at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122) 
     at org.apache.felix.framework.util.WeakZipFileFactory$WeakZipFile$WeakZipInputStream.read(WeakZipFileFactory.java:669) 
     at java.io.DataInputStream.readShort(DataInputStream.java:312) 
     at com.sun.xml.bind.v2.bytecode.ClassTailor.tailor(ClassTailor.java:173) 
     at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.tailor(AccessorInjector.java:126) 
     at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:85) 
     - locked <0x0000000582e56bc8> (a java.lang.Class for com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector) 
     at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:176) 

Update 2 Спасибо за @Holder

Как я понимаю waiting to lock <0x0000000582e56bc8>, означает, что поток ожидает 0x0000000582e56bc8, что является указателем. Затем вы должны найти - locked <0x0000000582e56bc8>. И вы найдете Thread, который заблокировал объект. Затем я посмотрел на трассировку стека и, наконец, нашел преступника.

Если у вас есть проблемы с com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector, посмотрите на this question.

Answer 1

Итак, как читать стек следы, чтобы найти проблему, как это сделано в комментариях на вопрос по:

Если вы нашли запись, как

at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:82) 
    - waiting to lock <0x0000000582e56bc8> (a java.lang.Class for com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector) 

в вашем трассировки стека вы знаете, что нить пытаясь заблокировать экземпляр объекта, который представлен номером 0x0000000582e56bc8, а текст в фигурных скобках также указывает, что этот объект является экземпляром Class, представляющим класс времени выполнения AccessorInjector.

Поскольку этот объект класса представляет класс, объявляющий метод, возможно, что метод является методом static synchronized, но также возможно, что этот метод содержит конструкцию типа synchronized(AccessorInjector.class).

Для того, чтобы узнать, какие потоки блокируют другие, вам нужно найти поток, у которого трассировка стека содержит соответствующую запись - locked.

Поскольку вы нашли матч в

at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:85) 
    - locked <0x0000000582e56bc8> (a java.lang.Class for com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector) 

мы видим, что нить, которая заблокировала объект выполняет тот же метод, ожидающих потоков, так что все получится правдоподобным, если этот метод synchronized или содержит a synchronized(AccessorInjector.class) блок.

Это свойство инварианта встроенных замков Java, что только один поток может продолжить с блокировкой объекта, в то время как любое количество других потоков должно ждать.