Java ReentrantReadWriteLock 读写锁解析

java 中锁是个很重要的概念,当然这里的前提是你会涉及并发编程。除了语言提供的锁关键字 synchronizedvolatile 之外,jdk 还有其他多种实用的锁。不过这些锁大多都是基于 AQS 队列同步器。ReadWriteLock 读写锁就是其中一个。

读写锁的含义是,将读锁与写锁分开对待,读锁可以任意个一起读,因为读并不涉及数据变更,而遇到写锁后,所有后续的读写都将被阻塞。这特性有什么用呢?比如我们有一个缓存,我们可以用它来提高访问速度,但是当数据变更时,怎样能保证读到准确的数据?

在没有读写锁之前,我们可以使用 wait/notify 机制,我们可以以写锁作为一个同步介质,当写锁被占用时,读只能等待,写操作完成后,通知所有读继续。这看起来不那么好实现!

当有了读写锁后,我们就不需要这么麻烦了,只需要读操作使用读锁,写操作获取写锁操作。大家可能会想,既然都要获取锁,那和其他锁有什么差别呢,一般看到锁咱们都会想到串行,阻塞。但其实读写锁不是这样的。看起来你是每次都获取读锁,但其实单纯的读锁并不会阻塞线程,所以同样是并行无阻,读锁只有在一种情况下会阻塞,那就是写锁被某线程占用时。因为写锁被占用则意味着,数据可能马上发生变化,如果此再允许读操作任意进行的话,多半可能读到写了一半或者是老数据,而这简直太糟了。而写锁则只每次都会真正进行后续操作的阻塞动作,使写操作保证强一致性。

好了,以上就是咱们从概念上来理解读写锁。

而实际上呢?ReadWriteLock 只是一个接口,而其实现则可能是 n 多的。我们就以 jdk 实现的 ReentrantReadWriteLock 为契机,看一下读写锁的实现吧。

在介绍 ReetrantReadWriteLock 之前,我们要先简单说下 ReentrantLock 重入锁,从字面意思理解,就是可重新进入的锁。那么,到底是什么意思呢?我们想一下,如果我们有 2 个资源锁可用,那么,如果我在本线程上锁两次,是不是资源就没有了呢,那第三次进行锁获取的时候,是不是就把自己给锁死了呢?想想应该是这样的,但是为啥平时咱们都遇不到这种情况呢?原因就在于可重入性。可重入的意思是说,如果当前线程进行多次加锁操作,那么无论如何它自己都是可以进入的。简单从实现来说就是,锁会排除当前线程,从而避免自身阻塞。这些需求看起来很理所当然,但是咱们自己实现的时候可能会因为场景不一样,从而不一定需要这种特性呢。syncronized 也是一种重入锁。好了,说了这么多,还是没有看到 ReetrantLock 是怎么实现的!

用个不恰当的图描绘下:(该锁是读写分离的,读多于写的场景能够在保证线程安全的同时提供尽可能大的并发能力)

我们来看下源码就一目了然了。

/**
* Fair version of tryAcquire
*/
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 次
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

重入锁介绍完后,咱们可以安心的来说说 ReentrantReadWriteLock 了。该读写锁也是一种可重入锁。它要实现的特性就是,读读锁无阻塞,写锁必阻塞(包括写读锁/写写锁),读写锁阻塞(需等待读锁释放后才能获取写锁从而保证无脏读)。

从上面可以看出,读和写是两个锁,但是他们的状态却是互相关联的,那怎样设计其数据结构呢?用两个变量去推导往往不太可行,因为其本身就是锁,如果再用两个变量去判定锁状态,那么又如何保证变量自身的可靠性呢?ReentrantReadWriteLock 是通过一个状态变量来控制的,具体为高 16 位保存读锁状态,低 16 位保存写锁状态,而在改变状态时,使用 cas 保证写入的可靠性。(其实这里可以看出,锁个数不应该超过 16 位即 65536 个,这种锁数量已经完全被忽略掉了)。有了数据结构,咱们再看下怎么控制读写互联。读锁的获取,写锁没被占用时,即低位为 0 时,高位大于 0 即可代表获取了读锁,所以,读锁是 n 个可用的。而写锁的获取,则要依赖高低位判定了,高位大于 0,即代表还有读锁存在,不能进入,如果高位为 0,也不一定可进入,低位不为 0 则代表有写锁在占用,所以只有高低位都为 0 时,写锁才可用。

