并发(六)--重入锁ReentrantLock

最新推荐文章于 2022-12-11 20:48:03 发布

想飞的盗版鱼

最新推荐文章于 2022-12-11 20:48:03 发布

阅读量207

点赞数

分类专栏：并发

本文链接：https://blog.csdn.net/chen772209/article/details/107196997

版权

并发专栏收录该内容

14 篇文章 1 订阅

订阅专栏

并发(六)–重入锁ReentrantLock

重入锁，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。

`一、实现重进入：`

重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞，该特性的实现需要解决以下两个问题。

线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。
锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。

当方法将同步状态是否为0作为最终释放的条件，当同步状态为0时，将占有线程设为null，并返回true，表示最终释放成功。

ReentrantLock还提供了公平锁也非公平锁的选择，构造方法接受一个可选的公平参数（默认非公平锁），当设置为true时，表示公平锁，否则为非公平锁。公平锁与非公平锁的区别在于公平锁的锁获取是有顺序的。但是公平锁的效率往往没有非公平锁的效率高，在许多线程访问的情况下，公平锁表现出较低的吞吐量。

在这里插入图片描述

二、公平与非公平获取锁的区别：

公平性与否是针对获取锁而言的，如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。对于非公平锁，只要CAS设置同步状态成功，则表示当前线程获取了锁，而公平锁则不同，唯一不同的位置为判断条件多了
hasQueuedPredecessors()方法，即加入了同步队列中当前节点是否有前驱节点的判断，如果该方法返回true，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。

三、源码分析：

回忆在同步器一节中的示例（Mutex），同时考虑如下场景：当一个线程调用Mutex的lock()方法获取锁之后，如果再次调用lock()方法，则该线程将会被自己所阻塞，原因是Mutex在实现tryAcquire(int acquires)方法时没有考虑占有锁的线程再次获取锁的场景，而在调用tryAcquire(int acquires)方法时返回了false，导致该线程被阻塞。简单地说，Mutex是一个不支持重进入的锁。

ReentrantLock虽然没能像synchronized关键字一样支持隐式的重进入，但是在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。

这里提到一个锁获取的公平性问题，如果在绝对时间上，先对锁进行获取的请求一定先被满足，那么这个锁是公平的，反之，是不公平的。公平的获取锁，也就是等待时间最长的线程最优先获取锁，也可以说锁获取是顺序的。ReentrantLock提供了一个构造函数，能够控制锁是否是公平的。公平与非公平的是基于锁内部维护的一个双向链表（CLH），表节点Node的值就是每个请求当前锁的线程。

接下来我们从源码角度来看看ReentrantLock的实现原理，它是如何保证可重入性，又是如何实现公平锁的？？

ReentrantLock是基于AQS的，AQS是Java并发包中众多同步组件的构建基础，它通过一个int类型的状态变量state和一个FIFO队列来完成共享资源的获取，线程的排队等待等。AQS是个底层框架，采用模板方法模式，它定义了通用的较为复杂的逻辑骨架，比如线程的排队，阻塞，唤醒等，将这些复杂但实质通用的部分抽取出来，这些都是需要构建同步组件的使用者无需关心的，使用者仅需重写一些简单的指定的方法即可（其实就是对于共享变量state的一些简单的获取释放的操作）。

ReentrantLock依赖的AQS组件的，AQS有一个核心变量state，用来表示锁状态的。当每个进程用这个锁时，会判断一下当前加锁的线程是否是自己，若是则state+1，当其他线程来时，看到sate不是0，则放入到AQS等待队列中等待被唤醒。另外还有一个关键变量，用来记录当前加锁的是哪个线程。

在这里插入图片描述

四、获取锁：

我们一般都是这么使用ReentrantLock获取锁的：

//非公平锁
ReentrantLock lock = new ReentrantLock();
lock.lock();

lock方法：

  public void lock() {
        sync.lock();
    }

Sync为ReentrantLock里面的一个内部类，它继承AQS（AbstractQueuedSynchronizer），它有两个子类：公平锁FairSync和非公平锁NonfairSync。

