【并发编程】ReentrantLock的lockInterruptibly()方法源码分析

目录

1 lockInterruptibly()

2 lock()

3 总结

---

ReentrantLock.lockInterruptibly()：允许在尝试获取锁时由其它线程调用尝试获取锁的线程的Thread.interrupt方法来中断线程而直接返回，这时不用获取到锁，而会直接抛出一个InterruptedException。

• ReentrantLock.lock()：方法不允许Thread.interrupt中断,即使检测到Thread.isInterrupted，一样会继续尝试获取锁，获取失败则阻塞等待。只是在最后获取锁成功后再把当前线程置为interrupted状态。

总的来说，lockInterruptibly()支持线程中断，它与lock()方法的主要区别在于lockInterruptibly()获取锁的时候如果线程中断了，会抛出一个异常，而lock()不会管线程是否中断都会一直尝试获取锁，获取锁之后把自己标记为已中断，继续执行自己的逻辑，后面也会正常释放锁。我们就记住：

1. 使用lockInterruptibly时：当前线程可以被其他线程直接中止结束，并且在其他线程中抛出异常信息；（优先考虑响应中断）
2. 使用lock时：当前线程也可以响应其他线程的中断命令，但不会抛出异常信息，不会直接中止，而是会在成功获取到锁时将自己的中断标志设置true；（优先考虑获取锁）

具体实现以及与lock()方法的对比如下：

1 lockInterruptibly()

// ReentrantLock.lockInterruptibly()
// 相当于ReentrantLock.lock()
public void lockInterruptibly() throws InterruptedException {
    // 这里调用的sync的acquireInterruptibly()方法，该方法是sync继承自AbstractQueuedSynchronizer的方法，由抽象类AbstractQueuedSynchronizer实现
    sync.acquireInterruptibly(1);
}

// AbstractQueuedSynchronizer.acquireInterruptibly()
// 相当于acquire(int arg)方法
public final void acquireInterruptibly(int arg) throws InterruptedException {
    // 在第一次调用acquireInterruptibly时，如果发现当前线程已经被中断了，则直接抛出中断异常，响应中断
    if (Thread.interrupted())
        throw new InterruptedException();
    
    // 尝试获取锁
    // 这里调用的sync的tryAcquire()方法，它的具体实现是根据当前ReentrantLock是公平锁还是非公平锁来决定的
    // 如果当前sync是公平锁tryAcquire()方法就是使用的FairSync实现类中的tryAcquire()实现方法，如果当前是非公平锁，则使用的是NonfairSync实现类中的tryAcquire()方法，也就是nonfairTryAcquire()方法
    if (!tryAcquire(arg))
        // 尝试获取所失败之后
        doAcquireInterruptibly(arg);
}

doAcquireInterruptibly()方法与acquireQueue()差别在于方法的返回途径有两种，一种是for循环结束，正常获取到锁；另一种是线程被唤醒后检测到中断请求，则立即抛出中断异常，该操作导致方法结束。

