文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Java实现读写锁的原理是什么

2023-06-29 16:15

关注

本文小编为大家详细介绍“Java实现读写锁的原理是什么”,内容详细,步骤清晰,细节处理妥当,希望这篇“Java实现读写锁的原理是什么”文章能帮助大家解决疑惑,下面跟着小编的思路慢慢深入,一起来学习新知识吧。

读/写锁Java实现

首先我们总结一下获取资源读写权限的条件:

读取权限,如果没有线程在写,并且没有线程请求写访问。

写访问,如果没有线程正在读取或写入。

如果一个线程想要读取资源,只要没有线程正在写入,并且没有线程请求对该资源的写访问,就可以了。通过提高写访问请求的优先级,我们假设写请求比读请求更重要。此外,如果读取是最常发生的事情,并且我们没有提高写入的优先级,则可能会发生饥饿。请求写访问的线程将被阻止,直到所有读者都解锁了ReadWriteLock. 如果新线程不断被授予读访问权限,则等待写访问权限的线程将无限期地保持阻塞,从而导致饥饿。因此,如果当前没有线程锁定线程,则只能授予线程读取访问权限ReadWriteLock写作,或要求锁定写作。

可以授予想要对资源进行写访问的线程,因此当没有线程正在读取或写入资源时。有多少线程请求写访问或按什么顺序都没有关系,除非您想保证请求写访问的线程之间的公平性。

考虑到这些简单的规则,我们可以实现ReadWriteLock如下所示:

公共类读写锁{  私人 int 读者 = 0;  私人 int 作家 = 0;  私人 int writeRequests = 0;  公共同步 void lockRead() 抛出 InterruptedException{    而(作家> 0 || writeRequests > 0){      等待();    }    读者++;  }  公共同步无效解锁读取(){    读者——;    通知所有();  }  公共同步 void lockWrite() 抛出 InterruptedException{    写请求++;    而(读者> 0 ||作家> 0){      等待();    }    写请求——;    作家++;  }  公共同步 void unlockWrite() 抛出 InterruptedException{    作家——;    通知所有();  }}

有ReadWriteLock两种锁定方法和两种解锁方法。一种用于读取访问的锁定和解锁方法,一种用于写入访问的锁定和解锁方法。

读取访问的规则在该lockRead()方法中实现。所有线程都获得读访问权限,除非有一个线程具有写访问权限,或者一个或多个线程请求了写访问权限。

写访问的规则在lockWrite()方法中实现。想要写访问的线程从请求写访问开始(writeRequests++)。然后它将检查它是否真的可以获得写访问权限。如果没有对资源具有读访问权限的线程,并且没有对资源具有写访问权限的线程,则线程可以获得写访问权限。有多少线程请求写访问并不重要。

值得注意的是,两者都是unlockRead()andunlockWrite()调用 notifyAll()而不是notify(). 要解释为什么会这样,请想象以下情况:

在 ReadWriteLock 内部有等待读访问的线程和等待写访问的线程。如果被唤醒的线程notify()是读访问线程,它将被放回等待,因为有线程在等待写访问。但是,没有一个等待写访问的线程被唤醒,所以没有更多的事情发生。没有线程既不能读也不能写。通过调用noftifyAll()唤醒所有等待的线程并检查它们是否可以获得所需的访问权限。

打电话notifyAll()还有另一个好处。如果多个线程正在等待读取访问,而没有一个线程正在等待写入访问,并且unlockWrite()被调用,则所有等待读取访问的线程都被立即授予读取访问权限 - 而不是一个接一个。

读/写锁重入

前面显示的ReadWriteLock类是不可重入的。如果一个具有写访问权限的线程再次请求它,它将阻塞,因为已经有一个写者——它自己。此外,考虑这种情况:

线程 1 获得读取权限。

线程 2 请求写访问,但由于只有一个读取器而被阻止。

线程1重新请求读访问(重新入锁),但是因为有写请求而被阻塞

在这种情况下,前一个ReadWriteLock会锁定 - 类似于死锁的情况。不会授予既不请求读取也不请求写入访问的线程。

要使ReadWriteLock可重入,有必要进行一些更改。读者和作者的重入将分别处理。

读取重入

为了让ReadWriteLock读者可以重入,我们首先要建立阅读重入的规则:

如果线程可以获得读取访问权限(没有写入者或写入请求),或者如果它已经具有读取访问权限(无论写入请求如何),它就会被授予读取重入权限。

