三、锁
1、锁的分类
1.1 可重入锁、不可重入锁
Java中提供的synchronized,ReentrantLock,ReentrantReadWriteLock都是可重入锁。
可重入锁：当前线程获取到A锁，在获取之后尝试再次获取A锁是可以直接拿到的。
不可重入锁：当前线程获取到A锁，在获取之后尝试再次获取A锁是无法拿到的， 因为A锁被当前线程占用着， 需要等待自己释放锁在获取锁。（一般都是用 可重入锁，但是在线程池中用到了不可重入锁）
1.2 乐观锁、悲观锁
Java中提供的synchronized,ReentrantLock,ReentrantReadWriteLock都是悲观锁。
乐观锁： 获取不到锁可以让cpu 继续重新获取锁资源（ 其实java中提供的CAS的操作， 就是乐观锁的一种实现。）
悲观锁：获取不到锁资源时，会将当前线程挂起（ 进入BLOCKED、WAITING 状态 、如果线程进入这两中状态还涉及了用户态和内核态的切换，而这两种状态切换是比较消耗资源的 )
- 用户态：JVM可以自行执行的指令， 不需要借助操作系统执行。
- 内核态：JVM不可以自行执行， 需要操作系统才能执行。
1.3 公平锁、非公平锁
java 中提供的synchronized 只能是非公平锁。
java中提供的ReentrantLock,ReentrantReadWriteLock 可以实现非公平锁和公平锁
- 公平锁： 线程A获取到锁， 线程B没有拿到， 线程B去排队， 线程C来，而线程A持有锁， 线程B在排队， 那线程C直接在B后面排队等待， 等待B拿到锁并释放锁后，才会尝试获取锁资源。
- 非公平锁：线程A获取到了锁资源，线程B没有拿到，线程B去排队，线程C来了，先尝试竞争一波
- 如果拿到锁资源，则插队成功。
- 设有拿到锁资源，依然要排到B的后面，等待B拿到锁资源或者是B取消后，才可以尝试去竞争锁资源。
1.4 互斥锁和共享锁
Java中提供的synchronized、ReentrantLock是互斥锁。
Java中提供的ReentrantReadWriteLock,有互斥锁也有共享锁。
互斥锁： 同一时间点，只会有一个线程持有着当前互斥锁。
共享锁： 同一时间点，当前共享锁可以被多个线程同时持有。
2、 深入synchronized
2.1 类锁、对象锁
synchronized的使用一般就是同步方法和同步代码块。
synchronized的锁是基于对像实现的。
如果使用同步方法：
- ·static：此时使用的是当前类.class作为锁（类锁）
- ·非static：此时使用的是当前对象做为锁（对象锁）
可以查询一下八锁问题就能彻底明白锁对象
2.2 synchronized的优化
在JDK1.S的时候，Doug Lee推出了ReentrantLock，lock的性能远高于synchronized，所以JDK团队就在JDK1.6中，对synchronized做了大量的优化。
- **锁消除：**在synchronized修饰的代码中，如果不存在操作临界资源的情况，会触发锁消除，你即便写了synchronized,他也不会触发。 （ 生在编译器级别的一种锁优化方式）
public synchronized void destroy(){
//没有操作临界资源
//此时这个synchronized 加了也没有用。编译期不会编译进去
}
- **锁粗化：**如果在一个循环中，频繁的获取和释放做资源，这样带来的消耗很大，锁膨胀就是将锁的范围扩大，避免频繁的竞争和获取锁资源带来不必要的消耗。
public synchronized void destroy(){
for (int i = 0; i < 10000; i++) {
synchronized (test2.class){
}
}
}
- 锁升级：ReentrantLock的实现，是先基于乐观锁的CAS尝试获取锁资源，如果拿不到锁资源，才会挂起线程。synchronized在JDK1.6之前，完全就是获取不到锁，立即挂起当前线程，所以synchronized性能比较差。synchronized就在JDK1.6做了锁升级的优化
- 无锁：匿名偏向：当前对象没有作为锁存在。
- 偏向锁：如果当前锁资源，只有一个线程在频繁的获取和释放，那么这个线程过来，只需要判断，当前指向的线程是否是当前线程。
- 如果是，直接拿着锁资源走。
- 如果当前线程不是我，基于CAS的方式，尝试获取一下。如果获取不到，触发锁升级，升级为轻量级锁。（偏向锁状态出现了锁竞争的请求就会升级）
- 轻量级锁：会采用自旋锁的方式去频繁的以CAS的形式获取锁资源
- 如果成功获取到，拿着锁资源走
- 如果自旋了一定时间，没拿到锁资源（采用的是自适应自旋锁）
- 重量级锁：最传统的synchronized方式，拿不到锁资源，就挂起当前线程。（用户态&内核态）
2.3 synchronized的实现原理
synchronized是基于对象实现的。
MarkWord中标记着四种锁的信息：无锁、偏向锁 \ 匿名偏向、轻量级锁、重量级锁
2.4 synchronized的锁升级
为了可以在java 中看到对象的MarkWord信息，需要导入依赖
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>
锁默认情况下，开启了偏向锁延迟。
偏向锁升级为轻量级锁时， 会涉及到偏向锁撤销，需要等到一个安全点（STW），才可以做到偏向撤销，在明知道有并发情况，就可以选择不开启偏向锁，或者是设置偏向锁延迟开启。
因为VM在启动时，需要加载大量的.cass文件到内存中，这个操作会涉及到synchronized的使用，为了避免出现偏向锁敬销操作，VM启动初期，有一个延迟5秒开启偏向锁的操作
如果正常开启偏向锁了，那么就不会出现无锁状态， 对象会直接变成匿名偏向
public static void main(String[] args) throws InterruptedException {
Thread.sleep(6000);
Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
new Thread(() -> {
synchronized (o) {
System.out.println("t1" + ClassLayout.parseInstance(o).toPrintable());
}
}).start();
Thread.sleep(10);
synchronized (o) {
System.out.println("main" + ClassLayout.parseInstance(o).toPrintable());
}
}
整个锁状态的转变
Lock Record以及ObjectMonitor存储的内容
2.5 重量锁底层 ObjectMonitor
要了解 ObjectMonitor 的底层要看 openjdk 的 hotspot 的底层源码， 里面有一个ObjectMonitor.hpp的文件（ 路径在 /src/share/vm/runtime/objectMonitor.hpp ）
// initialize the monitor, exception the semaphore, all other fields
// are simple integers or pointers
ObjectMonitor() {
_header = NULL; // header 存储 MarkWord
_count = 0; // 表示竞争锁的线程个数
_waiters = 0, // wait 的线程的个数
_recursions = 0; // 标识当前 synchronized 锁重入的次数
_object = NULL;
_owner = NULL; // 持有锁的线程
_WaitSet = NULL; // 保存 wait 的线程信息， 双向链表
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ; // 在获取锁资源失败后， 线程要放在当前的链表中
FreeNext = NULL ;
_EntryList = NULL ; // _cxq 以及被唤醒的 waitSet 中的线程， 在一定机制下， 会放到 EntryList 中
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}
C++中实现的加锁流程
TryLock 方法
// Caveat: TryLock() is not necessarily serializing if it returns failure.
// Callers must compensate as needed.
int ObjectMonitor::TryLock (Thread * Self) {
for (;;) {
// 拿到持有锁的线程
void * own = _owner ;
// 如果有线程持有锁， 那么直接返回 0
if (own != NULL) return 0 ;
// 如果没有线程持有锁, own 是null 的，cmpxchg_ptr 指令就是底层cas实现。
// 如果Atomic::cmpxchg_ptr (Self, &_owner, NULL) 的cas操作成功了返回 null代表成功
if (Atomic::cmpxchg_ptr (Self, &_owner, NULL) == NULL) {
// Either guarantee _recursions == 0 or set _recursions = 0.
assert (_recursions == 0, "invariant") ;
assert (_owner == Self, "invariant") ;
// CONSIDER: set or assert that OwnerIsThread == 1
// 成功就返回1
return 1 ;
}
// The lock had been free momentarily, but we lost the race to the lock.
// Interference -- the CAS failed.
// We can either return -1 or retry.
// Retry doesn't make as much sense because the lock was just acquired.
// 失败返回 -1 或者 重试， 但是重试没有意义， 因为竞争锁刚刚失败， 锁已经被人拿走了
if (true) return -1 ;
}
}
try_enter
// -----------------------------------------------------------------------------
// Enter support
bool ObjectMonitor::try_enter(Thread* THREAD) {
// 当前线程 THREAD 不是持有锁的线程
if (THREAD != _owner) {
// 判断当前持有锁的线程是否当前线程， 说明轻量级锁刚刚升级过来的情况， 如果是则返回true
if (THREAD->is_lock_owned ((address)_owner)) {
assert(_recursions == 0, "internal state error");
_owner = THREAD ;
_recursions = 1 ;
OwnerIsThread = 1 ;
return true;
}
// 如果不是尝试cas操作， 获取锁资源
if (Atomic::cmpxchg_ptr (THREAD, &_owner, NULL) != NULL) {
// 没有拿到锁着返回false
return false;
}
return true;
} else {
// 将 _recursions重入操作 加1
_recursions++;
return true;
}
}
enter（ 想方设法拿到锁资源， 如果没有拿到， 挂起扔到 _cxq 链表中）
void ATTR ObjectMonitor::enter(TRAPS) {
// The following code is ordered to check the most common cases first
// and to reduce RTS->RTO cache line upgrades on SPARC and IA32 processors.
// 获取当前线程
Thread * const Self = THREAD ;
void * cur ;
// 直接CAS操作
cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
if (cur == NULL) {
// CONSIDER: set or assert OwnerIsThread == 1
// 如果CAS成功返回
return ;
}
// 判断上次CAS成功的线程是否是自己， 如果是自己则就是锁重入操作
if (cur == Self) {
// TODO-FIXME: check for integer overflow! BUGID 6557169.
_recursions ++ ;
return ;
}
// 轻量级锁过来的重新判断一下
if (Self->is_lock_owned ((address)cur)) {
assert (_recursions == 0, "internal state error");
_recursions = 1 ;
// Commute owner from a thread-specific on-stack BasicLockObject address to
// a full-fledged "Thread *".
_owner = Self ;
OwnerIsThread = 1 ;
return ;
}
// 走到这里了，就说明没有拿到锁资源， count++（竞争锁资源数量+1）
Atomic::inc_ptr(&_count);
// TODO-FIXME: change the following for(;;) loop to straight-line code.
for (;;) {
jt->set_suspend_equivalent();
// cleared by handle_special_suspend_equivalent_condition()
// or java_suspend_self()
// 入队操作， 进入到cxq中， （下面有EnterI 的核心代码）
EnterI (THREAD) ;
if (!ExitSuspendEquivalent(jt)) break ;
//
// We have acquired the contended monitor, but while we were
// waiting another thread suspended us. We don't want to enter
// the monitor while suspended because that would surprise the
// thread that suspended us.
//
_recursions = 0 ;
_succ = NULL ;
exit (false, Self) ;
jt->java_suspend_self();
}
}
// count --
Atomic::dec_ptr(&_count);
}
EnterI 内部核心的就是这个循环
for (;;) {
// 入队
node._next = nxt = _cxq ;
// CAS的方式入队
if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) break ;
// Interference - the CAS failed because _cxq changed. Just retry.
// As an optional optimization we retry the lock.
// 重写尝试锁资源
if (TryLock (Self) > 0) {
assert (_succ != Self , "invariant") ;
assert (_owner == Self , "invariant") ;
assert (_Responsible != Self , "invariant") ;
return ;
}
}
3、 深入ReentrantLock
3.1 ReentrantLock和synchronized的区别
核心区别：
- ReentrantLock:是个类，synchronized是关键字，当然都是在JVM层面实现互斥锁的方式
效率区别：
- 如果竞争比较激烈，推荐ReentrantLock去实现，不存在锁升级概念。而synchronized是存在锁升级概念的，如果升级到重量级锁，是不存在锁降级的。
底层实现区别：
- 实现原理是不一样，ReentrantLock基于AQS实现的，synchronized.是基于ObjectMonitor
功能向的区别：
- ReentrantLock的功能比synchronized更全面。
- ReentrantLock支特公平锁和非公平锁
- ReentrantLock可以指定等待锁资源的时i间。
选择哪个：如果你对并发编程特别熟练，推荐使用ReentrantLock,功能更丰富。如果掌握的一般般，使用synchronized会更好
3.2 AQS概述
AQS就是AbstractQueuedSynchronizer类，AQS其实就是JUC包下的一个基类，JUC下的很多内容都是基于AQS实现了部分功能，比如ReentrantLock，ThreadPoolExecutor，阻塞队列。CountDownLatch，Semaphore，CyclicBarrier等等都是基于AQS实现。
首先AQS中提供了一个由 volatile 修饰的 state 变量。 并采用CAS方式修改的int类型的state变量。
其次AQS中维护了一个双向列表，有 head 和 tail，并且每个节点都是node对象。
//用于指示节点正在共享模式下等待的标记
static final Node SHARED = new Node();
//用于指示节点正在独占模式下等待的标记
static final Node EXCLUSIVE = null;
// waitStatus值，指示线程已取消
static final int CANCELLED = 1;
//waitStatus值，指示后续线程需要取消标记
static final int SIGNAL = -1;
//waitStatus值，指示线程正在等待条件
static final int CONDITION = -2;
//waitStatus值，指示下一个acquireShared应无条件传播
static final int PROPAGATE = -3;
//状态字段，仅采用以下值：SIGNAL：此节点的后续节点被
//（或很快将被）阻止（通过park），因此当前节点在释放或取消时必须取消标记其后续节点。
//为了避免竞争，获取方法必须首先指示它们需要一个信号，然后重试原子获取，
//然后在失败时阻止。CANCELLED:由于超时或中断，此节点被取消。
//节点永远不会离开此状态。特别是，具有取消节点的线程再也不会阻塞。
//条件：此节点当前在条件队列中。在传输之前，它不会用作同步队列节点，此时状态将设置为0。
//（此处使用此值与字段的其他用途无关，但简化了机制。）
//传播：releaseShared应该传播到其他节点。这是在doReleaseShared中设置的（仅适用于头节点），
//以确保传播继续，即使其他操作已经介入。0：以上都没有。为了简化使用，
//这些值以数字形式排列。非负值表示节点不需要发出信号。因此，大多数代码不需要检查特定的值，
//只需要检查符号。对于正常同步节点，字段初始化为0，对于条件节点，字段则初始化为CONDITION。
//它使用CAS（或在可能的情况下，无条件的易失性写入）进行修改。
volatile int waitStatus;
//链接到当前节点/线程检查waitStatus所依赖的前置节点。在入队期间分配，
//仅在出队时清空（为了GC）。此外，在取消前一个节点时，
//我们会在找到未被取消的前一个时短路，因为头部节点从未被取消，
//所以它将始终存在：只有成功获取后，节点才会成为头部节点。
//被取消的线程永远不会成功获取，线程只会取消自己，而不会取消任何其他节点。
volatile Node prev;
//链接到当前节点/线程在发布时取消标记的后续节点。在入队期间分配，
//在绕过取消的前置任务时进行调整，在出队时为null（为了GC）。
//enq操作直到连接之后才分配前置节点的下一个字段，
//所以看到下一个空字段并不一定意味着节点在队列的末尾。
//然而，如果下一个字段显示为空，我们可以从尾部扫描prev以进行双重检查。
//取消节点的下一个字段被设置为指向节点本身，而不是null，以使isOnSyncQueue的工作更轻松。
volatile Node next;
//将此节点排入队列的线程。在构造时初始化，使用后为null。
volatile Thread thread;
//链接到等待条件或特殊值SHARED的下一个节点。
//因为条件队列只有在独占模式下保持时才被访问，
//所以我们只需要一个简单的链接队列来在节点等待条件时保持它们。
//然后将它们转移到队列中以重新获取。由于条件只能是独占的，
//我们通过使用特殊值来指示共享模式来保存字段。
Node nextWaiter;
AQS内部的主要部分结构图
3.3 加锁流程概述
非公平锁的流程：
- 线程A先执行CAS， 将state从0修改为1， 线程A就获取到了锁资源， 去执行业务代码即可。
- 线程B再去执行CAS，发现state已经是1了， 无法获取到锁资源
- 线程B需要去排队， 将自己封装为Node对象。
- 需要将当前B线程的Node放到双向队列保存，排队
- 但是双向链表中，必须要先有一个伪节点作为头节点，并且放在双向队列中
- 将B线程的Node挂在tai的前面， 并且将上一个节点状态改为-1， 再挂起B线程
3.4 三种加锁源码分析
3.4.1 lock方法
非公平锁的lock实现（ NonfairSync 内部类 ）
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
// 非公平锁
final void lock() {
// 上来就先基于CAS的方式，尝试将state从0改到1
if (compareAndSetState(0, 1))
// 获取锁资源成功， 会将当前线程设置到exclusiveOwnerThread 这个属性里面
setExclusiveOwnerThread(Thread.currentThread());
else
// 执行acquire，尝试获取锁资源
acquire(1);
}
公平锁的lock实现（ FairSync 内部类 ）
//公平锁
final void lock() {
// 执行acquire，尝试获取锁资源
acquire(1);
}
acquire 方法是公平锁和非公平锁的逻辑。
public final void acquire(int arg) {
// tryAcquire：再次查看，当前线程是否可以尝试获取锁资源
if (!tryAcquire(arg) &&
// tryAcquire 方法如果没有尝试拿到锁资源
// addWaiter(Node.EXCLUSIVE): 将当前线程封装为Node节点，插入到AQS的双向链表的结尾
// acquireQueued： 查看我是否是第一个排队的节点，如果是可以再次尝试获取锁资源，
// 如果长时间拿不到，挂起线程
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
// 中断线程的操作。
selfInterrupt();
}
非公平锁的tryAcquire
// 非公平锁的tryAcquire 实际调用的是sync类的nonfairTryAcquire方法
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
/**
* 执行非公平tryLock。tryAcquire在子类中实现，
* 但两者都需要trylock方法的非致命尝试。
*/
final boolean nonfairTryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// 获取了state属性
int c = getState();
// 判断是 State 当前是否为0, 之前持有锁的线程释放锁资源，把State属性有改成0了
if (c == 0) {
// 如果State状态改成了0，那么就再次cas抢锁一次
if (compareAndSetState(0, acquires)) {
// 如果成功了返回true
setExclusiveOwnerThread(current);
return true;
}
}
// 如果State 不是0 ,说明有线程持有着锁， 先判断当前线程是否是自己持有着锁
// 如果是则说明是锁重入操作
else if (current == getExclusiveOwnerThread()) {
// 将State 状态加1
int nextc = c + acquires;
// 如果不停加1 超过了int 的最大值会变成负数 则抛出异常
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
// 将计算的结果复制给State，说明锁重入成功
setState(nextc);
// 返回成功
return true;
}
// 返回失败
return false;
}
公平锁的 tryAcquire
// 公平锁的 tryAcquire
protected final boolean tryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// 获取了state属性
int c = getState();
// 判断是 State 当前是否为0, 之前持有锁的线程释放锁资源，把State属性有改成0了
if (c == 0) {
// 查看是否有排队的node
// 没人排队抢一手， 有人排队判断排队是不是自己，如果是自己也抢一手
if (!hasQueuedPredecessors() &&
// 抢一手锁
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
// 将State 状态加1
int nextc = c + acquires;
// 如果不停加1 超过了int 的最大值会变成负数 则抛出异常
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
// 将计算的结果复制给State，说明锁重入成功
setState(nextc);
// 返回成功
return true;
}
// 返回失败
return false;
}
// 查看是否有线程在AQS的双向队列中排队
// 返回false， 代表没有人排队
public final boolean hasQueuedPredecessors() {
// 尾节点
Node t = tail;
// 头节点
Node h = head;
// 头节点的下一个节点
Node s;
// 如果头尾节点相等， 证明没有线程排队， 直接去抢占锁资源
return h != t &&
// 头节点下一个节点不为null ， 并且s节点的线程就是我自己
((s = h.next) == null || s.thread != Thread.currentThread());
}
addWaiter 将没有拿到锁资源的线程扔到AQS队列中排队
// 没有拿到锁资源， 过来排队，
private Node addWaiter(Node mode) {
// 将当前线程封装为Node
Node node = new Node(Thread.currentThread(), mode);
// 尾节点赋值给 pred
Node pred = tail;
// 判断尾节点是否为null
if (pred != null) {
// 当前的node节点的pred属性指向尾节点
node.prev = pred;
// 以CAS的方式将当前线程设置为tail节点
if (compareAndSetTail(pred, node)) {
// 如何尾巴节点设置成功， 将之前的尾巴节点的next指针指向当前节点
pred.next = node;
return node;
}
}
// 如果CAS失败， 以死循环的方式，保证当前线程的Node一定可以放在AQS队列的末尾
enq(node);
return node;
}
// 将节点插入队列，必要时进行初始化。见上图。
private Node enq(final Node node) {
for (;;) {
// 拿到尾结点
Node t = tail;
// 如果尾节点为null，AQS中一个节点都没有， 构建一个伪节点， 作为head和tail
// 该节点的中的线程属性为null
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
// 以CAS的方式将当前线程设置为tail节点，将之前的尾巴节点的next指针指向当前节点
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
acquireQueued 方法， 判断当前线程是否还能再次尝试获取锁资源， 如果不能再次获取锁资源， 或者又没获取到， 尝试将当前线程挂起
// 这里都是没有拿到锁资源后才会走到这里来，并且是AQS排队了之后触发的方法。中断操作这里可以不用考虑
final boolean acquireQueued(final Node node, int arg) {
// failed：获取锁资源是否失败（这里简单了解真正触发的， 还是tryLock 和 lockInterruptibly方法）
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
// 拿到当前线程前一个的节点
final Node p = node.predecessor();
// 如果我的上个节点为head， 如果是head，再次尝试获取锁资源
if (p == head && tryAcquire(arg)) {
// 如果获取成功
// 将当前节点设置为头节点
setHead(node);
// 将上次的头节点的下个节点设置为null 方便GC
p.next = null; // help GC
// 获取锁失败标识为false， 也就是如果获取锁资源成功就不会执行cancelAcquire方法了
failed = false;
return interrupted;
}
// shouldParkAfterFailedAcquire: 基于上个节点的状态来判断当前节点是否能否挂起线程
// 如果可以返回true ， 如果不行就返回false， 继续下次循环， 直到将上个线程状态改为-1
if (shouldParkAfterFailedAcquire(p, node) &&
// 这里基于Unsafe类中的 park方法，将当前线程挂起
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
// 在lock方法中基本不会执行
cancelAcquire(node);
}
}
// 获取锁资源成功后， 先执行setHead
private void setHead(Node node) {
// 将当前线程设置为头节点
head = node;
node.thread = null;
node.prev = null;
}
// 当前Node 没有获取到锁资源， 或者没有资格竞争锁资源， 看下是否能挂起当前线程
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
// SIGNAL 的值为 -1： 代表当前节点的后续节点，可以挂起线程， 后续我会唤醒我的后续节点
// CANCELLED 的值为1： 代码当前的节点以及取消了
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
// 只有上个节点为 -1 后，当前节点才能安心的挂起线程
return true;
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
// 如果当前节点的上个节点为取消状态，我就将我当前节点的上个节点设置为我当前节点
// 上个节点的上个节点， 然后我while循环不停判断 我上个节点状态是不是为CANCELLED 状态
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
// 这里先略过状态为-2 和-3 的情况。
// 上个节点的状态不是1或者 -1， 就是0 ， 那就将上个节点状态改为-1
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
3.4.2 tryLock方法
- tryLock ( ) ;
- tryLock ( long timeout, TimeUnit unit ) ;
tryLock 不传递参数的
// tryLock 方法， 无论公平锁还是非公平锁。都会走非公平锁抢占锁资源的操作，
// 就是拿到state的值， 如果是0， 直接CAS浅尝一下，state 不是0 ， 那就看看是不是锁重入
// 如果没抢到锁， 或者不是说重入操作， 返回false
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
tryLock ( long timeout, TimeUnit unit ) ; 带时间参数的方式
public final boolean tryAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
// 这边判断线程中断为是否从false 改为了true， 如果是，直接抛出异常， 同时重置标记位
if (Thread.interrupted())
throw new InterruptedException();
// tryAcquire前面说过了分为公平和非公平两种执行方式， 如果锁拿成功了直接返回
return tryAcquire(arg) ||
doAcquireNanos(arg, nanosTimeout);
}
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
// 如果传递的时间小于0 就直接返回false失败
if (nanosTimeout <= 0L)
return false;
// 计算结束时间是多少
final long deadline = System.nanoTime() + nanosTimeout;
// 将当前线程添加到队列中。
final Node node = addWaiter(Node.EXCLUSIVE);
// 是否失败， 默认为失败
boolean failed = true;
try {
for (;;) {
// 获取我当前节点的前置节点
final Node p = node.predecessor();
// 和前面一样， 如果当前节点是头节点参数抢一下锁， 如果成功就返回true
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return true;
}
// 抢失败执行后面代码， 先计算剩余时间
nanosTimeout = deadline - System.nanoTime();
// 判断剩余时间是否用完了， 用完成了返回fash
if (nanosTimeout <= 0L)
return false;
//shouldParkAfterFailedAcquire: 根据上个节点来确认是否能够挂起线程
if (shouldParkAfterFailedAcquire(p, node) &&
// 为了避免剩余时间过少， 如果剩余时间少就不用挂起线程了
nanosTimeout > spinForTimeoutThreshold)
// 如果剩余时间足够，将线程挂起
LockSupport.parkNanos(this, nanosTimeout);
// 如果线程醒了， 查看是中断唤醒还是时间唤醒。
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
cancelAcquire 取消结果分析图
// 取消在AQS中排队的Node
private void cancelAcquire(Node node) {
// 如果当前节点为null 直接忽略
if (node == null)
return;
// 1.线程设置为null
node.thread = null;
// Skip cancelled predecessors
Node pred = node.prev;
// 2. 往前找节点waitStatus状态没有取消的节点， 把当前节点的上个节点指向找到的这个节点
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
// 3.拿到找到的未取消的节点的下个节点
Node predNext = pred.next;
// 4.将当前节点的状态设置为1， 代表节点取消
node.waitStatus = Node.CANCELLED;
// 开始脱离AQS队列操作
// 当前Node是尾节点, 将tail从当前节点替换为上个节点
if (node == tail && compareAndSetTail(node, pred)) {
compareAndSetNext(pred, predNext, null);
} else {
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
// 到了这里上面的操作CAS操作失败
int ws;
// 不是head的后续节点
if (pred != head &&
// 拿到上个节点的状态， 只要上个节点的状态不是取消节点， 那就改为-1
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) {
// 上一个节点是有效节点， 确保上一个节点，可以有效唤醒后续节点
Node next = node.next;
if (next != null && next.waitStatus <= 0)
compareAndSetNext(pred, predNext, next);
} else {
// 当前节点是head的后续节点操作
unparkSuccessor(node);
}
node.next = node; // help GC
}
}
3.4.3 lockInterruptibly方法
/**
* Acquires in exclusive interruptible mode.
* @param arg the acquire argument
*/
// lockInterruptibly 和tryLock（time, unit）唯一的区别:
// lockInterruptibly, 拿不到锁资源就死等, 等到锁资源释放, 或者中断线程, 抛出异常
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return;
}
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
// 上面的parkAndCheckInterrupt 方法如果是中断唤醒则为true， 抛出异常
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
// 这个方法可以确认， 当前挂起的线程，是被中断唤醒，还是正常唤醒的。
// 中断唤醒， 返回true， 如过正常唤醒，返回false
return Thread.interrupted();
}
3.5 释放锁流程概述
3.6 释放锁源码分析
public void unlock() {
// 释放锁资源不分公平锁和非公平锁，第一是一个sync对象
sync.release(1);
}
// 释放锁资源核心流程
public final boolean release(int arg) {
// 释放锁资源的核心流程之一， 如果为true 则代表锁资源释放干净了
if (tryRelease(arg)) {
// 如果锁已经被释放掉了走这个逻辑
Node h = head;
// h 如果为null 说明没有排队的
// 如果h 的状态不为0（为-1），说明后面有排队的node，并且线程已经挂起了
if (h != null && h.waitStatus != 0)
// 唤醒排队的线程
unparkSuccessor(h);
return true;
}
return false;
}
// ReentrantLock 释放锁资源操作
protected final boolean tryRelease(int releases) {
// 拿到state属性后先减1 （并没有赋值给state）
int c = getState() - releases;
// 判断当前线程是否是自己， 如果不是直接抛出异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
// free 代表当前锁资源是否释放干净
boolean free = false;
if (c == 0) {
// 如果state -1 后的值为0， 代表释放干净了。
free = true;
// 将持有锁的线程位
setExclusiveOwnerThread(null);
}
// 将C设置为state
setState(c);
// 锁资源释放干净返回true， 如果锁还未释放干净返回false
return free;
}
/**
* 唤醒后面排队的线程
*
* @param node the node
*/
private void unparkSuccessor(Node node) {
// 拿到头结点状态
int ws = node.waitStatus;
// 判断头节点是否为-1
if (ws < 0)
// 先基于CAS， 将节点状态从-1，改成0
compareAndSetWaitStatus(node, ws, 0);
// 拿到头节点的后续节点
Node s = node.next;
// 如果后续节点为null， 或者后续节点的状态为1， 代表节点取消了。
if (s == null || s.waitStatus > 0) {
s = null;
// 如果后续节点为null，或者后续节点状态为取消装填， 从后往前找到一个有效节点环境
// 比较核心的就是从后往前找， 而不是从前往后找
for (Node t = tail; t != null && t != node; t = t.prev)
// 从后往前找到状态小于等于0 的节点
if (t.waitStatus <= 0)
s = t;
}
// 直到找到要唤醒的线程
if (s != null)
LockSupport.unpark(s.thread);
}
3.7 AQS中常见的问题
3.7.1 AQS中为什么要有一个虚拟的head节点
AQS可以没有head， 设计之初指定head只是为了更加方便操作
比如：ReentrantLock中释放锁资源时，会考虑是香需要唤醒后继节点。如果头节点的状态不是-1，就不需要去唤醒后续节点。 唤醒后续节点时，需要找到head.next为null， 或者是取消了，此时需要遍历整个双向链表， 从后面往前遍历， 找到离head最近的node。规避一些不必要的唤醒操作。
如果不用虚拟节点（ 哨兵节点 ），当前节点挂起，当前节点的状态设置为-1， 这样也可以。 AQS本身就是使用了哨兵节点做双向链表的一些操作。
虚拟的head,可以避免重复唤醒操作？虚拟的head可以解决这个重复唤醒问题， 但是并没有去处理这个问题，
3.7.2 AQS中为什么使用双向链表
AQS的双向链表就为了更方便的操作Node节点。
在执行tryLock，lockInterruptibly方法时，如果在线程阻塞时，中断了线程，此时线程会执行cancelAcquirel方法取消当前节点，不在AQS的双向链表中排队。如果是单向链表，此时会导致取消节点，无法直接将当前节点的prv节点的next指针，指向当前节点的next节点（ 操作会变得麻烦， 要遍历整个链表找到当前节点上个节点 ）
3.8 ConditionObject
3.8.1 ConditionObject 的介绍
像synchronized提供了wait和notifyl的方法实现线程在持有锁时，可以实现挂起，已经唤醒的操作，ReentrantLock也拥有这个功能。
ReentrantLock提供了 await 和 signal 方法去实现类似 wait 和 notify 的功能。想执行await 或者是 signal 就必须先持有lock锁的资源。
ConditionObject的使用：
public static void main(String[] args) throws InterruptedException {
ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();
new Thread(() -> {
lock.lock();
System.out.println("t1线程获取到锁资源并await挂起线程");
try {
Thread.sleep(1000);
condition.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("t1线程被唤醒并执行完成后续代码");
lock.unlock();
}).start();
Thread.sleep(100);
lock.lock();
System.out.println("主线程拿到锁资源");
Thread.sleep(3000);
System.out.println("主线程执行signal 唤醒线程");
condition.signal();
System.out.println("主线程等待 3秒释放锁");
Thread.sleep(3000);
lock.unlock();
}
3.8.2 ConditionObject 的构建方式以及核心属性
在通过lock锁对象，执行newCondition方法时，本质还是直接newAQS提供的ConditionObject对象
final ConditionObject newCondition() {
return new ConditionObject();
}
其实lock锁中可以有多个Condition对象。
在对Condition1 进行操作时候， 不会影响Condition2 的单向链表。
在ConditionObject中只有两个核心属性。
/** First node of condition queue. */
private transient Node firstWaiter;
/** Last node of condition queue. */
private transient Node lastWaiter;
虽然在ConditionObject中也是使用Node类， 而AQS中使用的双向链表也是用的Node，但是在ConditionObject中Node的prev和next两个属性都是为null ， 他使用的是 nextWaiter 属性来实现单向链表的效果。
3.8.3 Condition的await方法分析（ 前置分析 ）
持有锁的线程在执行await方法后会做几个操作：
- 判断线程是否中断， 如果中断了，什么都不做。
- 如果没有中断，就将当前线程封装为node 添加到Condition的单向链表中
- 一次性释放掉锁资源
- 如果当前线程没有在AQS队列中， 就正常执行挂起线程操作
public final void await() throws InterruptedException {
// 先判断线程的中断标记是否为true
if (Thread.interrupted())
// 如果为true， 就没必要执行后续挂起先线程了
throw new InterruptedException();
// 在挂起线程之前， 先将当前线程封装为node，并添加到condition队列中
Node node = addConditionWaiter();
// fullyRelease在释放锁资源， 一次性将锁资源全部释放， 并保留重入次数
int savedState = fullyRelease(node);
int interruptMode = 0;
// 当前Node是否在AQS队列中
// 执行fullyRelease 方法后，如果线程刚刚释放锁资源了，其他线程就立即执行了signal方法，
// 此时当前线程就被放到了AQS的队列中， 这样一来线程就不需要执行LockSupport.park(this);挂起线程
while (!isOnSyncQueue(node)) {
// 如果没有在AQS队列中， 正常在Condition单项链表中， 正常挂起线程
LockSupport.park(this);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
/**
* Adds a new waiter to wait queue.
* @return its new wait node
*/
// 线程挂起前， 先添加到Condittion单向链表的业务
private Node addConditionWaiter() {
// 拿到尾节点。
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out.
// 如果尾节点不为null， 并且尾节点的状态不正常， 不是-2
if (t != null && t.waitStatus != Node.CONDITION) {
// 如果尾节点已经取消了， 那就要删除掉尾节点
unlinkCancelledWaiters();
// 重新获取lastWaite节点
t = lastWaiter;
}
// 构建当前线程的node，并且状态设置为-2
Node node = new Node(Thread.currentThread(), Node.CONDITION);
// 如果last节点为null。直接将当前节点设置为firsWaiter
if (t == null)
firstWaiter = node;
else
// 如果last不为null，说明有值， 将排在lastWaiter的后面
t.nextWaiter = node;
// 把当前节点设置为最后一个节点
lastWaiter = node;
// 返回当前节点
return node;
}
private void unlinkCancelledWaiters() {
// 拿到头节点
Node t = firstWaiter;
// 临时节点
Node trail = null;
while (t != null) {
// 拿到头节点的下一个节点
Node next = t.nextWaiter;
// 如果t的状态不为-2， 说明有问题走if里面的方法， 如果为-2 就走else的方法
// 将t赋值给trail
if (t.waitStatus != Node.CONDITION) {
// 说明这个节点有问题， 将t的next的设置为null
t.nextWaiter = null;
// 如果trail为null，代表头节点未null
if (trail == null)
// 将头节点指向next节点
firstWaiter = next;
else
// 如果trail有值，说明不是头节点位置
trail.nextWaiter = next;
// 如果next为null， 说明单项链表已经遍历到最后了， 直接结束
if (next == null)
lastWaiter = trail;
}
else {
// 如果t的状态为-2，将t 的值赋值给临时节点
trail = t;
}
t = next;
}
}
// 一次性释放锁资源
final int fullyRelease(Node node) {
// 标记位， 释放锁资源是否失败， 默认为失败
boolean failed = true;
try {
// 拿到现在的重入次数
int savedState = getState();
// 一次性释放干净全部锁资源
if (release(savedState)) {
// 释放锁资源成功
failed = false;
// 返回对应锁资源信息
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
// 如果释放锁资源失败， 将节点状态设置为取消
node.waitStatus = Node.CANCELLED;
}
}
3.8.4 Condition的signal方法分析
分为几个步骤：
- 确保执行signal方法的是持有锁的线程
- 脱离Condition的队列
- 将Node状态从-2改为0
- 将Node添加到AQS队列
- 为了避免当前Node无法在AQS队列正常唤醒做了一些判断和操作
// 线程挂起后， 需要signal方法唤醒
public final void signal() {
// 在ReentrantLock中，如果执行singnal的线程如果没有持有锁资源， 直接抛出异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 拿到排在 Condition 单向链表的首位的node
Node first = firstWaiter;
// 如果有node在排队，才需要唤醒， 如果没有跳过
if (first != null)
doSignal(first);
}
// 开始唤醒 Condition 中的node 中的线程
private void doSignal(Node first) {
do {
// 先获取到第二个节点， 并将第二个节点设置为firsWaiter， 判断第二个节点是否为null
if ( (firstWaiter = first.nextWaiter) == null)
// 说明就一个节点在Condition队列中， 那么直接将firsWaiter和lastWaiter置为null
lastWaiter = null;
// 如果第二个节点不为null， 因为当前节点要被唤醒了， 脱离整个Condittion队列。将nextWaiter置为null
first.nextWaiter = null;
// 如果transferForSignal 返回true了， 就整个方法结束了
} while (!transferForSignal(first) &&
// 如果后续节点还有， 就往后面继续唤醒
(first = firstWaiter) != null);
}
// 准备开始唤醒在 Condition 队列中的node
final boolean transferForSignal(Node node) {
// 将 Condition 队列中的node的状态从-2， 改成0， 代表要扔到AQS队列中了
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
// 如果失败了， 说明在singnal之前应该是线程被中断了， 从而被唤醒了。
return false;
// 如果正常的将node的状态从-2 改为0， 这是要将Condition中的这个Node扔到AQS的队列中
// 将当前队列扔到AQS中， 返回的p是node的prev
Node p = enq(node);
// 获取上个node的状态
int ws = p.waitStatus;
// 如果ws》0， 说明这个node已经被取消了
// 如果ws状态不是取消，将prev节点的状态改为-1
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
// 如果前面的节点以及取消了， 可能会导致当前节点永远不会被唤醒。 立即唤醒当前节点，基于
// acquireQueued 方法让当前节点找到正常的prev节点， 并挂起线程
// 如果prev节点正常， 但是CAS修改失败了。无论prev节点因为并发原因导致状态改变。 还是为了
// 避免当前节点无法被唤醒， 都提前唤醒当前线程， 基于acquireQueued方法
LockSupport.unpark(node.thread);
// 操作完成后返回true
return true;
}
3.8.5 Condition的await方法分析（ 后置分析 ）
- 分为了几个部分：
- 唤程之后，要先确认是中断唤醒还是signal唤醒，还是 signal 唤醒后被中断
- 确保当前线程的 Node 已经在AQS队列中
- 执行 acquireQueued 方法，等待锁资源。
- 在获取锁资源后，要确认是香在获取锁资源的阶段被中断过，如果被中断过，并且不是 THROW_IE ，那就确保 interruptMode 是 REINTERRUPT。
- 确认当前 Node 已经不在 Condition 队列中了
- 最终根据 interruptMode 来决定具体做的事情
- 0：什么都不操作
- THROW_IE：抛出异常
- REINTERRUPT：执行线程的 interrupt 方法
// 上面已经分析了await方法前半部分了
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
// 中断模式
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
// 如果线程执行到这里说明线程被唤醒了
// 线程可能被signa1唤醒。（如果是signa1唤醒，可以确认线程已经在AQS队列中
// 线程可能被中断唤醒。线程被唤醒后，可能没有在AQS队列中
// 如果线程先被signal唤醒，然后线程中断了。。。。（做一些额外处理）
// checkInterruptWhileWaiting 可以确认当前是如何唤醒的
// 返回值有三种：
// 0: 正常signal唤醒，没别的事（不知道Node是否在AQs队列）
// THROW_IE(-1): 中断唤醒，并且可以确保在AQS队列
// REINTERRUPT(1): signal唤醒，但是线程被中断了，并且可以确保在AQS队列
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 如果走到这里node一定放在了AQS队列中了
// 执行acquireQueued,尝试在ReentrantLock中获取锁资源。
// acquireQueued 方法返回了true： 代表线程在AQS队列中挂起来了，被中断过
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
// 如果线程在AQS队列排队时，被中断了，并且不是THROW_IE状态，
// 确保线程的interruptMode是REINTERRUPT
// REINTERRUPT: await不是中断唤醒，但是后续被中断过！！！
interruptMode = REINTERRUPT;
// 如果当前Node还在condition的单向链表中，脱离Condition的单向链表
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
// 如果interruptMode是0， 说明线程在signal后以及持有锁的过程中，没被中断过
if (interruptMode != 0)
// 这个方法就是看interruptMode是什么状态该抛出异常抛异常，
// 如果为0就什么都不做操作
reportInterruptAfterWait(interruptMode);
}
// 判断当前线程被唤醒的模式， 确认interruptMode的值
private int checkInterruptWhileWaiting(Node node) {
// 判断线程是否被中断了
return Thread.interrupted() ?
// THROW_IE:代表线程是被interrupt唤醒的，后续做判断后会向上排除异常
// REINTERRUPT: 代表线程是signal唤醒的，但是在唤醒之后，被中断了
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
// 线程是正常的被signal唤醒，并且线程没有中断过。
0;
}
// 判断线程是中断唤醒的，还是signal唤醒的
final boolean transferAfterCancelledWait(Node node) {
// 基于CAS将node的状态从-2改为0
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
// 如果修改成功了说明是中断唤醒的线程。因为CAS成功了
// 将ndoe添加到AQS中（如果是中断唤醒的，当前线程同时存在Condittion的单向链表以及AQS队列中）
enq(node);
return true;
}
/*
* If we lost out to a signal(), then we can't proceed
* until it finishes its enq(). Cancelling during an
* incomplete transfer is both rare and transient, so just
* spin.
*/
// 判断当前Node是否在AQS队列（Signal唤醒的， 但是可能线程还没放到AQS队列）
// 等到signal方法将线程的node扔到AQS队列后，在做后续操作
while (!isOnSyncQueue(node))
// 如果没有在AQS队列上， 那就线程让步， 等一会儿，node放在AQS队列上再做处理
Thread.yield();
// signal唤醒的返回false
return false;
}
// 确认node是否在AQS队列上
final boolean isOnSyncQueue(Node node) {
// 如果线程状态为 -2， 肯定没有在AQS队列中
// 并且如果上个节点的值为null， 肯定没有在AQS队列
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
// 如果节点next不为null。 说明已经在AQS队列上
if (node.next != null) // If has successor, it must be on queue
return true;
/*
* node.prev can be non-null, but not yet on queue because
* the CAS to place it on queue can fail. So we have to
* traverse from tail to make sure it actually made it. It
* will always be near the tail in calls to this method, and
* unless the CAS failed (which is unlikely), it will be
* there, so we hardly ever traverse much.
*/
// 如果上述判断都没有确定节点是否在AQS队列中， 在AQS队列中寻找
return findNodeFromTail(node);
}
// 循环查找是否在AQS队列中（从后往前找）
private boolean findNodeFromTail(Node node) {
Node t = tail;
for (;;) {
// 如果判断当前节点和临时节点是否相同
if (t == node)
return true;
// 如果临时节点为null 说明没有在AQS队列中
if (t == null)
return false;
// 移动到前一个
t = t.prev;
}
}
/**
* Throws InterruptedException, reinterrupts current thread, or
* does nothing, depending on mode.
*/
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {
// 如果是中断的唤醒await， 直接抛出异常
if (interruptMode == THROW_IE)
throw new InterruptedException();
// 如果是REINTERRUPT， signal后被中断
else if (interruptMode == REINTERRUPT)
// 确认线程的中断标记位是true
// 就重新中断一下
selfInterrupt();
}
/**
* Convenience method to interrupt current thread.
*/
static void selfInterrupt() {
Thread.currentThread().interrupt();
}
3.8.6 Condition的 awaitNanos 和 signalAll 方法分析
awaitNanos：仅仅只是在await的基础上，做了一些改变， 整体逻辑思想都是一样的
挂起线程时， 传入要挂起的时间，时间到了，自动唤醒， 走添加到AQS队列的逻辑
// await 指定时间， 多了一个时间到了自动唤醒
public final long awaitNanos(long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
// deadline： 当前时间最多挂起到什么时间点
final long deadline = System.nanoTime() + nanosTimeout;
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
//nanosTimeout 的时间小于等于0, 就不需要挂起
if (nanosTimeout <= 0L) {
// 正常扔到ASQ队列中
transferAfterCancelledWait(node);
break;
}
// 如果这个时间大于1000纳秒， 才可以挂起线程
if (nanosTimeout >= spinForTimeoutThreshold)
// 如果大于正常挂起
LockSupport.parkNanos(this, nanosTimeout);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
// 计算剩余的挂起时间时间， 可能需要重新走while循环， 再次挂起线程
nanosTimeout = deadline - System.nanoTime();
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
// 剩余时间
return deadline - System.nanoTime();
}
signalAll 方法， 这个方法很简单， signal是唤醒一个， 这个方法就全部唤醒
// 以do- while的形式， 将Condition单向链表中的所有Node，全部唤醒并扔到AQS队列中
private void doSignalAll(Node first) {
// 将头尾置为null
lastWaiter = firstWaiter = null;
do {
// 拿到next节点的引用
Node next = first.nextWaiter;
// 断开当前node的nextWaiter
first.nextWaiter = null;
// 修改Node状态， 扔到AQS队列， 是否唤醒
transferForSignal(first);
// 指向下一个节点
first = next;
// 直到下个节点为null
} while (first != null);
}
4、深入ReentrantReadWriteLock
4.1 为什么要出现读写锁
synchronized.和ReentrantLock都是互斥锁。
如果说有一个操作是读多写少的，还是要保证线程安全的话。 如果采用上述的两种互斥锁，效率肯定很低的。
在这个情况下， 就可以使用 ReentrantReadWriteLock 读写锁去实现。
读读操作是不互斥的，可以读写并发执行
但是如果涉及到了写操作，那还是互斥的（ 无论是读写， 还是读读， 还是写读， 都是互斥的。 只有读读操作不是互斥的 ）
简单的使用案例：
static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
static ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
static ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
public static void main(String[] args) {
new Thread(() -> {
readLock.lock();
try {
System.out.println("线程a拿到锁资源了...");
try {
Thread.sleep(5000L);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
} finally {
readLock.unlock();
System.out.println("线程A释放锁资源了...");
}
}).start();
new Thread(() -> {
try {
Thread.sleep(1000L);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
writeLock.lock();
try {
System.out.println("线程b拿到锁资源了...");
try {
Thread.sleep(5000L);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
} finally {
writeLock.unlock();
System.out.println("线程b释放锁资源了...");
}
}).start();
new Thread(() -> {
try {
Thread.sleep(2000L);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
readLock.lock();
try {
System.out.println("线程C拿到锁资源了...");
try {
Thread.sleep(7000L);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
} finally {
readLock.unlock();
System.out.println("线程C释放锁资源了...");
}
}).start();
}
}
4.2 读写锁的实现原理
ReentrantReadWriteLock 还是基于AQS实现的， 还是对state进行操作，拿到锁资源就去干活， 如果没有拿到，依然去AQS队列中排队
读锁操作：基于state的高16位进行操作。
写锁操作：基于tate的低16为进行操作。
ReentrantReadWriteLock 依然是可重入锁。
**写锁重入：**读写锁中的写锁的重入方式，基本和ReentrantLock 一致，没有什么区别，依然员对tte进行+1操作即可，只要确认持有锁资源的线程，是当前写锁线程即可。只不过之前ReentrantLock的重入次数是state的正数取值范围，但是读写锁中写锁范国就变小了
**读锁重入：**因为读锁是共享锁。读锁在获取锁资源操作时，是要对at的高16位进行+1操作。因为读锁是共享锁，所以同一时间会有多个读线程持有读锁资源。
这样一来，多个读操作在持有读锁时，无法确认每个线程读锁重入的次数。为了去记录读锁重入的次数。每个读操作的线程，都会有一个ThreadLocalii记录锁重入的次数。
**写锁的饥饿问题：**读锁是共享锁，当有线程持有读锁资源时，再来一个线程想要获取读锁，直接对state修改即
可。在读锁资源先被占用后， 来了一个写锁资源，此时大量的需要读锁的线程来请求锁资源，如果可以绕过写锁，直接拿资源，会造成写锁长时间无法获取写锁资源。
写锁在拿到锁资源后，如果再有读线程需要获取读锁资源，需要去AQS队列排队。如果队列的前面需要写锁资源的线程，那么后续读线程是无法拿到锁资源的。持有读锁的线程，只会让写锁线程之前的读线程拿到锁资源
4.3 写锁分析
4.3.1 写锁加锁流程概述
4.3.2 写锁加锁源码分析
// 写锁加锁的入口
public void lock() {
sync.acquire(1);
}
public final void acquire(int arg) {
// 如果 这里拿不到锁资源返回true
// 就不会执行acquireQueued方法了（也就是拿不到锁只有才会执行）
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
protected final boolean tryAcquire(int acquires) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到 state 的值
int c = getState();
// 得到低16位的值
int w = exclusiveCount(c);
// 判断是否有线程持有锁资源
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
// 当前没有线程持有写锁。（读写互斥）
// 有线程持有写锁，持有写锁的线程不是当前线程，（不是锁重入）
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 当前线程持有写锁，（锁重入）
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
// 没有超过锁重入的次数正常加1
setState(c + acquires);
return true;
}
// 尝试获取锁资源
// writerShouldBlock方法查看公平锁和非公平锁的效果
// 如果是非公平锁直接返回false 执行compareAndSetState 方法取尝试获取锁
// 公平锁需要查看是否有排队的，如果有排队的，我是否是head的next（头节点）
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
// 拿锁成功， 设置占有互斥锁的线程
setExclusiveOwnerThread(current);
return true;
}
static final int SHARED_SHIFT = 16;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
// 这个方法就是将state的低16为的值拿到
// exclusiveCount 整个方法就是相当于 state & ((1 << 16) - 1)
// 00000000 00000000 00000000 00000001 == 1
// 00000000 00000001 00000000 00000000 == 1 << 16
// 00000000 00000000 11111111 11111111 == 1 << 16 -1
// & 运算， 一个为0 必然为0 ， 都为1，才为1 ， 这样就取到了state的低16位
static int exclusiveCount(int c) {
return c & EXCLUSIVE_MASK;
}
// 非公平锁
final boolean writerShouldBlock() {
return false; // writers can always barge
}
// 公平锁
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
4.3.3 写锁释放锁源码分析
释放的流程和ReentrantLock一致，只是在判断释放是否干净时，判断低16位的值
public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
// 写锁释放锁的流程
protected final boolean tryRelease(int releases) {
// 释放锁先判断， 当前线程是否是持有锁的线程， 如果不是抛出异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 获取state - 1
int nextc = getState() - releases;
// 判断低16位结果是否为0， 如果为0， free设置为true
boolean free = exclusiveCount(nextc) == 0;
if (free)
// 将持有锁的线程设置为null
setExclusiveOwnerThread(null);
// 设置给state
setState(nextc);
// 释放干净返回true
return free;
}
4.4 读锁分析
4.4.2 读锁加锁流程慨述
- 分析读锁加速的基本流程
- 分析读锁的可重入锁实现以及优化
- 解决ThreadLocall内存泄漏问题
- 读锁获取锁自后，如果唤醒AQS中排队的读线程
=============== 重入操作 =============
前面阐述过，读锁为了记录锁重入的次数，需要让每个读线程用ThreadLocali存储重入次数ReentrantReadWriteLock对读锁重入做了一些优化操作
=====记录重入次数的核心
ReentrantReadWriteLock在内部对ThreadLocal做了封装，基于HoldCount的对象存储重入次数，在HoldCount内部有个count属性记录，而且每个线程都是自己的ThreadLocalHoldCounter,所以可以直接对内部的counti进行++操作。
==第一个获取读锁资源的重入次数记录方式
第一个拿到读锁资源的线程，不需要通过ThreādLocal存储，内部提供了两个属性来记录第一个拿到读锁资源线程的信息内部提供了firstReader记录第一个拿到读锁资源的线程，firstReaderHoldCounti记录firstReader的锁重入次数
======最后一个获取读锁资源的重入次数记录方式
最后一个拿到读锁资源的线程，也会缓存他的重入次数，这样++起来更方便基于cachedHoldCounter缓存最后一个拿到锁资源现成的重入次数
=============================================
重入次数的流程执行方式：
- 判断当前线程是否是第一个拿到读锁资源的：如果是，直接将firstReaderl以及firstReaderHoldCount设置为当前线程的信息
- 判断当前线程是否是firstReader::如果是，直接对firstReaderHoldCount++即可
- 跟firstReaderi设关系了，先获取cachedHoldCounter,.判断是否是当前线程，
- 如果不是，获取当前线程的重入次数，将cachedHoldCounteri设置为当前线程，
- 如果是，判断当前重入次数是否为0，重新设置当前线程的锁从入信息到readHolds(ThreadLocal)中，算是初始化操作，重入次数是0
- 前面两者最后都做count++
4.4.2 读锁加锁源码分析
// 读锁加锁方法入口
public final void acquireShared(int arg) {
// 竞争锁资源方法
if (tryAcquireShared(arg) < 0)
// 没拿到锁， 去排队
doAcquireShared(arg);
}
// 读锁竞争锁资源的操作
protected final int tryAcquireShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到 state
int c = getState();
// 拿到低16位， 判断!=0,
// 如果为true 证明有写锁占用锁资源,并且, 当前占用锁资源的线程不是当前线程
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
// 说明写锁资源被占用了， 无法读取锁资源， 直接返回-1去排队
return -1;
// 如果方法走到这里说明, 线程没有持有写锁或者当前线程持有写锁
// 获取读锁的信息， state的高16位
int r = sharedCount(c);
// readerShouldBlock 两个实现：
// 公平锁：查看队列是否有排队， 如果有排队就跳过这个if判断
// 没人排队就执行compareAndSetState 方法的CAS操作
// 非公平锁：没有排队,执行if后面的cas操作。
// 如果有排队，看是不是读锁是读锁, 是csa 出现这种情况,
// 大部分都是写锁资源刚刚释放, 后续node还未来得及拿到读锁资源
// 所以当前竞争的读线程可以去获取锁资源
if (!readerShouldBlock() &&
// 判断持有锁的临界资源是否达到最大资源
r < MAX_COUNT &&
// 以CAS的操作对高16位进 行+1 如果这里CAS失败就会走fullTryAcquireShared方法
compareAndSetState(c, c + SHARED_UNIT)) {
// 判断r == 0, 当前线程是否是第一个拿到多锁资源的线程
if (r == 0) {
// 如果是第一个拿到锁资源， 将firstReader 设置为当前线程
firstReader = current;
// 将firstReaderHoldCount 设置为1
firstReaderHoldCount = 1;
// 判断当前线程是否是第一个持有锁的线程，
// 如果是就对firstReaderHoldCount ++( 说明第一个进来的线程锁重入)
} else if (firstReader == current) {
firstReaderHoldCount++;
// 到这里，就说明不是第一个读取锁资源的线程
} else {
// 获取最后一个拿到读锁资源的线程
HoldCounter rh = cachedHoldCounter;
// 判断当前线程是否是最后一个拿到读锁资源的线程
if (rh == null || rh.tid != getThreadId(current))
// 如果不是， 设置当前线程为 cachedHoldCounter
cachedHoldCounter = rh = readHolds.get();
// 当前线程是之前的 cachedHoldCounter
else if (rh.count == 0)
// 将当前的重入信息设置到ThreadLocal中
readHolds.set(rh);
// 重入的++
rh.count++;
}
return 1;
}
// 如果竞争锁失败就走这个方法
return fullTryAcquireShared(current);
}
// 公平锁的查看队列是否有排队
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
// 公平锁的查看队列是否有排队
public final boolean hasQueuedPredecessors() {
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
// 非公平锁的查看队列是否有排队
final boolean readerShouldBlock() {
return apparentlyFirstQueuedIsExclusive();
}
// 非公平锁的判断
final boolean apparentlyFirstQueuedIsExclusive() {
Node h, s;
return (h = head) != null && // head为null, 可以抢占锁资源
(s = h.next) != null && // head的next为null， 可以抢占锁资源
!s.isShared() && // 如果排在head后面node是共享锁, 可以抢占锁资源
s.thread != null; // 如果head下一个next的thread属性为null, 可以抢占锁资源
}
// 如果在上面tryAcquireShared方法中， 如果没有拿到锁资源，走这个方法
// 尝试再次获取, 逻辑和上面基本一样
final int fullTryAcquireShared(Thread current) {
// 声明当前线程的重入次数
HoldCounter rh = null;
// 死循环
for (;;) {
// 再次拿到state
int c = getState();
// 当前如果有写锁资源占用， 并且不是当前线程， 返回-1 走排队
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
// else we hold the exclusive lock; blocking here
// would cause deadlock.
// 查看当前线程是否可以尝试竞争锁资源（公平和非公平的逻辑）
} else if (readerShouldBlock()) {
// Make sure we're not acquiring read lock reentrantly
// 无论公平还是非公平,
// 只要进来, 就意味准备阻塞当前线程了（先做一波准备放在AQS队列中）
// 在处理ThreadLocal的内存泄漏问题
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
// 如果当前线程是之前的firstReader， 什么都不用处理没有
// ThreadLocal的内存泄漏问题
} else {
// 这里第一次肯定为null 上面局部变量设置就是为null
if (rh == null) {
// 拿到最后一个读取锁的线程
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
// 进来这里说明当前线程并不是, 最后一个线程
// 从自己的ThreadLocal中拿到重入计数器
rh = readHolds.get();
// 如果这里计数器为0 说明没有拿到读锁
if (rh.count == 0)
// 避免内存泄漏
readHolds.remove();
}
}
// 前面处理完之后， 直接返回-1
if (rh.count == 0)
return -1;
}
}
// 判断重入次数是否超出阈值， 超出抛异常
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// CAS尝试获取锁
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
4.4.3 读线程在AQS队列获取资源后的操作
- 正常如果都是读线程来获取读锁资源，不需要使用到AQS队列的，直接CAS操作即可
- 如果写线程特有着写锁，这是读线程就需要进入到AQS队列排队，可能会有多个读线程在AQS中，当写锁释放资源后，会唤醒head后面的读线程，当head后面的读线程拿到锁资亚后，还需要查看next节点是否也是读线程在阻塞，如果是，直接唤醒
// tryAcquireShared 方法竞争锁资源失败（失败基本都是竞争过程中发现存在写锁）
// doAcquireShared 阻塞排队方法
private void doAcquireShared(int arg) {
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
// 拿到上个节点
final Node p = node.predecessor();
if (p == head) {
// 如果上个结果是head, 可以直接 tryAcquireShared
int r = tryAcquireShared(arg);
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 找到prev有效节点, 将状态设置为-1, 挂起当前线程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
// 将当前节点设置为head节点
setHead(node);
// 第一个判断更多是在处理信号量（jdk1.5的bug ）操作
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
// 拿到当前node的next节点
Node s = node.next;
if (s == null || s.isShared())
// 如果next节点是共享锁， 直接唤醒next节点
doReleaseShared();
}
}
4.4.3 读锁释放锁流程
// 读锁释放锁流程
public final boolean releaseShared(int arg) {
// tryReleaseShared 方法处理里面处理state的值, 以及可重入的内容
if (tryReleaseShared(arg)) {
// AQS队列的事情
doReleaseShared();
return true;
}
return false;
}
// 处理重入问题和处理state属性的值
protected final boolean tryReleaseShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
// 当前线程是第一个获取锁的现场就不需要 ThreadLocal
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {
// 如果不是firstReader, 从cachedHoldCounter 中获取，
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
// 如果当前线程不是从cachedHoldCounter 从线程的ThreadLocal获取
rh = readHolds.get();
int count = rh.count;
// 如果为1或者更小, 当前线程就释放干净了, 直接remove, 避免value内存泄漏
if (count <= 1) {
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
for (;;) {
// 拿到state, 高16位
int c = getState();
// 对高16位减1, 成功后判断state是否为0
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
// 如果高16位为0 说明没有读锁线程了, 如果高16位不为0说明存在读线程
// 那就不能去唤醒AQS队列中的线程( 其实就是只要读线程没有就顺带去队列中看下，不会影响怎么)
// 但是这里如果存在读线程了就不能去唤醒队列中的线程（存在写线程）
// 而也只有存在了写线程才会带AQS队列中
return nextc == 0;
}
}
//唤醒AQS中排队的线程
private void doReleaseShared() {
// 死循环
for (;;) {
// 拿到头节点
Node h = head;
if (h != null && h != tail) {
// 说明有排队
int ws = h.waitStatus;
// 判断是否为-1
if (ws == Node.SIGNAL) {
// 如果为-1 说明后面有挂起的线程, 先基于CAS将head的状态从-1， 改为0
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
// 唤醒后续线程
unparkSuccessor(h);
}
// 这里不是给读写锁去准备的 整个过程不涉及到WaitStatus 为-3 的情况
// 是给信号量准备的后续说。。。。
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
// 这里是出口
if (h == head) // loop if head changed
break;
}
}
5、死锁
后续跟新。。。。。。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
