JAVA并发： ReentrantLock独占锁

最新推荐文章于 2023-02-07 11:32:47 发布
最新推荐文章于 2023-02-07 11:32:47 发布
阅读量214 收藏
点赞数
分类专栏： JAVA并发编程 文章标签： java 多线程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wangbo199308/article/details/108688143
版权

概述

介绍java并发包中的Lock锁的基本使用与实现细节。

1 Lock接口

lock锁可以实现和synchroinzed关键字类似的同步功能。

  • Synchronized是关键字，内置语言实现，Lock是接口。
  • Lock在使用的时候需要显示的去获取锁与释放锁，缺少比synchroinzed关键字的获取释放锁的便捷性。
  • Synchronized在线程发生异常时会自动释放锁，因此不会发生异常死锁。Lock异常时不会自动释放锁，所以需要在finally中实现释放锁。
  • Lock是可以中断锁，Synchronized是非中断锁，必须等待线程执行完成释放锁。
  • Lock可以超时获取锁，Synchronized不具备。
Lock lock = new ReentrantLock();
lock.lock();
try {
} finally {
	lock.unlock();
}

在finally块中释放锁，目的是保证在获得锁后，最终能够被释放。

注意：不要讲获取锁的过程写在try块中，因为如果在获取锁时发生了异常，异常抛出的同时，也会导致锁无故释放。

2 LockSupport

介绍ReentrantLock之前，先了解LockSupport的一些用法。

LockSupport定义了一组的公共静态方法，提供了最基本的线程阻塞和唤醒功能。

image-20200727001941470

public class ParkDemo {

    private static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) throws InterruptedException {

        Thread thread = new Thread(() -> {
            System.out.println("thread strat");
            // LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(5));，阻塞线程，5s后没有LockSupport.unpark自动返回
            // 阻塞线程
            LockSupport.park();
            System.out.println("thread end");
        });

        thread.start();

        TimeUnit.SECONDS.sleep(3);
        // 唤醒线程thread
        LockSupport.unpark(thread);
    }
}

3 ReentrantLock

3.1 ReentrantLock类图

image-20200902222935735

从ReentrantLock类图中我们可以发现AbstractQueuedSynchronizer即队列同步器。它是一个同步工具也是 Lock 用来实现线程同步的核心组件。AQS 队列内部维护的是一个FIFO 的双向链表，这种结构的特点是每个数据结构都有两个指针，分别指向直接的后继节点和直接前驱节点。所以双向链表可以从任意一个节点开始很方便的访问前驱和后继。每个 Node 其实是由线程封装，当线程争抢锁失败后会封装成 Node 加入到 ASQ 队列中去；当获取锁的线程释放锁以后，会从队列中唤醒一个阻塞的节点(线程)。

3.2 ReentrantLock#lock

public ReentrantLock() {
  sync = new NonfairSync();
}

public void lock() {
  sync.lock();
}

实际上默认的锁为非公平锁。sync 实际上是一个抽象的静态内部类，它继承了 AQS

Sync 有两个具体的实现类，分别是：

NofairSync：表示可以存在抢占锁的功能，也就是说不管当前队列上是否存在其他线程等待，新线程都有机会抢占锁。

FailSync: 表示所有线程严格按照 FIFO 来获取锁。

公平锁与非公平锁的区别在于:线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁

以下以非公平锁为例子进行源码分析。

final void lock() {
  //state 为0即表示当前没有锁，通过CAS尝试去获取锁，如果获取成功，设置当前线程获取到锁
  if (compareAndSetState(0, 1))
    // java.util.concurrent.locks.AbstractOwnableSynchronizer#exclusiveOwnerThread为当前线程
    setExclusiveOwnerThread(Thread.currentThread());
  // 如果cas失败，需要把当前线程加入同步队列进行等待
  else
    acquire(1);	
}

