对象等待集
本质上是让程序员有一定的手段来干预线程的调度

场景:
当线程1上CPU之后,发现执行条件不满足
于是线程1就释放锁下CPU了
当一个线程释放锁之后,其他线程就要开始竞争这把锁,
但是线程1也要参与竞争
然后又让线程1竞争上了,他又进行了上锁
发现执行条件还是不满足,于是释放锁下CPU
然后又重新开始竞争
然后线程1又竞争上了…

于是线程1就频繁的获取锁释放锁
最终导致其他线程就被"饿死"了
严格意义上这不算线程不安全,但是这会影响程序的运行效率这里还是抢占式执行导致的,因为线程运行有优先级,谁优先级高谁就有可能先被调用到CPU上,但是他上了CPU又不执行有用的操作又使其他线程没有机会上CPU执行,所以就导致了其他线程的"饿死"

于是就有了对象等待集.

两个方法:
wait方法:当操作条件不成熟就等待
notify方法:当条件成熟时,通知指定的程序上来工作

一段代码

public static void main(String[] args) throws InterruptedException {Object  object = new Object();System.out.println("等待前");object.wait();System.out.println("等待后");}

运行:

如果线程出发了interrupted方法,那么救护出现InterruptedException异常

java.lang.IllegalMonitorStateException
这个异常叫做IllegalMonitorStateException
第一个词叫做非法的
第二个词叫做监视器
第三个词叫作状态
第四个词叫作异常

监视器就是监视器锁 synchronized 状态异常
当线程调用wait方法的时候,第一件事是先释放锁,再去进行等待.
wait的工作过程:
1.释放锁 (得先有锁才能释放)
2.等待通知 (可能会很久)
3.当收到通知后,尝试重新获取锁,继续往下执行

由于刚刚的代码中没有获得锁,所以会出现异常
wait方法必须在synchronized代码块内部使用,如果不是就会出现异常
notyfy方法也是

    public static void main(String[] args) throws InterruptedException {Object  object = new Object();synchronized (object){System.out.println("等待前");object.wait();System.out.println("等待后");}}

synchronized(locker)是给locker对象加锁
本质是这样:
每个对象内存空间上有一个特殊的区域,“对象头”
对象头中有一个"标志位"(boolean) 默认是false 没加锁
synchronized的时候就是在尝试修改这个locker对象的对象头的锁标记
尝试从flase改成true

所有的类都是直接或者简介继承于Object类

---

场景:
线程1先上CPU上执行操作,但是发现执行条件不成熟
与他线程1释放锁阻塞等待 (不参与后续的锁的竞争) (wait)
线程1要等到被其他线程通知为止 (notify)
这样就避免了抢占式调度带来的一些问题

代码:

public static void main(String[] args) throws InterruptedException {Object locker = new Object();Thread t1 = new Thread() {@Overridepublic void run() {synchronized (locker) {while (true) {try {//针对哪个对象锁,就要调用哪个对象的wait方法System.out.println("进入阻塞等待");System.out.println("wait方法开始");locker.wait();System.out.println("wait方法结束");} catch (InterruptedException e) {e.printStackTrace();}}}}};t1.start();Thread t2 = new Thread() {@Overridepublic void run() {synchronized (locker) {Scanner sc = new Scanner(System.in);System.out.println("输入任意数执行notify");int num = sc.nextInt();System.out.println("notify开始");locker.notify(); //这里还是要对应System.out.println("notyfy结束");}}};t2.start();}

运行结果:

查看线程情况:

堆栈跟踪的第一个方法是本地方法
所谓的本地方法是
java程序跑在jvm上
jvm是用c和c++实现的程序,
当我的程序需要调用到c++方法时,
这些方法就被叫做本地方法,java中的wait本质调用c++的代码
c++调用的操作系统的条件变量的api

线程状态中的WAITING 是使用wait进入阻塞等待时,线程的状态就是WAITING状态.

注意:wait方法和synchronized的对象和notify的对象是要对应的

当前代码执行过程:
线程1先执行,然后获取到锁以后进行等待,一旦开始等待就释放锁,
此时线程2开始执行,并且告知线程1可以继续执行了,此时线程2还没释放锁,
所以线程1不能继续,等到线程2所有指令都执行完成之后释放锁,
此时线程1再去获取锁完成剩余的指令

线程1 线程2

获取锁						创建Scanner对象进入循环						等待对象输入调用wait			
1.释放锁,2.进行等待通知用户输入了整数尝试获取整数(获取成功,线程1内部临时释放了锁)执行notifywait感知到了通知尝试重新获取锁(但是获取失败)释放锁wait尝试重新获取锁(获取成功)继续往下走一个循环

补充:
在一个已经加了锁的代码内部,再次尝试针对这个对象加锁,
此时由于lock对象已经被加锁了,因此第二个对lock加锁操作应该会失败(正常来说要等待第一个锁释放)
于是这个代码看起来是一个死锁
但事实上,这个代码不会死锁,因为synchronized在内部针对这样的情况进行了特殊处理
synchronized底层调用的是操作系统提供的mutex(互斥量)
java中的加锁对应的pthread_mutex_lock函数
如果在一个线程中连续调用两次这个方法,那么就死锁了,
但是synchronized会在加锁的时候判定
如果当前对象已经在当前线程中加过锁了
于是这个操作并不会真的执行lock函数
而是仅仅维护一个"引用计数"
第一次进行syn的时候才真的调用了lock函数,
当引用计数减到0的时候才会真的调用unlock函数
也就避免了死锁
java中的解锁对应的是pthread_mutex_unlock函数
这种特性的锁叫做"可重入锁"

总的来说
wait要做三件事:
1.释放锁
2.等待接收通知
3.收到通知后,尝试重新获取锁

正常情况下是这样的:

	线程1								线程21.释放锁2.等待接收通知发送通知3.收到通知后,尝试重新获取锁

可是也有可能:

	线程1								线程21.释放锁发送通知2.等待接收通知

因为抢占式调度,一旦出现这样的情况,就意味着线程1释放了锁,线程2就获取到锁并发送通知
一旦发送了通知,而线程1还没准备好接受通知,那么通知就错过了,没收到
线程1就会一直等待下去

为了避免这里的静态条件问题

事实上,1和2两个操作在wait中是原子的,也是说说释放锁和准备好接受通知是一气呵成的
所以不会因为线程调度调度产生错过的情况.