java并发锁ReentrantLock源码分析一 可重入支持中断锁的实现原理(1)

/**

• Acquires in exclusive uninterruptible mode for thread already in

• queue. Used by condition wait methods as well as acquire.

• @param node the node

• @param arg the acquire argument

• @return {@code true} if interrupted while waiting

*/

final boolean acquireQueued(final Node node, int arg) {

boolean failed = true;

try {

boolean interrupted = false;

for (;😉 {

final Node p = node.predecessor(); // @1

if (p == head && tryAcquire(arg)) { // @2

setHead(node);

p.next = null; // help GC

failed = false;

return interrupted;

}

if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt() ) //@3

interrupted = true;

}

} finally {

if (failed)

cancelAcquire(node);

}

}

首先@1,获取该节点的 node 的上一个节点。

@2如果node的前节点是head,因为head初始化时，都是假节点，不代表有线程拥有锁，所以，再次尝试获取锁，如果获取锁，则将锁的 head 设置为当前获取锁的线程的 Node，然后返回 false。返回 false, 则代表 if (!tryAcquire(arg) &&  acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) 的结果为 false,直接返回，并不需要设置中断标记。如果当前节点不是head的话，则说明该锁被别的线程占用了，那就需要等待其他线程释放该锁，具体，我们看一下shouldParkAfterFailedAcquire，为了更好的理解 shouldParkAfterFailedAcquire, 我们先看一下parkAndCheckInterrupt 方法。

/**

• Convenience method to park and then check if interrupted

• 阻塞该线程，然等待唤醒后，会返回 当前线程的中断位；

• @return {@code true} if interrupted

*/

private final boolean parkAndCheckInterrupt() {

LockSupport.park(this);

return Thread.interrupted();

}

/**

• Checks and updates status for a node that failed to acquire.

• Returns true if thread should block. This is the main signal

• control in all acquire loops. Requires that pred == node.prev

• @param pred node’s predecessor holding status

• @param node the node

• @return {@code true} if thread should block

该方法，如果返回true,则代表该线程将被阻塞。

*/

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {

int ws = pred.waitStatus; // @1

if (ws == Node.SIGNAL) // @2

/*

• This node has already set status asking a release

• to signal it, so it can safely park.

*/

return true;

if (ws > 0) { // @3

/*

• Predecessor was cancelled. Skip over predecessors and

• indicate retry.

*/

do { // @4 start

node.prev = pred = pred.prev;

} while (pred.waitStatus > 0); //@4 end

pred.next = node; // @5

} else { // @6

/*

• 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.

只有前置节点的状态为 0 或 PROPAGATE,才能进入到该代码块，表明我们需要一个信号，但暂不挂起线程，调用者需要重 试一次，确保它不能获取到锁，从而阻塞该线程。

*/

compareAndSetWaitStatus(pred, ws, Node.SIGNAL);

}

return false;

}

@1 首先获取前置节点的 waitStatus。

@2 如果前置节点的waitStatus = Node.SIGNAL,那么当前节点，直接阻塞，说明状态是一个信号，如果前置节点状态为             Node.SIGNAL,那么后续节点应该阻塞的信号量，为什么这么说，情况代码@6,一个节点，新增的时候，为 0 正常。

@3,ws > 0 ，则代表前置节点已取消。

@4 处的代码，就是当前 Node 的第一个不为取消状态的前置节点，重构 CLH 队列后，返回 false, 再次进入到 acquireQueued  的无限循环中，又继续 acquireQueued 的流程，继续尝试获取锁，获取锁，或者阻塞。

@6，如果前置节点为0或 PROPAGATE(可传播)，如果前置节点为0，还没有其他节点通过(prev)来判断该 prev 的后继节点是否需要阻塞过，所以，通过 CAS 设置前置节点为 Node.SIGNAL, 重试获取锁过程，避免不必要的线程阻塞。

至此，获取锁的过程就结束了，为了直观体现上述获取锁的过程，现给出如下流程图：

2、ReentrantLock unlock

==========================

public void unlock() {

sync.release(1);

}

//代码直接进入到AbstractQueuedSynchronzier 的 relase方法。

/**

• Releases in exclusive mode. Implemented by unblocking one or

• more threads if {@link #tryRelease} returns true.

• This method can be used to implement method {@link Lock#unlock}.

• @param arg the release argument. This value is conveyed to

•    {@link #tryRelease} but is otherwise uninterpreted and
  

•    can represent anything you like.
  

• @return the value returned from {@link #tryRelease}

*/

public final boolean release(int arg) {

if (tryRelease(arg)) { @1

Node h = head;

if (h != null && h.waitStatus != 0)

unparkSuccessor(h);

return true;

}

return false;

}

