适用场景
读操作频发,写操作不频繁。
两个线程同时读取同一个共享资源没有任何问题
如果一个线程对共享资源进行写操作,此时就不能有其他线程对共享资源进行读写
条件分析写操作的优先级高于读操作,在读操作频繁的场景下,如果写操作没有高于读操作的优先级,就会导致写操作线程“饿死”的情况发生
读操作触发条件:
没有线程正在执行写操作
没有线程在等待执行写操作
写操作触发条件:没有线程正在执行读写操作
代码实现
public class ReadWriteLock { private int readers = 0; private int writers = 0; private int writeRequests = 0; public synchronized void lockRead() throws InterruptedException { while (writers > 0 || writeRequests > 0) { wait(); } readers++; } public synchronized void unlockRead() { readers--; notifyAll(); } public synchronized void lockWrite() throws InterruptedException { writeRequests++; while (readers > 0 || writers > 0) { wait(); } writeRequests--; writers++; } public synchronized void unlockWrite() throws InterruptedException { writers--; notifyAll(); } } |
ReadWriteLockl类中通过读锁、写锁以两个锁的状态控制线程的读、写操作: writers表示当前正在使用写锁的线程数量; writeRequests表示等待请求写锁的线程数量; readers表示请求读锁的线程数量; 说明: 1.线程在获取读锁的时候,只要没有线程拥有写锁即writers==0同时没有线程请求写锁即writerRquests==0,那么线程就能成功获取读锁; 2.当一个线程想获取写锁的时候,会把写锁的请求数加1即writeRequests++,然后再尝试获取能否获取写锁,如果当前没有线程占用写锁即writers==0,那么此时就能成功获取写锁,同时writers++;如果wirters>0表示写锁此时被其他线程占用那么当前线程会被阻塞等待写锁释放时被唤醒。 3.写操作的优先级高于读操作的优先级体现在,线程请求读锁时会判断持有写锁的线程数和请求写锁的线程数,即while(writers > 0 || writeRequests > 0){wait();},而线程请求写锁时只需要判断持有写锁和读锁的线程数即可,即while(readers > 0 || writers > 0) {wait();} |
锁重入,是指同一线程 外层函数获得锁之后 ,内层递归函数仍然有获取该锁的代码,但不受影响。ReentrantLock 和synchronized 都是可重入锁,可重入锁最大的作用是避免死锁。
以自旋锁为例,如果自旋锁不是可重入锁的话,如果一个线程在第一次获取锁执行同步代码前提下,第二次再执行同步代码就产生了死锁。
以前面的代码为例:
此时有两个线程Thread1,Thread2
Thread2在Thread1获取读锁以后请求写锁,readers=1、writers=0、writeRequests=1
若此时Thread1再次尝试获取同一个读锁,根据已有的代码writers > 0 || writeRequests > 0,因为Thread请求写锁的原因导致该条件成立,Thread1进入阻塞状态,死锁出现
读锁重入public class ReadWriteLock{ private Map private int writers = 0; private int writeRequests = 0; public synchronized void lockRead() throws InterruptedException{ Thread callingThread = Thread.currentThread(); while(! canGrantReadAccess(callingThread)){ wait(); } readingThreads.put(callingThread, (getAccessCount(callingThread) + 1)); } public synchronized void unlockRead(){ Thread callingThread = Thread.currentThread(); int accessCount = getAccessCount(callingThread); if(accessCount == 1) { readingThreads.remove(callingThread); } else { readingThreads.put(callingThread, (accessCount -1)); } notifyAll(); } private boolean canGrantReadAccess(Thread callingThread){ if(writers > 0) return false; if(isReader(callingThread) return true; if(writeRequests > 0) return false; return true; } private int getReadAccessCount(Thread callingThread){ Integer accessCount = readingThreads.get(callingThread); if(accessCount == null) return 0; return accessCount.intValue(); } private boolean isReader(Thread callingThread){ return readingThreads.get(callingThread) != null; } } |
读锁的可重入有两种情况: 1.当前程序中没有线程请求写锁(这种情况是几乎不存在) 2.当前程序中有线程请求写锁也有线程请求读锁,并且有线程已经得到了读锁 第二种情况是最常见的,因此我们需要知道哪些线程是持有读锁的 因此在代码中使用Map来存储已经持有读锁的线程和对应线程获取读锁的次数,通过Map就可以判断对应的线程是否持有读锁,调整之后的代码在原有判断"writeRequests >0"和"writers > 0"还加上了判断当前线程是否持有读锁的判断逻辑 |
public class ReadWriteLock{ private Map private int writeAccesses = 0; private int writeRequests = 0; private Thread writingThread = null; public synchronized void lockWrite() throws InterruptedException{ writeRequests++; Thread callingThread = Thread.currentThread(); while(!canGrantWriteAccess(callingThread)){ wait(); } writeRequests--; writeAccesses++; writingThread = callingThread; } public synchronized void unlockWrite() throws InterruptedException{ writeAccesses--; if(writeAccesses == 0){ writingThread = null; } notifyAll(); } private boolean canGrantWriteAccess(Thread callingThread){ if(hasReaders()) return false; if(writingThread == null) return true; if(!isWriter(callingThread)) return false; return true; } private boolean hasReaders(){ return readingThreads.size() > 0; } private boolean isWriter(Thread callingThread){ return writingThread == callingThread; } } |
写锁重入,是在当前程序里有且只有一个线程持有写锁,如果写锁重入,说明当前程序中没有线程持有读锁,写锁重入只有持有写锁的线程才能重入,其他的线程就需要进入阻塞状态 |
public class ReadWriteLock{ private MapreadingThreads = new HashMap (); private int writeAccesses = 0; private int writeRequests = 0; private Thread writingThread = null; public synchronized void lockRead() throws InterruptedException{ Thread callingThread = Thread.currentThread(); while(! canGrantReadAccess(callingThread)){ wait(); } readingThreads.put(callingThread,(getReadAccessCount(callingThread) + 1)); } private boolean canGrantReadAccess(Thread callingThread){ #写锁降级到读锁的逻辑判断 if(isWriter(callingThread)) return true; if(hasWriter()) return false; if(isReader(callingThread)) return true; if(hasWriteRequests()) return false; return true; } public synchronized void unlockRead(){ Thread callingThread = Thread.currentThread(); if(!isReader(callingThread)){ throw new IllegalMonitorStateException( "Calling Thread does not" + " hold a read lock on this ReadWriteLock"); } int accessCount = getReadAccessCount(callingThread); if(accessCount == 1){ readingThreads.remove(callingThread); } else { readingThreads.put(callingThread, (accessCount -1)); } notifyAll(); } public synchronized void lockWrite() throws InterruptedException{ writeRequests++; Thread callingThread = Thread.currentThread(); while(!canGrantWriteAccess(callingThread)){ wait(); } writeRequests--; writeAccesses++; writingThread = callingThread; } public synchronized void unlockWrite() throws InterruptedException{ if(!isWriter(Thread.currentThread()){ throw new IllegalMonitorStateException( "Calling Thread does not" + " hold the write lock on this ReadWriteLock"); } writeAccesses--; if(writeAccesses == 0){ writingThread = null; } notifyAll(); } private boolean canGrantWriteAccess(Thread callingThread){ #读锁转换成写锁的逻辑判断 if(isOnlyReader(callingThread)) return true; if(hasReaders()) return false; if(writingThread == null) return true; if(!isWriter(callingThread)) return false; return true; } private int getReadAccessCount(Thread callingThread){ Integer accessCount = readingThreads.get(callingThread); if(accessCount == null) return 0; return accessCount.intValue(); } private boolean hasReaders(){ return readingThreads.size() > 0; } private boolean isReader(Thread callingThread){ return readingThreads.get(callingThread) != null; } private boolean isOnlyReader(Thread callingThread){ return readingThreads.size() == 1 && readingThreads.get(callingThread) != null; } private boolean hasWriter(){ return writingThread != null; } private boolean isWriter(Thread callingThread){ return writingThread == callingThread; } private boolean hasWriteRequests(){ return this.writeRequests > 0; } }
参考文献
http://ifeve.com/read-write-l...
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/71556.html
摘要:语言在之前,提供的唯一的并发原语就是管程,而且之后提供的并发包,也是以管程技术为基础的。但是管程更容易使用,所以选择了管程。线程进入条件变量的等待队列后,是允许其他线程进入管程的。并发编程里两大核心问题互斥和同步,都可以由管程来帮你解决。 并发编程这个技术领域已经发展了半个世纪了。有没有一种核心技术可以很方便地解决我们的并发问题呢?这个问题, 我会选择 Monitor(管程)技术。Ja...
摘要:此时线程和会再有一个线程能够获取写锁,假设是,如果不采用再次验证的方式,此时会再次查询数据库。而实际上线程已经把缓存的值设置好了,完全没有必要再次查询数据库。 大家知道了Java中使用管程同步原语,理论上可以解决所有的并发问题。那 Java SDK 并发包里为什么还有很多其他的工具类呢?原因很简单:分场景优化性能,提升易用性 今天我们就介绍一种非常普遍的并发场景:读多写少场景。实际工作...
摘要:公平锁非公平锁公平锁公平锁是指多个线程按照申请锁的顺序来获取锁。加锁后,任何其他试图再次加锁的线程会被阻塞,直到当前进程解锁。重量级锁会让其他申请的线程进入阻塞,性能降低。 Java 中15种锁的介绍 在读很多并发文章中,会提及各种各样锁如公平锁,乐观锁等等,这篇文章介绍各种锁的分类。介绍的内容如下: 公平锁 / 非公平锁 可重入锁 / 不可重入锁 独享锁 / 共享锁 互斥锁 / 读...
摘要:锁的使用建议减少锁持有时间减少锁粒度读写锁替代独占锁锁分离锁粗化减少锁的持有时间减少锁的持有时间有助于降低冲突的可能性进而提升并发能力减少锁粒度例如内部分为个加锁时不会像一样全局加锁只需要对相应加锁但是如果需要获取全局的信息比如首先会使用无 锁的使用建议 减少锁持有时间 减少锁粒度 读写锁替代独占锁 锁分离 锁粗化 减少锁的持有时间 减少锁的持有时间有助于降低冲突的可能性,进而...
阅读 1529·2021-09-22 15:52
阅读 3438·2021-09-22 14:59
阅读 2791·2021-09-02 15:12
阅读 929·2021-08-20 09:35
阅读 1545·2019-08-30 14:09
阅读 2690·2019-08-30 13:56
阅读 1562·2019-08-26 18:27
阅读 3345·2019-08-26 13:37