并发编程之J.U.C
全称是 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)成功,修改头结点,流程结束
来源:https://www.cnblogs.com/haizai/p/12345633.html