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

49次阅读

共计 6144 个字符,预计需要花费 16 分钟才能阅读完成。

前言

  • 上篇文章咱们基于两个案例理解了 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.

正文完
 0