ReentrantReadWriteLock读写锁的使用2

本文可作为传智播客《张孝祥-Java多线程与并发库高级应用》的学习笔记。

这一节我们做一个缓存系统。

在读本节前

请先阅读

ReentrantReadWriteLock读写锁的使用1

第一版

public class CacheDemo {

    private Map<String, Object> cache = new HashMap<String, Object>();
    public static void main(String[] args) {
        CacheDemo cd = new CacheDemo();
        System.out.println("ss   "+cd.getData2("ss"));
        System.out.println("ss   "+cd.getData2("ss"));
        System.out.println("mm   "+cd.getData2("mm"));
        System.out.println("mm   "+cd.getData2("mm"));
    }

    public Object getData2(String key){
        Object o=cache.get(key);
        if (o==null) {        //标识1
            System.out.println("第一次查  没有"+key);
            o=Math.random();     //实际上从数据库中获得
            cache.put(key, o);
        }
        return o;
    }
}

运行结果:

第一次查  没有ss

ss   0.4045014284225158

ss   0.4045014284225158

第一次查  没有mm

mm   0.9994663041529088

mm   0.9994663041529088

似乎没有问题。

你觉得呢?

如果有三个线程同时第一次到了getData2()的标识1处(所查找的key也都一样),一检查o为null,然后就去查数据库。在这种情况下,就等于三个线程查同一个key,然后都去了数据库。

这显然是不合理的。

第二版 synchronized

最简单的办法

public synchronized Object getData2(String key){

//.....

}

第三版 锁

上一节我们提到了ReentrantLock可以替换synchronized,前者是一种更为面向对象的设计。那我们试试。

    private Lock l=new ReentrantLock(); //l作为CacheDemo的成员变量

    public Object getData3(String key) {
        l.lock();
        Object o=null;
        try {
            o = cache.get(key);
            if (o == null) { // 标识1
                System.out.println("第一次查  没有" + key);
                o = Math.random(); // 实际上从数据库中获得
                cache.put(key, o);
            }
        } finally {
            l.unlock();
        }
        return o;
    }

第三版可以吗?

可以个p。

为什么,自己想。

我们得使用ReentrantReadWriteLock,在同一个方法中既有读锁也有写锁。

首先我又一个问题:

对同一个线程,可以在加了读锁后,没有解开读锁前,再加写锁吗?

换句话说,下面的代码会停吗?

public class CacheDemo {

    private Map<String, Object> cache = new HashMap<String, Object>();
    private ReadWriteLock rwl = new ReentrantReadWriteLock();
    public static void main(String[] args) {
        CacheDemo cd = new CacheDemo();
        cd.getData2();
    }

    public void getData2(){
        rwl.readLock().lock();
        System.out.println(1);
        rwl.writeLock().lock();
        System.out.println(2);
        rwl.readLock().unlock();
        System.out.println(3);
        rwl.writeLock().unlock();
        System.out.println(4);
    }
}

亲自试一下,控制台输出1后,程序就不动了。

说明加写锁前,读锁得先解开。

第四版

即有读锁,又有写锁

public static void main(String[] args) {
        CacheDemo cd = new CacheDemo();
        System.out.println("ss   "+cd.getData4("ss"));
        System.out.println("ss   "+cd.getData4("ss"));

        System.out.println("mm   "+cd.getData4("mm"));
        System.out.println("mm   "+cd.getData4("mm"));
    }

    public Object getData4(String key){
        rwl.readLock().lock();
        Object o=null;
        try {
            o=cache.get(key);
            if (o==null) {
                System.out.println("第一次查  没有"+key);
                rwl.readLock().unlock();  //标识4
                rwl.writeLock().lock();
                try {
                    if(value==null){  //标识0
                       value = "aaaa";//实际调用 queryDB();
                       cache.put(key,value);
                    }
                } finally {
                    rwl.writeLock().unlock();
                }
                rwl.readLock().lock(); //标识1
            }
        }finally {
            rwl.readLock().unlock();  //标注2
        }
        return o;
    }                 

