AQS 原理

全称是 AbstractQueuedSynchronizer，是阻塞式锁和相关的同步器工具的框架
特点 ：

• 用state 属性来表示资源的状态（分独占模式和共享模式），子类需要定义如何维护这个状态，控制如何获取锁和释放锁
  • getState - 获取 state 状态
  • setState - 设置 state 状态
  • compareAndSetState - cas 乐观锁机制设置 state 状态
  • 独占模式是只有一个线程能够访问资源，而共享模式可以允许多个线程访问资源
• 提供了基于FIFO的等待队列，类似于 Monitor的EntryList
• 条件变量来实现等待、唤醒机制，支持多个条件变量，类似于 Monitor的WaitSet

子类主要实现这样一些方法 （默认抛出UnsupportedOperationException）

• tryAcquire
• tryRelease
• tryAcquireShard
• tryReleaseShard
• isHeldExclusively
  获取锁的优势
  
  释放锁的姿势
  

ReentrantLock 原理

1. 非公平锁实现原理

加锁解锁流程
先从构造器开始看，默认为非公平锁实现

NonfairSync 继承自 AQS
没有竞争时

第一个竞争出现时 ：

Thread-1 执行了

1. CAS尝试将state 由0 改为 1，结果失败
2. 进入 tryAcquire 逻辑，这时state 已经是1，结果任然失败
3. 接下来进入 addWaiter逻辑，构造Node队列
   • 图中黄色三角表示该Node的waitStatus状态，其中0为默认正常状态
   • Node的创建时懒得的
   • 其中第一个 Node称为 Dummy （哑元）或哨兵，用来占位，并不关联线程
     
     当前线程进入 acquireQueued 逻辑
   1. acquireQueued 会在一个死循环中不断尝试获得锁，失败后进入 park 阻塞
   2. 如果自己是紧邻着 head （排第二位），那么再次 tryAcquire 尝试获取锁，当然时 state 仍为1，失败
   3. 进入 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阻塞
  加锁源码

2）可重入原理

3. 可打断原理

不可打断模式
在此模式下，即使它被打断，仍会驻留在AQS队列中，等获得锁后方能继续运行（是继续运行！只是打断标记被设置为true）



可打断模式

5） 条件变量实现原理

每个条件变量其实就对应着一个等待队列，其实现类是 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流程。

3. 读写锁

3.1 ReentrantReadWriteLock

当读操作远远高于写操作时，这时候使用读写锁让 读-读可以并发，提高性能。
类似于数据库中的select 。。。from 。。。lock in share mode
提供一个数据容器类内部分别使用读锁保护数据的read（）方法，写锁保护数据的write（）方法
注意事项

• 读锁不支持条件变量
• 重入时升级不支持 ：即持有读锁的情况下去获取写锁，会导致获取写锁永久等待
  
• 重入时降级支持 ：即持有写锁的情况下去获取读锁
  

缓存更新策略

更新时，是先清缓存还是先更新数据库
先清缓存

先更新数据库

读写锁原理

1. 图解流程
   读写锁同的是同一个Sycn同步器，因此等待队列、state等也是同一个
   t1 w.lock，t2 r.lock

1. 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)成功，修改头结点，流程结束