Java中wait()方法为什么要放在同步块中？

e.printStackTrace();
}
}

但是，为毛呢？？为毛呢？我也不知道啊，经过一番查阅，我找到了答案。

Lost Wake-Up Problem

事情得从一个多线程编程里面臭名昭著的问题"Lost wake-up problem"说起。

这个问题并不是说只在Java语言中会出现，而是会在所有的多线程环境下出现。

假如我们有两个线程，一个消费者线程，一个生产者线程。生产者线程的任务可以简化成先将count加一，而后唤醒消费者；消费者则是先将count减一，而后在减到0的时候陷入睡眠：

生产者伪代码：

count+1;
notify();

消费者伪代码：

while(count<=0)
wait()

count–

这里面有问题。什么问题呢？

生产者是两个步骤：

1. count+1;
2. notify();

消费者也是两个步骤：

1. 检查count值；
2. 睡眠或者减一；

如果这些步骤混在一起会怎样呢？

比如说，初始的时候count等于0，这个时候消费者检查count的值，发现count小于等于0的条件成立；就在这个时候，发生了上下文切换，生产者进来了，噼噼啪啪一顿操作，把两个步骤都执行完了，也就是发出了通知，准备唤醒一个线程。这个时候消费者刚决定睡觉，还没睡呢，所以这个通知就会被丢掉。紧接着，消费者就睡过去了，消费者成睡美人了。

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

尝试解决

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

常见的解决方式是加锁，让消费者和生产者竞争一把锁，竞争到了的，才能够修改count的值。

我这里将两者的两个操作都放进去了同步块中，于是生产者的代码是:

tryLock()

count+1

notify()

releaseLock()

消费者的代码是:

tryLock()

while(count <= 0)
wait()

count-1

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 test2() {
try {
condition.signal();
} catch (Exception e) {
e.printStackTrace();
}
}

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Java开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
资料的朋友可以戳我获取！！**](https://bbs.csdn.net/topics/618164986)

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！