In the below thread dump:No it isn't. The first thread is BLOCKED waiting for the lock, the second thread is RUNNABLE and holding the lock.
The vector object 0x94fb1580 is locked in two threads (*DwgCmdExecutionThread:UXPRD150:16975* and DwgCmdExecutionThread:UXPRD150:16404).
Sachin Thatte wrote:Presumably it's simply showing that the lock is currently held, not indicating that the current thread is what's holding it.
Although the first thread is BLOCKED, the thread dump indicates that a lock is acquired in that thread? Why does the dump say 'locked' in the stack trace? That is confusing...
EJP wrote:I can't tell whether there's a problem or not. The OP hasn't indicated if he observed a problem or not, but if there are indeed two threads holding the same lock (which it seems might be the case based on OP's other observations that refute my initial theory), then, deadlock or not, there's a serious bug. I'm still thinking there's another explanation.
There doesn't appear to be a real problem here. There is no deadlock, one thread is runnable, the others are all blocked.
Sachin Thatte wrote:You might want to confirm that assumption if you're going to operate under it.
My assumption is that when a thread dump is taken, the JVM provides a consistent snapshot picture at an instant in the life of the JVM (pausing the running threads).
If that is not the case, most of thread analysis goes out of the window.Not really. The only part you lose is finding bugs in the JVM, which isn't what the thread dump is really for, and not something that most Java developers concern themselves with. You can still find deadlocks, see which threads are blocked for long periods of time, etc. In my experience, there's more to be gained from a picture of the overall flow than from a snapshot at an arbitrary instant.