state 是 AQS 中的一个属性，它在不同的实现中所表达的含义不一样，对于重入锁的实现来说，表示一个同步状态。它有两个含义的表示

  1. 当 state=0 时，表示无锁状态

  2. 当 state>0 时，表示已经有线程获得了锁，也就是 state=1，但是因为ReentrantLock 允许重入，所以同一个线程多次获得同步锁的时候，state 会递增，比如重入 5 次，那么 state=5。而在释放锁的时候，同样需要释放 5 次直到 state=0其他线程才有资格获得锁。

继续查看 acquire(1)方法，该方法存在于 AbstractQueuedSynchronizer 类，该类是 java.util.concurent.locks 锁的队列机制实现类

public final void acquire(int arg) {
  if (!tryAcquire(arg) &&
      acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
    selfInterrupt();
}

这个方法的主要逻辑是

  1. 通过 tryAcquire 尝试获取独占锁，如果成功返回 true，失败返回 false

  2. 如果 tryAcquire 失败，则会通过 addWaiter 方法将当前线程封装成 Node 添加到 AQS 队列尾部

  3. acquireQueued，将Node作为参数，通过自旋去尝试获取锁。

3.2.1 tryAcquire

我们先分析tryAcquire的实现

protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}

我们一路跟踪进来，发现尝试获取锁的代码在 ReentrantLock内部类 Sync 汇总，Sync 是 NonFairSync 和 FairSync 的父类。

final boolean nonfairTryAcquire(int acquires) {
  // 当前线程
  final Thread current = Thread.currentThread();
  // 锁的状态
  int c = getState();
  // 无锁状态
  if (c == 0) {
    // cas替换state的值，cas成功表示获取锁成功
    if (compareAndSetState(0, acquires)) {
      // 设置获得锁的线程为当前线程
      setExclusiveOwnerThread(current);
      return true;
    }
  }
  // state不为0且获得锁的线程为当前线程
  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;
}

如果 tryAcquire(arg) 返回 true,则不会执行 acquireQueued，表示成功获取锁，如果 tryAcquire(arg) 返回 false, 说明没有成功获取锁，则加入请求队列中。接着请看 addWaiter (Node.EXCLUSIVE) 方法。

3.2.2 addWaiter
private Node addWaiter(Node mode) {
  	// mode 为Node.EXCLUSIVE独占锁
    // 把当前线程封装为 Node
    Node node = new Node(Thread.currentThread(), mode);
  	// tail是AQS中表示同比队列队尾的属性，默认是 null
    Node pred = tail;
    // tail不为空的情况下，说明队列中存在节点(有线程已经在该锁上等待)
    if (pred != null) {
        node.prev = pred;
      	// 如果cas成功。把node加入到AQS队列，也就是设置为tail。
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    // 如果tail为空或者cas设置tail失败
    enq(node);
    return node;
}

addWaiter 将当前线程封装成Node后加入AQS队列

  1. 将当前线程封装成 Node

  2. 当前链表中的 tail 节点是否为空，如果不为空，则通过 cas 操作把当前线程的node 添加到 AQS 队列

  3. 如果tail为空或者 cas 失败，调用 enq 将节点添加到 AQS 队列

下图为加入AQS队列时，CAS失败的节点链表

image-20200902235932942

3.2.3 enq
private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
      	// AQS队列为空，先加入一个空Node作为head与tail后通过自旋把node加入AQS
        if (t == null) {
            // CAS失败说明存在head与tail，通过自旋把node节点加入AQS队列
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            // 把node加入AQS队列
            node.prev = t;
            // CAS失败，通过自旋把node加入AQS队列
            if (compareAndSetTail(t, node)) {
                t.next = node;
              	// 返回原先的尾节点
                return t;
            }
        }
    }
}

使用自旋来加入，需要初始化一个head 节点，也就是 head 节点并不代表一个等待获取锁的对象，AbstractQueuedSynchronzier 选择初始化 head,tail 的时机为第一次产生锁争用的时候。初始化head,tail,设置成功后，再将新添加的节点放入到队列的尾部，然后该方法会返回原先的尾节点。

图解分析

image-20200903001642995

3.2.4 acquireQueued