下面,来看下读写锁的具体实现!来个例子先:

public class ReadWriteLockTest {
    private ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
    /**
     * 读锁
     */
    private Lock r = reentrantReadWriteLock.readLock();

    /**
     * 写锁
     */
    private Lock w = reentrantReadWriteLock.writeLock();

    /**
     * 执行线程池
     */
    private ExecutorService executorService = Executors.newCachedThreadPool();

    @Test
    public void testReadLock() {
        for (int i = 0; i < 10; i++) {
            Thread readWorker = new ReadWorker();
            executorService.submit(readWorker);
        }
        waitForExecutorFinish();
    }

    @Test
    public void testWriteLock() {
        for (int i = 0; i < 10; i++) {
            Thread writeWorker = new WriteWorker();
            executorService.submit(writeWorker);
        }
        waitForExecutorFinish();
    }

    @Test
    public void testReadWriteLock() {
        for (int i = 0; i < 10; i++) {
            Thread readWorker = new ReadWorker();
            Thread writeWorker = new WriteWorker();
            executorService.submit(readWorker);
            executorService.submit(writeWorker);
        }
        waitForExecutorFinish();
    }

    /**
     * 线程模拟完成后,关闭线程池
     */
    private void waitForExecutorFinish() {
        executorService.shutdown();
        try {
            executorService.awaitTermination(100, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    private final class ReadWorker extends Thread {
        @Override
        public void run() {
            r.lock();
            try {
                SleepUtils.second(1);
                System.out.println(System.currentTimeMillis() + ": " + Thread.currentThread().getName() + " reading...");
                SleepUtils.second(1);
            }
            finally {
                r.unlock();
            }
        }
    }

    private final class WriteWorker extends Thread {
        @Override
        public void run() {
            w.lock();
            try {
                SleepUtils.second(1);
                System.out.println(System.currentTimeMillis() + ": " + Thread.currentThread().getName() + " writing...");
                SleepUtils.second(1);
            }
            finally {
                w.unlock();
            }
        }
    }
}

可以看到 testReadLock(),无阻塞,立即完成 10 个读任务!而 testWriteLock() 则是全部阻塞执行,20 秒完成串行 10 个任务!而 testReadWriteLock() 则是读锁与写锁交替执行,在执行写锁时,所有锁等待,在执行读锁时,可能存在多个锁同时运行!执行结果样例如下:

1543816105277: pool-1-thread-1 reading...
1543816107278: pool-1-thread-2 writing...
1543816109278: pool-1-thread-20 writing...
1543816111278: pool-1-thread-16 writing...
1543816113279: pool-1-thread-12 writing...
1543816115279: pool-1-thread-8 writing...
1543816117280: pool-1-thread-19 reading...
1543816117280: pool-1-thread-15 reading...
1543816119280: pool-1-thread-4 writing...
1543816121280: pool-1-thread-18 writing...
1543816123281: pool-1-thread-3 reading...
1543816123281: pool-1-thread-7 reading...
1543816125287: pool-1-thread-14 writing...
1543816127290: pool-1-thread-6 writing...
1543816129290: pool-1-thread-10 writing...
1543816131290: pool-1-thread-11 reading...
1543816131290: pool-1-thread-13 reading...
1543816131290: pool-1-thread-9 reading...
1543816131290: pool-1-thread-5 reading...
1543816131290: pool-1-thread-17 reading...

ok,现象已经展示了,是时候透过现象看本质了!

  1. 读锁的获取过程 r.lock(),其实现为 ReadLock
public void lock() {
    // 调用 AQS 的 acquireShared() 方法,进行统一调度
    sync.acquireShared(1);
}
// AQS 获取共享读锁    
public final void acquireShared(int arg) {
    // 调用 ReentrantReadWriteLock.Sync.tryAcquireShared(), 定义锁获取方式
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}

// 获取读锁,unused 传参未使用,直接使用内置的高位加1方式处理
protected final int tryAcquireShared(int unused) {
    /*
    * Walkthrough:
    * 1. If write lock held by another thread, fail.
    * 2. Otherwise, this thread is eligible for
    *    lock wrt state, so ask if it should block
    *    because of queue policy. If not, try
    *    to grant by CASing state and updating count.
    *    Note that step does not check for reentrant
    *    acquires, which is postponed to full version
    *    to avoid having to check hold count in
    *    the more typical non-reentrant case.
    * 3. If step 2 fails either because thread
    *    apparently not eligible or CAS fails or count
    *    saturated, chain to version with full retry loop.
    */
    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)) {
        if (r == 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++;
        }
        return 1;
    }
    // 对读锁阻塞情况,进行处理
    return fullTryAcquireShared(current);
}

// 获取低位数,即写锁状态值
static int exclusiveCount(int c) {
    return c & EXCLUSIVE_MASK; 
}
// 获取高位数,即读锁状态值
static int sharedCount(int c) { 
    return c >>> SHARED_SHIFT; 
}

/**
* Full version of acquire for reads, that handles CAS misses
* and reentrant reads not dealt with in tryAcquireShared.
*/
final int fullTryAcquireShared(Thread current) {
    /*
    * This code is in part redundant with that in
    * tryAcquireShared but is simpler overall by not
    * complicating tryAcquireShared with interactions between
    * retries and lazily reading hold counts.
    */
    HoldCounter rh = null;
    for (;;) {
        int c = getState();
        if (exclusiveCount(c) != 0) {
            if (getExclusiveOwnerThread() != current)
                return -1;
            // else we hold the exclusive lock; blocking here
            // would cause deadlock.
        } else if (readerShouldBlock()) {
            // Make sure we're not acquiring read lock reentrantly
            if (firstReader == current) {
                // assert firstReaderHoldCount > 0;
            } else {
                if (rh == null) {
                    rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current)) {
                        rh = readHolds.get();
                        if (rh.count == 0)
                            readHolds.remove();
                    }
                }
                if (rh.count == 0)
                    return -1;
            }
        }
        if (sharedCount(c) == MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        // 验证通过,cas更新锁状态,使用 SHARED_UNIT 进行高位加1
        if (compareAndSetState(c, c + SHARED_UNIT)) {
            if (sharedCount(c) == 0) {
                firstReader = current;
                firstReaderHoldCount = 1;
            } else if (firstReader == current) {
                firstReaderHoldCount++;
            } else {
                if (rh == null)
                    rh = cachedHoldCounter;
                if (rh == null || rh.tid != getThreadId(current))
                    rh = readHolds.get();
                else if (rh.count == 0)
                    readHolds.set(rh);
                rh.count++;
                cachedHoldCounter = rh; // cache for release
            }
            return 1;
        }
    }
}

