某天我在***的时候，突然有个小伙伴微信上说：“哥，阿里面试又又挂了，被问到为什么wait()方法要放在同步块中，没答出来！”

但是，为毛呢？？我也没去了解过。

机智如我立刻假装正在开会忙得不可开交，回了一条：“开会中，等会和你细说。”

这就是所谓的lost wake up问题。

那么怎么解决这个问题呢？

现在我们应该就能够看到，问题的根源在于，消费者在检查count到调用wait()之间，count就可能被改掉了。

这就是一种很常见的竞态条件。

很自然的想法是，让消费者和生产者竞争一把锁，竞争到了的，才能够修改count的值。

于是生产者的代码是：

tryLock()
count+1
notify()
releaseLock()

消费者的代码是:

tryLock()
while(count <= 0) wait()
count-1
releaseLock

注意的是，我这里将两者的两个操作都放进去了同步块中。

现在来思考一个问题，生产者代码这样修改行不行？

tryLock()
count+1
notify()
releaseLock()

答案是，这样改毫无卵用，依旧会出现lost wake up问题，而且和无锁的表现是一样的。

终极答案

所以，我们可以总结到，为了避免出现这种lost wake up问题，在这种模型之下，总应该将我们的代码放进去的同步块中。

Java强制我们的wait()/notify()调用必须要在一个同步块中，就是不想让我们在不经意间出现这种lost wake up问题。

不仅仅是这两个方法，包括java.util.concurrent.locks.Condition的await()/signal()也必须要在同步块中：

private ReentrantLock lock = new ReentrantLock();
private Condition condition = lock.newCondition();
@Test public void test() { try { condition.signal(); } catch (Exception e) { e.printStackTrace(); } }