返回是否中断标志（interrupt）。

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            // 此节点的前驱结点
            final Node p = node.predecessor();
            // 前驱结点为head，有资格去争抢锁且获取锁成功。(有线程释放锁，锁的释放见下面的分析)
            if (p == head && tryAcquire(arg)) {
                // 1、把当前结点设置为head
                // 2、head的线程设置为null
                // 3、head的前驱结点为null
                setHead(node);
                // 把原 head 节点从链表中移除
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
          	// 获取锁的线程还未释放
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                // 返回当前线程在等待过程中有没有中断过。
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

private void setHead(Node node) {
  	head = node;
  	node.thread = null;
  	node.prev = null;
}

通过 addWaiter 方法把线程添加到链表后，会接着把 Node 作为参数传递给

acquireQueued 方法，去竞争锁

  1. 获取当前节点的 prev 节点

  2. 如果 prev 节点为 head 节点，那么它就有资格去争抢锁，调用 tryAcquire 抢占锁

  3. 抢占锁成功以后，把获得锁的节点设置为 head，并且移除原来的初始化 head节点

  4. 如果获得锁失败，则根据 waitStatus 决定是否需要挂起线程及是否有中断

  5. 发生异常，通过 cancelAcquire 取消获得锁的操作。

3.2.5 shouldParkAfterFailedAcquire
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    // 前置结点
    int ws = pred.waitStatus;
    // 如果前置节点为 SIGNAL，意味着只需要等待其他前置节点的线程被释放
    if (ws == Node.SIGNAL)
    		//返回 true，意味着可以直接放心的挂起了
        return true;
    // ws大于0，意味着prev节点取消了排队，直接移除这个节点就行    
    if (ws > 0) {
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0); //这里采用循环，从双向列表中移除 CANCELLED 的节点
        pred.next = node;
    } else {
        // 利用cas设置prev节点的状态为 SIGNAL(-1), 自旋时下次即可返回为true，把此节点的线程park
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

Node 有 5 中状态，分别是：CANCELLED（1），SIGNAL（-1）、CONDITION（- 2）、PROPAGATE(-3)、默认状态(0)

CANCELLED: 在同步队列中等待的线程等待超时或被中断，需要从同步队列中取消该 Node 的结点, 其结点的 waitStatus 为 CANCELLED，即结束状态，进入该状态后的结点将不会再变化。

SIGNAL: 只要前置节点释放锁，就会通知标识为 SIGNAL 状态的后续节点的线程。

CONDITION： 和 Condition 有关系，后续会讲解

PROPAGATE：共享模式下，PROPAGATE 状态的线程处于可运行状态

0:初始状态

CANCELLED节点移除示例图

image-20200903011104981

3.2.6 parkAndCheckInterrupt
private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}

使用 LockSupport.park 挂起当前线程变成 WATING 状态。

Thread.interrupted，返回当前线程是否被其他线程触发过中断请求，也就是thread.interrupt(); 如果有触发过中断请求，那么这个方法会返回当前的中断标识true，并且对中断标识进行复位标识已经响应过了中断请求。如果返回 true，意味着在 acquire 方法中会执行 selfInterrupt()。

selfInterrupt： 标识如果当前线程在 acquireQueued 中被中断过，则需要产生一个中断请求，原因是线程在调用 acquireQueued 方法的时候是不会响应中断请求。如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上

static void selfInterrupt() {
    Thread.currentThread().interrupt();
}

image-20200903011839390

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

image-20200924223750434

3.3 ReentrantLock#unlock

public void unlock() {
  sync.release(1);
}

public final boolean release(int arg) {
  // 释放锁成功
  if (tryRelease(arg)) {
    // 得到 aqs 中 head 节点
    Node h = head;
    //如果 head 节点不为空并且状态=0.调用 unparkSuccessor(h)唤醒后继节点
    if (h != null && h.waitStatus != 0)
      unparkSuccessor(h);
    return true;
  }
  return false;
}
3.3.1 tryRelease

先查看tryRelease代码

