Java 线程：在 lock.wait() 中提供超时参数时出现意外行为

Question

不幸的是，我无法提供完整的上下文，因为周围的代码太复杂了。简而言之：

我有一段代码正在等待锁：

            synchronized (lock) {
                lock.wait();
            }

按预期工作。相当简单——它获取锁，当它开始等待时释放它，另一个线程获取锁，然后通知它。

但是，一旦我提供超时，行为就会完全改变。

            synchronized (lock) {
                lock.wait(60000L);
            }

同样，应该相当简单（这在代码中的其他几个地方可以正常工作）。但是，在这种情况下，执行基本上会停止，直到发生超时。我对似乎正在发生的事情的唯一猜测是它在进入等待时没有释放锁——通知程序永远无法获得锁，所以等待会休眠直到超时。更糟糕的是，这是一个阻塞睡眠——没有其他线程能够等待锁，它会强制执行完全同步。

有人对这里可能发生的事情有任何想法吗？这是一个相当简单的功能，在任何时候嵌套同步块都没有什么奇怪的。考虑到通过不提供超时它应该无限期地等待，如果通知器本身被破坏，代码将永远挂起，但事实并非如此。仅在提供超时后才停止工作。

任何想法将不胜感激。

操作系统：OS X 10.8.5

JDK：1.6.0、1.7.0.45 和 1.7.0.67

Answer 1

您的示例没有显示 wait() 调用周围的 while() 循环。这表明您可能不完全理解等待和通知的用例。这是一个例子：

// This object is used to synchronize *EVERY* method
// that can change the value of count.
final Object lock = new Object();

int count;

void waiter() {
    synchronized(lock) {
        while(count <= 0) {
            lock.wait();
        }
        //do something that you are only allowed to do
        //when count > 0.
    }
}

void notifier() {
    synchronized(lock) {
        count++;
        if (count >= 0) {
            lock.notify();
        }
    }
}

[编辑：添加了这一段，感谢 Nathan Hughes 提醒我...] wait() 调用处于循环中，因为在锁定后等待（）线程仍然需要重新获取锁定通知：如果线程 A 正在等待条件变为真，而线程 B 使条件变为真并调用 notify()；不能保证线程 C 不会首先获得锁，并在 wait() 调用能够返回之前再次使条件为 false。

此外，即使对象没有被通知，wait() 也可以返回（这称为“虚假唤醒”）。

要等待的条件在代码中是明确的（即 count > 0）。

除非在用于 wait() 和 notify() 调用的同一个锁对象上同步，否则不会更改要等待的条件。

Answer 2

无论您是否提供超时，对象的 wait 方法都会释放当前线程持有的锁，正如 John 所评论的那样。

使用您给出的代码并根据您对场景的描述，我的猜测是，在执行 lock.wait(60000L) 的那一刻，JVM 会释放对象上的锁，同时处于可运行/运行状态的任何其他线程可能被拾起，如果它们在同一个对象上同步，那么它们可能会在您的通知线程获取锁之前获取锁。

这种行为很难调试，因为它依赖于 JVM 分析器来选择应该运行的线程。因此，正如您在执行 lock.wait(60000L) 时所解释的那样，通知程序线程不必总是单独获取 common object 上的锁。如果有任何其他线程也在等待公共对象，它可以很好地获得锁，最终导致通知线程无法获得锁，因此 lock.wait(60000L) 超时。

Answer 3

当你使用 lock.wait(..) 时，你必须使用 lock.notify() 或 lock.notifyAll() .确保在逻辑中有意义的地方使用它，它会在超时之前“唤醒”锁（考虑到你输入的超时值就足够了）。这是它的一些使用指南，我希望它有用：http://www.javamex.com/tutorials/wait_notify_how_to.shtml