读写锁--ReentrantReadWriteLock

时间 2019-12-05

标签读写 reentrantreadwritelock 繁體版

原文原文链接

读写锁，对于读操做来讲是共享锁，对于写操做来讲是排他锁，两种操做均可重入的一种锁。底层也是用AQS来实现的，咱们来看一下它的结构跟代码：

-----------------------------------------------------------------------------------------------

读写锁，固然要区分读跟写两种操做，所以其内部有ReadLock跟WriteLock两种具体实现。但二者也有交互的地方，好比获取写锁要判断当前是否有线程在读，有的话就须要等待，所以内部是使用的同一个队列同步器。由于获取锁的时候，支持公平与非公平两种方式，故而同步器的包装类Sync也有两个：FairSync跟NonfairSync。

从写锁的获取开始：

protected final boolean tryAcquire(int acquires) {
    Thread current = Thread.currentThread();monitor
    int c = getState();  // 重入锁的计数
    int w = exclusiveCount(c); // 计数高低位拆开为读计数跟写计数，计算写计数
    if (c != 0) { // 有人在占有锁
        if (w == 0 || current != getExclusiveOwnerThread())  // 写计数为0，只有读锁直接返回(避免了读锁升级为写锁) 或者  当前线程不是执行线程(执行线程可能读也可能写)也返回
            return false;
        if (w + exclusiveCount(acquires) > MAX_COUNT)  //写锁重入次数 > 65525，抛出异常
            throw new Error("Maximum lock count exceeded");
        setState(c + acquires);  //重入的写线程，直接设置状态（第6行代码没有return，说明当前线程是重入的写线程(写计数不是0，且current就是获取锁的线程)）
        return true;
    }
    if (writerShouldBlock() ||  !compareAndSetState(c, c + acquires))  //c!=0没有return，说明当前锁是空着的，因此cas抢占
        return false;
    setExclusiveOwnerThread(current); // 当前线程参数设置
    return true;
}

　　这里有个writerShouldBlock()，看一下这个是干啥的：

　　追踪源码能够发现，在FairSync跟NonfairSync分别都有这个方法，nonfair中直接return false，fair中是调用的hasQueuedPredecessors()，该方法是用来判断是否有线程排队的，这个writerShouldBlock()就是字面上意思(读锁是否该阻塞(排队))，若是是非公平锁，直接compareAndSetState进行抢占，抢占不到则进入排队挂起，公平锁，则判断是否有排队的，有则本身进入排队，而不是先进行抢占。公平锁就像一个老实人，先排队，没人排队(本身是第一个)则本身抢座位(为啥要抢，由于可能这时候也来了一个认为本身是第一个的老实人)，非公平锁就像土匪，管你排不排队，老子先抢一把座位试试，抢不到(被别的线程抢走了)，被别人打脸了再去排队。综上，第13行的逻辑就是：对于写锁，当前锁没有被占用，若是是非公平方式获取，直接抢占，失败则直接返回，公平方式则查看是否有排队，有则获取失败直接返回，无则进行抢占。方法总体上，没获取到锁返回false，获取到了返回true，而后结合AQS的代码：

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&  acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) //没有获取到，就往等待队列添加节点，而后挂起线程
        selfInterrupt();
}

　　so，整个这个获取写锁的过程就是：查看有没有人占用锁，若是有读锁，则进入队列等待；有写锁，则看是不是本身的线程，是则重设state而后继续执行，不是则进入队列等待。tryAcquire必定要跟acquire联合起来看，不然难以理清整个流程。

　　对了，还有个exclusiveCount(int c)用来拆分高低位的方法要说一下，由于读写锁要分别记录读跟写被重入的次数，按照通常设计，这分两个变量来计数就好了，但jdk就是jdk，它把这两个用一个int变量来记录了。方法么，就是高低位分开计算的，高16位表示读状态，低16位表示写状态。假设同步状态为s，则写状态为s & 0x0000FFFF，至关于高16位所有清0，同理，读状态则为s >>> 16，也就是右移，至关于把低16位都移除了。固然，复杂的就是读状态变化的时候，不是简单的s +1，这样的话就加到了写操做上，而是s + 0x00010000，把低位补上0就好了。相似的与操做、位移等等，jdk中有大量的应用，好比hashmap中肯定元素所在链表等操做都有应用。

写锁释放代码：

protected final boolean tryRelease(int releases) {
    if (!isHeldExclusively())  //没有写锁，抛异常
        throw new IllegalMonitorStateException();
    int nextc = getState() - releases;
    boolean free = exclusiveCount(nextc) == 0;  //次数是否清0了
    if (free)  //清0 了，说明彻底释放了
        setExclusiveOwnerThread(null);
    setState(nextc);
    return free;
}

　　释放锁比较简单，不作赘述。

读锁获取：

protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread(); 
    int c = getState();
    if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current) // 有写锁 且当前线程不是写锁线程，不能重入，失败
        return -1;
    int r = sharedCount(c);  //向右移位，获取读锁计数
    if (!readerShouldBlock() &&  r < MAX_COUNT &&  compareAndSetState(c, c + SHARED_UNIT)) { // 若无需排队  && 读计数<65535(16位最大值) && 状态设置成功(读锁的总体计数就是在这里改的，注意加了一个默认值的操做)
        if (r == 0) { //读锁为0
              firstReader = current;  //记录第一个获取锁的线程
            firstReaderHoldCount = 1;
        } else if (firstReader == current) { //是本身重入的
            firstReaderHoldCount++;
        } else { // 
            HoldCounter rh = cachedHoldCounter;  //用于计算读计数的计数器
            if (rh == null || rh.tid != getThreadId(current))  
                cachedHoldCounter = rh = readHolds.get();  
            else if (rh.count == 0) 
                readHolds.set(rh);
            rh.count++;   //当前线程的读计数+1
        }
        return 1;
    }
    return fullTryAcquireShared(current); //第7行条件不知足，则for循环获取读锁(实际不会死循环的)
}