直接看代码 tryRelease(arg)方法：tryRelease 方法，是由具体的子类实现的，故将目光转移到 NonFairSync 类的 tryRelease() 方法。

protected final boolean tryRelease(int releases) {

int c = getState() - releases; // @1

if (Thread.currentThread() != getExclusiveOwnerThread()) //@2

throw new IllegalMonitorStateException();

boolean free = false;

if (c == 0) { // @3

free = true;

setExclusiveOwnerThread(null);

}

setState©; //@4

return free;

}

代码@1，首先，计算持有锁的次数=当前被持有锁的次数-减去释放的锁的数量；

代码@2，判断当前锁的持有线程释放与释放锁的线程是否相同，否则，直接抛出运行时异常

代码@3，如果释放锁后，占有次数为0，则代表该锁被释放，设置锁的占有线程为null,

代码@4，设置锁的state,如果返回true,表示锁被释放，如果返回false,表示，锁继续被该线程占有（重入了多次，就需要释放多次）。再次回到release方法，如果tryRelease方法返回true,表示可以释放锁，

public final boolean release(int arg) {

if (tryRelease(arg)) { @1

Node h = head;

if (h != null && h.waitStatus != 0) // @2

unparkSuccessor(h);

return true;

}

return false;

}

代码@2为什么需要判断 h!=null && h.waitStatus != 0的判断呢？，在讲解获取锁的时候，方法 shouldParkAfterFailedAcquire 中对于代码@6处的讲解，其实不难发现，一个节点在请求锁时，只有当它的前驱节点的waitStatus=Node.SIGNAL时，才会阻塞。如果 head为空，则说明 CLH 队列为空，压根就不会有线程阻塞，故无需执行 unparkSuccessor(h), 同样的道理，如果根节点的waitStatus=0，则说明压根就没有 head 后继节点判断是否要绑定的逻辑，故也没有线程被阻塞这一说。原来一个更重要的原因：改进后的CLH，head如果不为空，该节点代表获取锁的那个线程对于的Node,请看获取锁代码acquireQueued中的代码@2处，如果获得锁，setHead(node);知道这一点，就不难理解为什么在释放锁时调用unparkSuccessor(h)时，参数为head了。

现在将目光转移到 AbstractQueuedSynchronizer. unparkSuccessor(h)方法中:

/**

• Wakes up node’s successor, if one exists.

• @param node the node

*/

private void unparkSuccessor(Node node) {

/*

• If status is negative (i.e., possibly needing signal) try

• to clear in anticipation of signalling. It is OK if this

• fails or if status is changed by waiting thread.

*/

int ws = node.waitStatus;

if (ws < 0) // @1

compareAndSetWaitStatus(node, ws, 0);

/*

• Thread to unpark is held in successor, which is normally

• just the next node. But if cancelled or apparently null,

• traverse backwards from tail to find the actual

• non-cancelled successor.

*/

Node s = node.next;

if (s == null || s.waitStatus > 0) { //@2 start

s = null;

for (Node t = tail; t != null && t != node; t = t.prev)

if (t.waitStatus <= 0)

s = t;

} // @2 end

if (s != null) // @3

LockSupport.unpark(s.thread);

}

代码@1，目前waitStatus > 0表示取消，等于0表示正常（新建），该步骤主要是    为了保护，避免重复释放。

代码@2 start-end,此处，主要是从占有锁的节点，往后找，找到第一个没有被取     消的节点，然后唤醒它所代表的线程。这里为什么要从尾部寻址呢？

代码@3，唤醒线程，释放锁的逻辑代码已经结束，那调用LockSupport.unpark(s.thread)后，会进入到哪呢？此时，请再次进入获取锁代码的 acquireQueue方法和shouldParkAfterFailedAcquire方法，先解读如下：

当LockSupport.unpark(s.thread)事，那acquireQueued的代码@3处parkAndCheckInterrupt方法会解除阻塞，继续放下执行，进入到 acquireQueued的for循环处：此时会有两种情况

• HEAD --> Node  … > 其中Node 为  LockSupport.unpark 中的 s;

• HEAD --> A Cancel Node -->  Node(s)

如果为第一种情况，直接进入 @2去尝试获取锁。

如果为第二种情况，shouldParkAfterFailedAcquire(prev,node) 中的 prev 为一个取消的节点，然后会重构整个 CLH 链表，删除Node 到 head 节点直接的取消节点，使得被唤醒线程的节点的上一个节点为 head,从而满足@2处的条件，进入获取锁方法。至此， lock 方法与 unlock 方法流通畅。