protected final boolean tryRelease(int releases) {
  	// 计算持有锁的次数=当前被持有锁的次数-减去释放的锁的数量
    int c = getState() - releases;
    // 判断当前锁的持有线程释放与释放锁的线程是否相同，否则，直接抛出运行时异常
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    // 如果释放锁后，占有次数为0，则代表该锁被释放，设置锁的占有线程为null
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    // 设置锁的state,如果返回true,表示锁被释放，如果返回false,表示，锁继续被该线程占有（重入了多次，就需要释放多次）。
    setState(c);
    return free;
}

这个方法可以认为是一个设置锁状态的操作，通过将 state 状态减掉传入的参数值（参数是 1），如果结果状态为 0，就将排它锁的 Owner 设置为 null，以使得其它的线程有机会进行执行。在排它锁中，加锁的时候状态会增加 1，在解锁的时候减掉 1，同一个锁，在可以重入后，可能会被叠加为 2、3、4 这些值，只有 unlock()的次数与 lock()的次数对应才会将 Owner 线程设置为空，而且也只有这种情况下才会返回 true。

3.3.2 release

分析完tryRelease方法，返回为true，再分析release方法。

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

代码@为什么需要判断 h!=null && h.waitStatus != 0的判断呢？

在讲解获取锁的时候，方法 shouldParkAfterFailedAcquire 中对于代码的讲解，其实不难发现，一个节点在请求锁时，只有当它的前驱节点的waitStatus=Node.SIGNAL时，才会阻塞。如果 head为空，则说明AQS队列为空，压根就不会有线程阻塞，故无需执行 unparkSuccessor(h), 同样的道理，如果根节点的waitStatus=0，则说明压根就没有 head 后继节点，故也没有线程被阻塞这一说。head如果不为空，该节点代表获取锁的那个线程。

3.3.3 unparkSuccessor
private void unparkSuccessor(Node node) {
    // node为head节点，获得 head 节点的状态
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);
    // head的后继节点
    Node s = node.next;
    // 如果下一个节点为 null 或者 status>0 表示 cancelled 状态
    if (s == null || s.waitStatus > 0) {
        s = null;
        // 从尾部节点开始扫描，找到距离 head 最近的一个waitStatus<=0 的节点
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    // next 节点不为空，直接唤醒这个线程即可
    if (s != null)
        LockSupport.unpark(s.thread);
}

为什么在释放锁的时候是从 tail 进行扫描?

我们再回到 enq那个方法或者addWaiter方法

private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
      	// AQS队列为空，先加入一个空Node作为head与tail后通过自旋把node加入AQS
        if (t == null) {
            // CAS失败说明存在head与tail，通过自旋把node节点加入AQS队列
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            // 把node加入AQS队列
            node.prev = t;
            // CAS失败，通过自旋把node加入AQS队列
            if (compareAndSetTail(t, node)) {
                t.next = node;
              	// 返回原先的尾节点
                return t;
            }
        }
    }
}

