ReentrantLock和Synchronized

Java

一、前言

Synchronized和 ReentrantLock 大家应该都不陌生了，作为java中最常用的本地锁，最初版本中 ReentrantLock 的性能是远远强于 Synchronized 的，后续java在一次次的版本迭代中对 Synchronized 进行了大量的优化，直到 jdk1.6 之后，两种锁的性能已经相差无几，甚至 Synchronized 的自动释放锁会更好用。

二、Synchronized使用

在 java 代码中 synchronized 的使用是非常简单的

直接贴在方法上(锁住的是当前类的字节码文件)
贴在代码块儿上(锁住的是对象)

程序运行期间，Synchronized那一块儿代码发生了什么

在多线程运行过程中，线程会去先抢对象的监视器，这个监视器是对象独有的，其实就相当于一把钥匙，抢到了，那你就获得了当前代码块儿的执行权。

每一个锁都对应一个monitor对象，在HotSpot虚拟机中它是由ObjectMonitor实现的（C++实现）。每个对象都存在着一个monitor与之关联，对象与其monitor之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个monitor被某个线程持有后，它便处于锁定状态。

monitor介绍

每个对象有一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：
1. 如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。
如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1.这里涉及重入锁，如果一个线程获得了monitor，他可以再获取无数次，进入的时候monito+1，退出-1，直到为0，开可以被其他线程获取
如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。

其他没有抢到的线程会进入队列(SynchronizedQueue)当中等待，等待当前线程执行完后，释放锁.

最后当前线程执行完毕后通知出队然后继续重复当前过程.

从 jvm 的角度来看 monitorenter 和 monitorexit 指令代表着代码的执行与结束。

SynchronizedQueue

SynchronizedQueue 是一个比较特殊的队列，它没有存储功能，它的功能就是维护一组线程,其中每个插入操作必须等待另一个线程的移除操作，同样任何一个移除操作都等待另一个线程的插入操作。因此此队列内部其实没有任何一个元素，或者说容量是0，严格说并不是一种容器。由于队列没有容量，因此不能调用 peek 操作，因为只有移除元素时才有元素。

锁升级的过程

无锁：对象一开始就是无锁状态。
偏向锁：相当于给对象贴了一个标签 (将自己的线程 id 存入对象头中)，下次我再进来时，发现标签是我的，我就可以继续使用了。
自旋锁：想象一下有一个厕所，里面有一个人在，你很想上但是只有一个坑位，所以你只能徘徊等待，等那个人出来以后，你就可以使用了。这个自旋是使用 cas 来保证原子性的，关于 cas 我这里就不再赘述了。
重量级锁：直接向 cpu 去申请申请锁，其他的线程都进入队列中等待。

1.锁膨胀

上面讲到锁有四种状态，并且会因实际情况进行膨胀升级，其膨胀方向是：无锁——>偏向锁——>轻量级锁——>重量级锁。

2.偏向锁

一句话总结它的作用：减少统一线程获取锁的代价。在大多数情况下，锁不存在多线程竞争，总是由同一线程多次获得，那么此时就是偏向锁。

核心思想：

如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word的结构也就变为偏向锁结构，当该线程再次请求锁时，无需再做任何同步操作，即获取锁的过程只需要检查Mark Word的锁标记位为偏向锁以及当前线程ID等于Mark Word的ThreadID即可，这样就省去了大量有关锁申请的操作。

3.轻量级锁

轻量级锁是由偏向锁升级而来，当存在第二个线程申请同一个锁对象时，偏向锁就会立即升级为轻量级锁。注意这里的第二个线程只是申请锁，不存在两个线程同时竞争锁，可以是一前一后地交替执行同步块。

4.重量级锁

重量级锁是由轻量级锁升级而来，当同一时间有多个线程竞争锁时，锁就会被升级成重量级锁，此时其申请锁带来的开销也就变大。

重量级锁一般使用场景会在追求吞吐量，同步块或者同步方法执行时间较长的场景。

5.锁消除

消除锁是虚拟机另外一种锁的优化，这种优化更彻底，在JIT编译时，对运行上下文进行扫描，去除不可能存在竞争的锁

6.锁粗化

锁粗化是虚拟机对另一种极端情况的优化处理，通过扩大锁的范围，避免反复加锁和释放锁

7.自旋锁与自适应自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。

自旋锁：许多情况下，共享数据的锁定状态持续时间较短，切换线程不值得，通过让线程执行循环等待锁的释放，不让出CPU。如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式。但是它也存在缺点：如果锁被其他线程长时间占用，一直不释放CPU，会带来许多的性能开销。

