Question

I took a thread dump of a Java program, and it said Found one Java-level deadlock.

Can I confidently affirm that there is a bug in this program?

To me, it sounds like a deadlock is a programming problem, and the only solution is to fix the source code.
Am I wrong? Are there circumstances where a deadlock is a normal part of the program’s execution, and the deadlock eventually somehow disappears?

It is a rather conventional Java web application with hundreds of users. The two threads that are waiting for each other seem to be one Tomcat request worker and one Lucene indexing job, both using sun.misc.Unsafe.park. As far as I know, the program does not have any thread monitoring meta-sophistication.

Answer 1

Are there circumstances where a deadlock is a normal part of the program’s execution, and the deadlock eventually somehow disappears?

In theory yes, depending on the kind of deadlock.

For example, if two threads are Object.wait() deadlocked, one of the wait calls could time out (eventually). Alternatively, a third thread could break the deadlock by calling Thread.interrupt() on one of the deadlocked threads. This might be done as a deliberate deadlock-breaking strategy, or for some other reason.

On the other hand, a deadlock on a acquiring primitive mutexes won’t ever go away of its own accord, and cannot be broken short of calling one of the deprecated Thread stop/kill methods. And if you do that, you are liable to leave data structures in an intermediate state, making it problematic to continue after breaking the lock.

---

The key thing to look for is whether the blocking action is interruptible; e.g. whether it can throw an InterruptedException or similar.