private Node addWaiter(Node mode) {
  	// mode 为Node.EXCLUSIVE独占锁
    // 把当前线程封装为 Node
    Node node = new Node(Thread.currentThread(), mode);
  	// tail是AQS中表示同比队列队尾的属性，默认是 null
    Node pred = tail;
    // tail不为空的情况下，说明队列中存在节点(有线程已经在该锁上等待)
    if (pred != null) {
        node.prev = pred;
      	// 如果cas成功。把node加入到AQS队列，也就是设置为tail。
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    // 如果tail为空或者cas设置tail失败
    enq(node);
    return node;
}

  1. 将新的节点的 prev 指向 tail

  2. 通过 cas 将 tail 设置为新的节点，因为 cas 是原子操作所以能够保证线程安全性

  3. t.next=node；设置原 tail 的 next 节点指向新的节点

image-20200903234504418

在 cas 操作之后，t.next=node 操作之前。存在其他线程调用 unlock 方法从 head开始往后遍历，由于 t.next=node 还没执行意味着链表的关系还没有建立完整。

就会导致遍历到 t 节点的时候被中断。所以从后往前遍历，一定不会存在这个问题。

图解分析

image-20200903235320749

通过锁的释放，原本的结构就发生了一些变化。head 节点的 waitStatus 变成了 0，ThreadB 被唤醒。

当LockSupport.unpark(s.thread)时，原本挂起的线程被唤醒以后继续执行，应该从哪里执行呢？从acquireQueued的代码parkAndCheckInterrupt方法会解除阻塞，继续放下执行，进入到 acquireQueued的for循环处详细解释见acquireQueued。

图解分析

image-20200904000346758

释放锁的流程图

image-20200904001040927

3.4 公平锁和非公平锁的区别

锁的公平性是相对于获取锁的顺序而言的，如果是一个公平锁，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是 FIFO。 在上面分析的例子来说，只要CAS 设置同步状态成功，则表示当前线程获取了锁，而公平锁则不一样。非公平锁在获取锁的时候，会先通过 CAS 进行抢占，而公平锁则不会。

FairSync.tryAcquire

protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 同步队列中当前节点是否有前驱节点,该方法返回 true，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

public final boolean hasQueuedPredecessors() {
    // 尾节点
    Node t = tail;
    // 头节点
    Node h = head;
    Node s;
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}
  1. 如果h==t成立，h和t均为null或是同一个具体的节点，无后继节点，返回false
  2. 如果h!=t成立，head.next是否为null，如果为null，返回true。什么情况下h!=t的同时h.next==null？？，有其他线程第一次正在入队时，可能会出现。见AQS的enq方法，compareAndSetHead(node)完成，还没执行tail=head语句时，此时tail=null,head=newNode,head.next=null。
  3. 如果h!=t成立，head.next != null，则判断head.next是否是当前线程，如果是返回false，否则返回true（head节点是获取到锁的节点，但是任意时刻head节点可能占用着锁，也可能释放了锁（unlock()）,未被阻塞的head.next节点对应的线程在任意时刻都是有必要去尝试获取锁）

3.5 ReentrantLock#tryLock

public boolean tryLock() {
    return sync.nonfairTryAcquire(1);
}

tryLock它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

3.6 ReentrantLock#tryLock(long timeout, TimeUnit unit)

public boolean tryLock(long timeout, TimeUnit unit)
        throws InterruptedException {
    return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}

public final boolean tryAcquireNanos(int arg, long nanosTimeout)
        throws InterruptedException {
    if (Thread.interrupted())
        throw new InterruptedException();
    // 调用tryAcquire先尝试获取锁，如果失败则调用doAcquireNanos
    return tryAcquire(arg) ||
        doAcquireNanos(arg, nanosTimeout);
}
3.6.1 doAcquireNanos

tryAcquire前面已经分析过，以下分析doAcquireNanos的源码

private boolean doAcquireNanos(int arg, long nanosTimeout)
        throws InterruptedException {
    if (nanosTimeout <= 0L)
        return false;
    // 计算出到期时间
    final long deadline = System.nanoTime() + nanosTimeout;
    // 将当前线程封装成Node后加入AQS队列(前面已经分析过)
    final Node node = addWaiter(Node.EXCLUSIVE);
    boolean failed = true;
    try {
    		// 反复重试直到成功获取锁或者超时返回false
        for (;;) {
            final Node p = node.predecessor();
            // 该节点的前驱节点是头节点则尝试获取锁
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return true;
            }
            // 剩余时间
            nanosTimeout = deadline - System.nanoTime();
          	// 超时返回false
            if (nanosTimeout <= 0L)
                return false;
          // shouldParkAfterFailedAcquire 判断是否需要阻塞线程 并且剩余时间大于 spinForTimeoutThreshold （默认1000）
            if (shouldParkAfterFailedAcquire(p, node) &&
                nanosTimeout > spinForTimeoutThreshold)
                // 阻塞线程，超时唤醒去尝试抢占锁
              	// 并发问题时，当前驱结点释放锁时。锁被新加入的线程抢占，此时需要重新park，时间为剩余的时间
                LockSupport.parkNanos(this, nanosTimeout);
          	// 中断检测
            if (Thread.interrupted())
                throw new InterruptedException();
        }
    } finally {
        // 发生异常, park超时唤醒并且没有成功抢占锁
        if (failed)
            // 把当前结点从AQS队列中取消
            cancelAcquire(node);
    }
}
3.6.2 cancelAcquire

