【Java并发编程】ReentrantLock重入锁解析

概述

重入锁ReentrantLock,顾名思义,就是支持重进入的锁,它表示能够支持一个线程对资源的重复加锁。除此之外,该锁还支持获取锁时的公平和非公平选择。Synchronized关键字通过获取自增、释放递减的方式来隐式的支持重入,那么Reentrant是如何支持重入的呢?又是怎么实现公平和非公平选择的呢?接下来我们带着这些问题来看ReentrantLock的源码

重进入的实现原理

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

  1. 线程再次获取锁。锁需要识别来尝试获取锁的线程,是不是当前占有锁的线程,如果是,那么获取成功,如果不是,那么获取失败。
  2. 锁的最终释放。线程重复n次获取了锁,随后在n次释放该锁后,其他线程能够正常获取到锁。锁最终能够正常释放,要求锁的获取进行自增计数,计数表示该锁被重复获取的次数,而锁被释放时,计数自减,当计数归零时,表示该锁已经成功释放。

ReentrantLock是通过组合自定义同步器来实现锁的获取和释放的,下面我们以默认的非公平锁源码来深入分析下实现原理,非公平锁获取锁的源码如下:

final boolean nonfairTryAcquire(int acquires) {
    //获取当前线程
    final Thread current = Thread.currentThread();
    //获取当前同步状态
    int c = getState();
    //如果同步状态等于0,说明该锁未被任何线程占用
    if (c == 0) {
        //CAS方法修改同步状态
        if (compareAndSetState(0, acquires)) {
            //将当前线程赋值给exclusiveOwnerThread
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    //否则,判断占有该锁的线程是不是当前线程
    else if (current == getExclusiveOwnerThread()) {
        //再次获取,状态值加上acquires
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

相信大家很容易看懂这段代码,该方法增加了重入锁再次获取同步状态的逻辑:判断占有锁的线程是否为当前线程来决定获取操作是否成功,如果是获取锁的线程再次请求,那么将同步状态值增加并返回true,来表示获取同步状态成功。成功获取锁的线程再次获取锁,只是增加了同步状态值,这也就要求ReentrantLock在释放同步状态的时候,减少同步状态的值,其对应的tryRelease()方法源码如下:

protected final boolean tryRelease(int releases) {
    //同步状态递减
    int c = getState() - releases;
    //如果当前线程不是占有该锁的线程,那么抛出异常
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    //如果递减后同步状态为0,那么将释放锁,返回true
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    //如果状态不为0,那么返回false
    setState(c);
    return free;
}

从代码中我们可以看出,只有同步状态为0的时候,锁才会被完全释放。如果该锁被获取了n次,那么前(n-1)次tryRelease(int releases)方法必须返回false,只有最后一次才会返回true。

公平锁与非公平锁

ReentrantLock支持两种锁:公平锁与非公平锁,分别对应实现为FairSync和NonfairSync。公平性与否是针对获取锁而言的,如果一个锁是公平的,那么锁的获取顺序就应该符合请求的绝对时间顺序,也就是FIFO。 回顾上一小节中非公平锁获取的nonfairTryAcquire(int acquires)方法,只要CAS自旋获取同步状态成功,则表示当前线程获取了锁,不会要求FIFO,而公平锁则不然。ReentrantLock的构造方法为无参构造方法时,构造的就是非公平锁,源码为:

public ReentrantLock() {
        sync = new NonfairSync();
}

而ReentrantLock还有另外一种构造方法,有参构造方法:

public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

当传入参数为true时,创建公平锁;否则创建非公平锁。下面我们来看下公平锁的处理逻辑是怎么样的,核心方法如下:

protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    //如果当前同步状态为0
    if (c == 0) {
        //判断同步队列中当前节点前面是否还有其余节点,如果没有,那么尝试获取同步状态,成功则返回true
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    //否则,判断占有锁的线程是否为当前线程,如果是,那么同步状态加1,返回true。
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    //否则返回false
    return false;
}

public final boolean hasQueuedPredecessors() {
    // The correctness of this depends on head being initialized
    // before tail and on head.next being accurate if the current
    // thread is first in queue.
    Node t = tail; // Read fields in reverse initialization order
    Node h = head;
    Node s;
    //判断同步队列中,当前节点前面是否还有其余节点
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

从上面的源码中我们看到,nonfailSync中的tryAcquire方法,多调用了hasQueuedPredecessors()方法来判断同步队列中,当前节点前是否还有其余节点。如果有,则说明有线程比当前线程更早请求资源,根据公平性要求,当前节点获取资源失败;如果当前节点没有前驱节点,才会做后续操作。

公平锁和非公平锁可以总结出一下几点:

  1. 公平锁保证了锁的获取按照FIFO原则,每次获取到锁的都是同步队列的第一个节点,保证了请求资源时间上的绝对顺序;非公平锁,有可能刚刚释放锁的线程立马又获取到锁,而有的线程会一直获取不到锁,这也就可能造成“饥饿”现象。
  2. 公平锁为了保证请求资源上的绝对顺序,需要频繁的更换线程,切换上下文,而非公平锁则一定程度上降低了上下文的切换,降低了性能开销。所以ReentrantLock默认选择非公平锁,这样做是为了减少上下文切换,保证系统有更大的吞吐量。

注:本文参考《Java并发编程的艺术》

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,445评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,889评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,047评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,760评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,745评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,638评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,011评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,669评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,923评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,655评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,740评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,406评论 4 320
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,995评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,961评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,023评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,483评论 2 342

推荐阅读更多精彩内容