java高级-高性能-多线程并发编程--1.1.5 线程通信_重点API协作

实现多个线程的协同,线程执行先后顺序,获取某个线程执行的结果,等等.

文件共享

写入

读取

线程- 1

文件系统

线程- 2

网络共享

…

共享变量

写入

读取

线程- 1

内存:变量

线程- 2

jdk提供的线程协调API

wait/notify 等待/通知

了解了被弃用的方法,你就了解的原版本的不足和开始的解决方案.
而且新的方法往往修复了原来的问题,做了规定和设计.

这些方法只能由一对锁的持有者线程调用 ==写在同步块内
否则抛出异常 ILLegaLMonitorStateException 非法监控器状态

wait方法导致当前线程等待,放弃当前持有的对象锁 ,加入该对象的等待集合中(相对弃用的方法更新部分)

对应的

notify/notifyAll 方法唤醒一个或多个正在等待这个对象锁的过程.

新规范:
wait可以自动解锁

但是

解决的释放锁,遗留了执行顺序的问题

如果出现老问题 ,唤醒优先于 等待 执行 导致没人来唤醒 时,线程会永远处于waiting状态

park/unpark 等待许可/提供许可给(xx线程)

如果加上锁park/unpark就死锁了

解决了第二个两个问题,用了独立锁之外的方式许可,但第一个问题仍然存在

多次调用提供许可,在调用等待许可 线程直接运行,

但提供的许可不会叠加 ,即

许可给了好多次
前面的线程调用了许可 ,
接下来的线程任然需要等待

suspend/resume

前面挂起,后面回复线程

容易死锁 所以不用了

1. 写同步代码的时候
   挂起后 不会释放锁 ,所以没法唤醒

2. suspend比resume 后执行
   我通知了,你还没挂起 ,等你挂起了 也没人通知了

伪唤醒–>不要用if判断

不要用if判断,是否进入等待状态,原因:涉及底层

等待状态的线程 可能会收到错误警报和伪唤醒 导致无条件退出