结果

第一次查  没有ss

ss   0.5989899889645358

ss   0.5989899889645358

第一次查  没有mm

mm   0.8534424949014686

mm   0.8534424949014686

这个还有三个问题

1为什么在标识2处还得解锁。

这个答案在上一节已经提过。

2为什么在标识1出还得加锁?

如果标识1处不加锁,且程序一直正常执行,那么到标识2处,它解谁的锁?

3为什么标识0出还要检查一次?

如果同时又三个线程运行到标识4(查找相同的key),其中一个获得写锁,写入数据后,释放了写锁。此时另外两个线程还需要去数据库跑一趟么?

另外把标识1处的加读锁,放到finally的前面称之为降级锁。对降级锁,我目前也不太清楚。

官方文档中给了一个例子就是关于降级锁,如下

class CachedData {
   Object data;
   volatile boolean cacheValid;
   final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

   void processCachedData() {
     rwl.readLock().lock();
     if (!cacheValid) {
        // Must release read lock before acquiring write lock
        rwl.readLock().unlock();
        rwl.writeLock().lock();
        try {
          // Recheck state because another thread might have
          // acquired write lock and changed state before we did.
          if (!cacheValid) {
            data = ...
            cacheValid = true;
          }
          // Downgrade by acquiring read lock before releasing write lock
          rwl.readLock().lock();
        } finally {
          rwl.writeLock().unlock(); // Unlock write, still hold read
        }
     }

     try {
       use(data);
     } finally {
       rwl.readLock().unlock();
     }
   }
 }

感谢glt

时间: 2024-12-17 01:56:49

ReentrantReadWriteLock读写锁的使用2的相关文章

java中ReentrantReadWriteLock读写锁的使用

ReentrantReadWriteLock读写锁的使用 Lock比传统线程模型中的synchronized方式更加面向对象,与生活中的锁类似,锁本身也应该是一个对象.两个线程执行的代码片段要实现同步互斥的效果,它们必须用同一个Lock对象. 读写锁:分为读锁和写锁,多个读锁不互斥,读锁与写锁互斥,这是由jvm自己控制的,你只要上好相应的锁即可.如果你的代码只读数据,可以很多人同时读,但不能同时写,那就上读锁:如果你的代码修改数据,只能有一个人在写,且不能同时读取,那就上写锁.总之,读的时候上读

java并发锁ReentrantReadWriteLock读写锁源码分析

