乐趣区

关于java:并发系列五基于两种案例来认识ReentrantLock源码解锁过程公平锁

jiezi

前言

  • 上篇文章咱们基于两个案例理解了 ReentrantLock(偏心锁)的加锁过程。接下来咱们持续基于雷同的案例来意识它的解锁过程。

  • 两个案例

    1. 线程 A 独自加锁再解锁
    2. 线程 A 正在持有锁的过程中，线程 t1 来加锁，线程 t1 阻塞后，线程 A 解锁

一、案例 1：线程 A 独自加锁再解锁

  • 还是应用雷同的代码：

    public class SimpleThreadLock {static ReentrantLock lock = new ReentrantLock(true);

    public static void main(String[] args) throws InterruptedException {Thread a = new Thread(() -> {
            try {lock.lock();
                System.out.println("Get lock");
            } catch (Exception e) {e.printStackTrace();
            } finally {lock.unlock();
            }
        }, "线程 a");

        a.start();
        a.join();
        System.out.println("end");
    }
}

  • 还记得线程 A 独自加锁时的流程么？或者说独自加锁后的程序会定位到哪里？没错，在执行完 tryAcquire 办法后，它返回的是 true，那么进而阐明 acquire 办法前面的语句压根不会执行。

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

    这也间接阐明了在单个线程加锁时，只会操作 aqs 队列中的 state 变量，其中队列都不会产生。那么咱们来做一个猜想：是不是解锁时，只是独自的将 aqs 中的 state 变量 cas 成 0 呢？ 咱们带着这个疑难来看 unlock 办法的源码。

  • java.util.concurrent.locks.ReentrantLock#unlock 源码：

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

    依据咱们的主题，偏心锁的解锁过程，所以咱们间接定位到 FairSync 的 release 办法，然而它并没有对父类 AbstractQueuedSynchronizer 的 release 办法进行重写，那么此时调用的必定是父类的 release 办法，咱们间接粘贴源码 ( 父类 AbstractQueuedSynchronizer release 办法源码)：

    public final boolean release(int arg) {
    // 尝试去开释锁，与 tryLock 一样，有可能会失败
    // tryRelease 具体源码剖析将在上面给出
    // 咱们先接着往下看，看完 tryRelase 再回过头来看
    // if 内的逻辑
    // ...... 上面的逻辑请先看完 tryRelease 来回过头来接着看




    // 在上面的 tryRelease 办法中有说到，只有线程对
    // 锁开释胜利了，这里返回的才是 true，若
    // 开释锁的次数 < 重入的次数，那么会返回 false
    // 若解锁的线程和以后持有 state 的线程不是同一个线程
    // 则抛出异样。if (tryRelease(arg)) {
        // 进入了 if, 则示意线程开释锁胜利
        // 因为在本案例中，只有一个线程加锁
        // 所以 aqs 队列都没有初始化，head 必定为 null
        // 因而不须要执行 if 内的逻辑，而后间接返回 true 即可
        // 在本案例中，返回 true 也毫无意义，在最顶端的
        // 办法调用链中并没有接管这个返回值，因而
        // 本案例的解锁过程完结
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

  • java.util.concurrent.locks.ReentrantLock.Sync#tryRelease 源码：

        protected final boolean tryRelease(int releases) {
        // 在以后案例中，state 的值为 1,
        // 而传入的 release 为 1(由上述的调用链可知)
        // 所以此时做完操作后，c 的值就等于 0 了
        int c = getState() - releases;
        // 这里做了一个校验，肯定要以后持有 state 的
        // 线程能力做解决操作，否则抛异样
        if (Thread.currentThread() != getExclusiveOwnerThread())
            throw new IllegalMonitorStateException();
        
        // 能执行到这一步，就阐明是以后持有
        // state 的线程执行的 unlock 办法，// 后续要做的操作就是：// 确认 c 是否等于 0，如果等于 0 则示意锁开释
        // 结束，接着就是设置 state 的拥有者为 null
        // 且设置 state 变量为 0,
        // 若 c 不等于 0，则示意以后这个线程持有的锁
        // 是一把重入锁，重入多少次就要 unlock 多少次
        // ===> 只有以后线程解锁胜利后，才返回 true
        // 若解锁的次数 < 重入的次数则返回 false
        boolean free = false;
        if (c == 0) {
            free = true;
            setExclusiveOwnerThread(null);
        }
        setState(c);
        return free;
    }

    看完这部分源码后记得返回看上述的 release 源码。在 release 源码中的正文有说到，在此案例下，线程 A 的解锁过程就完结了。因而在 ReentrantLock 中，单线程的执行或者多线程交替执行，并不会产生 aqs 队列，就是对 state 变量的一个加、减操作。但需注意：ReentrantLock 的重入个性以及解锁的校验，重入了多少次就要解锁多少次，以及只能由以后持有 state 的线程能力 unlock，否则抛异样。

二、案例 2：线程 A 正在持有锁的过程中，线程 t1 来加锁，线程线程 A 解锁

  • 还是应用雷同上篇文章雷同的代码：

    public class TwoThreadLock {static ReentrantLock lock = new ReentrantLock(true);

    public static void main(String[] args) throws InterruptedException {new Thread(() -> {
            try {lock.lock();
                System.out.println("Thread a get lock");
                TimeUnit.SECONDS.sleep(60);
            } catch (Exception e) {e.printStackTrace();
            } finally {lock.unlock();
            }
        }, "线程 a").start();

        Thread t1 = new Thread(() -> {
            try {lock.lock();
                System.out.println("Thread t1 get lock");
            } catch (Exception e) {e.printStackTrace();
            } finally {lock.unlock();
            }
        }, "线程 t1");

        t1.start();
        t1.join();

        System.out.println("end");
    }
}

    还记得线程 t1 加锁时是在哪里被阻塞的吗？没错，就是在 java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued 办法

    final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            // 局部代码省略.....
            // 在上篇博客的案例中，咱们有说到
            // 当线程 t1 在线程 a 持有锁的过程中
            // 来竞争锁了，此时就会在这里被 park
            // 也就是在这里被阻塞了。if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {if (failed)
            cancelAcquire(node);
    }
}

    依据源码中的正文可知，线程 t1 在指定地位被阻塞了。依照以后案例来说，当线程 t1 阻塞时，线程 a 调用了 unlock 办法进行理解锁，此时的解锁过程和案例一的差不多，区别就在于 release 中的 if 代码块，详见下述源码解释：

    public final boolean release(int arg) {
    // 尝试去开释锁，与 tryLock 一样，有可能会失败
    // tryRelease 具体源码剖析将在上面给出
    // 咱们先接着往下看，看完 tryRelase 再回过头来看
    // if 内的逻辑
    // ...... 上面的逻辑请先看完 tryRelease 来回过头来接着看
    // 在上面的 tryRelease 办法中有说到，只有线程对
    // 锁开释胜利了，这里返回的才是 true，若
    // 开释锁的次数 < 重入的次数，那么会返回 false
    // 若解锁的线程和以后持有 state 的线程不是同一个线程
    // 则抛出异样。if (tryRelease(arg)) {
        // 进入了 if, 则示意线程开释锁胜利
        // 在本案例中，因为 aqs 队列初始化了，// 所以 head 不为 null，且它的 waitStatus
        // 为 0，于是会执行 if 外部的
        // unparkSuccessor 办法
        // 看完上面对 unparkSuccessor 办法的源码解析
        // 再回过头来持续往下看！！！！！// ...................
        // 最终返回 true，// 其实这个返回值在这个案例中也没作用,
        // 因为在调用链中并没有接管它的返回值
        // 所以它线程 a 的解锁流程算是实现了。Node h = head;
        if (h != null && h.waitStatus != 0)
            // 此时传入的为 aqs 队列中的 head 节点
            unparkSuccessor(h);
        return true;
    }
    return false;
}

  • java.util.concurrent.locks.AbstractQueuedSynchronizer#unparkSuccessor 源码解析

    private void unparkSuccessor(Node node) {
    // 在以后案例中，传入的 node 为队列中的 head 节点
    // 此时它的 ws 为 0
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);

    /**
     拿到 head 节点的下一个节点，因为它的下一个节点不为 null 且 waitStatus 的值为 -1(
     在以后案例下，它的下一个节点
     是处于 park 状态，那么它的 waitStatus 必定是 -1)
     于是不进 if 外面的逻辑
     */
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    // 在以后案例下 head 节点的下一个节点不为 null
    if (s != null)
        // 于是对 s 这个 node 中保护的线程做 unpark 操作
        // 在本案例中，这个 s 节点外部保护的线程就是
        // t1, 于是 t1 会被唤醒。// 还记得线程 t1 是在哪里被阻塞的吗？咱们持续往下看
        LockSupport.unpark(s.thread);
}

  • 再次回到 java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued 办法

    final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
             // ---------- 看完上面的 start 局部再回头看 ------------
             // 此时的 node 为 t2 线程对应的 node
             // 此时获取它的上一个节点，// 它的上一个节点是 head 节点，// 于是走前面的 && 逻辑
             // 前面的 && 逻辑就是持续去加锁
             // 此时因为只有线程 t2 在，所以必定
             // 会加锁胜利，最终返回 true
             // 进而进入 if 的代码块中，// 在 if 代码块中次要做的时就是
             // 批改 head 节点的援用，并回收
             // 原来的 head 节点，最终获取锁
             // 胜利
             // ---------- 看完上面的 start 局部再回头看 ------------
             final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            
            // ----------start 局部 ------------
            // start 局部: 线程 t1 是在 parkAndCheckInterrupt 办法中被阻塞的，// ******************
            // 先看上面的 parkAndCheckInterrupt 办法再回头持续往下看
            // ******************

            // 在 parkAndCheckInterrupt 办法中返回了 true
            // 所以会持续自旋，// ----------start 局部 ------------
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {if (failed)
            cancelAcquire(node);
    }
}

  • java.util.concurrent.locks.AbstractQueuedSynchronizer#parkAndCheckInterrupt 办法

    private final boolean parkAndCheckInterrupt() {
    // 所以当线程 a 调用 unlock 办法时，线程 t2
    // 会从此处开始继续执行，LockSupport.park(this);
    // 会将以后线程标识为 interrupt 状态，// 并且返回 true
    return Thread.interrupted();}

    通过上述的源码正文，应该对案例 2 的解锁过程也理解了。其实也蛮简略，就是上一个线程 unlock，于是 unpark head 节点的后一个节点对应的线程。当然，这也只是针对于案例 2 的简略，外面还有很多细节没有提及到，因为是针对案例而言的嘛，咱们得以案例为核心进行总结。

三、总结

  • 还是那句话，解锁过程也是基于两个简略的案例来总结的，其实 ReentrantLock 还有很多其余的情景，然而咱们把最根本的加锁、解锁过程的流程给弄清楚后，后续的各种情景咱们 照单全收！丝毫不慌
  • ReentrantLock 加锁流程波及到每个办法的具体步骤可查看在 github 中的总结：传送门
  • I am a slow walker, but I never walk backwards.
退出移动版