<p>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?  </p>

<p>Java 1.5_14 on Windows 2003</p>

[{'answer_id': 65462, 'author': 'jrudolph', 'author_id': 7647, 'author_profile': 'https://Stackoverflow.com/users/7647', 'pm_score': 0, 'selected': False, 'text': "<p>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.</p>\n"}, {'answer_id': 75639, 'author': 'eckes', 'author_id': 13189, 'author_profile': 'https://Stackoverflow.com/users/13189', 'pm_score': 0, 'selected': False, 'text': '<p>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).</p>\n\n<p>Can you some where upload the dump as a text file for easier searching, and tell us which monitor you are looking at.</p>\n'}, {'answer_id': 79588, 'author': 'Joshua McKinnon', 'author_id': 235, 'author_profile': 'https://Stackoverflow.com/users/235', 'pm_score': 1, 'selected': False, 'text': "<p>Does your code by any change use any JNI? (i.e. are you running any native code launched from Java?).</p>\n\n<p>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.</p>\n\n<p>We haven't found a solution for this and the issue is only reproducible on 1 machine.</p>\n"}, {'answer_id': 79671, 'author': 'tgdavies', 'author_id': 11002, 'author_profile': 'https://Stackoverflow.com/users/11002', 'pm_score': 1, 'selected': False, 'text': '<p>Do those waiting threads wait for ever, or do they eventually proceed?</p>\n\n<p>If the latter, it may be that the lock is held by the garbage collector.</p>\n\n<p>You can add the arguments <code>-verbose:gc with -XX:+PrintGCDetails</code> 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.</p>\n\n<p>Here\'s some <a href="http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html" rel="nofollow noreferrer">information on garbage collection</a>.</p>\n'}, {'answer_id': 3728840, 'author': 'Ryan Gross', 'author_id': 428972, 'author_profile': 'https://Stackoverflow.com/users/428972', 'pm_score': 0, 'selected': False, 'text': '<p>I had a similar problem today, and it also involved accesses of static resources.  </p>\n\n<p>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.</p>\n\n<p>The key observation here is that the lock for the class loader did not show up as locked in the thread dump.</p>\n\n<p>The full answer can be found <a href="https://stackoverflow.com/questions/3728125/strange-thread-dump-on-deadlock" title="on this thread">on this thread</a>.  </p>\n'}, {'answer_id': 3728850, 'author': 'Chris Dennett', 'author_id': 87197, 'author_profile': 'https://Stackoverflow.com/users/87197', 'pm_score': 0, 'selected': False, 'text': "<p>Have you tried upgrading to Java 1.6? A bug could be your issue if you're only on 1.5.</p>\n"}]
['https://Stackoverflow.com/questions/64989', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/8530/']