// AbstractQueuedSynchronizer.doAcquireInterruptibly()
// 相当于acquireQueued(addWaiter(Node.EXCLUSIVE), arg))，将获取锁失败的线程添加到等待队列并阻塞
private void doAcquireInterruptibly(int arg) throws InterruptedException {
    // 为当前线程创建Node线程节点，并将其入队
    final Node node = addWaiter(Node.EXCLUSIVE);
    // 入队之后，开始对线程进行阻塞
    // 阻塞线程是否失败
    boolean failed = true;
    try {
        // 自旋
        for (;;) {
            // 获取当前节点的前一个节点
            final Node p = node.predecessor();
            // 如果当前节点是等待队列中的第一个线程节点，则调用tryAcquire()尝试获取锁
            if (p == head && tryAcquire(arg)) {
                // 尝试获取锁成功，下面就需要将当前节点的node出队
                // 将head指针节点指向node，并且将node节点的前驱节点和代表的线程属性都设置为null
                setHead(node);
                p.next = null; // help GC
                // 将阻塞标志设置为false，说明没有阻塞节点线程
                failed = false;
                // 1.这里没有中断标识，也就没有返回中断标志，而是直接返回结束方法
                // lock和lockInterruptibly区别就是对中断的处理方式 
                return;
            }
            // shouldParkAfterFailedAcquire：判断线程可否安全阻塞
            // parkAndCheckInterrupt：挂起线程并返回当时中断标识Thread.interrupted()
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                // 2.当parkAndCheckInterrupt返回中断标识为true时立即抛出异常中断线程，而不是和lock()一样记录中断标志，等到获取锁成功之后再响应中断
                throw new InterruptedException();
        }

	// finally的执行一定会在throw new InterruptedException();抛出异常之前执行。finally代码块中的代码不管什么情况下，一定会被执行的
    } finally {

		/**
         * failed标识当前线程的阻塞有没有失败
         * doAcquireInterruptibly()最初始把failed设置为true，只有进入到成功获取到锁的分支中，才会将failed设置为false。
         * 所以除了成功获取锁return导致try{}执行结束以外，其他任何情况导致try{}执行结束都会使failed仍然等于true，也就是没有成功将线程阻塞过
         * 
         * waitStatus = CANCELLED =  1，表示线程已被取消（等待超时或者被中断），需要废弃结束。
         * 说的就是这种情况，当一个线程在doAcquireInterruptibly()方法中因为被中断（响应中断的方法lockInterruptibly()在识别到终端信号之后会直接抛出异常就会将try{}代码块执行结束掉）或等待超时等原因而提前结束，就需要将该线程node节点生命状态设置为CANCELLED
         * 在未来该节点的后继节点进入到shouldParkAfterFailedAcquire()方法时，就会将该节点给移出队列
         */
        // 如果阻塞线程失败了
        if (failed)
            // 取消获取锁，标注当前节点的生命状态为canceld信号量，这种状态的节点应该剔除
            cancelAcquire(node);
    }
}

除以上代码，其他的方法源码都和lock()一致。

2 lock()

lock()会先尝试获取锁，失败后再将线程入队并阻塞等待，会在获取锁成功之后调用selfInterrupt()来将线程的中断标志设置true来响应中断：

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        // 获取锁成功后，中断当前线程。默认处理中断方式
        selfInterrupt();
}

addWaiter封装Node节点插入到队列尾部，acquireQueued负责队列的挂起、出队、是否中断。acquireQueued方法只有一种返回途径，就是通过for循正常返回时，必定是成功获取到了锁。

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                // 1.在独占锁后，才返回中断标识
                return interrupted;
            }
            //shouldParkAfterFailedAcquire：判断线程可否安全挂起
            //parkAndCheckInterrupt：挂起线程并返回当时中断标识Thread.interrupted()
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                // 2.当parkAndCheckInterrupt返回中断标识为true时修改interrupted
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

3 总结

ReentrantLock的lockInterruptibly(中断)和lock(非中断加锁模式)的区别在于：线程尝试获取锁操作失败后，在等待过程中，如果该线程被其他线程中断了，它是如何响应中断请求的。lock方法会忽略中断请求，继续获取锁直到成功；而lockInterruptibly则直接抛出中断异常来立即响应中断，由上层调用者处理中断。

那么，为什么要分为这两种模式呢？这两种加锁方式分别适用于什么场合呢？根据它们的实现语义来理解，lock()适用于锁获取操作不受中断影响的情况，此时可以忽略中断请求正常执行加锁操作，因为该操作仅仅记录了中断状态（通过Thread.currentThread().interrupt()操作，只是恢复了中断状态为true，并没有对中断进行响应)。如果要求被中断线程不能参与锁的竞争操作，则此时应该使用lockInterruptibly方法，一旦检测到中断请求，立即返回不再参与锁的竞争并且取消锁获取操作（即finally中的cancelAcquire操作）

---

   相关文章： 【并发基础】CAS（Compare And Swap）操作的底层原理以及应用详解
                    【并发基础】AQS（Abstract Queued Synchronizer）框架的使用和实现原理详解
                    【并发编程】Lock接口
                    【并发编程】Condition条件锁源码详解
                    【并发编程】ReentrantLock的lock()方法源码分析