JAVA High Concurrency (JUC) ReadWriteLock (read-write lock)

This time I will explain JUC's ReadWriteLock (read-write lock):
there is no problem with multiple threads reading a resource class at the same time, so in order to meet the amount of concurrency, reading shared resources should be possible at the same time. However, if a thread wants to share the resource class, there should not be other threads that can read or write to the resource.

• Summary: Read and read coexist, read and write do not coexist, write and write do not coexist
  Next, let’s look at a case: the
  code is as follows:

public class ReadWriteLockDemo {
    public static void main(String[] args) {
        MyCache myCache = new MyCache();
        for (int i = 0; i < 5; i++) {
            final int finali= i;
            new Thread(() -> {
                try {
                    myCache.put(finali+"", finali+"");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }, String.valueOf(i)).start();
        }

        for (int i = 0; i < 5; i++) {
            final int finali= i;
            new Thread(() -> {
                try {
                    myCache.get(finali+"");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }, String.valueOf(i)).start();
        }
    }
}

class MyCache {
    private volatile Map<String, Object> map = new HashMap<>();

    public void put(String key, Object value) throws InterruptedException {
        System.out.println(Thread.currentThread().getName() + "\t-----写入数据key");
        Thread.sleep(3000);
        map.put(key, value);
        System.out.println(Thread.currentThread().getName() + "\t-----写入数据成功");
    }

    public void get(String key) throws InterruptedException {
        System.out.println(Thread.currentThread().getName() + "\t读取数据key");
        Thread.sleep(3000);
        Object result = map.get(key);
        System.out.println(Thread.currentThread().getName() + "\t读取数据成功" + result);
    }
}

The results of the operation are as follows:

What we can see is that when data is written in 1, it has not been written successfully at this time, and the read operation has been performed on 1, just like the atomicity of our database, there is no After the data is written, the read operation is performed, so the read is empty.
Next, let's take a look at the effect of adding a read-write lock: the
code is as follows:
here you only need to modify MyCache:

class MyCache {
    private volatile Map<String, Object> map = new HashMap<>();
    private ReadWriteLock readWriteLock = new ReentrantReadWriteLock();

    public void put(String key, Object value) throws InterruptedException {
        readWriteLock.writeLock().lock();  //上写锁
        try {
            System.out.println(Thread.currentThread().getName() + "\t-----写入数据key");
            Thread.sleep(3000);
            map.put(key, value);
            System.out.println(Thread.currentThread().getName() + "\t-----写入数据成功");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            readWriteLock.writeLock().unlock();
        }
    }
    public void get(String key) throws InterruptedException {
        readWriteLock.readLock().lock();  //上读锁
        try {
            System.out.println(Thread.currentThread().getName() + "\t读取数据key");
            Thread.sleep(3000);
            Object result = map.get(key);
            System.out.println(Thread.currentThread().getName() + "\t读取数据成功" + result);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            readWriteLock.readLock().unlock();
        }
    }
}

The results of the operation are as follows:

we can see that we have maintained consistency in writing, read guarantees concurrent reading, and prevented read operations while writing, so this is the function of the read-write lock.

Summary: Read and read coexist, read and write do not coexist, write and write do not coexist