全称是 AbstractQueuedSynchronizer，是阻塞式锁和相关的同步器工具的框架
特点 ：
- 用state 属性来表示资源的状态（分独占模式和共享模式），子类需要定义如何维护这个状态，控制如何获取锁和释放锁
- getState - 获取 state 状态
- setState - 设置 state 状态
- compareAndSetState - cas 乐观锁机制设置 state 状态
- 独占模式是只有一个线程能够访问资源，而共享模式可以允许多个线程访问资源
- 提供了基于FIFO的等待队列，类似于 Monitor的EntryList
- 条件变量来实现等待、唤醒机制，支持多个条件变量，类似于 Monitor的WaitSet
子类主要实现这样一些方法 （默认抛出UnsupportedOperationException）
- tryAcquire
- tryRelease
- tryAcquireShard
- tryReleaseShard
- isHeldExclusively
获取锁的优势
释放锁的姿势
加锁解锁流程
先从构造器开始看，默认为非公平锁实现
NonfairSync 继承自 AQS
没有竞争时
第一个竞争出现时 ：
Thread-1 执行了
- CAS尝试将state 由0 改为 1，结果失败
- 进入 tryAcquire 逻辑，这时state 已经是1，结果任然失败
- 接下来进入 addWaiter逻辑，构造Node队列
- 图中黄色三角表示该Node的waitStatus状态，其中0为默认正常状态
- Node的创建时懒得的
- 其中第一个 Node称为 Dummy （哑元）或哨兵，用来占位，并不关联线程
当前线程进入 acquireQueued 逻辑
- acquireQueued 会在一个死循环中不断尝试获得锁，失败后进入 park 阻塞
- 如果自己是紧邻着 head （排第二位），那么再次 tryAcquire 尝试获取锁，当然时 state 仍为1，失败
- 进入 shouldParkAfterFailedAcquire 逻辑，将前驱 node，即 head 的waitStatus改为 -1，这次返回false
再次多个线程经历上述过程竞争失败，变成这个样子
Thread-0 释放锁，进入tryRelease 流程，如果成功
- 设置exclusiveOwnerThread为null
- state = 0
当队列不为null，并且head的waitStatus = -1，进入unparkSuccessor 流程找到队列中离head最近的一个Node（没取消的），unpark恢复其运行，本例中即为Thread-1
回到 Thread-1 的acquireQueued 流程
回到 Thread - 1的 acquireQueued 流程
如果加锁成功（没有竞争），会设置 - exclusiveOwnerThread 为 Thread - 1，state = 1
- head 指向刚刚 Thread - 1 所在的Node，该Node清空Thread
- 原本的head因为从链表断开，而可被垃圾回收
如果这时候有其它线程来竞争（非公平的体现），例如这时有Thread - 4来了
如果不巧又被 Thread - 4 占了先 - Thread - 4被设置为 exclusiveOwnerThread，state = 1
- Thread - 1再次进入 acquireQueued 流程，获取锁失败，重新进入 park阻塞
加锁源码
不可打断模式
在此模式下，即使它被打断，仍会驻留在AQS队列中，等获得锁后方能继续运行（是继续运行！只是打断标记被设置为true）
可打断模式
每个条件变量其实就对应着一个等待队列，其实现类是 ConditionObject
await 流程
开始 Thread - 0 持有锁，调用await，进入ConditionObject 的addConditionWaiter流程创建新的Node状态为 -2 （Node.CONDITION），关联Thread - 0，加入等待队列尾部
接下来进入AQS的fullyRelease流程，释放同步器上的锁
unpark AQS 队列中的下一个节点，竞争锁，假设没有其他竞争线程，那么Thread - 1竞争成功
park 阻塞 Thread - 0
signal
假设Thread - 1 要来唤醒 Thread - 0
进入 ConditionObject 的doSignal流程，取得等待队列中第一个 Node，即Thread - 0所在Node
执行transferForSignal 流程，将该Node 加入AQS队列尾部，将Thread - 0
的waitStatus改为0，Thread - 3的waitStatus改为 - 1
Thread - 1 释放锁，进入unlock流程。
当读操作远远高于写操作时，这时候使用读写锁让 读-读可以并发，提高性能。
类似于数据库中的select 。。。from 。。。lock in share mode
提供一个数据容器类内部分别使用读锁保护数据的read（）方法，写锁保护数据的write（）方法
注意事项
- 读锁不支持条件变量
- 重入时升级不支持 ：即持有读锁的情况下去获取写锁，会导致获取写锁永久等待
- 重入时降级支持 ：即持有写锁的情况下去获取读锁
更新时，是先清缓存还是先更新数据库
先清缓存
先更新数据库
- 图解流程
读写锁同的是同一个Sycn同步器，因此等待队列、state等也是同一个
t1 w.lock，t2 r.lock
- t1成功上锁，流程与ReentrantLock 加锁相比没有特殊之处，不同是写锁状态占了state的低16位，而读锁使用的是state的高16位
2）t2 执行 t.lock，这时进入读锁的 sync.acquireShared(1)流程，首先会进入tryAcquireShard流程。如果有写锁占据，那么tryAcquireShared返回-1 表示失败
tryAcquireShared 返回值表示- -1 表示失败
- 0 表示成功，但后继节点继续唤醒
- 正数表示成功，而且数值是还有几个后继节点需要唤醒，读写锁返回1
3）这时会进入 sync.doAcquireShared(1)流程，首先也是调用 addWaiter添加节点，不同之处在于节点被设置为 Node.SHARED 模式而非 Node.
EXCLUSIVE模式，注意此时t2仍处于活跃状态
4）t2会看看自己的节点是不是老二，如果是，还会再次调用tryAcquireShared(1)来尝试获取锁
5）如果没有成功，在doAcquireShared 内 for (;;)循环一次，把前驱节点的waitStatus改为 -1，再for(;;)循环一次尝试tryAcquireShared(1)如果还不成功，那么在parkAndCheckInterrupt()处park
t3 r.lock, t4 w.lock
这种状态下，假设又有t3 加读锁和t4加写锁，这期间t1任然持有锁，就编程了下面样子
t1 w.unlock
这时会走到写锁的 sync.release(1)流程，调用sync.tryRelease(1)成功，变成下面的样子
接下来执行唤醒流程 sync.unparkSuccessor，即让老二恢复运行，这时 t2 在doAcquireShared 内 parkAndCheckInterrupt()处恢复运行
这回再来一次 for(;;)执行 tryAcquireShared成功则让读锁计数加一
这时t2 已经恢复运行，接下来t2调用 setHeadAndPropagate(node, 1)，它原本所在节点被置为头节点
事情还没完，在setHeadAndPropagate 方法内还会检查下一个节点是否是 shared，如果是则调用 doReleaseShared 将head的状态从 -1 改为 0并唤醒老二，这时t3在 doAcquireShared 内 parkAncCheckInterrupt() 会恢复运行
这回再来一次for(;;)执行tryAcquireShared 成功则让读锁计数加一
这时t3 已经恢复运行，接下来t3 调用 setHeadAndPropagate(node,1),它原本所在节点被置为头节点
下一个节点不是shared了，因此不会继续唤醒t4所在节点
t2 r.unlock, t3 r.unlock
t2 进入 sync.releaseShared(1)中，调用 tryReleaseShared(1)让计数减一，但由于计数为零
t3 进入 sync.releaseShared(1)中，调用tryReleaseShared(1)让计数减一，这回计数为零了，进入doReleaseShared()将头节点从-1改为0并唤醒老二，即
之后 t4 在acquireQueued 中 parkAndCheckInterrupt 处恢复运行，再次for(;;)这次自己是老二，并且没有其他竞争，tryAcquire(1)成功，修改头结点，流程结束