Normally when I ask for a thread dump, the symptoms of a poorly performing system are easily explained; i.e. normally I would be able to see that a number of threads are clearly waiting on a monitor which has been acquired but not released by another.
In this case, I have a lot of threads waiting for a monitor (0x965ad100), but none appears to have that monitor in the first place. The threads in question can be identified with this signature:
waiting to lock <0x965ad100> (a uk.gov.dti.og.fox.ConAgent)
I've tried Googling this, and all I seem to find are posts that discuss monitors that are locked, nothing about waiting for a monitor that isn't locked.
Thread dump in full: http://www.basson.at/docs/stackoverflow/thread_dump.txt
I hope someone here can explain what I'm seeing, or at least point me in the right direction. Thanks in advance for any responses.
It is possible (although unlikely) that a thread just released the monitor when your thread dump was taken. There can be a brief period between when a monitor is released and the next thread gets it. If you're not in an actual deadlock, this could explain what you are seeing. Try another thread dump and check that one.
More likely, there is a thread in there somewhere that already holds the monitor. Sometimes it isn't obvious. Your stack traces have some "locked" lines which list threads which hold certain locks, but that list isn't necessarily complete. For instance, I suspect locks obtained via JNI aren't listed.
If you could replace the built-in lock with, e.g. java.util.concurrent.locks.ReentrantLock, then you could suspend the program and attach a debugger, find the lock you care about, and find the lock owner using the getOwner method.
If you're using Eclipse, you can use the built-in lock viewer via the Debug view which might be helpful. You can enable it using the drop down menu accessible via the downward arrow in the toolbar :)
来源：https://stackoverflow.com/questions/4174560/java-threads-waiting-to-lock-object-that-isnt-visibly-locked