以上是获取读锁的过程,其实际控制很简单,只是多了很多的状态统计,所以看起来复杂!

  1. 下面,来看写锁的获取过程,WriteLock.lock()
public void lock() {
    // AQS获取独占锁
    sync.acquire(1);
}

// AQS 锁调度
public final void acquire(int arg) {
    // 如果获取锁失败,则加入到等待队列中
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

// ReentrantReadWriteLock.Sync.tryAcquire(), 写锁获取过程
protected final boolean tryAcquire(int acquires) {
    /*
    * Walkthrough:
    * 1. If read count nonzero or write count nonzero
    *    and owner is a different thread, fail.
    * 2. If count would saturate, fail. (This can only
    *    happen if count is already nonzero.)
    * 3. Otherwise, this thread is eligible for lock if
    *    it is either a reentrant acquire or
    *    queue policy allows it. If so, update state
    *    and set owner.
    */
    Thread current = Thread.currentThread();
    int c = getState();
    int w = exclusiveCount(c);
    // 如果是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");
        // Reentrant acquire
        setState(c + acquires);
        return true;
    }
    // cas 更新 state 
    if (writerShouldBlock() ||
        !compareAndSetState(c, c + acquires))
        return false;
    setExclusiveOwnerThread(current);
    return true;
}

/**
* Creates and enqueues node for current thread and given mode.
*
* @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
* @return the new node
*/
private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    // Try the fast path of enq; backup to full enq on failure
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}

