Backend Development 5 min read

Understanding Java ReentrantReadWriteLock: Read‑Write Sharing and Mutual Exclusion

This article explains how Java's ReentrantReadWriteLock provides read‑write separation, allowing concurrent reads while enforcing exclusive access for writes, and demonstrates its behavior with sample code and thread‑execution results that illustrate read‑read sharing, read‑write mutual exclusion, and write‑write mutual exclusion.

Selected Java Interview Questions
Selected Java Interview Questions
Selected Java Interview Questions
Understanding Java ReentrantReadWriteLock: Read‑Write Sharing and Mutual Exclusion

In concurrent Java development, locks are commonly used to protect shared resources, but the built‑in Synchronized keyword suffers from a performance drawback because it blocks even read‑read operations.

Java introduced ReadWriteLock in JDK 5 to separate read and write locks, which reduces lock contention and improves overall system performance.

ReadWriteLock manages two distinct locks: a read‑only lock and a write lock.

The JDK implementation ReentrantReadWriteLock adds reentrancy to the ReadWriteLock interface.

Its semantics are:

Read‑read: shared (multiple threads can read simultaneously).

Read‑write: exclusive (a writer blocks readers and vice‑versa).

Write‑write: exclusive (only one writer at a time).

Because reads are often more frequent than writes, this lock can provide significantly higher concurrency and throughput compared to a simple exclusive lock.

The lock is built on the AbstractQueuedSynchronizer (AQS) framework; the lock state is stored in the synchronizer’s internal state.

The following example demonstrates how to create a ReentrantReadWriteLock , obtain its read and write locks, and use them in separate read and write methods. Four threads (t1‑t4) are started to invoke these methods.

public class ReentrantWriteReadLockTest {
    ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
    ReadLock readLock = lock.readLock();
    WriteLock writeLock = lock.writeLock();

    public void read() {
        try {
            readLock.lock();
            System.out.println("线程" + Thread.currentThread().getName() + "进入。。。");
            Thread.sleep(3000);
            System.out.println("线程" + Thread.currentThread().getName() + "退出。。。");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            readLock.unlock();
        }
    }

    public void write() {
        try {
            writeLock.lock();
            System.out.println("线程" + Thread.currentThread().getName() + "进入。。。");
            Thread.sleep(3000);
            System.out.println("线程" + Thread.currentThread().getName() + "退出。。。");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            writeLock.unlock();
        }
    }

    public static void main(String[] args) {
        final ReentrantWriteReadLockTest wr = new ReentrantWriteReadLockTest();
        Thread t1 = new Thread(() -> wr.read(), "t1");
        Thread t2 = new Thread(() -> wr.read(), "t2");
        Thread t3 = new Thread(() -> wr.write(), "t3");
        Thread t4 = new Thread(() -> wr.write(), "t4");
        t1.start();
        t2.start();
        // t3.start();
        // t4.start();
    }
}

When threads t1 and t2 are started, both enter the read method simultaneously, confirming the read‑read sharing property.

When threads t2 and t3 run together, the writer blocks the reader (or vice‑versa), demonstrating read‑write mutual exclusion .

When threads t3 and t4 run together, only one writer proceeds at a time, illustrating write‑write mutual exclusion .

JavaconcurrencymultithreadingreadwritelockReentrantReadWriteLock
Selected Java Interview Questions
Written by

Selected Java Interview Questions

A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.