Java Object.wait（0）和Condition.wait（）返回失败？

几年前，在花了几天时间试图解决死锁问题后，我被告知（由于JVM和/或操作系统中的错误），在某些情况下Object.wait（0）可能无法在应该返回的时候返回，并且我永远不应该对监视器或锁使用无限阻塞调用。添加一个非零参数是有效的，从那以后我在所有代码中都使用了这种模式

例如，代码如下所示：

synchronized (monitor) {
    while (monitor_condition) {
        monitor.wait(0L);
    }
}
// or
lock.lock();
try {
    while (lock_condition) {
        condition.await();
    }
} finally {
    lock.unlock();
}

相反，我是这样写的（几十年来一直如此）：

最近，在一次代码审查中，有人问我为什么要写这样的代码，（在讲述了我的战争故事之后），我决定在互联网上四处寻找当前的文献或工作故事，看看其他人是否仍然存在类似的死锁问题，比如无限阻塞版本的wait and wait。我什么也没找到

由于上述两个代码块在技术上都没有什么不正确的地方（我的首选方法只是使用比必要的多几个CPU周期），所以这个问题更多的是一个集体的注释请求。我将在这里发布我的问题，不管它是编程相关的

无论如何，我想知道是否有人使用现代JVM（如1.7+）经历过所谓的伪死锁（与Java 1.[78]Java文档中的伪唤醒相比）当监视器收到通知或发出条件信号时，被阻止的线程无法从无限等待或等待调用返回

i、 例如，给定代码以取消阻止上面的示例，沿着以下几行：

synchronized (monitor) {
    monitor_condition = false;
    monitor.notifyAll();
}
// or
lock.lock();
try {
    lock_condition = false;
    condition.signalAll();
} finally {
    lock.unlock();
}

---

有没有人观察到过这样的行为：在解锁代码的代码完成时，上面第一个示例中的wait或wait方法无法返回（就像在无限等待中一样，被卡住了）？

特别是，我没有寻找由于代码导致的错误，但是，如果代码正确，阻塞API无法返回。这可能是一个Future.get（）、Object.wait、Condition.wait（）或任何由于底层实现中的问题而无法返回的高级构造。我从未听说过或见过此类代码。技术文献、文章、博客文章中的任何链接或引用，甚至用遗留的开源代码编写文档也很理想。当然，个人的战争故事也会被欣赏。特别是，我不会寻找由于代码导致的错误，但是，如果代码正确，阻塞API无法返回。这可能是一个Future.get（）、Object.wait、Condition.wait（）或任何由于底层实现中的问题而无法返回的高级构造。我从未听说过或见过此类代码。技术文献、文章、博客文章中的任何链接或引用，甚至用遗留的开源代码编写文档也很理想。当然，个人战争故事也会被欣赏。

synchronized (monitor) {
    monitor_condition = false;
    monitor.notifyAll();
}
// or
lock.lock();
try {
    lock_condition = false;
    condition.signalAll();
} finally {
    lock.unlock();
}