自适应自旋锁：这种相当于是对上面自旋锁优化方式的进一步优化，它的自旋的次数不再固定，其自旋的次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，这就解决了自旋锁带来的缺点。

锁升级是什么时候发生的

偏向锁：一个线程获取锁时会由无锁升级为偏向锁
自旋锁：当产生线程竞争时由偏向锁升级为自旋锁,想象一下 while(true)
重量级锁：当线程竞争到达一定数量或超过一定时间时，晋升为重量级锁

既然synchronized有锁升级那么有锁降级吗？

在 HotSpot 虚拟机中是有锁降级的，但是仅仅只发生在 STW 的时候，只有垃圾回收线程能够观测到它，也就是说，在我们正常使用的过程中是不会发生锁降级的，只有在 GC 的时候才会降级。

三、ReentrantLock的使用

ReentrantLock 的使用也是非常简单的，与 Synchronized 的不同就是需要自己去手动释放锁，为了保证一定释放，所以通常都是和 try~finally 配合使用的。

ReentrantLock的原理

ReentrantLock 意为可重入锁，说起 ReentrantLock 就不得不说 AQS ，因为其底层就是使用 AQS 去实现的。

AQS 原理概览

AQS (AbstractQueuedSynchronizer)核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 CLH 队列锁实现的，即将暂时获取不到锁的线程加入到队列中。

CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的分配。

AQS 使用一个 int 成员变量来表示同步状态，通过内置的 FIFO 队列来完成获取资源线程的排队工作。AQS 使用 CAS 对该同步状态进行原子操作实现对其值的修改。

private volatile int state;//共享变量，使用volatile修饰保证线程可见性

状态信息通过 protected 类型的 getState，setState，compareAndSetState 进行操作

//返回同步状态的当前值
protected final int getState() {
        return state;
}
 // 设置同步状态的值
protected final void setState(int newState) {
        state = newState;
}
//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值）
protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

AQS 定义两种资源共享方式

Exclusive（独占）：只有一个线程能执行，如 ReentrantLock。又可分为公平锁和非公平锁：
- 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁
- 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
Share（共享）：多个线程可同时执行，如CountDownLatch、Semaphore、CountDownLatch、 CyclicBarrier、ReadWriteLock 我们都会在后面讲到。

ReentrantReadWriteLock 可以看成是组合式，因为 ReentrantReadWriteLock 也就是读写锁允许多个线程同时对某一资源进行读。

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS 已经在顶层实现好了。

ReentrantLock 默认采用非公平锁，因为考虑获得更好的性能，重载构造函数，通过 boolean 来决定是否用公平锁（传入 true 用公平锁）。

ReentrantLock 中公平锁的 lock 方法

static final class FairSync extends Sync {
    final void lock() {
        acquire(1);
    }
    // AbstractQueuedSynchronizer.acquire(int arg)
    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            // 1. 和非公平锁相比，这里多了一个判断：是否有线程在等待
            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;
    }
}

非公平锁的 lock 方法：

static final class NonfairSync extends Sync {
    final void lock() {
        // 2. 和公平锁相比，这里会直接先进行一次CAS，成功就返回了
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }
    // AbstractQueuedSynchronizer.acquire(int arg)
    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}
/**
 * Performs non-fair tryLock.  tryAcquire is implemented in
 * subclasses, but both need nonfair try for trylock method.
 */
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 这里没有对阻塞队列进行判断
        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;
}

公平锁和非公平锁只有两处不同：

非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了。
非公平锁在 CAS 失败后，和公平锁一样都会进入到 tryAcquire 方法，在 tryAcquire 方法中，如果发现锁这个时候被释放了（state == 0），非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。

公平锁和非公平锁就这两点区别，如果这两次 CAS 都不成功，那么后面非公平锁和公平锁是一样的，都要进入到阻塞队列等待唤醒。

相对来说，非公平锁会有更好的性能，因为它的吞吐量比较大。当然，非公平锁让获取锁的时间变得更加不确定，可能会导致在阻塞队列中的线程长期处于饥饿状态。

AQS底层使用了模板方法模式

同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）：

使用者继承 AbstractQueuedSynchronizer 并重写指定的方法。（这些重写方法很简单，无非是对于共享资源 state 的获取和释放）
将 AQS 组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。

自定义同步器时需要重写下面几个 AQS 提供的模板方法：

isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。

