"Found 1 deadlock" but trace shows that not locked by any thread

Question

The JVM tells me that a deadlock has occurred:

Found one Java-level deadlock:
=============================
"TP-Processor107":
  waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
  which is held by "indexTrackerThread3"
"indexTrackerThread3":
  waiting for ownable synchronizer 0x00002aaaf4394580, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
  which is held by "TP-Processor16"
"TP-Processor16":
  waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
  which is held by "indexTrackerThread3"

We can see that indexTrackerThread3 is waiting for a resource held by TP-Processor16, and vice-versa. That is indeed a deadlock.

We can see that indexTrackerThread3 is waiting for 0x00002aaaf4394580:

"indexTrackerThread3":
    - parking to wait for  <0x00002aaaf4394580>

My question:

In the threads dump, why is there no line - locked <0x00002aaaf4394580> ?

It seems like 0x00002aaaf58e70f0 is actually not locked by any thread. What could be locking it?

In all the deadlock documentation I have read (example), for every different - parking to wait for <0x123> line, there is always one - locked <0x123> line. So I begin suspecting a JVM bug. Am I misunderstanding something?

Note: Sorry for linking to pastebin, but the question is not answerable without having the full dump. For brevity, I removed all lines that contained " at", they do not include any lock information.

Answer 1

The java.util.concurrent package utilizes an extralingual, native parking mechanism (as well as other native mechanisms, such as an atomic compare-and-swap). You can see what I'm talking about here.

The pattern you describe as usually occuring in the thread dump stems from the classic Java idiom synchronized(lock) { lock.wait(); }.