第六讲 - 用"等待-通知"机制优化循环等待
引出问题:
上一篇中,破坏死锁条件之一:占用且等待条件,采用的方式是一次性申请所有资源,并且死循环等待资源;
代码如下:如果申请资源耗时长,并发量大,要循环上万次才能获取锁,非常消耗CPU;
解决方案:
使用线程阻塞的方式避免循环等待消耗CPU问题;当线程要求的条件不满足时,线程应该阻塞自己, 进入
等待状态,当线程要求的条件满足后,通知等待的线程重新执行;
"等待-通知"机制:
方法一:java语言内置synchronized配合wait()、notify()、notifyAll();
0)等待队列与互斥锁是一对一关系,每个互斥锁都有自己的等待队列;
1)同一时刻,只允许一个线程进入synchronized保护的临界区,当有一个线程进入临界区后,其他线程就
只能在左边的等待队列里等待;
2)当一个线程进入临界区后,由于某些条件不满足,需要进入等待状态,java对象的wait()方法就能满足这
种需求,调用wait()方法后,当前线程被阻塞,并且进入右边的等待队列,右边的等待队列也是互斥锁的
等待队列;
3)线程在进入等待队列的同时,会释放持有的互斥锁,线程释放锁后,其他线程就有机会获取锁,进入临
界区;
5)当满足条件时,调用java对象的notify()、notifyAll()方法通知等待队列中的线程,告诉它曾经满足过;
6)notify()、notifyAll()只能保证在通知的时间点条件是满足的,而被通知线程的执行时间点和通知时间点基
本上不会重合,所以当线程执行的时候,很可能条件已经不满足了;
7)被通知的线程想要重新执行,仍然需要获取到互斥锁,因为曾经获取的锁在调用wait()时已经释放了;
8)wait()、notify()、notifyAll()方法操作的等待队列是互斥锁的等待队列;
如果synchronized锁定的是this,那么对应的一定是this.wait()、this.notify()、this.notifyAll();
如果synchronized锁定的是target,那么对应的一定是target.wait()、target.notify()、target.notifyAll();
9)wait()、notify()、notifyAll能被调用的前提是已经获得了相应的互斥锁,所以在synchronized内部被调用;
案例分享:
解决一次性申请转出账户和转入账户问题:
1)互斥锁:因为Allocator是单例的,可以用this作为互斥锁;
2)线程要求的条件:转出账户和转入账户都没有被分配过;
3)何时等待:线程要求的条件不满足就等待;
4)何时通知:当有线程释放账户时就通知;