// AQS 的锁入队列操,从队列中进行锁获取,如果获取失败,则产线一个中断标志
final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            // 这里是公平锁的实现方式,只会从队列头获取锁
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            // 阻塞判定,响应中断
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

ok,读写锁的获取已经完成,再来看一下释放的过程!

  1. 读锁的释放 ReadLock.unlock()
public void unlock() {
    // AQS 的释放控制
    sync.releaseShared(1);
}

// AQS 释放锁
public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {
        doReleaseShared();
        return true;
    }
    return false;
}

// ReentrantReadWriteLock.Sync.tryReleaseShared() 自定义释放
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;
        // cas更新状态,每次减1,直到为0,锁才算真正释放
        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;
    }
}

/**
* Release action for shared mode -- signals successor and ensures
* propagation. (Note: For exclusive mode, release just amounts
* to calling unparkSuccessor of head if it needs signal.)
*/
private void doReleaseShared() {
    /*
    * Ensure that a release propagates, even if there are other
    * in-progress acquires/releases.  This proceeds in the usual
    * way of trying to unparkSuccessor of head if it needs
    * signal. But if it does not, status is set to PROPAGATE to
    * ensure that upon release, propagation continues.
    * Additionally, we must loop in case a new node is added
    * while we are doing this. Also, unlike other uses of
    * unparkSuccessor, we need to know if CAS to reset status
    * fails, if so rechecking.
    */
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;            // loop to recheck cases
                unparkSuccessor(h);
            }
            else if (ws == 0 &&
                        !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;                // loop on failed CAS
        }
        if (h == head)                   // loop if head changed
            break;
    }
}
  1. 读锁的释放,WriteLock.unlock()
public void unlock() {
    // AQS 释放控制
    sync.release(1);
}

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

// Sync.tryRelease()
protected final boolean tryRelease(int releases) {
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    int nextc = getState() - releases;
    // 如果写锁状态为0,则意味着当前线程完全释放锁,将 owner 线各设置为null
    boolean free = exclusiveCount(nextc) == 0;
    if (free)
        setExclusiveOwnerThread(null);
    setState(nextc);
    return free;
}

/**
* Wakes up node's successor, if one exists.
*
* @param node the node
*/
private void unparkSuccessor(Node node) {
    /*
    * If status is negative (i.e., possibly needing signal) try
    * to clear in anticipation of signalling.  It is OK if this
    * fails or if status is changed by waiting thread.
    */
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);

    /*
    * Thread to unpark is held in successor, which is normally
    * just the next node.  But if cancelled or apparently null,
    * traverse backwards from tail to find the actual
    * non-cancelled successor.
    */
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    // 调用 LockSupport 释放锁
    if (s != null)
        LockSupport.unpark(s.thread);
}

综上,读写锁的简要解析就算完成了。 其主要使用 AQS 的基础组件,进行锁调度!使用 CAS 进行状态的安全设置! 而锁的阻塞,则是使用 LockSupport 工具组件进行实际阻塞!

作者:等你归去来
原文链接:https://www.cnblogs.com/yougewe/p/10059315.html

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

推荐阅读更多精彩内容