转载

小白的 ReentrantLock 源码略谈

ReentrantLock (简称RLock) 是Java的一种锁机制。从API上看,RLock提供了公平锁与非公平锁,并提供了当前锁状态监测的一些接口。其内部是由 FairSyncNonFairSync 来实现锁资源的抢占与释放。下面我们来学习下其源码。

从最直白的方法入手

首先我们打开 RLock 的构造函数,源码如下:

private final Sync sync;
    public ReentrantLock() {
        sync = new NonfairSync();
    }
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }
复制代码

好的,很直白,根据入参构造成员变量 Sync。默认为 NonfairSync 。到这里,我们遇到了第一个新概念 Sync 。先按住好奇心,我们先找到 lock()unlock() 源码。如下:

public void lock() {
        sync.lock();
    }
    public void unlock() {
        sync.release(1);
    }
复制代码

到这里好像有些明白了,RLock更像是对Sync的进一层封装,通过多态来实现不同的锁策略。到这里,我有个疑问,公平锁和非公平锁的策略有何不同呢?那么这样看来,啃透 Sync 是关键。

居高观下

首先我们捋一下 Sync 继承结构。IDEA里鼠标移到类声明上, Ctrl+H 即可清晰看到类的继承结构。

小白的 ReentrantLock 源码略谈
这里我们看到了一个熟悉的老朋友-- AbstractQueuedSynchronizer

(简称AQS)。这个类是JDK并发包中的锁基类,定义了锁资源获取与释放的框架与基本行为。这个先略过不谈,继续贯彻第一步,从最直白的方法入手。

lock()

我们回忆一下lock的行为,我们调用来获取锁,如果其它线程已抢占到锁资源,当前线程挂起,直到当前线程获取到锁。而且RLock支持重入。 NonfairSync#lock()FairSync#lock() 源码如下:

小白的 ReentrantLock 源码略谈
从第4,5,6行可以看到, NonfairSync 先设置了状态位,然后调用了 acquire()FairSync 则直接调用了 acquire() 。那么我们先从 compareAndSetState()

入手,源码如下:

protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }
复制代码

这个函数定义在 AQS 中,用于设置当前lock的状态,unsafe呢,是JDK中非常变态的一个工具类,可以直接操控实例对象所在的内存,同时提供了一些原子操作。具体的后面会再展开介绍,简而言之,这个函数可以理解为:

protected final boolean compareAndSetState(int expect, int update) {
        synchronized (this.getClass()) {
            if (this.state == expect) {
                this.state = update;
                return true;
            } else {
                return false;
            }
        }
    }
复制代码

那么到这里我们好像得到了第一把钥匙: lock.state 为0时,为空闲,而上锁请求会将状态置为1,并且将 exclusiveOwnerThread 设为当前线程。

接下来,我们来看 acquire() 。继续跟踪下去, 的 acquire() 代码如下:

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

唔,好像看不出来什么东西,那么继续跟下去,先从 tryAcquire 开始, NonfairSyncFairSync tryAcquire() 核心代码如下

小白的 ReentrantLock 源码略谈
唯一的差别在于, FairSync 获取锁之前会调用 hasQueuedPredecessors()

源码如下:

/**
     * @return {@code true} if there is a queued thread preceding the
     *         current thread, and {@code false} if the current thread
     *         is at the head of the queue or the queue is empty
     *  两种情况返回 false:1. 当前线程在队头。2. 队列为空
     */
    public final boolean hasQueuedPredecessors() {
        Node t = tail; // Read fields in reverse initialization order
        Node h = head;
        Node s;
        return h != t &&
            ((s = h.next) == null || s.thread != Thread.currentThread());
    }
复制代码

那么我们拿到了第二把钥匙: 公平锁在获取锁之前会先去查询是否有其他人在等待这把锁,如果没有,再尝试获取。而非公平锁则不会询问

这么看来,公平锁 Peace&Love,像民谣,多愁善感,与世无争。而非公平锁 Aggressive,像Hip-Hop,张扬自我,锐意进取。 那么回到 acquire() ,还有一个函数: acquireQueued() ,源码如下:

final boolean acquireQueued(final Node node, int 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);
        }
    }
复制代码

忽略其他细节,我们在 parkAndCheckInterrupt() 函数中找到了 LockSupport.park(this); 。就是他了!这个函数会将指定线程挂起,直至 LockSupport.unpark(Thread) 被调用或者发生意外被操作系统 interrupt 。 至此, lock() 的链便通了。

我们再来总结一下:*** ReentrantLock 在上锁时,会根据实例化时指定的策略去获取锁,默认为非公平锁。如果上锁成功,锁状态值+1(重入,最大次数为 Integer.MAX_VALUE ),并将锁持有者设置为当前线程实例。在 Sync 内部维护了一个队列,存放了所有上锁失败的线程。公平锁在上锁前,会检查在自己前面是否还有其他线程等待,如果有就放弃竞争,继续等待。而非公平锁会抓住每个机会,不管是否前面是否还有其它线程等待,只顾上锁***

unlock()

至于锁释放,公平锁与非公平锁的行为就一样了。核心代码如下

// ReentrantLock#unlock() 释放锁资源
    public void unlock() {
        sync.release(1);
    }
    // Sync#release()
    public final boolean release(int arg) {
        // 重入锁,状态计数器减一,为0时释放
        if (tryRelease(arg)) { 
            Node h = head;
            // 释放锁时,从等待队列中获取线程并尝试唤醒
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
    // Sync#tryRelease() 状态计数器减一,为0时,释放锁资源,返回true
    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;
    }
    // Sync#unparkSuccessor()  唤醒等待队列中的线程,让他(们)继续抢占锁
    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;
        }
        // boomya,合适的线程找到啦,将其唤醒
        if (s != null)
            LockSupport.unpark(s.thread);
    }
复制代码

总结一下: 线程在释放锁时,将状态计数器减一(重入),当状态计数器为0时,锁可用。此时再从等待队列中寻找合适的线程唤醒,默认从队首开始,如果队列正在更新中,且未找到合适的线程,那么从队尾开始寻找。

原文  https://juejin.im/post/5d2602f851882514f92ecb92
正文到此结束
Loading...