自定义同步工具

状态依赖：并发程序中，其他线程可能改变状态使本线程可以解除阻塞并执行
状态变量构成前提条件，获取锁的情况下测试前提条件，不满足阻塞（释放锁让其他线程获取锁并改变状态），醒来再获取锁测试前提条件直到成立
不好的处理：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位写入锁计数