final boolean acquireQueued(final Node node, int arg) {

boolean failed = true;

try {

boolean interrupted = false;

for (;😉 {

final Node p = node.predecessor(); // @1

if (p == head && tryAcquire(arg)) { // @2

setHead(node);

p.next = null; // help GC

failed = false;

return interrupted;

}

if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt() ) //@3

interrupted = true;

}

} finally {

if (failed)

cancelAcquire(node);

}

}

与shouldParkAfterFailedAcquire方法：

*/

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {

int ws = pred.waitStatus; // @1

if (ws == Node.SIGNAL) // @2

/*

• This node has already set status asking a release

• to signal it, so it can safely park.

*/

return true;

if (ws > 0) { // @3

/*

• Predecessor was cancelled. Skip over predecessors and

• indicate retry.

*/

do { // @4 start

node.prev = pred = pred.prev;

} while (pred.waitStatus > 0); //@4 end

pred.next = node; // @5

} else { // @6

/*

• 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.

只有前置节点的状态为 0 或 PROPAGATE,才能进入到该代码块，表明我们需要一个信号，但暂不挂起线程，调用者需要重 试一次，确保它不能获取到锁，从而阻塞该线程。

*/

compareAndSetWaitStatus(pred, ws, Node.SIGNAL);

}

return false;

}

为了方便大家理解，给出一个简要的释放锁的流程图：

3、ReentrantLock lockInterruptibly 源码分析

======================================

void lockInterruptibly() throws InterruptedException;

首先先提一个问题： void lock()，通过该方法去获取锁，如果锁被占用，线程阻塞，如果调用被阻塞线程的                  interupt()方法，会取消获取锁吗？答案是否定的。

首先需要知道 LockSupport.park 会响应中断，但不会抛出 InterruptedException。

接下来，我们就从lockInterruptibly()方法入手，一步一步解析，并分析与lock方法的差异。

首先进入的是AbstractQueuedSynchronizer的acquireInterruptibly方法。

/**

• Acquires in exclusive mode, aborting if interrupted.

• Implemented by first checking interrupt status, then invoking

• at least once {@link #tryAcquire}, returning on

• success. Otherwise the thread is queued, possibly repeatedly

• blocking and unblocking, invoking {@link #tryAcquire}

• until success or the thread is interrupted. This method can be

• used to implement method {@link Lock#lockInterruptibly}.

• @param arg the acquire argument. This value is conveyed to

•    {@link #tryAcquire} but is otherwise uninterpreted and
  

•    can represent anything you like.
  

• @throws InterruptedException if the current thread is interrupted

*/

public final void acquireInterruptibly(int arg)

throws InterruptedException {

if (Thread.interrupted())

throw new InterruptedException();

if (!tryAcquire(arg))

doAcquireInterruptibly(arg); // @1

}

如果尝试获取锁失败后，进入获取锁并等待锁逻辑，doAcquireInterruptibly

/**

• Acquires in exclusive interruptible mode.

• @param arg the acquire argument

*/

private void doAcquireInterruptibly(int arg)

throws InterruptedException {

final Node node = addWaiter(Node.EXCLUSIVE); // @1

boolean failed = true;

try {

for (;😉 {

final Node p = node.predecessor();

if (p == head && tryAcquire(arg)) { // @2

setHead(node);

p.next = null; // help GC

failed = false;

return;

}

if (shouldParkAfterFailedAcquire(p, node) &&

parkAndCheckInterrupt())

throw new InterruptedException(); //@3

}

} finally {

if (failed)

cancelAcquire(node); //@4

}

}

整个获取锁的逻辑与 lock 方法一样，唯一的区别在于  @3 处，如果 parkAndCheckInterrupt 如果是通过 t.interupt 方法，使LockSupport.park 取消阻塞的话，会抛出 InterruptedException，停止尝试获取锁，然后将添加的节点取消，那重点关注一下cancelAcquire(node);

/**

• Cancels an ongoing attempt to acquire.

• @param node the node

*/

private void cancelAcquire(Node node) {

// Ignore if node doesn’t exist

if (node == null)

return;

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

最后

分布式技术专题+面试解析+相关的手写和学习的笔记pdf

还有更多Java笔记分享如下：

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算

[外链图片转存中…(img-K6DkIWQd-1712166693008)]
[外链图片转存中…(img-m3IaGtXt-1712166693008)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-a3UkuHiC-1712166693009)]

最后

分布式技术专题+面试解析+相关的手写和学习的笔记pdf

还有更多Java笔记分享如下：

[外链图片转存中…(img-X8OI9Mqw-1712166693009)]

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算