AQS深入理解系列（二）独占锁的释放过程

小鱼儿 2023-02-14 13:13 13阅读 0赞

### 文章目录 ###

*  前言
 *  ReentrantLock.unlock()
 *  release
 *  tryRelease
 *  unparkSuccessor
 *  head后继从哪里被唤醒

# 前言 #

在上一篇文章[AQS深入理解 独占锁的获取过程][AQS_]中，我们分析了独占锁的获取过程。相对于获取过程，独占锁的释放过程则相对简单了很多。

Lock lock = new ReentrantLock();
    ...
    lock.lock();
    try { 
        // 搞事情
    } finally { 
        lock.unlock();
    }

对于ReentrantLock的使用，一定要注意将unlock操作写在finally块里，以保证锁的释放。这种手法我们已经在`doAcquireInterruptibly`里见过，在此函数里，即使抛出中断异常也会在异常抛给上一层调用函数之前，先去执行完`cancelAcquire`后，再将异常抛给上一层函数。

同样的，本文将以ReentrantLock的视角分析独占锁的释放过程。

[JUC框架 系列文章目录][JUC_]

# ReentrantLock.unlock() #

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

如上是释放锁的逻辑，在之后的源码分析你会发现，释放锁的过程，根本不会区分 公平或不公平、响应中断或不响应中断、超时或不超时。这是因为，这些区别都只是存在于尝试获取锁的方式上而已，既然已经获得了锁，也就不需要有这些区别。

# 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;
    }

*  尝试释放锁`tryRelease`，这是子类的实现。
 *  `h != null`标准地防止空指针，不过这种情况肯定也有，比如从头到尾都只有一个线程在使用锁，那么队列也不会初始化，head肯定为null。
 *  使用`h.waitStatus != 0`作为唤醒head后继的判断标准，当队列只有一个dummy node时，它的状态为0，也就不会执行`unparkSuccessor(h)`了。当head的状态为SIGNAL时，说明head后继已经设置了闹钟，会执行`unparkSuccessor(h)`。

# tryRelease #

//ReentrantLock.java
            protected final boolean tryRelease(int releases) { 
                int c = getState() - releases;
                if (Thread.currentThread() != getExclusiveOwnerThread())
                    throw new IllegalMonitorStateException();
                boolean free = false;
                if (c == 0) { 
                    free = true;
                    setExclusiveOwnerThread(null);
                }
                setState(c);
                return free;
            }

*  `if (Thread.currentThread() != getExclusiveOwnerThread())`有了这个判断，没有持有锁的线程调用了`ReentrantLock.unlock()`就会抛出异常。只有持有锁的线程，才会继续往下执行。
 *  该函数执行完毕，同步器的状态会变成`c`。如果`c`不为0，说明重入的锁还没有返回足够多的次数，返回false；如果`c`为0，说明独占锁已经被释放，设置ExclusiveOwnerThread成员为null，并返回true。

# unparkSuccessor #

private void unparkSuccessor(Node node) { 
            /* * 一般为SIGNAL，然后将其设置为0.但允许这次CAS操作失败 */
            int ws = node.waitStatus;
            if (ws < 0)
                compareAndSetWaitStatus(node, ws, 0);
    
            /* * head后继一般能直接通过next找到，但只有prev是肯定有效的。 * 所以遇到next为null，肯定需要从队尾的prev往前找。 * 遇到next的状态为取消，也需要从队尾的prev往前找。 */
            Node s = node.next;
            if (s == null || s.waitStatus > 0) { 
                s = null;//上面两种情况，都需要先置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);
        }

*  首先会尝试设置状态从小于0变成0。一般可以这样认为，如果head的状态为0，代表head后继线程即将被唤醒，或者已经被唤醒。
 *  如果遇到`s == null`，说明我们遇到一种中间状态，next指针还没有指好。如果遇到`s.waitStatus > 0`，说明head后继刚取消了。这两种情况，都需要从队尾的prev往前找。关于**prev的有效性**，已经在上一篇博客讲过了。
 *  注意循环条件`t != null && t != node`，它会从队尾一直往前找，直到`t`是null或`t`已经到达了`node`。一般情况下，不会出现`t != null`，所以，这样循环肯定能找到`node`之后第一个不是取消状态的节点。

# head后继从哪里被唤醒 #

从哪里跌倒就从哪里爬起来，所以我们找到head后继当初是何处开始阻塞的就行。

final boolean acquireQueued(final Node node, long 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;
                        return interrupted;
                    }
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())  //我们当初阻塞在这里了！！！
                        interrupted = true;
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

*  head后继当初是阻塞在了`parkAndCheckInterrupt()`这里，根据它的返回值，我们将设置`interrupted`变量，以在返回用户代码之前，补上中断状态。
 *  被唤醒的线程将开始下一次循环，最重要的，会再一次执行`p == head && tryAcquire(arg)`，考虑本文的流程且没有别的线程竞争的话，此处的`tryAcquire`必定能成功。

[AQS_]: https://blog.csdn.net/anlian523/article/details/106344926
[JUC_]: https://blog.csdn.net/anlian523/article/details/106598910