java多线程-读写锁原理_java

Java5 在 java.util.concurrent 包中已经包含了读写锁。尽管如此，我们还是应该了解其实现背后的原理。

  1. 读/写锁的 Java 实现(Read / Write Lock Java Implementation)
  2. 读/写锁的重入(Read / Write Lock Reentrance)
  3. 读锁重入(Read Reentrance)
  4. 写锁重入(Write Reentrance)
  5. 读锁升级到写锁(Read to Write Reentrance)
  6. 写锁降级到读锁(Write to Read Reentrance)
  7. 可重入的 ReadWriteLock 的完整实现(Fully Reentrant ReadWriteLock)
  8. 在 finally 中调用 unlock() (Calling unlock() from a finally-clause)

读/写锁的 Java 实现

先让我们对读写访问资源的条件做个概述：

读取 没有线程正在做写操作，且没有线程在请求写操作。

写入 没有线程正在做读写操作。

如果某个线程想要读取资源，只要没有线程正在对该资源进行写操作且没有线程请求对该资源的写操作即可。我们假设对写操作的请求比对读操作的请求更重要，就要提升写请求的优先级。此外，如果读操作发生的比较频繁，我们又没有提升写操作的优先级，那么就会产生“饥饿”现象。请求写操作的线程会一直阻塞，直到所有的读线程都从 ReadWriteLock 上解锁了。如果一直保证新线程的读操作权限，那么等待写操作的线程就会一直阻塞下去，结果就是发生“饥饿”。因此，只有当没有线程正在锁住 ReadWriteLock 进行写操作，且没有线程请求该锁准备执行写操作时，才能保证读操作继续。

当其它线程没有对共享资源进行读操作或者写操作时，某个线程就有可能获得该共享资源的写锁，进而对共享资源进行写操作。有多少线程请求了写锁以及以何种顺序请求写锁并不重要，除非你想保证写锁请求的公平性。

按照上面的叙述，简单的实现出一个读/写锁，代码如下

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();
 }
}

ReadWriteLock 类中，读锁和写锁各有一个获取锁和释放锁的方法。

读锁的实现在 lockRead()中,只要没有线程拥有写锁（writers==0），且没有线程在请求写锁（writeRequests ==0），所有想获得读锁的线程都能成功获取。

写锁的实现在 lockWrite()中,当一个线程想获得写锁的时候，首先会把写锁请求数加 1（writeRequests++），然后再去判断是否能够真能获得写锁，当没有线程持有读锁（readers==0 ）,且没有线程持有写锁（writers==0）时就能获得写锁。有多少线程在请求写锁并无关系。

需要注意的是，在两个释放锁的方法（unlockRead，unlockWrite）中，都调用了 notifyAll 方法，而不是 notify。要解释这个原因，我们可以想象下面一种情形：

如果有线程在等待获取读锁，同时又有线程在等待获取写锁。如果这时其中一个等待读锁的线程被 notify 方法唤醒，但因为此时仍有请求写锁的线程存在（writeRequests>0），所以被唤醒的线程会再次进入阻塞状态。然而，等待写锁的线程一个也没被唤醒，就像什么也没发生过一样（译者注：信号丢失现象）。如果用的是 notifyAll 方法，所有的线程都会被唤醒，然后判断能否获得其请求的锁。

用 notifyAll 还有一个好处。如果有多个读线程在等待读锁且没有线程在等待写锁时，调用 unlockWrite()后，所有等待读锁的线程都能立马成功获取读锁 —— 而不是一次只允许一个。

读/写锁的重入

上面实现的读/写锁(ReadWriteLock) 是不可重入的，当一个已经持有写锁的线程再次请求写锁时，就会被阻塞。原因是已经有一个写线程了——就是它自己。此外，考虑下面的例子：

  1. Thread 1 获得了读锁。
  2. Thread 2 请求写锁，但因为 Thread 1 持有了读锁，所以写锁请求被阻塞。
  3. Thread 1 再想请求一次读锁，但因为 Thread 2 处于请求写锁的状态，所以想再次获取读锁也会被阻塞。 上面这种情形使用前面的 ReadWriteLock 就会被锁定——一种类似于死锁的情形。不会再有线程能够成功获取读锁或写锁了。

为了让 ReadWriteLock 可重入，需要对它做一些改进。下面会分别处理读锁的重入和写锁的重入。

读锁重入

为了让 ReadWriteLock 的读锁可重入，我们要先为读锁重入建立规则：

