【小家java】并发编程中wait/notify await/singal notify/notifyAll sleep/yield 的区别以及死锁案例
【小家java】并发编程中wait/notify await/singal notify/notifyAll sleep/yield 的区别以及死锁案例
并发编程中，容易混淆的一些概念和方法使用，本文来解惑。
常用的sleep两种方式：（都会抛出InterruptedException） 1、Thread.sleep(2000) 2、TimeUnit.SECONDS.sleep(2) 推荐使用，因为语意更加清晰
是否释放锁：
调用sleep和yield的时候不释放当前线程所获得的锁，但是调用await/wait的时候却释放了其获取的锁并阻塞等待。
调用后何时恢复：
sleep让线程阻塞，且在指定的时间之内都不会执行，时间到了之后恢复到就绪状态，也不一定被立即调度执行； yield只是让当前对象回到就绪状态，还是有可能马上被再次被调用执行。 await/wait，它会一直阻塞在条件队列之上，之后某个线程调用对应的notify/signal方法，才会使得await/wait的线程回到就绪状态，也是不一定立即执行。 下面贡献一幅图，一目了然：
wait/notify await/singal 的使用区别
在使用Lock之前，我们都使用Object 的wait和notify实现同步的。举例来说，一个producer和consumer，consumer发现没有东西了，等待，produer生成东西了，唤醒。形如下面的伪代码：
线程consumer
synchronize(obj){
obj.wait();//没东西了，等待
}
线程producer
synchronize(obj){
obj.notify();//有东西了，唤醒
}有了lock后，世道变了，现在是：
//生产
lock.lock();
condition.await();
lock.unlock();
//消费
lock.lock();
condition.signal();
lock.unlock();为了突出区别，省略了若干细节。区别有三点：
- lock不再用synchronize把同步代码包装起来；
- 阻塞需要另外一个对象condition；
- 同步和唤醒的对象是condition而不是lock，对应的方法是await和signal，而不是wait和notify。
为什么需要使用condition呢？简单一句话，lock更灵活。以前的方式只能有一个等待队列，在实际应用时可能需要多个，比如读和写。为了这个灵活性，lock将同步互斥控制和等待队列分离开来，互斥保证在某个时刻只有一个线程访问临界区（lock自己完成），等待队列负责保存被阻塞的线程（condition完成）。
通过查看ReentrantLock的源代码发现，condition其实是等待队列的一个管理者，condition确保阻塞的对象按顺序被唤醒。
wait()和notify()必须在synchronized的代码块中使用 因为只有在获取当前对象的锁时才能进行这两个操作 否则会报异常 而await()和signal()一般与Lock()配合使用
notify和notifyAll有什么区别
notify():唤醒在此对象监视器上等待的单个线程。 notifyAll():唤醒在此对象监视器上等待的所有线程。线程通过调用其中一个 wait 方法，在对象的监视器上等待。
先说两个概念：锁池和等待池
- 锁池:假设线程A已经拥有了某个对象(注意:不是类)的锁，而其它的线程想要调用这个对象的某个synchronized方法(或者synchronized块)，由于这些线程在进入对象的synchronized方法之前必须先获得该对象的锁的拥有权，但是该对象的锁目前正被线程A拥有，所以这些线程就进入了该对象的锁池中。
- 等待池:假设一个线程A调用了某个对象的wait()方法，线程A就会释放该对象的锁后，进入到了该对象的等待池中
所以我们可以很容易看到这两者的区别了：
- 如果线程调用了对象的 wait()方法，那么线程便会处于该对象的等待池中，等待池中的线程不会去竞争该对象的锁。
- 当有线程调用了对象的 notifyAll()方法（唤醒所有 wait 线程）或 notify()方法（只随机唤醒一个 wait 线程），被唤醒的的线程便会进入该对象的锁池中，锁池中的线程会去竞争该对象锁。也就是说，调用了notify后只要一个线程会由等待池进入锁池，而notifyAll会将该对象等待池内的所有线程移动到锁池中，等待锁竞争
- 优先级高的线程竞争到对象锁的概率大，假若某线程没有竞争到该对象锁，它还会留在锁池中，唯有线程再次调用 wait()方法，它才会重新回到等待池中。而竞争到对象锁的线程则继续往下执行，直到执行完了 synchronized 代码块，它会释放掉该对象锁，这时锁池中的线程会继续竞争该对象锁。
综上，所谓唤醒线程，另一种解释可以说是将线程由等待池移动到锁池，notifyAll调用后，会将全部线程由等待池移到锁池，然后参与锁的竞争，竞争成功则继续执行，如果不成功则留在锁池等待锁被释放后再次参与竞争。而notify只会唤醒一个线程。有了这些理论基础，后面的notify可能会导致死锁，而notifyAll则不会的例子也就好解释了
死锁案例
public class NotifyDeadLockDemo {
public static void main(String[] args) {
final OutTurn outTurn = new OutTurn();
for (int i = 0; i < 100; i++) {
new Thread(() -> {
for (int j = 0; j < 5; j++) {
outTurn.sub();
}
}).start();
new Thread(() -> {
for (int j = 0; j < 5; j++) {
outTurn.main();
}
}).start();
}
}
}
class OutTurn {
private boolean isSub = true;
private int count = 0;
public synchronized void sub() {
try {
while (!isSub) {
this.wait();
}
System.out.println("sub --- " + count);
isSub = false;
this.notify();
} catch (InterruptedException e) {
e.printStackTrace();
}
count++;
}
public synchronized void main() {
try {
while (isSub) {
this.wait();
}
System.out.println("main --- " + count);
isSub = true;
this.notify();
} catch (InterruptedException e) {
e.printStackTrace();
}
count++;
}
}
输出：
死锁了原因分析： OutTurn类中的sub和main方法都是同步方法，所以多个调用sub和main方法的线程都会处于阻塞状态，等待一个正在运行的线程来唤醒它们。下面分别分析一下使用notify和notifyAll方法唤醒线程的不同之处：
- 上面的代码使用了notify方法进行唤醒，而notify方法只能唤醒一个线程，其它等待的线程仍然处于wait状态，假设调用sub方法的线程执行完后（即System. out .println("sub ---- " + count )执行完之后），所有的线程都处于等待状态，此时在sub方法中的线程执行了isSub=false语句后又执行了notify方法，这时如果唤醒的是一个sub方法的调度线程，那么while循环等于true，则此唤醒的线程也会处于等待状态，此时所有的线程都处于等待状态，那么也就没有了运行的线程来唤醒它们，这就发生了死锁。
- 如果使用notifyAll方法来唤醒所有正在等待该锁的线程，那么所有的线程都会处于运行前的准备状态（就是sub方法执行完后，唤醒了所有等待该锁的状态,注：不是wait状态），那么此时，即使再次唤醒一个sub方法调度线程，while循环等于true，唤醒的线程再次处于等待状态，那么还会有其它的线程可以获得锁，进入运行状态。
总结：notify方法很容易引起死锁，除非你根据自己的程序设计，确定不会发生死锁，notifyAll方法则是线程的安全唤醒方法。