ReentrantLock源码探讨

ReentrantLock是一种可重入锁,可重入是说同一个线程可以多次获取同一个锁,内部会有响应的字段纪录重入次数,它同时也是一把互斥锁,意味着同时只有一个线程能获取到可重入锁。

1.组织函数

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

    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

ReentrantLock提供了两个组织函数,组织函数只是用来初始化sync字段,可以看到,默认情形下ReentrantLock使用的是非公正锁,固然,也可以使用带有布尔参数的组织函数来选择使用公正锁。公正锁和非公正锁的实现依赖于两个内部类:FairSyncNonfairSync,接下来认识一下这两个类:

    //非公正锁
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        /**
         * Performs lock.  Try immediate barge, backing up to normal
         * acquire on failure.
         */
        final void lock() {
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }

        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }

    static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

        final void lock() {
            acquire(1);
        }

        /**
         * Fair version of tryAcquire.  Don't grant access unless
         * recursive call or no waiters or is first.
         */
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                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;
        }
    }

这两个内部类的代码都很短,而且都继续了另一个内部类Sync。这里先不急着先容Sync类,由于这个类自己也并不庞大,后续在需要用到其中的方式时顺带解说,现在只需要知道这个类继续了AbstractQueuedSynchronizer(AQS)即可。

2.常用方式

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

lock方式提供了加锁的功效,公正锁和非公正锁的加锁操作是不一样的,先来看看非公正锁的细节,接着再解说公正锁。

  • 非公正锁加锁逻辑
    final void lock() {
        //使用CAS操作,实验将state字段从0修改为1,若是乐成修改该字段,则示意获取了互斥锁
        //若是获取互斥锁失败,转入acquier()方式逻辑
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }
    
    //设置获得了互斥锁的线程
    protected final void setExclusiveOwnerThread(Thread thread) {
        exclusiveOwnerThread = thread;
    }

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

对于非公正锁来讲,使用lock()方式一上来就实验获取互斥锁,获取乐成就将exclusiveOwnerThread指向自己,代表当前是自己持有锁,否则就执行acquire()方式的逻辑,下面临acquire()方式的逻辑举行逐个剖析。
首先是tryAcquire()方式,非公正锁重写了该方式,并在内部挪用Sync类的nonfairTryAcquire()

