ReentrantLock+可重入锁

为什么需要 ReentrantLock ？

既生 synchronized，何生 ReentrantLock？

每一个接触过多线程的 java coder 肯定都知道 synchronized 关键字，那为什么还需要 ReentrantLock 呢？

其实这就是 ReentrantLock 与 synchronized 对比的优势问题：

（1）ReentrantLock 使用起来更来更加灵活。我们在需要控制的地方，可以灵活指定加锁或者解锁。

这可以让加锁的范围更小，记住老马的一句话，更小往往意味着更快。

（2）ReentrantLock 提供了公平锁、非公平锁等多种方法特性，这些都是 synchronized 关键字无法提供的。

接下来，就让我们一起来学习一下 ReentrantLock 可重入锁吧。

ReentrantLock 使用

线程定义

创建一个可重入锁线程。

/**
 * @author 老马啸西风
 */
public class ReconnectThread extends Thread {

    /**
     * 声明可重入锁
     */
    private static final ReentrantLock reentrantLock = new ReentrantLock();


    /**
     * 用于标识当前线程
     */
    private String name;

    public ReconnectThread(String name) {
        this.name = name;
    }

    @Override
    public void run() {
        reentrantLock.lock();

        try {
            for (int i = 0; i < 5; i++) {
                System.out.println(name+" "+i+" times");
                Thread.sleep(1000);
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            reentrantLock.unlock();
        }

    }
}

测试

Test

/**
 * @author 老马啸西风
 */
public static void main(String[] args) {
    Thread one = new ReconnectThread("one");
    Thread two = new ReconnectThread("two");
    one.start();
    two.start();
}

result

根据结果可知。两个必须要等待另外一个执行完成才能运行。

two 0 times
two 1 times
two 2 times
two 3 times
two 4 times
one 0 times
one 1 times
one 2 times
one 3 times
one 4 times

锁的释放和获取

锁是 java 并发编程中最重要的同步机制。

锁除了让临界区互斥执行外，还可以让释放锁的线程向获取同一个锁的线程发送消息。

实例

MonitorExample.java

/**
 * @author 老马啸西风
 */
class MonitorExample {
    int a = 0;

    public synchronized void writer() {  //1
        a++;                             //2
    }                                    //3

    public synchronized void reader() {  //4
        int i = a;                       //5
        //……
    }                                    //6
}

假设线程 A 执行 writer() 方法，随后线程 B 执行 reader() 方法。

根据 happens-before 规则，这个过程包含的 happens-before 关系可以分为两类：

根据程序次序规则，1 happens before 2, 2 happens before 3; 4 happens before 5, 5 happens before 6。
根据监视器锁规则，3 happens before 4。
根据 happens before 的传递性，2 happens before 5。

因此，线程 A 在释放锁之前所有可见的共享变量，在线程 B 获取同一个锁之后，将立刻变得对 B 线程可见。

锁释放和获取的内存语义

当线程释放锁时，JMM 会把该线程对应的本地内存中的共享变量刷新到主内存中。

以上面的 MonitorExample 程序为例，A 线程释放锁后，共享数据的状态示意图如下：

线程 A

本地内存 A: a = 1;

(写入到主内存)

主内存：a = 1;

当线程获取锁时，JMM 会把该线程对应的本地内存置为无效。

从而使得被监视器保护的临界区代码必须要从主内存中去读取共享变量。

下面是锁获取的状态过程：

在线程 A 写入主内存之后。

线程之间通信：线程 A 向 B 发送消息

线程 B

主内存：a = 1;

(从主内存中读取)

本地内存 B: a = 1;

和 volatile 内存语义对比

对比锁释放-获取的内存语义与 volatile 写-读的内存语义，

可以看出：锁释放与 volatile 写有相同的内存语义；锁获取与 volatile 读有相同的内存语义。

内存语义小结

下面对锁释放和锁获取的内存语义做个总结：

线程 A 释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。
线程 B 获取一个锁，实质上是线程 B 接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。
线程 A 释放锁，随后线程 B 获取这个锁，这个过程实质上是线程 A 通过主内存向线程 B 发送消息。

锁内存语义的实现

本文将借助 ReentrantLock 的源代码，来分析锁内存语义的具体实现机制。

ReentrantLockExample.java

/**
 * @author 老马啸西风
 */
class ReentrantLockExample {

    int a = 0;

    ReentrantLock lock = new ReentrantLock();

    public void writer() {
        lock.lock();         //获取锁
        try {
            a++;
        } finally {
            lock.unlock();  //释放锁
        }
    }

    public void reader () {
        lock.lock();        //获取锁
        try {
            int i = a;
            //……
        } finally {
            lock.unlock();  //释放锁
        }
    }
}

在 ReentrantLock 中，调用 lock() 方法获取锁；调用 unlock() 方法释放锁。

源码实现

ReentrantLock 的实现依赖于 java 同步器框架 AbstractQueuedSynchronizer（本文简称之为AQS）。

AQS 使用一个整型的 volatile 变量（命名为state）来维护同步状态，马上我们会看到，这个 volatile 变量是 ReentrantLock 内存语义实现的关键。

/**
 * @author 老马啸西风
 */
public class ReentrantLock implements Lock, java.io.Serializable {