为了确定一个线程是否已经具有读访问权限,对每个被授予读访问权限的线程的引用以及它获得读锁的次数都保存在 Map 中。在确定是否可以授予读取访问权限时,将检查此 Map 是否对调用线程的引用。以下是更改后lockRead()andunlockRead()方法的外观:

公共类读写锁{  私有 Map<Thread, Integer> readingThreads =      新的 HashMap<Thread, Integer>();  私人 int 作家 = 0;  私人 int writeRequests = 0;  公共同步 void lockRead() 抛出 InterruptedException{    线程调用Thread = Thread.currentThread();    而(!canGrantReadAccess(调用线程)){      等待();                                                                       }    readingThreads.put(调用线程,       (getAccessCount(callingThread) + 1));  }  公共同步无效解锁读取(){    线程调用Thread = Thread.currentThread();    int accessCount = getAccessCount(callingThread);    if(accessCount == 1){ readingThreads.remove(callingThread); }    否则 { readingThreads.put(callingThread, (accessCount -1)); }    通知所有();  }  私有布尔canGrantReadAccess(线程调用线程){    如果(作家> 0)返回假;    如果(isReader(调用线程)返回真;    如果(writeRequests > 0)返回假;    返回真;  }  私有 int getReadAccessCount(线程调用线程){    整数 accessCount = readingThreads.get(callingThread);    if(accessCount == null) 返回 0;    返回 accessCount.intValue();  }  私有布尔 isReader(线程调用线程){    返回阅读Threads.get(callingThread) != null;  }}

如您所见,仅当当前没有线程写入资源时才授予读取重入。此外,如果调用线程已经具有读取访问权限,则这优先于任何 writeRequests。

写重入

仅当线程已经具有写访问权限时才授予写重入。以下是更改后的lockWrite()andunlockWrite()方法:

公共类读写锁{    私有 Map<Thread, Integer> readingThreads =        新的 HashMap<Thread, Integer>();    私有 int writeAccesses = 0;    私人 int writeRequests = 0;    私有线程写作Thread = null;  公共同步 void lockWrite() 抛出 InterruptedException{    写请求++;    线程调用Thread = Thread.currentThread();    而(!canGrantWriteAccess(调用线程)){      等待();    }    写请求——;    写访问++;    写线程 = 调用线程;  }  公共同步 void unlockWrite() 抛出 InterruptedException{    写访问——;    如果(writeAccesses == 0){      写线程=空;    }    通知所有();  }  私有布尔canGrantWriteAccess(线程调用线程){    如果(hasReaders())返回假;    if(writingThread == null) 返回真;    if(!isWriter(callingThread)) 返回假;    返回真;  }  私有布尔 hasReaders(){    返回读数Threads.size() > 0;  }  私有布尔 isWriter(线程调用线程){    返回写线程 == 调用线程;  }}

请注意,在确定调用线程是否可以获得写访问权时,现在如何考虑当前持有写锁的线程。

读写重入

有时,具有读访问权限的线程也需要获得写访问权限。为此,线程必须是唯一的读者。为了实现这一点,writeLock()应该稍微改变方法。这是它的样子:

公共类读写锁{    私有 Map<Thread, Integer> readingThreads =        新的 HashMap<Thread, Integer>();    私有 int writeAccesses = 0;    私人 int writeRequests = 0;    私有线程写作Thread = null;  公共同步 void lockWrite() 抛出 InterruptedException{    写请求++;    线程调用Thread = Thread.currentThread();    而(!canGrantWriteAccess(调用线程)){      等待();    }    写请求——;    写访问++;    写线程 = 调用线程;  }  公共同步 void unlockWrite() 抛出 InterruptedException{    写访问——;    如果(writeAccesses == 0){      写线程=空;    }    通知所有();  }  私有布尔canGrantWriteAccess(线程调用线程){    if(isOnlyReader(callingThread)) 返回真;    如果(hasReaders())返回假;    if(writingThread == null) 返回真;    if(!isWriter(callingThread)) 返回假;    返回真;  }  私有布尔 hasReaders(){    返回读数Threads.size() > 0;  }  私有布尔 isWriter(线程调用线程){    返回写线程 == 调用线程;  }  私有布尔 isOnlyReader(线程线程){      返回读数Threads.size() == 1 &&             readingThreads.get(callingThread) != null;      } }

现在ReadWriteLock该类是读写访问可重入的。

写读重入

有时,具有写访问权限的线程也需要读访问权限。如果请求,应始终授予写入者读取访问权限。如果一个线程有写访问权限,其他线程就不能有读或写访问权限,所以它并不危险。以下是该 canGrantReadAccess()方法在更改后的外观:

公共类读写锁{    私有布尔canGrantReadAccess(线程调用线程){      if(isWriter(callingThread)) 返回真;      如果(写线程!= null)返回false;      如果(isReader(调用线程)返回真;      如果(writeRequests > 0)返回假;      返回真;    }}

完全可重入读写锁

下面是完全可重入的ReadWriteLock实现。我对访问条件进行了一些重构,以使它们更易于阅读,从而更容易说服自己它们是正确的。

公共类读写锁{  私有 Map<Thread, Integer> readingThreads =       新的 HashMap<Thread, Integer>();   私有 int writeAccesses = 0;   私人 int writeRequests = 0;   私有线程写作Thread = null;  公共同步 void lockRead() 抛出 InterruptedException{    线程调用Thread = Thread.currentThread();    而(!canGrantReadAccess(调用线程)){      等待();    }    readingThreads.put(调用线程,     (getReadAccessCount(callingThread) + 1));  }  私有布尔canGrantReadAccess(线程调用线程){    if( isWriter(callingThread) ) 返回真;    if( hasWriter() ) 返回假;    if( isReader(callingThread) ) 返回真;    if( hasWriteRequests() ) 返回假;    返回真;  }  公共同步无效解锁读取(){    线程调用Thread = Thread.currentThread();    如果(!isReader(调用线程)){      throw new IllegalMonitorStateException("调用线程没有" +        " 持有此 ReadWriteLock 的读锁");    }    int accessCount = getReadAccessCount(callingThread);    if(accessCount == 1){ readingThreads.remove(callingThread); }    否则 { readingThreads.put(callingThread, (accessCount -1)); }    通知所有();  }  公共同步 void lockWrite() 抛出 InterruptedException{    写请求++;    线程调用Thread = Thread.currentThread();    而(!canGrantWriteAccess(调用线程)){      等待();    }    写请求——;    写访问++;    写线程 = 调用线程;  }  公共同步 void unlockWrite() 抛出 InterruptedException{    if(!isWriter(Thread.currentThread()){      throw new IllegalMonitorStateException("调用线程没有" +        " 持有这个 ReadWriteLock 的写锁");    }    写访问——;    如果(writeAccesses == 0){      写线程=空;    }    通知所有();  }  私有布尔canGrantWriteAccess(线程调用线程){    if(isOnlyReader(callingThread)) 返回真;    如果(hasReaders())返回假;    if(writingThread == null) 返回真;    if(!isWriter(callingThread)) 返回假;    返回真;  }  私有 int getReadAccessCount(线程调用线程){    整数 accessCount = readingThreads.get(callingThread);    if(accessCount == null) 返回 0;    返回 accessCount.intValue();  }  私有布尔 hasReaders(){    返回读数Threads.size() > 0;  }  私有布尔 isReader(线程调用线程){    返回阅读Threads.get(callingThread) != null;  }  私有布尔 isOnlyReader(线程调用线程){    返回读数Threads.size() == 1 &&           readingThreads.get(callingThread) != null;  }  私有布尔 hasWriter(){    返回写作线程!= null;  }  私有布尔 isWriter(线程调用线程){    返回写线程 == 调用线程;  }  私有布尔 hasWriteRequests(){      返回 this.writeRequests > 0;  }}

从 finally 子句调用 unlock()

当用 保护临界区时ReadWriteLock,临界区可能会抛出异常,从 - 子句内部调用readUnlock()和writeUnlock()方法很重要finally。这样做可以确保ReadWriteLock已解锁,以便其他线程可以锁定它。这是一个例子:

lock.lockWrite();尝试{  //做临界区代码,可能会抛出异常} 最后 {  lock.unlockWrite();}

这个小结构确保ReadWriteLock在关键部分的代码抛出异常的情况下解锁。如果unlockWrite() 没有从 - 子句内部调用finally,并且从临界区抛出异常,ReadWriteLock则将永远保持写锁定,导致调用该实例的所有线程lockRead()或lockWrite()在该 ReadWriteLock实例上无限期停止。唯一可以解锁的ReadWriteLock方法是如果 ReadWriteLock是可重入的,并且在抛出异常时锁定它的线程后来成功锁定它,执行关键部分并unlockWrite() 随后再次调用。那将ReadWriteLock再次解锁。但为什么要等到这种情况发生,如果它发生了吗?unlockWrite()从 -子句调用finally是一个更健壮的解决方案。

读到这里,这篇“Java实现读写锁的原理是什么”文章已经介绍完毕,想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会,如果想了解更多相关内容的文章,欢迎关注编程网行业资讯频道。

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