【JDK1.8】JUC——ReentrantLock

一、前言

在之前的几篇中，我们回顾了锁框架中比较重要的几个类，他们为实现同步提供了基础支持，从现在开始到后面，就开始利用之前的几个类来进行各种锁的具体实现。今天来一起看下ReentrantLock，首先来看一下Java doc 上对ReentrantLock的解释：

ReentrantLock，作为可重入的互斥锁，具有与使用synchronized方法和语句相同的基本行为和语义，但功能更强大。

对上面这句话的解释：

拥有和synchronized关键字一样的行为，可重入互斥（注意，synchronized也是可重入的）
更强大的功能：比如支持公平锁和非公平锁，前面文章提到过的Condition的使用等。

另外来看一下它的最佳时间：

class X {
    private final ReentrantLock lock = new ReentrantLock();
    public void m() {
        // 上锁
        lock.lock();
        try {
            // 执行方法体
        } finally {
            lock.unlock()
        }
    }
}

要点就是try-finally，在执行的最后，无论是否出错都调用unlock解锁，保证释放资源。

二、源码分析

2.1、成员变量

早在第一章JUC.Lock综述的时候，我们就大体看过juc包里的关系图，上面提到过，ReentrantLock支持公平锁和非公平锁，其原因就是内部实现了两个内部类FairSync和NonfairSync，分别实现了对应的支持，先来看一下成员变量：

public class ReentrantLock implements Lock, java.io.Serializable {
    private static final long serialVersionUID = 7373984872572414699L;
    private final Sync sync;
    
    public ReentrantLock() {
        sync = new NonfairSync();
    }

    /**
     * fair = true：公平锁， false:非公平锁
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }
}

这里由于final关键字，方便理解，直接将构造方法也一并放了进来。

默认构造器在初始化的时候，实例化的是非公平锁，举个栗子，我去买蛋糕，蛋糕店刚好出炉了一个蛋糕，我刚好碰到买到了，那我就买回去了。
而带fair的构造器，为true的时候，实例化的是公平锁，再举个栗子，我去买蛋糕，蛋糕店刚好又出炉了一个，我想买，但是人家已经预定好了，要买就得排队等。

2.2、内部类

前面提到的FairSync和NonfairSync都继承自ReentrantLock的内部类，而在JUC关系图中，Sync在大部分的锁框架中都各自进行了不同的实现，但是都继承自AQS。

2.2.1、Sync

一起来看一下ReentrantLock中的Sync实现：

abstract static class Sync extends AbstractQueuedSynchronizer {
    private static final long serialVersionUID = -5179523762034025860L;

    abstract void lock();
    // 尝试获取非公平锁
    final boolean nonfairTryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        // AQS中的state成员变量，0表示没有线程持有锁
        int c = getState();
        if (c == 0) {
            // cas设置入锁次数，仅尝试一次，成功则设置当前线程为独占线程
            if (compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        // 如果当前线程为独占线程，则重入次数叠加
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0) // overflow
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        // 否则尝试获取锁失败
        return false;
    }
	// 释放锁
    protected final boolean tryRelease(int releases) {
        // 由于可重入性，所以获取当前重入次数，与releases相减
        int c = getState() - releases;
        if (Thread.currentThread() != getExclusiveOwnerThread())
            throw new IllegalMonitorStateException();
        boolean free = false;
        // 为0则说明已经全部释放，则清空持有状态
        if (c == 0) {
            free = true;
            setExclusiveOwnerThread(null);
        }
        setState(c);
        return free;
    }
    ...
}

lock()的逻辑由继承的NonfairSync和FairSync自己实现。

这里笔者阅读的时候注意到一个问题：前面提到FairSync是公平锁，每个线程按照队列的顺序来获取，但是其父类却有nonfairTryAcquire()方法来尝试直接获取锁，这一实现放在NonfairSync中不是更合适吗？为什么要放在父类中呢？

仔细查看代码后发现，ReentrantLock里有tryLock()方法：允许线程尝试获取一次锁，有则获得锁，返回true，没有则返回false。

那么就可以解释的通了，因为这个是ReentrantLock的public方法，所以不论是公平锁还是非公平锁，都可以调用，所以说，nonfairTryAcquire()方法放在的父类Sync当中。

2.2.2、NonfairSync

下面是非公平锁的实现：

static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;

    final void lock() {
        // cas 原子性操作将state设置为1，如果设置成功，则说明当前没有线程持有锁
        if (compareAndSetState(0, 1))
            //把当前线程设置为独占锁
            setExclusiveOwnerThread(Thread.currentThread());
        // 反之则锁已经被占用，或者set失败
        else
            // 调用父类AQS分析里提到过的方法，以独占模式获取对象，acquire会调用tryAcquire
            acquire(1);
    }

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

其实非公平锁核心实现在上一篇AQS之中就基本分析过了，所以这里的代码就相对简单。

但是为什么lock()方法不直接调用acquire(1)，而是直接先尝试CAS操作设置呢，笔者暂时没有想明白，因为调用acquire(1)后，会进入tryAcquire(1)，里面的操作其实是一样的，估计就是为了更快尝试获取？

2.2.3、FairSync

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

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

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

与NonfairSync不同，公平锁的tryAcquire中，当发现当前没有线程持有锁的时候，会判断队列中有无前驱节点，之所以要判断的原因是：

在当前持有锁的线程调用unlock()的的过程中，存在的这样一个过程：

在tryRelease()到唤醒后继节点的过程中，可能有新的线程进来，这个时候，就需要判断队列是否有其他节点等待了，这就是公平锁的奥义吧。

详情查看hasQueuedPredecessors代码，查看当前线程前有没有前驱节点：

public final boolean hasQueuedPredecessors() {
    Node t = tail;
    Node h = head;
    Node s;
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

其中代码值得我们认真思考一下：

为什么要先从tail开始赋值？
说明时候h.next为null

这两点，我们要结合入队列时候的代码说起，在前面结束AQS的时候，分析过enq()方法：

private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        // 队列初始化
        if (t == null) {
            if (compareAndSetHead(new Node()))
                tail = head;
        // 重复执行插入直到return
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

我们先假设从head开始赋值：

当第一个线程调用enq的时候，cpu切换，进入了线程t2的hasQueuedPredecessors，首先对head进行赋值，此时还没有到compareAndSetHead(new Node())，那么此时 head = null，这个时候cpu切换，t1继续执行，执行完了tail == head，再切换回t2，继续执行Node t = tail;，这个时候，在return的时候，h != t成立，当调用(s = h.next) == null，h为null，报了空指针。

所以先从tail开始赋值，至少能保证在tail有值的时候，head必然有值！

另外什么时候h.next == null，其实可以从enq的else里找到答案，也是第一次enq插入空队列的时候，当线程执行到compareAndSetTail(t, node)的时候，head != tail，但是此时head.next还未开始赋值，所以为null。

三、总结

关于ReentrantLock的使用例子，其实在第一篇将Lock的时候，就曾经有提到过，是Java Doc上提供的一个例子，典型的生产者-消费者模式，这里笔者就不赘述了。其实ReentrantLock关键的核心实现在于AQS，AQS仔细阅读的话，还是有很多值得推敲的地方，再一次觉得它的实现博大精深~最后谢谢各位园友观看，如果有描述不对的地方欢迎指正，与大家共同进步！

posted @ 2018-08-11 16:31 joemsu 阅读(698) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

joemsu

Thinking instead of questioning