数据挖掘入门系列教程(四点五)之Apriori算法

    //从上面的逻辑来看,这里的acquires=1
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }

    final boolean nonfairTryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        //c==0,说明当前处于未加锁状态,锁没有被其他线程获取
        if (c == 0) {
            //在锁没有被其他线程占有的情形下,非公正锁再次实验获取锁,获取乐成则将exclusiveOwnerThread指向自己
            if (compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        //执行到这里说明锁已经被占有,若是是被自己占有,将state字段加1,纪录重入次数
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            //当nextc到达int类型最大值时会溢出,因此可重入次数的最大值就是int类型的最大值
            if (nextc < 0) // overflow
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        //执行到这里说明:1)锁未被占有的情形下,抢锁失败,说明当前有其他线程抢到了锁;2)锁已经被其他线程占有
        //即只要当前线程没有获取到锁,就返回false
        return false;
    }
    
    //获取state字段,该字段界说在AQS中
    protected final int getState() {
        return state;
    }
    //设置state字段
    protected final void setState(int newState) {
        state = newState;
    }

当前线程没有在tryAcquire()方式中获取到锁时,会先执行addWaiter(Node.EXCLUSIVE)方式,其中参数Node.EXCLUSIVE是一个常量,其界说是static final Node EXCLUSIVE = null,作用是符号锁的属性是互斥锁。addWaiter()方式的作用是将当前线程包装成一个Node节点,放入守候行列的队尾,该方式在先容CountDownLatch类时详细解说过,有兴趣的同伙可以参考ConcurrentHashMap源码探讨(JDK 1.8),本文不再赘述。
将当前线程加入守候行列之后,会接着执行acquireQueued()方式,其源码如下:

    final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            //自旋
            for (;;) {
                //获取当前节点的前一个节点
                final Node p = node.predecessor();
                //若是前一个节点是头节点,说明当前节点排在队首,非公正锁会则再次通过tryAcquire方式获取锁
                if (p == head && tryAcquire(arg)) {
                    //将自己设置为头节点
                    setHead(node);
                    //前一个头结点没用了,会被垃圾回收掉
                    p.next = null; // help GC
                    failed = false;
                    //正常竣事,返回false,注重该字段可能会在下面的条件语句中被改变
                    return interrupted;
                }
                //若是前一个节点不是头节点,或者当前线程获取锁失败,会执行到这里
                //shouldParkAfterFailedAcquire()方式只有在p的状态是SIGNAL时才返回false,此时parkAndCheckInterrupt()方式才有机遇执行
                //注重外层的自旋,for循环体会一直重试,因此只要执行到这里,总会有机遇将p设置成SIGNAL状态从而将当前线程挂起
                //另外,若是parkAndCheckInterrupt()返回true,说明当前线程设置了中止状态,会将interrupted设置为true,代码接着自旋,会在上一个条件语句中返回true
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            //若是在自旋中线程被中止或者发送异常,failed字段的值将会为true,这里会处置这种情形,放弃让当前线程获取锁,并抛出中止异常
            if (failed)
                cancelAcquire(node);
        }
    }
    //方式逻辑是:只有在前置节点的状态是SIGNAL时才返回true,其他情形都返回false
    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
            return true;
        //删除当前节点之前延续状态是CANCELLED的节点
        if (ws > 0) {
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }
    //线程在这里壅闭,并在被叫醒后检查中止状态
    private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);
        return Thread.interrupted();
    }
    
    //
    private void cancelAcquire(Node node) {
        // Ignore if node doesn't exist
        if (node == null)
            return;

        node.thread = null;

        // Skip cancelled predecessors
        Node pred = node.prev;
        while (pred.waitStatus > 0)
            node.prev = pred = pred.prev;

        Node predNext = pred.next;

        node.waitStatus = Node.CANCELLED;

        // If we are the tail, remove ourselves.
        if (node == tail && compareAndSetTail(node, pred)) {
            compareAndSetNext(pred, predNext, null);
        } else {
            // If successor needs signal, try to set pred's next-link
            // so it will get one. Otherwise wake it up to propagate.
            int ws;
            if (pred != head &&
                ((ws = pred.waitStatus) == Node.SIGNAL ||
                 (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
                pred.thread != null) {
                Node next = node.next;
                if (next != null && next.waitStatus <= 0)
                    compareAndSetNext(pred, predNext, next);
            } else {
                //叫醒后一个节点
                unparkSuccessor(node);
            }

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

注重acquireQueued()要么会抛出中止异常,要么正常竣事返回false,只有在线程被叫醒后设置了中止状态才会返回true。对比可以发现,acquireQueued()方式的逻辑与CountDownLatch中的doAcquireSharedInterruptibly()十分类似,许多方式在CountDownLatch这篇博客中讲到过,本文不再对这些方式举行赘述。
先容完了acquire()方式,回过头来看看方式逻辑:

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

若是在tryAcquire()方式中没有获取锁,那么将当前线程加入到守候行排队尾,查看节点的前一个节点是否是头结点,是的话当前线程可以继续向下执行,否则就会壅闭挂起。当acquireQueued返回true时,说明线程设置了中止状态,就挪用selfInterrupt()中止该线程,其他情形selfInterrupt()方式没机遇执行。
到这里非公正锁的加锁流程已经先容完了,由于代码逻辑比较长,且看源码的过程中会在好几个类中往返切换,思绪很容易断,阅读代码的时刻要注重。(有需要补个流程图)。

  • 公正锁加锁逻辑
    接下来看看公正锁的加锁逻辑:
    final void lock() {
        acquire(1);
    }

与非公正锁相比,公正锁没有一上来就抢锁的逻辑,这也是公正性的体现。两种锁的acquire()方式的框架相同,然则实现细节差别,来看看公正锁的tryAcquire()方式:

    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        //c=0示意当前没有其他线程持有锁
        if (c == 0) {
            //下面的代码与非公正锁相比,多了hasQueuedPredecessors()方式的处置逻辑,公正锁只有在前面没有其他线程排队的情形下才会实验获取锁
            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;
        }
        //只要当前线程没有获取到锁,就返回false
        return false;
    }

    public final boolean hasQueuedPredecessors() {
        // The correctness of this depends on head being initialized
        // before tail and on head.next being accurate if the current
        // thread is first in queue.
        Node t = tail; // Read fields in reverse initialization order
        Node h = head;
        Node s;
        //h != t示意守候行列中有其他节点
        //h.next == null可能会有点费解,按理说h!=t之后,h后面一定会有节点才对,这种情形实在已经见过,在上文先容acquireQueued()方式时说过,
        //被叫醒的第一个守候节点会将自己设置为头结点,若是这个节点是行列中的唯一节点的话,它的下一个节点就是null
        //至于s.thread != Thread.currentThread()这个条件暂时可以忽略,由于公正锁执行到hasQueuedPredecessors方式时基本还没有入队,
        //这也意味着,只要行列中有其他节点在期待,公正锁就要求其他线程排队守候
        return h != t &&
            ((s = h.next) == null || s.thread != Thread.currentThread());
    }
  • lockInterruptibly
    从名字可以看出,lockInterruptibly可以响应中止,来看看该方式的实现:
    public void lockInterruptibly() throws InterruptedException {
        sync.acquireInterruptibly(1);
    }

    public final void acquireInterruptibly(int arg)
            throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();
        //先实验获取锁,获取失败才执行后面的逻辑
        if (!tryAcquire(arg))
            doAcquireInterruptibly(arg);
    }

    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())
                    throw new InterruptedException();
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

lockInterruptibly()方式险些与acquire()方式完全一样,唯一的区别是acquire()方式中,parkAndCheckInterrupt由于线程设置了中止状态而返回true时,只是简朴设置了一下interrupted字段的值,而lockInterruptibly()则是直接抛出异常。

  • unlock方式
    先容完加锁的逻辑,接下来看看解锁的逻辑:
    public void unlock() {
        sync.release(1);
    }

    public final boolean release(int arg) {
        //若是乐成释放了锁,则执行下面的代码块
        if (tryRelease(arg)) {
            Node h = head;
            //若是头节点不为null,请求节点状态不是初始状态,就释放头结点后第一个有用节点
            //问题:这里为什么需要判断头结点的状态呢???
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
    
    //
    protected final boolean tryRelease(int releases) {
        int c = getState() - releases;
        //线程没有持有锁的情形下,不允许释放锁,否则会抛异常
        if (Thread.currentThread() != getExclusiveOwnerThread())
            throw new IllegalMonitorStateException();
        boolean free = false;
        //可重入性的判断,若是释放了一次锁,使得c=0,就指针释放锁,做法是将纪录锁的字段exclusiveOwnerThread重新指向null
        //注重,只有最后一次释放可重入锁,才会返回true
        if (c == 0) {
            free = true;
            setExclusiveOwnerThread(null);
        }
        setState(c);
        return free;
    }

    //叫醒node节点的下一个有用节点,这里的有用指的是状态不是CANCELLED状态的节点
    private void unparkSuccessor(Node node) {

        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        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;
        }
        if (s != null)
            LockSupport.unpark(s.thread);
    }
  • newCondition()
    ReentrantLock可以实现绑定多个守候条件,这个功效是在newCondition()方式中实现的,每次挪用newCondition()方式时,都市发生一个新的ConditionObject工具,这是AQS中的一个内部类,代码很长,这里就不详细讨论了。来简朴看看该方式的源码:
    public Condition newCondition() {
        return sync.newCondition();
    }
    final ConditionObject newCondition() {
        return new ConditionObject();
    }

3.总结

在多线程环境中,ReentrantLock的非公正锁要比公正锁拥有更高的性能,由于非公正锁制止了线程挂起发生的上下文切换的开销,然则公正锁能够制止线程饥饿问题,因此各有各的使用场景。从源码来看,J.U.C包下的许多类都依赖AQS类,因此异常有需要搞懂AQS。提到ReentrantLock,总免不了与synchronized举行对比。synchronized也是可重入的,而且在JDK 1.6以后,synchronized的性能已经得到了很大的提升,因此选择使用ReentrantLock一样平常是思量使用它的三个优势:可中止、可实现公正锁、可绑定多个条件,这些优势是synchronized不具备的。

原创文章,作者:admin,如若转载,请注明出处:https://www.2lxm.com/archives/1386.html