JVM Thread dumps containing monitors without locking threads

Question

What could be the cause of JVM thread dumps that show threads waiting to lock on a monitor, but the monitors do not have corresponding locking threads?

Java 1.5_14 on Windows 2003

Fachanan

Have you got a dump we could see? – Algerian

Answer 1

Does your code by any change use any JNI? (i.e. are you running any native code launched from Java?).

We've seen a similar behavior, but JDK 1.6.0_05. App appears to deadlock, but Jstack shows threads waiting for a lock that no other threads are holding onto. We have some JNI code, so it's possible we're corrupting something.

We haven't found a solution for this and the issue is only reproducible on 1 machine.

Willett

Answer 2

Do those waiting threads wait for ever, or do they eventually proceed?

If the latter, it may be that the lock is held by the garbage collector.

You can add the arguments -verbose:gc with -XX:+PrintGCDetails on your java command line to be told when GCs are occurring. If gc activity coincides with your slowdowns it may indicate that this is the problem.

Here's some information on garbage collection.

Resiniferous

They do eventually proceed after several minutes. How can I confirm if it is held by the garbage collector. Should I expect to see a garbage collector thread in the thread dump? – Fachanan

Answer 3

That's just a wild guess, but could it be, that a thread locks itself by trying to acquire a lock twice? Probably it would help if you could post some code.

Spinozism

Answer 4

Yes normally each monitor which is locked must have an owner Thread. Maybe your stack dump was not complete (too long) or maybe the dumping was not consistent. I could imagine that it is not stopping the world, so a locked monitor is dumped but the thread who owns the lock releases it before beeing dumped (this is just an guess).

Can you some where upload the dump as a text file for easier searching, and tell us which monitor you are looking at.

Urba

Answer 5

I had a similar problem today, and it also involved accesses of static resources.

The short version is that a class made GUI changes in a static block, and outside of the AWT-EventQueue thread, which were blocked by the AWT TreeLock, then the EventQueue made a reference to the blocked class, which forced it to wait on the class loader's monitor for that class.

The key observation here is that the lock for the class loader did not show up as locked in the thread dump.

The full answer can be found on this thread.

Raul

Answer 6

Have you tried upgrading to Java 1.6? A bug could be your issue if you're only on 1.5.

Scroggins