    /**
     * Base of synchronization control for this lock. Subclassed
     * into fair and nonfair versions below. Uses AQS state to
     * represent the number of holds on the lock.
     */
    abstract static class Sync extends AbstractQueuedSynchronizer {
        //...
    }

    /**
     * Sync object for non-fair locks
     */
    static final class NonfairSync extends Sync {
        //...
    }

    /**
     * Sync object for fair locks
     */
    static final class FairSync extends Sync {
        //...        
    }
}

公平锁

lock()

使用公平锁时，加锁方法lock()的方法调用轨迹如下：

ReentrantLock : lock()
FairSync : lock()
AbstractQueuedSynchronizer : acquire(int arg)
ReentrantLock : tryAcquire(int acquires)

在第 4 步真正开始加锁，下面是该方法的源代码(JDK 1.8)：

/**
 * Fair version of tryAcquire.  Don't grant access unless
 * recursive call or no waiters or is first.
 * @author 老马啸西风
 */
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;
}

加锁方法首先读 volatile 变量 state。

unlock()

在使用公平锁时，解锁方法unlock()的方法调用轨迹如下：

ReentrantLock : unlock()
AbstractQueuedSynchronizer : release(int arg)
Sync : tryRelease(int releases)

在第 3 步真正开始释放锁，下面是该方法的源代码：

/**
 * @author 老马啸西风
 */
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;
}

在释放锁的最后写 volatile 变量 state。

公平锁在释放锁的最后写 volatile 变量 state；在获取锁时首先读这个 volatile 变量。

根据 volatile 的 happens-before 规则，释放锁的线程在写 volatile 变量之前可见的共享变量，在获取锁的线程读取同一个 volatile 变量后将立即变的对获取锁的线程可见。

非公平锁

非公平锁的释放和公平锁完全一样，所以这里仅仅分析非公平锁的获取。

lock()

使用非公平锁时，加锁方法lock()的方法调用轨迹如下：

ReentrantLock : lock()
NonfairSync : lock()
AbstractQueuedSynchronizer : compareAndSetState(int expect, int update)

在第 3 步真正开始加锁，下面是该方法的源代码：

/**
 * Atomically sets synchronization state to the given updated
 * value if the current state value equals the expected value.
 * This operation has memory semantics of a {@code volatile} read
 * and write.
 *
 * @param expect the expected value
 * @param update the new value
 * @return {@code true} if successful. False return indicates that the actual
 *         value was not equal to the expected value.
 * @author 老马啸西风
 */
protected final boolean compareAndSetState(int expect, int update) {
    // See below for intrinsics setup to support this
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

该方法以原子操作的方式更新 state 变量，本文把 java 的 compareAndSet() 方法调用简称为CAS。

JDK文档对该方法的说明如下：如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。此操作具有 volatile 读和写的内存语义。

内存语义总结

现在对公平锁和非公平锁的内存语义做个总结：

公平锁和非公平锁释放时，最后都要写一个 volatile 变量 state。
公平锁获取时，首先会去读这个 volatile 变量。
非公平锁获取时，首先会用 CAS 更新这个 volatile 变量,这个操作同时具有 volatile 读和 volatile 写的内存语义。

从本文对 ReentrantLock 的分析可以看出，锁释放-获取的内存语义的实现至少有下面两种方式：

利用 volatile 变量的写-读所具有的内存语义。
利用 CAS 所附带的 volatile 读和 volatile 写的内存语义。

小结

本文从介绍 ReentrantLock 使用案例开始，引出了锁的获取和释放的内存语义。

为了读者加深印象，对源码进行了简单的学习，下一节将对源码进行深入讲解。

秉着没有对比，就没有发现的原则，我们对比了 ReentrantLock 和 volatile 以及 synchronized 的差异性，便于读者正确地根据自己的场景选择合适的加锁策略。

希望本文对你有帮助，如果有其他想法的话，也可以评论区和大家分享哦。

各位极客的点赞收藏转发，是老马写作的最大动力！

参考资料

JSR 133
other

http://www.infoq.com/cn/articles/java-memory-model-5

为什么需要 ReentrantLock ？
ReentrantLock 使用
- 线程定义
- 测试
锁的释放和获取
- 实例
锁释放和获取的内存语义
- 和 volatile 内存语义对比
- 内存语义小结
锁内存语义的实现
小结
参考资料

JMM-07-lock ReentrantLock 可重入锁详解

为什么需要 ReentrantLock ？

ReentrantLock 使用

线程定义

测试

锁的释放和获取

实例

锁释放和获取的内存语义

和 volatile 内存语义对比

内存语义小结

锁内存语义的实现

源码实现

公平锁

lock()

unlock()

非公平锁

lock()

内存语义总结

小结

参考资料

更多学习