zoukankan      html  css  js  c++  java
  • j.u.c系列(07)---之读写锁:ReentrantReadWriteLock

    写在前面

      重入锁ReentrantLock是排他锁,排他锁在同一时刻仅有一个线程可以进行访问,但是在大多数场景下,大部分时间都是提供读服务,而写服务占有的时间较少。然而读服务不存在数据竞争问题,如果一个线程在读时禁止其他线程读势必会导致性能降低。所以就提供了读写锁。

      读写锁维护着一对锁,一个读锁和一个写锁。通过分离读锁和写锁,使得并发性比一般的排他锁有了较大的提升:在同一时间可以允许多个读线程同时访问,但是在写线程访问时,所有读线程和写线程都会被阻塞。

    读写锁的主要特性:

    1. 公平性:支持公平性和非公平性。
    2. 重入性:支持重入。读写锁最多支持65535个递归写入锁和65535个递归读取锁。
    3. 锁降级:遵循获取写锁、获取读锁在释放写锁的次序,写锁能够降级成为读锁

      

      读写锁ReentrantReadWriteLock实现接口ReadWriteLock,该接口维护了一对相关的锁,一个用于只读操作,另一个用于写入操作。只要没有 writer,读取锁可以由多个 reader 线程同时保持。写入锁是独占的。

    public interface ReadWriteLock {
        Lock readLock();
        Lock writeLock();
    }

       ReadWriteLock定义了两个方法。readLock()返回用于读操作的锁,writeLock()返回用于写操作的锁。ReentrantReadWriteLock定义如下:

        /** 内部类  读锁 */
        private final ReentrantReadWriteLock.ReadLock readerLock;
        /** 内部类  写锁 */
        private final ReentrantReadWriteLock.WriteLock writerLock;
    
        final Sync sync;
    
        /** 使用默认(非公平)的排序属性创建一个新的 ReentrantReadWriteLock */
        public ReentrantReadWriteLock() {
            this(false);
        }
    
        /** 使用给定的公平策略创建一个新的 ReentrantReadWriteLock */
        public ReentrantReadWriteLock(boolean fair) {
            sync = fair ? new FairSync() : new NonfairSync();
            readerLock = new ReadLock(this);
            writerLock = new WriteLock(this);
        }
    
        /** 返回用于写入操作的锁 */
        public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
        /** 返回用于读取操作的锁 */
        public ReentrantReadWriteLock.ReadLock  readLock()  { return readerLock; }
    
        abstract static class Sync extends AbstractQueuedSynchronizer {
            /**
             * 省略其余源代码
             */
        }
        public static class WriteLock implements Lock, java.io.Serializable{
            /**
             * 省略其余源代码
             */
        }
    
        public static class ReadLock implements Lock, java.io.Serializable {
            /**
             * 省略其余源代码
             */
        }

      ReentrantReadWriteLock与ReentrantLock一样,其锁主体依然是Sync,它的读锁、写锁都是依靠Sync来实现的。所以ReentrantReadWriteLock实际上只有一个锁,只是在获取读取锁和写入锁的方式上不一样而已,它的读写锁其实就是两个类:ReadLock、writeLock,这两个类都是lock实现。

      在ReentrantLock中使用一个int类型的state来表示同步状态,该值表示锁被一个线程重复获取的次数。但是读写锁ReentrantReadWriteLock内部维护着两个一对锁,需要用一个变量维护多种状态。所以读写锁采用“按位切割使用”的方式来维护这个变量,将其切分为两部分,高16为表示读,低16为表示写。分割之后,读写锁是如何迅速确定读锁和写锁的状态呢?通过为运算。假如当前同步状态为S,那么写状态等于 S & 0x0000FFFF(将高16位全部抹去),读状态等于S >>> 16(无符号补0右移16位)。代码如下:

            static final int SHARED_SHIFT   = 16;
            static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
            static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
            static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
    
            static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
            static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

    写锁(写锁就是一个支持可重入的排他锁)

    写锁的获取(写锁的获取最终会调用tryAcquire(int arg),该方法在内部类Sync中实现:)

    protected final boolean tryAcquire(int acquires) {
            Thread current = Thread.currentThread();
            //当前锁个数
            int c = getState();
            //写锁
            int w = exclusiveCount(c);
            if (c != 0) {
                //c != 0 && w == 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;
        }

      该方法和ReentrantLock的tryAcquire(int arg)大致一样,在判断重入时增加了一项条件:读锁是否存在。因为要确保写锁的操作对读锁是可见的,如果在存在读锁的情况下允许获取写锁,那么那些已经获取读锁的其他线程可能就无法感知当前写线程的操作。因此只有等读锁完全释放后,写锁才能够被当前线程所获取,一旦写锁获取了,所有其他读、写线程均会被阻塞。

    写锁的释放(获取了写锁用完了则需要释放,WriteLock提供了unlock()方法释放写锁)

        public void unlock() {
            sync.release(1);
        }
    
        public final boolean release(int arg) {
            if (tryRelease(arg)) {
                Node h = head;
                if (h != null && h.waitStatus != 0)
                    unparkSuccessor(h);
                return true;
            }
            return false;
        }

      写锁的释放最终还是会调用AQS的模板方法release(int arg)方法,该方法首先调用tryRelease(int arg)方法尝试释放锁,tryRelease(int arg)方法为读写锁内部类Sync中定义了,如下:

        protected final boolean tryRelease(int releases) {
            //释放的线程不为锁的持有者
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            int nextc = getState() - releases;
            //若写锁的新线程数为0,则将锁的持有者设置为null
            boolean free = exclusiveCount(nextc) == 0;
            if (free)
                setExclusiveOwnerThread(null);
            setState(nextc);
            return free;
        }

      写锁释放锁的整个过程和独占锁ReentrantLock相似,每次释放均是减少写状态,当写状态为0时表示 写锁已经完全释放了,从而等待的其他线程可以继续访问读写锁,获取同步状态,同时此次写线程的修改对后续的线程可见。

    读锁(读锁为一个可重入的共享锁,它能够被多个线程同时持有,在没有其他写线程访问时,读锁总是或获取成功)

    读锁的获取(读锁的获取可以通过ReadLock的lock()方法)

            public void lock() {
                sync.acquireShared(1);
            }

      Sync的acquireShared(int arg)定义在AQS中:

        public final void acquireShared(int arg) {
            if (tryAcquireShared(arg) < 0)
                doAcquireShared(arg);
        }

      tryAcqurireShared(int arg)尝试获取读同步状态,该方法主要用于获取共享式同步状态,获取成功返回 >= 0的返回结果,否则返回 < 0 的返回结果。

        protected final int tryAcquireShared(int unused) {
            //当前线程
            Thread current = Thread.currentThread();
            int c = getState();
            //exclusiveCount(c)计算写锁
            //如果存在写锁,且锁的持有者不是当前线程,直接返回-1
            //存在锁降级问题,后续阐述
            if (exclusiveCount(c) != 0 &&
                    getExclusiveOwnerThread() != current)
                return -1;
            //读锁
            int r = sharedCount(c);
    
            /*
             * readerShouldBlock():读锁是否需要等待(公平锁原则)
             * r < MAX_COUNT:持有线程小于最大数(65535)
             * compareAndSetState(c, c + SHARED_UNIT):设置读取锁状态
             */
            if (!readerShouldBlock() &&
                    r < MAX_COUNT &&
                    compareAndSetState(c, c + SHARED_UNIT)) {
                /*
                 * holdCount部分后面讲解
                 */
                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);
        }

      读锁获取的过程相对于独占锁而言会稍微复杂下,整个过程如下:

    1. 因为存在锁降级情况,如果存在写锁且锁的持有者不是当前线程则直接返回失败,否则继续
    2. 依据公平性原则,判断读锁是否需要阻塞,读锁持有线程数小于最大值(65535),且设置锁状态成功,执行以下代码(对于HoldCounter下面再阐述),并返回1。如果不满足改条件,执行fullTryAcquireShared()。
      final int fullTryAcquireShared(Thread current) {
            HoldCounter rh = null;
            for (;;) {
                int c = getState();
                //锁降级
                if (exclusiveCount(c) != 0) {
                    if (getExclusiveOwnerThread() != current)
                        return -1;
                }
                //读锁需要阻塞
                else if (readerShouldBlock()) {
                    //列头为当前线程
                    if (firstReader == current) {
                    }
                    //HoldCounter后面讲解
                    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设置读锁成功
                if (compareAndSetState(c, c + SHARED_UNIT)) {
                    //如果是第1次获取“读取锁”,则更新firstReader和firstReaderHoldCount
                    if (sharedCount(c) == 0) {
                        firstReader = current;
                        firstReaderHoldCount = 1;
                    }
                    //如果想要获取锁的线程(current)是第1个获取锁(firstReader)的线程,则将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;
                }
            }
        }

      fullTryAcquireShared(Thread current)会根据“是否需要阻塞等待”,“读取锁的共享计数是否超过限制”等等进行处理。如果不需要阻塞等待,并且锁的共享计数没有超过限制,则通过CAS尝试获取锁,并返回1

    读锁的释放(与写锁相同,读锁也提供了unlock()释放读锁)

            public void unlock() {
                sync.releaseShared(1);
            }

      unlcok()方法内部使用Sync的releaseShared(int arg)方法,该方法定义在AQS中:

        public final boolean releaseShared(int arg) {
            if (tryReleaseShared(arg)) {
                doReleaseShared();
                return true;
            }
            return false;
        }

      调用tryReleaseShared(int arg)尝试释放读锁,该方法定义在读写锁的Sync内部类中:

       protected final boolean tryReleaseShared(int unused) {
            Thread current = Thread.currentThread();
            //如果想要释放锁的线程为第一个获取锁的线程
            if (firstReader == current) {
                //仅获取了一次,则需要将firstReader 设置null,否则 firstReaderHoldCount - 1
                if (firstReaderHoldCount == 1)
                    firstReader = null;
                else
                    firstReaderHoldCount--;
            }
            //获取rh对象,并更新“当前线程获取锁的信息”
            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;
            }
            //CAS更新同步状态
            for (;;) {
                int c = getState();
                int nextc = c - SHARED_UNIT;
                if (compareAndSetState(c, nextc))
                    return nextc == 0;
            }
        }

    锁降级

      锁降级:从写锁变成读锁; 

      锁升级:从读锁变成写锁。 

      读锁是可以被多线程共享的,写锁是单线程独占的。也就是说写锁的并发限制比读锁高,这可能就是升级/降级名称的来源。

      如下代码会产生死锁,因为同一个线程中,在没有释放读锁的情况下,就去申请写锁,这属于锁升级,ReentrantReadWriteLock是不支持的。

     ReadWriteLock rtLock = new ReentrantReadWriteLock();
     rtLock.readLock().lock();
     System.out.println("get readLock.");
     rtLock.writeLock().lock();
     System.out.println("blocking");

      ReentrantReadWriteLock支持锁降级,如下代码不会产生死锁。

    ReadWriteLock rtLock = new ReentrantReadWriteLock();
    rtLock.writeLock().lock();
    System.out.println("writeLock");
    
    rtLock.readLock().lock();
    System.out.println("get read lock");

      以上这段代码虽然不会导致死锁,但没有正确的释放锁。从写锁降级成读锁,并不会自动释放当前线程获取的写锁,仍然需要显示的释放,否则别的线程永远也获取不到写锁。锁降级就意味着写锁是可以降级为读锁的,但是需要遵循先获取写锁、获取读锁在释放写锁的次序。注意如果当前线程先获取写锁,然后释放写锁,再获取读锁这个过程不能称之为锁降级,锁降级一定要遵循那个次序。

      锁降级中读锁的获取释放为必要?肯定是必要的。试想,假如当前线程A不获取读锁而是直接释放了写锁,这个时候另外一个线程B获取了写锁,那么这个线程B对数据的修改是不会对当前线程A可见的。如果获取了读锁,则线程B在获取写锁过程中判断如果有读锁还没有释放则会被阻塞,只有当前线程A释放读锁后,线程B才会获取写锁成功。

    读写锁例子

    public class ReadWriteLockTest {
        public static void main(String[] args) {
            final Queue3 q3 = new Queue3();
            for(int i=0;i<3;i++)
            {
                new Thread(){
                    public void run(){
                        while(true){
                            q3.get();                        
                        }
                    }
                }.start();
            }
            for(int i=0;i<3;i++)
            {        
                new Thread(){
                    public void run(){
                        while(true){
                            q3.put(new Random().nextInt(10000));
                        }
                    }            
                    
                }.start();    
            }
        }
    }
    class Queue3{
        private Object data = null;//共享数据,只能有一个线程能写该数据,但可以有多个线程同时读该数据。
        private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
        public void get(){
                System.out.println(Thread.currentThread().getName() + " be to read data!");
                try {
                    Thread.sleep((long)(Math.random()*1000));
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread().getName() + "have read data :" + data);        
        }
        public void put(Object data){
            rwl.writeLock().lock();//上写锁,不允许其他线程读也不允许写
            try {
                System.out.println(Thread.currentThread().getName() + " be to write data!");                    
                try {
                    Thread.sleep((long)(Math.random()*1000));
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                this.data = data;        
                System.out.println(Thread.currentThread().getName() + " have write data: " + data);                    
            } finally {
                rwl.writeLock().unlock();//释放写锁    
            }
        }
    }
    Thread-0 be ready to read data!
    Thread-1 be ready to read data!
    Thread-2 be ready to read data!
    Thread-0have read data :null
    Thread-2have read data :null
    Thread-1have read data :null
    Thread-5 be ready to write data!
    Thread-5 have write data: 6934
    Thread-5 be ready to write data!
    Thread-5 have write data: 8987
    Thread-5 be ready to write data!
    Thread-5 have write data: 8496

    使用读写锁模拟一个缓存器:

    import java.util.HashMap;
    import java.util.Map;
    import java.util.concurrent.locks.ReadWriteLock;
    import java.util.concurrent.locks.ReentrantReadWriteLock;
    
    public class CacheDemo {
        /**
         * 缓存器,这里假设需要存储1000左右个缓存对象,按照默认的负载因子0.75,则容量=750,大概估计每一个节点链表长度为5个
         * 那么数组长度大概为:150,又有雨设置map大小一般为2的指数,则最近的数字为:128
         */
        private Map<String, Object> map = new HashMap<>(128);
        private ReadWriteLock rwl = new ReentrantReadWriteLock();
        public static void main(String[] args) {
    
        }
        public Object get(String id){
            Object value = null;
            rwl.readLock().lock();//首先开启读锁,从缓存中去取
            try{
                value = map.get(id);
                if(value == null){  //如果缓存中没有释放读锁,上写锁
                    rwl.readLock().unlock();
                    rwl.writeLock().lock();
                    try{
                        if(value == null){ //防止多写线程重复查询赋值
                            value = "redis-value";  //此时可以去数据库中查找,这里简单的模拟一下
                        }
                        rwl.readLock().lock(); //加读锁降级写锁,不明白的可以查看上面锁降级的原理与保持读取数据原子性的讲解
                    }finally{
                        rwl.writeLock().unlock(); //释放写锁
                    }
                }
            }finally{
                rwl.readLock().unlock(); //最后释放读锁
            }
            return value;
        }
    }
  • 相关阅读:
    MySQL 优化实施方案
    MySQL Replication 主从复制全方位解决方案
    CentOS 7.X 系统安装及优化
    W25Q32的使用
    Word分栏
    转载:STM32之中断与事件---中断与事件的区别
    常见贴片电阻的分类、功率、封装、标注规则
    导线时延
    重装系统流程
    MFC应用程序向导生成的文件
  • 原文地址:https://www.cnblogs.com/chihirotan/p/8521257.html
Copyright © 2011-2022 走看看