要保证某个线程中的读锁可重入，要么满足获取读锁的条件（没有写或写请求），要么已经持有读锁（不管是否有写请求）。 要确定一个线程是否已经持有读锁，可以用一个 map 来存储已经持有读锁的线程以及对应线程获取读锁的次数，当需要判断某个线程能否获得读锁时，就利用 map 中存储的数据进行判断。下面是方法 lockRead 和 unlockRead 修改后的的代码：

public class ReadWriteLock{
 private Map<Thread, Integer> readingThreads =
  new HashMap<Thread, Integer>();

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

代码中我们可以看到，只有在没有线程拥有写锁的情况下才允许读锁的重入。此外，重入的读锁比写锁优先级高。

写锁重入

仅当一个线程已经持有写锁，才允许写锁重入（再次获得写锁）。下面是方法 lockWrite 和 unlockWrite 修改后的的代码。

public class ReadWriteLock{
 private Map<Thread, Integer> readingThreads =
  new HashMap<Thread, Integer>();

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

注意在确定当前线程是否能够获取写锁的时候，是如何处理的。

读锁升级到写锁

有时，我们希望一个拥有读锁的线程，也能获得写锁。想要允许这样的操作，要求这个线程是唯一一个拥有读锁的线程。writeLock()需要做点改动来达到这个目的：

public class ReadWriteLock{
 private Map<Thread, Integer> readingThreads =
  new HashMap<Thread, Integer>();

 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(isOnlyReader(callingThread)) return true;
  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;
 }

 private boolean isOnlyReader(Thread thread){
  return readers == 1 && readingThreads.get(callingThread) != null;
 }
}

现在 ReadWriteLock 类就可以从读锁升级到写锁了。

写锁降级到读锁

有时拥有写锁的线程也希望得到读锁。如果一个线程拥有了写锁，那么自然其它线程是不可能拥有读锁或写锁了。所以对于一个拥有写锁的线程，再获得读锁，是不会有什么危险的。我们仅仅需要对上面 canGrantReadAccess 方法进行简单地修改：

public class ReadWriteLock{
 private boolean canGrantReadAccess(Thread callingThread){
  if(isWriter(callingThread)) return true;
  if(writingThread != null) return false;
  if(isReader(callingThread) return true;
  if(writeRequests > 0) return false;
  return true;
 }
}

可重入的 ReadWriteLock 的完整实现

下面是完整的 ReadWriteLock 实现。为了便于代码的阅读与理解，简单对上面的代码做了重构。重构后的代码如下。

public class ReadWriteLock{
 private Map<Thread, Integer> readingThreads =
  new HashMap<Thread, Integer>();

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

在 finally 中调用 unlock()

在利用 ReadWriteLock 来保护临界区时，如果临界区可能抛出异常，在 finally 块中调用 readUnlock()和 writeUnlock()就显得很重要了。这样做是为了保证 ReadWriteLock 能被成功解锁，然后其它线程可以请求到该锁。这里有个例子：

lock.lockWrite();
try{
 //do critical section code, which may throw exception
} finally {
 lock.unlockWrite();
}

上面这样的代码结构能够保证临界区中抛出异常时 ReadWriteLock 也会被释放。如果 unlockWrite 方法不是在 finally 块中调用的，当临界区抛出了异常时，ReadWriteLock 会一直保持在写锁定状态，就会导致所有调用 lockRead()或 lockWrite()的线程一直阻塞。唯一能够重新解锁 ReadWriteLock 的因素可能就是 ReadWriteLock 是可重入的，当抛出异常时，这个线程后续还可以成功获取这把锁，然后执行临界区以及再次调用 unlockWrite()，这就会再次释放 ReadWriteLock。但是如果该线程后续不再获取这把锁了呢？所以，在 finally 中调用 unlockWrite 对写出健壮代码是很重要的。

