自定义同步工具

今天药忘吃喽~ 2022-03-26 00:54 202阅读 0赞

状态依赖：并发程序中，其他线程可能改变状态使本线程可以解除阻塞并执行  
状态变量构成前提条件，获取锁的情况下测试前提条件，不满足阻塞（释放锁让其他线程获取锁并改变状态），醒来再获取锁测试前提条件直到成立  
不好的处理：1前提条件失败传递给调用者，调用者必须自己处理失败重试等  
2 内部轮询和休眠，两问题：前提条件为真还在休眠（低响应性），前提条件不为真老是醒来（性能不好）  
考虑使用条件队列：高效，高可响应性，条件谓词（前提条件），一个条件队列可对应多条件谓词（等待不为空和不为满的线程在同一队列），线程被唤醒且恢复执行（已取到锁）后需测试条件谓词（可能其他条件谓词生效或等你取到锁时已有线程又修改了状态）  
丢失的信号（活跃性故障）：不测试条件谓词直接等待（此时条件谓词已经满足了的）  
notify 单一通知 不推荐使用（容易导致信号被劫持，即本该被唤醒没有唤醒） 使用前提：条件队列只对应一个条件谓词且通知后只能唤醒一个线程执行  
notifyAll 性能问题（大量上下文切换和竞争锁），推荐使用  
条件通知 不是每次put都通知，put使状态改变（空变为非空）才通知  
子类处理：1 公开等待通知协议，确保子类能获取并了解如何正确使用  
2禁止子类化：final或封装条件队列，锁，状态变量，确保子类不破坏等待通知协议  
封装条件队列：不暴露 **条件队列和锁**（一般在内置锁下，条件队列和锁为同一对象），否则调用方可能错误地在条件队列上等待，可考虑使用私用锁对象（条件队列）  
入口协议：条件谓词 出口协议：检查修改过的状态变量是否导致某条件谓词为真，并通知相关队列  
内置锁的缺陷：一个锁关联一个队列，很容易公开锁和队列（导致错误等待）  
考虑Lock Condition，Condition继承了Lock的公平性，单一通知可实现fifo  
考虑如何用Lock实现Semaphore：acquire （测试permits是否大于0，否则就在条件队列上等待）  
aqs ：通过state来确认获取操作能否成功，不能可能加入队列或直接失败，释放操作一定成功  
委托机制而不是直接扩展：1保证接口简洁如Lock 2 避免调用者误用  
ReentrantLock: state检查是否被占用和aos检查是否自己占用，cas改state失败（其他线程瞬间抢占）即获取失败  
Semaphore：state检查剩余许可数，cas改state失败（其他线程acquire，重新获取state和cas）  
CountDownLatch: 获取即检查state是否为0，释放state-1，只有state减到0才释放所有线程  
FutureTask: state检查任务是否终止  
ReentrantReadWriteLock: state分2部分，16位读取锁计数，16位写入锁计数