默认情况下，每个方法都抛出 UnsupportedOperationException。这些方法的实现必须是内部线程安全的，并且通常应该简短而不是阻塞。AQS 类中的其他方法都是 final ，所以无法被其他类使用，只有这几个方法可以被其他类使用。

以 ReentrantLock 为例，state 初始化为 0，表示未锁定状态。A 线程 lock() 时，会调用 tryAcquire()独占该锁并将 state+1。此后，其他线程再 tryAcquire() 时就会失败，直到 A 线程 unlock()到 state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（state 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证 state 是能回到零态的。

再以 CountDownLatch 以例，任务分为 N 个子线程去执行，state 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后 countDown() 一次，state 会 CAS(Compare and Swap)减 1。等到所有子线程都执行完后(即 state=0)，会 unpark()主调用线程，然后主调用线程就会从 await() 函数返回，继续后余动作。

一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。

四、ReentrantLock和Synchronized的区别

其实ReentrantLock和Synchronized 最核心的区别就在于 Synchronized适合于并发竞争低的情况，因为Synchronized的锁升级如果最终升级为重量级锁在使用的过程中是没有办法消除的，意味着每次都要和cpu去请求锁资源，而ReentrantLock主要是提供了阻塞的能力，通过在高并发下线程的挂起，来减少竞争，提高并发能力，所以我们文章标题的答案，也就显而易见了。
synchronized是一个关键字，是由 jvm层面去实现的，而ReentrantLock是由 java api 去实现的。
synchronized是隐式锁，可以自动释放锁 ，ReentrantLock是显式锁，需要手动释放锁 。
ReentrantLock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断。
ReentrantLock可以获取锁状态，而synchronized不能。

五、性能对比：ReentrantLock vs Synchronized

自增操作

首先测试用 synchronized 与 ReentrantLock 同步自增操作，测试代码如下：

@Benchmark
@Group("lock")
@GroupThreads(4)
public void lockedOp() {
    try {
        lock.lock();
        lockCounter ++;
    } finally {
        lock.unlock();
    }
}

@Benchmark
@Group("synchronized")
@GroupThreads(4)
public void synchronizedOp() {
    synchronized (this) {
        rawCounter ++;
    }
}

测试结果

链表操作

自增操作 CPU 时间太短，适当增加每个操作的时间，改为往 linkedList 插入一个数据。代码如下：

@Benchmark
@Group("lock")
@GroupThreads(2)
public void lockedOp() {
    try {
        lock.lock();
        lockQueue.add("event");
        if (lockQueue.size() >= CLEAR_COUNT) {
            lockQueue.clear();
        }
    } finally {
        lock.unlock();
    }
}

@Benchmark
@Group("synchronized")
@GroupThreads(2)
public void synchronizedOp() {
    synchronized (this) {
        rawQueue.add("event");
        if (rawQueue.size() >= CLEAR_COUNT) {
            rawQueue.clear();
        }
    }
}

结果如下

结果分析

可以看到 ReentrantLock 的性能还是要高于 Synchronized 的。
在 2 个线程时吞吐量达到最低，而 3 个线程反而提高了，推测是因为两个线程竞争时一定会发生线程调度，而多个线程（不公平）竞争时有一些线程是可以直接从当前线程手中接过锁的。
随着线程数的增加，吞吐量只有少量的下降。首先推测因为同步代码最多只有一个线程在执行，所以线程数虽然增多，吞吐量是不会增加多少的。其次是大部分线程变成等待后就不太会被唤醒，因此不太会参与后续的竞争。
(linkedlist 测试中)持有锁的时间增加后，ReentrantLock 与 Synchronized 的吞吐量差距减小了，应该是能佐证 CAS 线程重试的开销在增长的。

当然，所有寄语CAS操作的，比如CopyOnWriteArrayList，如果存在大量竞争，都会存在线程重试的开销

这个测试让我对 ReentrantLock 有了更多的信心，不过一般开发时还是建议用 synchronized, 毕竟大佬们还在不断优化中（看到有文章说 JDK 9 中的 Lock 和 synchronized 已经基本持平了）

动态高并发时为什么推荐ReentrantLock而不是Synchronized？
性能对比：ReentrantLock vs Synchronized

如果觉得文章对你有用，请随意赞赏

框架锁

ReentrantLock和Synchronized

https://www.cychee.cn/archives/reentrantlock-he-synchronized

作者

小蓝同学

发布于

2022-02-25

更新于

2023-09-12

许可协议

CC BY 4.0