1, 线程同步一般有两种基础设施:mutex和condition variable


mutex对应java中的锁,condition variable对应java中的wait/notify
java中的锁和wait/notify都有两种:
1, 对象固有的,锁对应oop中的mark word中的锁标志位,也即是synchronized底层的实现机制,wait/notify对应Object中的对应方法。
但是基于对象固有锁的synchronized不能跨越方法边界。wait/notify依赖synchronized,所以会有相同的限制。
于是就有了今天的主角:java.util.concurrent.locks.AbstractQueuedSynchronizer,简称AQS
AQS类似hotspot中对象固有锁的实现机制,重新实现了mutex和condition variable,移除了不能跨越方法边界的限制,使得CountDownLatch之类的高级同步原语可以方便的实现。
2, 从AQS的名字可以看出来是基于队列实现的,AQS的核心状态都在head和tail表示的双链表队列上,另一个状态是int类型的state。AQS基于抽象模板设计模式实现了锁机制,保留了4个try开头的protected方法基于读写state实现具体的锁机制。
tryAcquire:尝试获取互斥锁,子类应该先检查state是否允许获取互斥锁
tryRelease:修改state表明互斥锁被释放
tryAcquireShared:尝试获取共享锁,子类应该先检查state是否允许获取共享锁,return 负值表示获取共享锁失败,0表示后续节点不能获取共享锁,正数表示后续节点也能获取共享锁
tryReleaseShared:修改state表明共享锁被释放
下面围绕互斥锁/共享锁的获取和释放分析AQS实现机制
3, 获取互斥锁

先尝试获取锁,失败之后,加入同步队列

加入队列之后,死循环,直到当前线程成为第一个节点,然后再尝试获取锁,获取锁成功之后,当前节点成为head节点

获取锁失败时,确保当前线程有机会被队列中的前置节点唤醒,理解此处需要参考下文释放共享锁的过程

获取共享锁失败,确保有机会被唤醒之后,暂停当前线程等待被唤醒,然后检查暂停过程中是否被打断过。
4, 释放互斥锁

释放互斥锁,唤醒后继节点,参照前面获取锁的过程,节点不在队列头时,会被暂停等待被队列前面的节点唤醒,正是此处,唤醒后继节点,让后继节点有机会获取锁

查找后继节点中的第一个非cancel节点,唤醒它,让它有机会获取锁。
5, 获取共享锁

跟互斥锁实现类似,先尝试获取共享锁

尝试失败之后,加入同步队列,跟互斥锁实现基本相同,除了简单的setHead换成了setHeadAndPropagate

获取锁成功之后,当前线程所在节点成为head。tryAcquireShared返回正数时表示后续获取共享锁的请求也能满足,如果下一个节点正好也是获取共享锁,处理流程跟释放共享锁一致,所以直接调用doReleaseShared,释放刚刚获取的锁,唤醒下一个线程,让它也有机会获取共享锁。
6, 释放共享锁

先尝试释放共享锁

释放共享锁成功之后,唤醒想一个非cancel的后继节点,让它有机会获得锁。
AQS内部类ConditionObject实现了wait/notify的condition variable。也是基于双链表队列。
7, 实现notify

类似Object#notify,调用之前必须先获得Object的固有锁

把等待队列中的第一个节点挪到同步队列

挪到同步队列之后,把前置节点的waitStatus置为Node.SIGNAL,确保当前节点有机会被唤醒以获得锁,如果当前节点没机会被唤醒,那就直接唤醒它。
8, 实现notifyAll
遍历双链表队列,挨个调用transferForSignal挪到同步队列
9, 实现wait

await参考Linux condition variable的语义,与Object#wait一样,调用之前必须先获取condition variable关联的锁,await时先加入等待队列等待signal,然后释放锁,然后检查是否收到了signal被挪到了同步队列,如果还没收到signal,暂停线程,等待收到signal加入同步队列之后,在同步队列的前置线程release时唤醒。线程被打断或收到了signal之后,再次获取锁,使得调用await的线程可以继续执行。
补一个wait的常用套路:

网友评论