　　读锁的获取比较复杂，这里主要有一个多线程各自计数的问题。对于读锁，除了要对全局的state中的读锁的计数进行修改，还要每一个线程各自维护一份本身重入的次数计数，这个计数存在一个ThreadLocal(readHolds)中的一个对象(cachedHoldCounter)里边。读锁获取的逻辑是：没有写锁占用，则直接获取读锁，这就是第7行的逻辑(固然，可能跟其它读线程冲突致使获取失败，则进入fullTryAcquireShared(current))；若是有写锁占用了呢，就调用fullTryAcquireShared(current)获取锁，看一下源码：

final int fullTryAcquireShared(Thread current) {
    HoldCounter rh = null;
    for (;;) {
        int c = getState();
        if (exclusiveCount(c) != 0) { // 有写锁
            if (getExclusiveOwnerThread() != current) // 写锁持有者不是当前线程,获取失败，经过aqs的doAcquireShared()进入排队
                return -1;                                                   //这里只作了不是当前线程的判断，若是是当前线程，这个地方不能进行排队，由于若已有写线程在排队的话，就会形成死锁，源码中else一句的英文备注就是说这个
        } else if (readerShouldBlock()) { //没写锁，但可能有写锁在等待读锁释放！！须要排队
                       // 写锁空闲  且  公平策略决定 线程应当被阻塞
            	       // 下面的处理是说，若是是已获取读锁的线程重入读锁时， 即便公平策略指示应当阻塞也不会阻塞。
                       // 不然，这也会致使死锁的。
            if (firstReader == current) { //
                // assert firstReaderHoldCount > 0;
            } else {
            // threadlocal 相关处理
                if (rh.count == 0)    // 须要阻塞且是非重入(还未获取读锁的)，获取失败
                    return -1;
            }
        }
        if (sharedCount(c) == MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        if (compareAndSetState(c, c + SHARED_UNIT)) { // cas 抢锁成功
   	//threadlocal相关处理
            return 1;
        }
    }
}

　　 读锁的释放：

protected final boolean tryReleaseShared(int unused) {
    Thread current = Thread.currentThread();
    if (firstReader == current) {// 清理firstReader缓存 或 readHolds里的重入计数
        // 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))
// 释放读锁对其余读线程没有任何影响，
// 但能够容许等待的写线程继续，若是读锁、写锁都空闲。
            return nextc == 0;
    }
}

-------------------------------------------------------------------------

　　读写锁的源码，读起来比想象中的难度大得多，缘由是读锁的部分设计比较复杂，主要涉及锁降级，以及几个变量跟threadlocal优化性能的处理。照着《java并发编程的艺术》跟一些博客看了2天，仍是没把这部分彻底理清楚，这个艰苦的工做之后继续搞吧。

　　咱们看一下关于锁的降级跟升级的问题，看是如何实现的：

　　锁降级的定义：锁降级指的是写锁降级为读锁。若是当前线程持有写锁，而后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。锁降级指的是把持住(当前拥有的)写锁，再获取到读锁，随后释放(先前拥有的)写锁的过程。----《java并发编程的艺术》

　　这段话的理解是不难的，但要在读写锁的源码中去找到与之对应的逻辑是不太好找的。实际上：

if (exclusiveCount(c) != 0) {
    if (getExclusiveOwnerThread() != current)
        return -1;

　　这个就是与之相关的逻辑代码，在tryAcquireShared跟fullTryAcquireShared(Thread current) 中都有体现。

　　上面的代码的意思是：当写锁被持有时，若是持有该锁的线程不是当前线程，就返回 “获取锁失败”，反之就会继续获取读锁。称之为锁降级。

　　关于锁降级，书中还给出了一个例子：

public void processCachedData() {
    readLock.lock();
    if(!update){
        //必须先释放读锁
        readLock.unlock();
        //锁降级从写锁获取到开始
        writeLock.lock();
        try{
            if(!update){
                //准备数据的流程(略)
                update = true;
            }
            readLock.lock();
        }finally {
            writeLock.unlock();
        }
        //锁降级完成，写锁降级为读锁
    }
    try{
        //使用数据的流程
    }finally {
        readLock.unlock();
    }
}

　　有一段文字说明：锁降级中的读锁获取是否必要呢？答案是必要的。主要是为了保证数据的可见性，若是当前线程不获取读锁而是直接释放写锁，假设另外一个线程获取了写锁并修改了数据，那么当前线程没法感知该线程的数据更新。

　　但是，，，这里有个疑问，另外一个线程获取了写锁，你当前线程还能获取读锁吗？既然不能获取，何来没法感觉数据更新一说？这个地方感受有点问题。网上博文基本千篇一概也是说可见性如何的，跟书中观点同样，我以为不对，比较赞同 https://www.jianshu.com/p/cd485e16456e这个所说的。

　　至于ThreadLocal相关代码，稍后再去理这里边的逻辑。