1.ReentrantReadWriterLock基础 所谓读写锁,是对访问资源共享锁和排斥锁,一般的重入性语义为 如果对资源加了写锁,其他线程无法再获得写锁与读锁,但是持有写锁的线程,可以对资源加读锁(锁降级):如果一个线程对资源加了读锁,其他线程可以继续加读锁. java.util.concurrent.locks中关于多写锁的接口:ReadWriteLock public interface ReadWriteLock { /** * Returns the lock used for r

ReentrantReadWriteLock读写锁的使用

Lock比传统线程模型中的synchronized方式更加面向对象,与生活中的锁类似,锁本身也应该是一个对象.两个线程执行的代码片段要实现同步互斥的效果,它们必须用同一个Lock对象. 读写锁:分为读锁和写锁,多个读锁不互斥,读锁与写锁互斥,这是由jvm自己控制的,你只要上好相应的锁即可.如果你的代码只读数据,可以很多 人同时读,但不能同时写,那就上读锁:如果你的代码修改数据,只能有一个人在写,且不能同时读取,那就上写锁.总之,读的时候上读锁,写的时候上写锁! ReentrantReadWrit

ReentrantReadWriteLock读写锁详解

一.读写锁简介 现实中有这样一种场景:对共享资源有读和写的操作,且写操作没有读操作那么频繁.在没有写操作的时候,多个线程同时读一个资源没有任何问题,所以应该允许多个线程同时读取共享资源:但是如果一个线程想去写这些共享资源,就不应该允许其他线程对该资源进行读和写的操作了. 针对这种场景,JAVA的并发包提供了读写锁ReentrantReadWriteLock,它表示两个锁,一个是读操作相关的锁,称为共享锁:一个是写相关的锁,称为排他锁,描述如下: 线程进入读锁的前提条件: 没有其他线程的写锁, 没

java多线程:ReentrantReadWriteLock读写锁使用

Lock比传统的线程模型synchronized更多的面向对象的方式.锁和生活似,应该是一个对象.两个线程运行的代码片段要实现同步相互排斥的效果.它们必须用同一个Lock对象. 读写锁:分为读锁和写锁.多个读锁不相互排斥,读锁与写锁相互排斥,这是由jvm自己控制的,你仅仅要上好对应的锁就可以.假设你的代码仅仅读数据,能够非常多人同一时候读.但不能同一时候写,那就上读锁.假设你的代码改动数据.仅仅能有一个人在写.且不能同一时候读取,那就上写锁.总之.读的时候上读锁,写的时候上写锁! Reentra

ReentrantReadWriteLock读写锁的使用&lt;转&gt;

Lock比传统线程模型中的synchronized方式更加面向对象,与生活中的锁类似,锁本身也应该是一个对象.两个线程执行的代码片段要实现同步互斥的效果,它们必须用同一个Lock对象. 读写锁:分为读锁和写锁,多个读锁不互斥,读锁与写锁互斥,这是由jvm自己控制的,你只要上好相应的锁即可.如果你的代码只读数据,可以很多人同时读,但不能同时写,那就上读锁:如果你的代码修改数据,只能有一个人在写,且不能同时读取,那就上写锁.总之,读的时候上读锁,写的时候上写锁! ReentrantReadWrite

AQS系列(三)- ReentrantReadWriteLock读写锁的加锁

前言 前两篇我们讲述了ReentrantLock的加锁释放锁过程,相对而言比较简单,本篇进入深水区,看看ReentrantReadWriteLock-读写锁的加锁过程是如何实现的,继续拜读老Lea凌厉的代码风. 一.读写锁的类图 读锁就是共享锁,而写锁是独占锁.读锁与写锁之间的互斥关系为:读读可同时执行(有条件的):读写与写写均互斥执行.注意此处读读可并行我用了有条件的并行,后文会对此做介绍. 继续奉上一张丑陋的类图: 可以看到ReentrantReadWriteLock维护了五个内部类,Ree

JUC之ReadWriteLock、ReentrantReadWriteLock读写锁

读写锁简介 对共享资源有读和写的操作,且写操作没有读操作那么频繁.在没有写操作的时候,多个线程同时读一个资源没有任何问题,所以应该允许多个线程读取共享资源:但是如果一个线程想去写这些共享资源,就不应该允许其他线程对该资源进行读和写操作了. 读写锁ReentrantReadWriteLock,它表示两个锁,一个是读操作相关的锁,称为共享锁:一个是写相关的锁,称为排他锁,描述如下: 读锁的条件: 1. 没有其他线程的写锁: 2. 对写锁请求的线程必须是同一个. 写锁的条件: 1. 没有其他线程的读锁

ReentrantReadWriteLock读写锁

ReentrantLock实现了标准的互斥锁:一次最多只有一个线程能够持有相同ReentrantLock.但是互斥通常做为保护数据一致性的很强的加锁约束,因此,过分的限制了并发性.互斥是保守的加锁策略,避免了 "写/写"和"写/读"的重读,但是同样避开了"读/读"的重叠.在很多情况下,数据结构是"频繁被读取"的--它们是可变的,有时候会被改变,但多数访问只进行读操作.此时,如果能够放宽,允许多个读者同时访问数据结构就 非常好了