This is similar to Java thread dump: BLOCKED thread without "waiting to lock ...".
Basically, I am seeing a BLOCKED thread but it has the lock it is wait
A lock is acquired on each Logger
while iterating over its appenders to prevent concurrent changes to the appender collection. If one thread is blocked in an appender (for example, writing events over a network connection) other threads logging to that Logger
instance must wait for the lock. An AsyncAppender
can be used to buffer events and minimize contention, but at the risk of losing events in the buffer.
The strange thing is not that you see "locked" instead of "waiting to lock", but that you don't see "waiting to lock" in addition to "locked". That is, it appears that the thread in question is the one that won the race to acquire the log on a given category, and is now waiting to acquire an additional lock on some other object. The mystery, then, is why doesn't the dump identify the other object?
I think your assumption that its the Logger
on which it already holds the lock is incorrect.
Still wondering what is the exact version you are using?
This is a known cosmetic bug in Oracle's HotSpot JVM. As you say, in your stack trace where you see - locked <0x00007f3e9a0b3830>
it should actually say - waiting to lock <0x00007f3e9a0b3830>
since the thread has not yet acquired the relevant lock.
See this bug for more details.