Java thread dump, can't find thread that blocking others

Question

Our application is lagging.

I'm get thread dump using jstack util.

I do a data preparation and sort it. And this is what I have:

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 threads are BLOCKED.

As I understand from waiting to lock <0x0000000582e56bc8>, they all waiting some thread with ID 0x0000000582e56bc8. The strange thing is that I cannot find this 0x0000000582e56bc8 in thread dump output, I cannot find what they all waiting for.

Or it is not true? What is this 0x0000000582e56bc8?

Here is little peace of dump:

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

All 198 other thread dumps are the same

Update 1. After @Holder comment

"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 Thanks for @Holder

As I understand waiting to lock <0x0000000582e56bc8>, means that thread is waiting for 0x0000000582e56bc8, which is a pointer. Next you should find - locked <0x0000000582e56bc8>. And you will find Thread that locked an object. Then I looked at stack trace and finally, find the culprit.

If you have also problem with com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector, look at this question.

Answer 1

To summarize how to read the stack traces to find the problem as done in the question’s comments:

If you find an entry like

  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)

within your stack trace you know that the thread is trying to lock an object instance which is represented by the number 0x0000000582e56bc8 and the text in the braces tell you further that this object is the Class instance representing the runtime class AccessorInjector.

Since this class object represent the class that is declaring the method it is possible that the method is a static synchronized method but it is also possible that the method contains a construct like synchronized(AccessorInjector.class).

So you have to find a thread whose stack trace contains a matching - locked entry to learn which threads blocks the others.

Since you found the match as

  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)

we see that the thread which has locked the object is executing the same method as the waiting threads so everything turn out to be plausible if this method is synchronized or contains a synchronized(AccessorInjector.class) block.

It’s the invariant property of Java’s intrinsic locks that only one thread can proceed with having the object locked while an arbitrary number of other threads must wait.