ReentrantLock里面大部分的功能都是委托给Sync来实现的，同时Sync内部定义了lock()抽象方法由其子类去实现，默认实现了nonfairTryAcquire(int acquires)方法，可以看出它是非公平锁的默认实现方式。下面我们看非公平锁的lock()方法：

final void lock() {
        //尝试获取锁
        if (compareAndSetState(0, 1))//当前state是否为0，若为0，则获取这个，自己占用（也就是获取了锁）
            setExclusiveOwnerThread(Thread.currentThread());
        else
            //获取失败，调用AQS的acquire(int arg)方法
            acquire(1);
    }

首先会第一次尝试快速获取锁，如果获取失败，则调用acquire(int arg)方法，该方法定义在AQS中，如下：

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

这个方法首先调用tryAcquire(int arg)方法，在AQS中讲述过，tryAcquire(int arg)需要自定义同步组件提供实现，非公平锁实现如下：

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

    final boolean nonfairTryAcquire(int acquires) {
        //当前线程
        final Thread current = Thread.currentThread();
        //获取同步状态
        int c = getState();
        //state == 0,表示没有该锁处于空闲状态
        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;
    }

该方法主要逻辑：首先判断同步状态state == 0 ?，如果是表示该锁还没有被线程持有，直接通过CAS获取同步状态，如果成功返回true。如果state != 0，则判断当前线程是否为获取锁的线程，如果是则获取锁，成功返回true。成功获取锁的线程再次获取锁，这是增加了同步状态state。

六、释放锁：

获取同步锁后，使用完毕则需要释放锁，ReentrantLock提供了unlock释放锁：

public void unlock() {
        sync.release(1);
    }

unlock内部使用Sync的release(int arg)释放锁，release(int arg)是在AQS中定义的：

public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

与获取同步状态的acquire(int arg)方法相似，释放同步状态的tryRelease(int arg)同样是需要自定义同步组件自己实现：

protected final boolean tryRelease(int releases) {
        //减掉releases
        int c = getState() - releases;
        //如果释放的不是持有锁的线程，抛出异常
        if (Thread.currentThread() != getExclusiveOwnerThread())
            throw new IllegalMonitorStateException();
        boolean free = false;
        //state == 0 表示已经释放完全了，其他线程可以获取同步状态了
        if (c == 0) {
            free = true;
            setExclusiveOwnerThread(null);
        }
        setState(c);
        return free;
    }

只有当同步状态彻底释放后该方法才会返回true。当state == 0 时，则将锁持有线程设置为null，free= true，表示释放成功。

七、公平锁与非公平锁：

公平锁与非公平锁的区别在于获取锁的时候是否按照FIFO的顺序来。释放锁不存在公平性和非公平性，上面以非公平锁为例，下面我们来看看公平锁的tryAcquire(int arg)：

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

比较非公平锁和公平锁获取同步状态的过程，会发现两者唯一的区别就在于公平锁在获取同步状态时多了一个限制条件：hasQueuedPredecessors()，定义如下：

public final boolean hasQueuedPredecessors() {
        Node t = tail;  //尾节点
        Node h = head;  //头节点
        Node s;

        //头节点 != 尾节点
        //同步队列第一个节点不为null
        //当前线程是同步队列第一个节点
        return h != t &&
                ((s = h.next) == null || s.thread != Thread.currentThread());
    }

该方法主要做一件事情：主要是判断当前线程是否位于CLH同步队列中的第一个。如果是则返回true，否则返回false。

需要注意的是，这个判断是否有排在自己之前的线程的逻辑稍微有些绕，我们来梳理下，由代码得知，有两种情况会返回true，我们将此逻辑分解一下（注意：返回true意味着有其他线程申请锁比自己早，需要放弃抢占）

1.h !=t && (s = h.next) == null ，这个逻辑成立的一种可能是head指向头结点，tail此时还为null。考虑这种情况：当其他某个线程去获取锁失败，需构造一个结点加入同步队列中（假设此时同步队列为空），在添加的时候，需要先创建一个无意义傀儡头结点（在AQS的enq方法中，这是个自旋CAS操作），有可能在将head指向此傀儡结点完毕之后，还未将tail指向此结点。很明显，此线程时间上优于当前线程，所以，返回true，表示有等待中的线程且比自己来的还早。