 以上就是对java  多线程的资料整理，后续继续补充相关资料，谢谢大家对本站的支持！

以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索java
， 多线程
， java多线程
多线程详解
java多线程读写锁、java 读写锁 原理、多线程 读写锁、linux 多线程 读写锁、java多线程原理，以便于您获取更多的相关知识。

时间： 2024-09-15 18:21:38

java多线程-读写锁原理_java的相关文章

asp.net 多线程读写锁代码

c#中使用多线程同步是一个头痛的问题,比较经常用的是lock(object){}这种方法,但是这种方法在读多写少的时候比较浪费资源,当然c#也提供了一种读写锁,我这里只是提供一个原创读写锁的类的源代码,该类的主要目的是允许多个线程同时读,而仅允许一个线程写,而用lock是不论读写都只能一个线程运行的 有兴趣的可以看看讨论讨论,以下是源代码:     public sealed class MutilThreadReadWriterLock : IReadWriteLock,IDisposable

Java 多线程学习详细总结_java

目录(?)[-] 一扩展javalangThread类 二实现javalangRunnable接口 三Thread和Runnable的区别 四线程状态转换 五线程调度 六常用函数说明 使用方式 为什么要用join方法 七常见线程名词解释 八线程同步 九线程数据传递      本文主要讲了java中多线程的使用方法.线程同步.线程数据传递.线程状态及相应的一些线程函数用法.概述等. 首先讲一下进程和线程的区别: 进程:每个进程都有独立的代码和数据空间(进程上下文),进程间的切换会有较大的开销,一个

Java实现排队论的原理_java

引入: 前段时间去银行办业务,排队的人那是真多,自己正式办理业务也就不到5分钟,但是却足足等了两个小时(相信很多人都遇到过这种情况),对这种服务水平真的是无语了,但是问题又来了,银行应该开几个窗口,既能保证整体的服务质量,又能保证资源资源的利用率呢?下面我们就通过排队论来模拟这个问题. 排队论简介       排队论是研究系统随机聚散现象和随机系统工作工程的数学理论和方法,又称随机服务系统理论,为运筹学的一个分支.我们下面对排队论做下简化处理,先看下图:       我们在图的左侧安排若干个蓝色

理解java多线程中ExecutorService使用_java

java.util.concurrent包里提供了关于多线程操作的类,平常用的比较多的是ExecutorService及其实现类(如ThreadPoolExecutor等),Executor,Executors,Future,Callable等 1. ExecutorService(继承自Executor)接口:提供了一些异步的多线程操作方法,如execute(), submit(), shutdown(), shutdownNow()等 2. Executor接口:执行提交的任务(线程),只有

Java多线程实现同时输出_java

一道经典的面试题目:两个线程,分别打印AB,其中线程A打印A,线程B打印B,各打印10次,使之出现ABABABABA.. 的效果 package com.shangshe.path; public class ThreadAB { /** * @param args */ public static void main(String[] args) { final Print business = new Print(); new Thread(new Runnable() { public v

Java 多线程使用要点分析_java

多线程细节问题 sleep方法和wait方法的异同点? 相同点: 让线程处于冻结状态. 不同点: sleep必须指定时间 wait可以指定时间也可以不指定时间 sleep时间到,线程处于临时阻塞状态或者运行态 wait如果没有时间,必须通过notify或者notifyAll唤醒 sleep不一定非要定义在同步中 wait必须定义在同步中 都定义在同步中时 sleep放执行权,不放锁 wait放执行权,放锁 syschronized(obj) { wait();// 0 1 2 code... }

Java HashMap的工作原理_java

大部分Java开发者都在使用Map,特别是HashMap.HashMap是一种简单但强大的方式去存储和获取数据.但有多少开发者知道HashMap内部如何工作呢?几天前,我阅读了java.util.HashMap的大量源代码(包括Java 7 和Java 8),来深入理解这个基础的数据结构.在这篇文章中,我会解释java.util.HashMap的实现,描述Java 8实现中添加的新特性,并讨论性能.内存以及使用HashMap时的一些已知问题. 内部存储 Java HashMap类实现了Map<K

深入了解Java GC的工作原理_java

JVM学习笔记之JVM内存管理和JVM垃圾回收的概念,JVM内存结构由堆.栈.本地方法栈.方法区等部分组成,另外JVM分别对新生代下载地址  和旧生代采用不同的垃圾回收机制. 首先来看一下JVM内存结构,它是由堆.栈.本地方法栈.方法区等部分组成,结构图如下所示. JVM学习笔记 JVM内存管理和JVM垃圾回收 JVM内存组成结构 JVM内存结构由堆.栈.本地方法栈.方法区等部分组成,结构图如下所示:     1)堆 所有通过new创建的对象的内存都在堆中分配,其大小可以通过-Xmx和-Xms来

Java多线程yield心得分享_java

一. Thread.yield( )方法: 使当前线程从执行状态(运行状态)变为可执行态(就绪状态).cpu会从众多的可执行态里选择,也就是说,当前也就是刚刚的那个线程还是有可能会被再次执行到的,并不是说一定会执行其他线程而该线程在下一次中不会执行到了. Java线程中有一个Thread.yield( )方法,很多人翻译成线程让步.顾名思义,就是说当一个线程使用了这个方法之后,它就会把自己CPU执行的时间让掉,让自己或者其它的线程运行. 打个比方:现在有很多人在排队上厕所,好不容易轮到这个人上厕