超时没有获取到锁，将添加的节点取消。

private void cancelAcquire(Node node) {
        if (node == null)
            return;
				// 设置node的线程为null
        node.thread = null;
				// 当前节点的前驱节点
        Node pred = node.prev;
        // 设置prev的值为从当前取消节点往head节点方向，第一个未取消节点。并将中间的取消节点脱离这条链。
  			// 跳过被cancel的前继node，找到一个有效的前继节点pred
        while (pred.waitStatus > 0)
            node.prev = pred = pred.prev;

        Node predNext = pred.next;
        // 设置当前节点为CANCELLED状态
        node.waitStatus = Node.CANCELLED;
				// 如果被取消的节点是尾节点的话，那么将pred设置为尾节点。如果设置失败，说明，有别的线程在申请锁，使得尾部节点发生了变化
        if (node == tail && compareAndSetTail(node, pred)) {
            // 如果设置成功了，既然pred是尾节点，那么再次将pred的next域设置为null;当然也能设置失败，表明又有新的线程在申请锁，创建了新的next节点
            compareAndSetNext(pred, predNext, null);
        } else {
            // 如果取消的节点，不是尾部节点或者CAS设置尾节点失败
            int ws;
          	// pred不是head节点
          	// pred的waitStatus为SIGNAL。或者设置<=0且设置为SIGNAL成功
          	// pred.thread 的线程不为空
            if (pred != head &&
                ((ws = pred.waitStatus) == Node.SIGNAL ||
                 (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
                pred.thread != null) {
              	// 待取消的节点的 next 
                Node next = node.next;
              	// 待取消的节点的 next不为空，并且状态为非取消的时，将 pred.next 设置为 node.next；该取消节点被删除
                if (next != null && next.waitStatus <= 0)
                    compareAndSetNext(pred, predNext, next);
            } else {
                // 如果pred为head执行唤醒操作即node是head的后继节点
                unparkSuccessor(node);
            }

            node.next = node; // help GC
        }
    }

  1. node是tail

    image-20200907235956180

  2. node既不是tail，也不是head的后继节点

    image-20200908000917861

    将successor指向pred是谁干的？
    是别的线程做的。当别的线程在调用shouldParkAfterFailedAcquire()时，会根据prev指针跳过被cancel掉的前继节点，同时，会调整其遍历过的prev指针

  3. 处于Node.CANCEL状态节点的删除发生在shouldParkAfterFailedAcquire，一处就发生在cancelAcquire方法。

3.7 ReentrantLock#lockInterruptibly

lock()，通过该方法去获取锁，如果锁被占用，线程阻塞，如果调用被阻塞线程的interupt()方法，会取消获取锁吗？答案是否定的。

首先需要知道 LockSupport.park 会响应中断，但不会抛出 InterruptedException。接下来，我们就从lockInterruptibly()方法入手，一步一步解析，并分析与lock方法的差异。

public final void acquireInterruptibly(int arg)
  throws InterruptedException {
  if (Thread.interrupted())
    throw new InterruptedException();
  // 如果尝试获取锁失败后，进入获取锁并等待锁逻辑。
  if (!tryAcquire(arg))
    doAcquireInterruptibly(arg);
}

// 与lock逻辑类似
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 如果是通过 t.interupt 方法，使LockSupport.park 取消阻塞的话，会抛出 InterruptedException，
        // 中断interupt相当于unpark,也会唤醒处于park状态的线程
        // 停止尝试获取锁，然后将添加的节点取消
        throw new InterruptedException();
    }
  } finally {
    if (failed)
      // 前面已经分析过
      cancelAcquire(node);
  }
}
我只是有点困呦
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
JAVA中的ReentrantLock和ReentrantReadWriteLock锁简单使用
madman
01-20 7178
ReentrantLock的作用和synchronize是一样的，都是实现锁的功能，但是ReentrantLock需要手写代码对锁进行获取和释放(一定要在finally里面释放)，要不然就永远死锁了，ReentrantLock也可以用来做线程之间的挂起和通知，synchronize一般是使用object的wait和notify来实现，ReentrantLock使用Condition来实现线程之间的...
详解java并发之重入锁-ReentrantLock
08-26
详解 Java 并发之重入锁-ReentrantLock Java 中的并发编程是一种复杂的技术，需要深入了解 Java 的并发机制和锁机制。ReentrantLock 是 Java 中的一种常用锁机制，它提供了一个可重入的锁机制，能够确保线程安全。...
Java并发编程--锁原理之独占锁ReentrantLock
一个巨大的博客
01-23 222
文章目录独占锁ReentrantLock的原理(1). 结构(2). 获取锁1). void lock()方法2). void lockInterruptibly()方法3). boolean tryLock()方法4). boolean tryLock(long timeout, TimeUnit unit)方法(3). 释放锁1). void unlock()方法 独占锁ReentrantLo...
Java 独占锁ReentrantLock、读（悲观读）写锁ReentrantReadWriteLock、读（乐观读/悲观读）写锁StampedLock
CodingAnHour
08-28 512
锁必然要知道AbstractQueuedSynchronizer（AQS），AQS提供了一个框架，用于实现依赖于先进先出（FIFO）等待队列的阻塞锁和相关同步器（信号量、事件等）。独占，只有一个线程能执行，如ReentrantLock（悲观锁：除非线程1全部运行完后才会释放锁，否则其他线程无法拿到锁。可重入，公平与非公平特征 ）Lock是juc中实现的锁接口，定义了锁的一些行为规范，他的设计目的是为了解决synchronized关键字在一些并发场景下不适用的问题，相对synchronized更灵活。....
AQS之独占锁ReentrantLock
xq_adress的博客
06-16 234
AQS
Java并发编程（六）——Java中的并发工具类
weixin_43985675的博客
10-12 141
等待多线程完成的CountDownLatch CountDownLatch允许一个或多个线程等待其他线程完成操作。 join用于让当前执行线程等待join线程执行结束。其实现原理是不停检查join线程是否存活，如果join线程存活则让当前线程永远等待。 直到join线程中止后，线程的this.notifyAll()方法会被调用，调用notidyAll（）方法是在JVM里实现的。 同步屏障CyclicBarrier 让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，
java并发编程：juc、aqs
08-09
Java并发编程中的`JUC`(Java Util Concurrency)库是Java平台中用于处理多线程问题的核心工具包，它提供了一系列高效、线程安全的工具类，帮助开发者编写并发应用程序。`AQS`(AbstractQueuedSynchronizer)是JUC库中的...
javabase:java并发
05-11
Java并发基础操作主要包括线程的创建、管理、同步以及异常处理，而并发集合、队列和锁则是实现并发控制的核心工具。 一、Java线程基础 Java通过`Thread`类或者实现`Runnable`接口来创建线程。线程的启动通过`start...
深入java并发编程，使用ReentrantLock和 Synchronized加锁
最新发布
12-25
在Java并发编程中，理解和熟练...总的来说，Java并发编程中的锁机制是确保线程安全的关键，理解并熟练使用`synchronized`和`ReentrantLock`，以及相应的等待/通知机制，能够帮助开发者设计出高效且可靠的多线程程序。
Java多线程并发编程和锁原理解析
08-25
Java多线程并发编程和锁原理解析是Java并发编程中非常重要的知识点，文章通过示例代码详细介绍了Java多线程并发编程和锁原理解析，对大家的学习或者工作具有一定的参考学习价值。 乐观锁和悲观锁 在Java多线程并发...
从 ReentrantLock 探究 AQS 细节 - 独占锁篇
BASK2312的博客
02-07 163
如何保障程序有序的运行，锁是永远都绕不开的一条拦路虎。即可以让程序有条不紊的运行，也可以让程序步履蹒跚。而今天，我们就来剥开 Java 中最常用的锁 ReentrantLock，研究它，参悟它。
ReentrantLock 独占锁学习
小城我家
07-02 450
ReentrantLock ReentrantLock 是可重入的独占锁 ， 同 时 只能有 一个线程可 以 获取该锁，其他获取该锁 的线程会被阻塞而被放入该锁的 AQS 阻塞队列里面 ReentrantLock 最终还是使用 AQS 来实现的，并且根据参数来决定 其 内 部是一个公平还是非公平锁，默认是非公平锁 public ReentrantLock() { sync...
Java并发编程（二十一）独占锁 ReentrantLock 的原理
逆流者的博客
06-10 596
此文为读书笔记，欢迎评论，讨论问题，共同进步！ 简介 ReentrantLock 是可重入的独占锁，同时只能有一个线程可以获取该锁，其他获取该锁的线程会被阻塞而被放入该锁的 AQS 阻塞队列里面。 类图: 从类图可以看到，ReentrantLock 是使用 AOS 来实现的，并且根据参数来决定其内部是一个公平还是非公平锁，默认是非公平锁。 // 默认非公平锁 public ReentrantLock() { sync = new NonfairSync(); } // fair
Java 锁概（二）ReentrantLock
qq_42583549的博客
07-03 591
Java 锁概（二）ReentrantLock
AQS、LockSupport、Lock和ReentrantLock、Condition
gao_tianLiang的博客
03-20 265
AQS、LockSupport、Lock和ReentrantLock、Condition
java多线程之LockSupport及ReentrantLock
stormCoder的博客
09-02 1451
目前java语言层面能够实现线程的阻塞与唤醒,主要包含两个组合对wait/notify以及park/unpark。wait/notify这组组合中wait必须发生在notify前面，否则很可能造成线程会一直阻塞,而park与unpark则不必,但是如果unpark先执行,后面执行park操作将不会阻塞。JDK并发中的AQS框架使用的就是LockSupport中的park/unpark操作，实际上调用
Java中的锁分类与使用
qq_44912603的博客
10-19 146
Java锁的种类 　　在笔者面试过程时，经常会被问到各种各样的锁，如乐观锁、读写锁等等，非常繁多，在此做一个总结。介绍的内容如下： 乐观锁/悲观锁 独享锁/共享锁 互斥锁/读写锁 可重入锁 公平锁/非公平锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁 　　以上是一些锁的名词，这些分类并不是全是指锁的状态，有的指锁的特性，有的指锁的设计，下面总结的内容是对每个锁的名词进行一定的解释。 1.1 乐观锁/悲观锁 　　乐观锁与悲观锁并不是特指某两种类型的锁，是人们定义出来的概念或思想，主要是指看待并发同步的角度.
Java并发：ReentrantLock源码分析
404 Not Found
05-24 1136
注：JDK1.7 对照源码效果更佳∠( ᐛ 」∠)_ 相关知识：队列同步器AbstractQueuedSynchronizer是用来构建锁或者其他同步组件的基础框架，它使用一个int变量（stats）来表示同步状态，并使用一个内置的FIFO队列来完成...
并发情况下ReentrantLock锁死锁
he91-com
09-25 1318
业务背景： 系统启动时需要向DRM服务器注册资源，同一个资源只能注册一次，不能重复注册。现在有两个资源需要注册，第一个资源为Profile阀门控制，第二个资源为模型阀门控制。 存在缺陷的代码： public class CommonConfig { /** 非公平锁 */ private static ReentrantLock lock = new Reentr...
Java并发编程实战：ReentrantLock与读写锁详解
Java并发编程实践的第七章深入探讨了Java5.0引入的高级锁定机制，特别是重入锁（ReentrantLock）和读写锁，这对于理解和优化多线程编程至关重要。这一章节首先介绍了Lock接口及其与内置锁的区别，Lock提供了一系列...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值