JAVA并发(11)——ReentrantReadWriteLock

ReentrantReadWriteLock的使用

ReentrantReadWriteLock是JDK提供的读写锁机制,写锁是排他锁,读锁是共享锁。

//创建一个读写锁
ReentrantReadWriteLock reentrantLock = new ReentrantReadWriteLock();
//根据读写锁对象分别创建写锁和读锁
Lock w = reentrantLock.writeLock();
Lock r = reentrantLock.readLock();

ReentrantReadWriteLock把AQS表示锁状态的字段state逻辑上分为了两个部分:高16位是同一个锁被获取共享锁(读锁)的次数,低16位是同一个锁被获取排他锁(写锁)的次数。
默认情况下,创建ReentrantReadWriteLock对象也是按照非公平策略:

public ReentrantReadWriteLock(boolean fair) {
        //sync 的实现与ReentrantLock一样
        sync = fair ? new FairSync() : new NonfairSync();
        readerLock = new ReadLock(this);
        writerLock = new WriteLock(this);
    }

由下面代码可以知道,ReadLock和WriteLock使用的相同的sync变量:

readerLock = new ReadLock(this);
writerLock = new WriteLock(this);

protected WriteLock(ReentrantReadWriteLock lock) {
            sync = lock.sync;
}
protected ReadLock(ReentrantReadWriteLock lock) {
            sync = lock.sync;
}

写锁加锁

执行写锁w.lock()方法,来获取写锁,w.lock方法的实现最终会调用Sync类的tryAcquire方法
写锁的tryAcquire方法实现如下:

protected final boolean tryAcquire(int acquires) {
            Thread current = Thread.currentThread();
            //获取锁状态
            int c = getState();
            //获取排他锁的个数,也就是写锁的个数
            int w = exclusiveCount(c);
            //锁状态个数不为0,且写锁为0或者持有锁的线程不是当前线程,那么失败
            if (c != 0) {
                // (Note: if c != 0 and w == 0 then shared count != 0)
                if (w == 0 || current != getExclusiveOwnerThread())
                    return false;
                if (w + exclusiveCount(acquires) > MAX_COUNT)
                    throw new Error("Maximum lock count exceeded");
                // 如果是当前线程之前已经获取该锁
                setState(c + acquires);
                return true;
            }
            if (writerShouldBlock() ||
                !compareAndSetState(c, c + acquires))
                return false;
            setExclusiveOwnerThread(current);
            return true;
}

主要逻辑:
1.判断锁状态
2.计算获取写锁的次数
(1)当前锁状态为0,执行 (2),否则执行下面
a 如果当前锁状态是读锁或者 b当前锁状态是写锁,但是持有锁的线程不是当前线程,那么获取失败,返回false
(2)设置锁的装状态,如果成功这设置获取锁的线程为当前线程,返回true。否则获取锁失败,返回false

如果写锁的tryAcquire方法返回true
那么会把当前线程封装为一个Node节点对象,把该node节点对象加入AQS的阻塞队列中。

写锁释放

写锁的释放,会调用ReentrantReadWriteLock内部静态类Sync的tryRelease方法,下面是tryRelease具体实现:

protected final boolean tryRelease(int releases) {
           //判断当前申请释放锁的线程是不是持有锁的线程
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            int nextc = getState() - releases;
            //判断排它锁值状态是不是0
            boolean free = exclusiveCount(nextc) == 0;
            if (free)
                setExclusiveOwnerThread(null);
            setState(nextc);
            return free;
 }

当tryRelease返回true之后,此时没有线程持有锁,接着就可以从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;
}

读锁获取

读锁也被称为共享锁,获取共享锁的方法tryAcquireShared实现如下

protected final int tryAcquireShared(int unused) {
            Thread current = Thread.currentThread();
            int c = getState();
           //排它锁不等于0并且拥有排他锁的线程不是当前线程,那么返回-1
            if (exclusiveCount(c) != 0 &&
                getExclusiveOwnerThread() != current)
                return -1;
            //获取共享锁数量
            int r = sharedCount(c);
            //这里有个readerShouldBlock()是为了避免在非公平策略下写锁一直处于饥饿状态,
           //readerShouldBlock实现主要是判断如果当阻塞队列的第一个等待锁的线程是写操作
           //那么就要阻塞当前读线程,使得让写线程能有机会获取到写锁
            if (!readerShouldBlock() &&
                r < MAX_COUNT &&
                compareAndSetState(c, c + SHARED_UNIT)) {
                if (r == 0) {
                    firstReader = current;
                    firstReaderHoldCount = 1;
                } else if (firstReader == current) {
                    firstReaderHoldCount++;
                } else {
                    //如果当前锁是读锁,但是持有锁的线程不是当前线程,执行下面的操作
                   //给获取一个存储在ThreadLocal对象中的缓存对象HoldCounter,该值主要是存储
                   //每个线程获取读锁的个数
                    HoldCounter rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current))
                        cachedHoldCounter = rh = readHolds.get();//readHolds 是Threadlocal对象
                    else if (rh.count == 0)
                        readHolds.set(rh);
                    rh.count++;
                }
                return 1;
            }
            //下面的方法是处理CAS失败或者是在tryAcquireShared没有处理的重入读锁
            return fullTryAcquireShared(current);
}

线程从tryAcquireShared方法中返回大于0表示成功获取到共享锁,如果返回小于0表示获取共享锁失败,那么就需要执行doAcquireShared()方法,把当前线程加入到等待队列中。

读锁释放

读锁释放的主要逻辑:
1.判断获取读锁的第一个线程是不是当前线程,如果是修改锁数量,然后执行3,如果不是当前线程,执行2
2.获取当前线程自己的HoldCounter 对象,修改HoldCounter 中读锁数量值,执行3
3.使用CAS修改AQS的锁状态信息,并返回AQS的缩状态

protected final boolean tryReleaseShared(int unused) {
            Thread current = Thread.currentThread();
            if (firstReader == current) {
                // assert firstReaderHoldCount > 0;
                if (firstReaderHoldCount == 1)
                    firstReader = null;
                else
                    firstReaderHoldCount--;
            } else {
                HoldCounter rh = cachedHoldCounter;
                if (rh == null || rh.tid != getThreadId(current))
                    rh = readHolds.get();
                int count = rh.count;
                if (count <= 1) {
                    readHolds.remove();
                    if (count <= 0)
                        throw unmatchedUnlockException();
                }
                --rh.count;
            }
            for (;;) {
                int c = getState();
                int nextc = c - SHARED_UNIT;
                if (compareAndSetState(c, nextc))
                    // Releasing the read lock has no effect on readers,
                    // but it may allow waiting writers to proceed if
                    // both read and write locks are now free.
                    return nextc == 0;
            }
}
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,014评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,796评论 3 386
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,484评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,830评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,946评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,114评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,182评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,927评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,369评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,678评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,832评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,533评论 4 335
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,166评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,885评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,128评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,659评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,738评论 2 351

推荐阅读更多精彩内容