为什么须要 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 timestwo 1 timestwo 2 timestwo 3 timestwo 4 timesone 0 timesone 1 timesone 2 timesone 3 timesone 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()的办法调用轨迹如下：

  1. ReentrantLock : lock()
  2. FairSync : lock()
  3. AbstractQueuedSynchronizer : acquire(int arg)
  4. 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()的办法调用轨迹如下：

  1. ReentrantLock : unlock()
  2. AbstractQueuedSynchronizer : release(int arg)
  3. 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()的办法调用轨迹如下：

  1. ReentrantLock : lock()
  2. NonfairSync : lock()
  3. 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 的剖析能够看出，锁开释-获取的内存语义的实现至多有上面两种形式：

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

小结

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

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

秉着没有比照，就没有发现的准则，咱们比照了 ReentrantLock 和 volatile 以及 synchronized 的差异性，便于读者正确地依据本人的场景抉择适合的加锁策略。

心愿本文对你有帮忙，如果有其余想法的话，也能够评论区和大家分享哦。

各位极客的点赞珍藏转发，是老马写作的最大能源！