2.h != t && (s = h.next) != null && s.thread != Thread.currentThread()。同步队列中已经有若干排队线程且当前线程不是队列的老二结点，此种情况会返回true。假如没有s.thread !=Thread.currentThread()这个判断的话，会怎么样呢？若当前线程已经在同步队列中是老二结点（头结点此时是个无意义的傀儡结点),此时持有锁的线程释放了资源，唤醒老二结点线程，老二结点线程重新tryAcquire（此逻辑在AQS中的acquireQueued方法中），又会调用到hasQueuedPredecessors，不加s.thread !=Thread.currentThread()这个判断的话，返回值就为true，导致tryAcquire失败。

八、总结：

ReentrantLock是一种可重入的，可实现公平性的互斥锁，它的设计基于AQS框架，可重入和公平性的实现逻辑都不难理解，每重入一次，state就加1，当然在释放的时候，也得一层一层释放。至于公平性，在尝试获取锁的时候多了一个判断：是否有比自己申请早的线程在同步队列中等待，若有，去等待；若没有，才允许去抢占。

事实上，公平的锁机制往往没有非公平的效率高，但是，并不是任何场景都是以TPS作为唯一的指标，公平锁能够减少“饥饿”发生的概率，等待越久的请求越是能够得到优先满足。

公平与非公平的获取上都使用了volatile，关键字的state字段，这是保证多线程环境下锁的获取与否的核心。但是当并发环境下多个线程都读取到了state==0时，则必须使用CAS技术，这样就可以保证对共享变量加锁的实现数据变更的原子操作。

公平性锁保证了锁的获取按照FIFO原则（使用了CAS+是否为最前节点），而代价是进行大量的线程切换。非公平性锁（CAS）虽然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。

九、ReentrantLock与synchronized的区别：

1，从底层来说：
synchronized是JVM层里面的锁，是java关键字，通过monitor对象来完成（monitorenter与monitorexit），对象只有在同步块儿中或者同步方法中，才能调用wait/notify/notifyall方法；ReentrantLock是从jdk1.5依赖。（java.util.concurrent.locks.Lock）提供的API工具层面的锁。

synchronized的实现涉及到锁的升级，具体为无锁、偏向锁、自旋锁、向os申请重量级锁；ReentrantLock实现则是通过CAS自旋机制保证线程操作的原子性和volatile保证数据可见性以实现锁的功能。

2，是否手动释放：

synchronized不需要用户手动释放锁，synchronized代码执行完成后系统会自动让线程释放对锁的占用。ReentrantLock则需要用户手动释放锁，若没有手动释放，就可能导致死锁现象。一般通过lock()和unlock()方法配合try/finally语块儿来完成。

3，是否可中断：

synchronized是不可中断类型的锁，除非加锁的代码中出现异常或正常执行完成，ReentrantLock则可以中断，可通过tryLock(long timeout,TimeUnit until)设置超时方法或者将lockInterruptibly()放到代码块儿中，调用interrupt方法进行中断。

4，是否公平锁：

synchronized为非公平锁。ReentrantLock则既可以选公平锁，也可以选择非公平锁

5，是否锁可绑定条件Condition：

synchronized不能绑定。ReentLock通过绑定Condition结合await()/singnal()方法实现线程的精确唤醒，而不是像synchd通过object类的wait()/notify()/notifyall()方法要么随机唤醒一个线程要么唤醒全部线程

6，锁的对象：

synchronized锁的是对象，锁是保存在对象头里面的，根据对象头数据来标识是否有线程获得锁/争抢锁，ReentrantLock锁的是线程，根据进入的线程和int类型的state标识锁的获得/争抢。

附上相关的链接：

https://www.javazhiyin.com/15047.html

https://www.javazhiyin.com/58355.html

感谢并参考：

java知音

想飞的盗版鱼

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
并发(六)--重入锁ReentrantLock

并发(六)–重入锁ReentrantLock重入锁，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。一、实现重进入：重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞，该特性的实现需要解决以下两个问题。线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，
复制链接

扫一扫