JUC源码解析二:unlock()方法的层层剥析

版权声明:欢迎转载,转载请标明来源 https://blog.csdn.net/weixin_41973131/article/details/88873394

一、前言

本次我们以ReentrantLock类来讲解一下unlock()方法的调用。

首先我们要清楚RentrantLock是一个独占可重入锁,并且内部实现了公平锁与非公平锁,那么下面就让我们一步步往下看吧。

二、正文

ReentrantLock类中我们可以看到有一个unlock()方法:

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

调用了AbracteQueuedSynchornizer类中的release(Int)方法:

	// 释放持有的锁,用于实现unlock操作
    public final boolean release(int arg) {
        if (tryRelease(arg)) {
            // 尝试获取锁成功,说明锁确实被当前线程所占用
            // 看AQS队列中的头结点是否为空并且能否被唤醒,如果可以的话就唤醒继任节点
            // 如果h == null则说明AQS还没有初始化头结点或者是非公平锁在释放锁
            Node h = head;
            if (h != null && h.waitStatus != 0)
                // 唤醒头结点的后继结点
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

使用tryRelease(Int)尝试释放锁:

		protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            // 判断当前持有锁的线程是否是当前线程,不是则抛出异常,因为其他线程不能够解除当前占有锁的线程
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            // 如果当前锁的状态位为0
            if (c == 0) {
                free = true;
                // 清除AQS持有锁的独占线程
                setExclusiveOwnerThread(null);
            }
            // 减少一层锁的状态位
            setState(c);
            return free;
        }

大概流程:

  1. 判断持有锁的线程是否是当前线程,如果不是就抛出IllegalMonitorStateExeception(),否则进行2。
  2. 将AQS状态位减少要释放的次数(对于独占锁而言总是1),如果剩余的状态位0(也就是没有线程持有锁),那么当前线程就是最后一个持有锁的线程,清空AQS持有锁的独占线程。进行3。
  3. 将剩余的状态位写回AQS,如果没有线程持有锁就返回true,否则就是false。

使用unparkSuccessor(Node)唤醒头结点的后继结点:

	// 唤醒该结点的后继结点,此处的node是需要释放锁的头结点
	private void unparkSuccessor(Node node) {
        int ws = node.waitStatus;
        // 清空头结点的waitStatus,也就是不再需要锁了
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        // 从头结点的下一个节点开始寻找继任节点,当且仅当继任节点的waitStatus<=0才是有效继任节点,否则将这些waitStatus>0(也就是CANCELLED的节点)从AQS队列中剔除
        // 这里并没有从head->tail开始寻找,而是从tail->head寻找最后一个有效节点。
        // 在lock()源码剥析那里有讲过,存在将清除结点的前继结点的next指向清除结点的后继结点,但是清除结点的后继结点没有指向清除结点的前继结点。这样可以跳过一些被清除的结点,并且由于存在一个傀儡节点(head),因此节点node.pre总是存在的,处理起来稍微容易点。不知道理解有没有错,欢迎指出。。
        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);
    }

三、最后

如果有误的地方请大家指出,一起学习。

猜你喜欢

转载自blog.csdn.net/weixin_41973131/article/details/88873394