? ? ? ? 所谓的wait和notify其实就是等待、通知机制;该机制的作用域join类似;由于多个线程之间是随机调度的,引入wait和notify就是为了能够从应用层面上,干预到多个不同线程代码的执行顺序,此处的干预,不是影响系统的线程调度策略(内核里调度线程任然是无序调度);
? ? ? ? 简单来说就是在应用程序代码中,让后执行的线程,主动放弃被调度的机会,就可以让先执行的线程,先把对应的代码执行完成;
????????现在有很多人要去ATM里,其中A是取钱,B是存钱的,C是运钞票的工作人员,负责给ATM机补充钱,防止ATM机没钱了,别人取不到钱。
????????而这里的A,B,C被当做是线程,每次去ATM机里,只能有一个人进去,相当于上锁了,其他人不能进去,且处于被阻塞等待的状态,等ATM机里面的人完成操作出来后,别的人才能进去,但是这里是多线程随机调度的原因,其他线程会有锁竞争。 ? ??
? ? ? ? 其中当A进去ATM机里后,就上锁,其他人不能进去;
? ? ? ? 从线程调度执行的角度来看,如果把A比作是线程,当A线程进去后就会上锁,A线程要进行取钱的操作,其他线程不能进去操作,当A线程执行完自己的操作后,其他线程才能去锁竞争。
????????但是如果ATM机里面没有钱时,A线程就不能完成取钱这个操作,它会退出ATM机,但退出后呢,它就因为没有取到钱而想继续进去ATM里面取钱,从而完成完成取钱这个操作;
????????但是A依旧就会继续和其他线程进行锁竞争,又因为A线程之前拿到了锁,处于RUNNABLE状态(本来就轮到A取),其他线程因为阻塞,处于BLOCKED状态,需要被系统唤醒后,才能去竞争锁;
? ? ? ? 总体来说,在ATM中依旧没有钱,线程A不用唤醒就能去竞争锁,所以A线程拿到锁的可能性还是很大的。但是如果这样子,那线程A频繁的在ATM门口反复横跳,始终占据的锁很长时间,导致其他线程(包括给ATM机送钱的线程)也不能进去操作,这样也就出现线程安全问题了。对于其他线程,始终无法拿到锁,这个情况称为 “线程饿死”。
? ? ? ? 上述所说的线程A的代码大概逻辑是这样的:
????????当A线程没有取到钱,就会一直重复加锁,解锁的操作。虽然这样的bug没有死锁那么严重,但也是要解决的。这时,就可以用wait和notify机制期望改进成如下图逻辑所示的效果:
这里的wait内部做了三件事
(1)释放锁,给其他线程竞争锁
(2)进入阻塞等待,让及时需要操作的线程运行
(3)等其他线程使用notify后,解除wait,参与到锁竞争中
????????wait的使用前提必须是当前对象被上锁了才能使用,不能你对象没被上锁,就wait了,那也不知道是在wait谁。
????????有线程wait后,也必须有其他线程notify来释放这个wait,不然这个wait就会一直阻塞。
? ? ? ? 代码如下:
package thread; public class ThreadDemo29 { public static void main(String[] args) throws InterruptedException { Object locker = new Object(); locker.wait(); } }
? ? ? ? 结果如下:
? ? ? ? 代码如下:
package thread; public class ThreadDemo29 { public static void main(String[] args) { Object locker = new Object(); Thread t1 = new Thread(() -> { synchronized (locker) { System.out.println("wait之前"); try { locker.wait(); } catch (InterruptedException e) { throw new RuntimeException(e); } System.out.println("wait之后"); } }); t1.start(); } }
? ? ? ? 结果如下:
? ? ? ? 当前锁对象在进行wait之后,没有在主线中使用notify来唤醒,导致该线程t1一在处于阻塞状态;
? ? ? ? 代码如下:
package thread; public class ThreadDemo29 { public static void main(String[] args) { Object locker = new Object(); Thread t1 = new Thread(() -> { synchronized (locker) { System.out.println("t1 wait之前"); try { locker.wait(); } catch (InterruptedException e) { throw new RuntimeException(e); } System.out.println("t2 wait之后"); } }); Thread t2 = new Thread(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) { throw new RuntimeException(e); } synchronized (locker) { System.out.println("t2 notify之前"); locker.notify(); System.out.println("t2 notify之后"); } }); t1.start(); t2.start(); } }
? ? ? ? 结果如下:
? ? ? ? 我们代码里释放wait的notify,用的锁对象必须是要一样的,如果不一样,wait是不能被释放的,t1也就不能被唤醒了.
????????在系统中,notify可以不用上锁,但是在java中,规定了要上锁,而且上锁的对象也要和notify对象一样,所以和系统是有区别的。
? ? ? ? 结果具体分析:
结果解析:
????????t1 和 t2 执行的时候:
? ? ? ? 1、因为t1 sleep了1秒,所以能保证t1 先wait,所以先打印 “t1 wait之前”,这时,t1就进入阻塞等待状态。
? ? ? ? 2、t2线程sleep了1秒后,获得这个locker锁,打印“t2 notify 之前”,当t2线程执行了notify后,t1 线程的wait就被释放了。
? ? ? ? 3、因为t2还在持有锁,所以t1会还会进入阻塞,t2打印 “t2 notify之后” ,释放锁。
? ? ? ? 4、t1拿到锁,再打印“t1 wait之后”。
????????唤醒等待这个对象的所有线程;
????????假设有很多个线程,都使用同一个对象wait,这时,使用notifyAll,所有使用了这个对象的wait的线程,都会被唤醒。
? ? ? ? 但是当这些线程都被唤醒时,就要重新获取锁,他们还是要进行锁竞争的,这里也就相当于串行执行了(线程调度还是随机调度的)。而且使用notifyAll后,全部使用同一对象wait的线程,都被唤醒了,不好控制,更加推荐使用notify。
???????没有参数的就是死等,但是很多情况,死等是不合理的,所以我们加参数,就是让某个线程在一定时间wait,如果超出了这个时间,就不wait了,直接去掉wait。
????????有一个参数的精确范围是毫秒级别,两个参数的精确范围是纳秒级别。
????????wait:需要搭配synchronized使用,线程wait时,处于WAITING状态,需要其他线程notify后,才能被唤醒,或者设置时间,到时就唤醒,可以兜底。
????????sleep:线程sleep时,要到一定休眠时间才能被唤醒,但是也能被interrupt终止,但是这种情况是会抛异常的,是非常规手段,不符合我们预期的效果。
????????join:啥线程调用join,当前线程就要等啥线程执行完,才能之前当前线程;和wait一样有参数可以选择,到时就不等了。
ps:本次的内容就到这里了,如果感兴趣的话就请一键三连哦!!!
?