• ReentrantReadWriteLock读写锁实现原理详解


    AQS实现的Mutex和ReentrantLock基本都是排他锁,这些锁在同一时刻只允许一个线程进行访问,而读写锁在同一时刻可以允许多个读线程访问,但是在写线程访问时,所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁,一个读锁和一个写锁,通过分离读锁和写锁,使得并发性相比一般的排他锁有了很大的提升。

    除了保证写操作对读操作的可见性以及并发性的提升之外,读写锁能够简化读写交互场景的编程方式。假设在程序中定义一个共享的用作缓存数据结构,它大部分时间提供读服务(例如查询和搜索),而写操作占有的时间很少,但是写操作完成之后的更新需要对后续的读服务可见。

    在没有读写锁支持(java5之前)的时候,如果需要完成上述工作就要使用java的等待通知机制,就是当写操作开始时,所有晚于写操作的读操作均会进入等待状态,只有写操作完成并进行通知之后,所有等待的读操作才能继续执行(写操作之间依靠synchronized关键字进行同步),这样做的目的是使读操作能读取到正确的数据,不会出现脏读。改用读写锁实现上述功能,只需要在读操作时获取读锁,写操作时获取写锁即可。当写锁被获取到时,后续(非当前写操作线程)的读写操作都会被阻塞,写锁释放之后,所有操作继续执行,编程方式相对于使用等待通知机制的实现方式,简单明了。

    一般情况下,读写锁的性能都会比排他锁好,因为大多数场景读是多于写的。在读多于写的情况下,读写锁能够提供比排他锁更好的并发性和吞吐量。java并发包提供读写锁的实现是ReentrantReadWriteLock,它的特性如下所示:

    特性说明
    公平性选择支持非公平(默认)和公平的锁获取方式,吞吐量还是非公平优于公平
    重进入该锁支持重进入,以读写线程为例:读线程在获取了读锁之后,能够再次获取读锁。而写线程在获取了写锁之后能够再次获取写锁,同时也可以获取读锁。
    锁降级遵循获取写锁、获取读锁再释放写锁的次序,写锁能够降级成为读锁

    读写锁的接口与示例

    ReadWriteLock仅定义了获取读锁和写锁的两个方法,即readLock()方法和writeLock()方法,而其实现-ReentrantReadWriteLock,除了接口方法之外,还提供了一些便于外界监控其内部工作状态的方法,这些方法如下所示:

    方法名称描述
    int getReadLockCount()返回当前读锁被获取的次数。该次数不等于获取读锁的线程数,例如,仅一个线程,它连续获取(重进入)了n次读锁,那么占据读锁的线程数是1,但该方法返回n
    int getReadHoldCount()返回当前线程获取读锁的次数。使用ThreadLocal保存当前线程获取的次数。
    boolean isWriteLocked()判断写锁是否被获取
    int getWriteHoldCount()返回当前写锁被获取的次数

    接下来,通过一个缓存示例说明读写锁的使用方式:

    public class Cache {
        static Map map = new HashMap();
        static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
        static Lock r = rwl.readLock();
        static Lock w = rwl.writeLock();
    
        /**
         * 获取一个key对应的value
         *
         * @param key
         * @return
         */
        public static final Object get(String key) {
            r.lock();
            try {
                return map.get(key);
            } finally {
                r.unlock();
            }
        }
    
        /**
         * 设置key对应的value,并返回旧的value
         *
         * @param key
         * @param value
         * @return
         */
        public static final Object put(String key, Object value) {
            w.lock();
            try {
                return map.put(key, value);
            } finally {
                w.unlock();
            }
        }
    
        /**
         * 清空所有的内容
         */
        public static final void clear() {
            w.lock();
            try {
                map.clear();
            } finally {
                w.unlock();
            }
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49

    上述示例中,Cache组合一个非线程安全的HashMap作为缓存的实现,同时使用读写锁的读锁和写锁来保证Cache是线程安全的。在读操作get(String key)方法中,需要获取读锁,这使得并发访问该方法时不会被阻塞。写操作put(String key,Object value)方法和clear()方法,在更新HashMap时必须提前获取写锁,当获取写锁后,其他线程对于读锁和写锁的获取均被阻塞,而只有写锁被释放之后,其他读写操作才能继续。Cache使用读写锁提升读操作的并发性,也保证每次写操作对所有的读写操作的可见性,同时简化了编程方式

    读写锁的实现分析

    ReentrantReadWriteLock的实现,主要包括:

    • 读写状态的设计
    • 写锁的获取与释放
    • 锁降级

    读写状态的设计

    读写锁同样依赖自定义同步器来实现同步功能,而读写状态就是其同步器的同步状态。同步状态表示锁被一个线程重复获取的次数。而读写锁的自定义同步器的实现,需要在同步状态(一个整型变量)上维护多个读线程和一个写线程的状态,使得该状态的设计成为读写锁实现的关键。

    如果在一个整型变量上维护多种状态,就一定需要“按位切割使用”这个变量,读写锁将比那辆切分成了两部分,高16位表示读,低16位表示写,划分如下:

    image

    当前同步状态表示一个线程已经获取了写锁,且重进入了两次,同时也连续获取了两次读锁。

    读写锁是如何迅速确定读和写各自的状态呢?答案是通过位运算。

    假设当前同步状态值为S,写状态等于S&0X0000FFFF(将高16位全部抹去),读状态等于S>>>16(无符号补0右移16位)。当写状态增加1时,等于S+1,当读状态增加1时,等于S+(1<<16),也就是S+0X00010000。

    根据状态的划分能得出一个推论:S不等于0时,当写状态(S&0X0000FFFF)等于0时,则读状态(S>>>16)大于0,即读锁已被获取。

    写锁的获取与释放

    写锁时一个支持重进入的排他锁。如果当前线程已经获取了写锁,则增加写状态。如果当前线程在获取写锁时,读锁已经被获取(读状态不为0)或者该线程不是已经获取写锁的线程,则当前线程进入等待状态,获取写锁的代码如下(ReentrantReadWriteLock的tryAcquire方法):

    protected final boolean tryAcquire(int acquires) {
        Thread current = Thread.currentThread();
        int c = getState();
        int w = exclusiveCount(c);
        if (c != 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;
        }
        if (writerShouldBlock() ||
            !compareAndSetState(c, c + acquires))
            return false;
        setExclusiveOwnerThread(current);
        return true;
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
  • 相关阅读:
    上周热点回顾(3.25-3.31)
    C到C++/编译过程/链接方式/内存模型/STL
    西安Biotin-PEG8-IA_IA-PEG8-生物素供应商
    秋招每日一题T6——链表合并
    第3部分 原理篇2去中心化数字身份标识符(DID)(2)
    提高工作效率的神器:基于前端表格实现Chrome Excel扩展插件
    【kafka】消费者与分区
    字符串排序程序
    创新实战|高转化网站首页设计的10大关键要素
    聊聊秒杀系统的设计(三)
  • 原文地址:https://blog.csdn.net/wozaibohaibian/article/details/126338169