ReentrantReadWriteLock for Read Heavy Workloads

ReentrantReadWriteLock is the standard JDK implementation of ReadWriteLock.

Its promise sounds attractive:

• let many readers proceed together
• still protect writers with exclusivity

But that promise only pays off for the right workload.

If you use it everywhere just because “reads are common,” you can easily add complexity without measurable benefit.

---

Problem Statement

Imagine an in-memory product catalog used by many request threads.

Reads happen on almost every request. Writes happen occasionally from a refresh task.

With one exclusive lock:

• reader A blocks reader B
• reader B blocks reader C
• writes block everyone

That may be too conservative for a truly read-heavy path.

This is the problem ReentrantReadWriteLock is trying to solve.

---

Why This Change Was Added

Many backend workloads are asymmetrical:

• reads happen constantly
• writes happen rarely

Examples:

• product catalogs
• routing tables
• permission snapshots
• feature metadata
• cached reference data

If harmless readers keep blocking each other, the concurrency model is leaving throughput on the table.

ReentrantReadWriteLock exists to allow shared read access while still protecting mutation correctly.

---

Runnable Example

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantReadWriteLock;

public class ReentrantReadWriteLockDemo {

    public static void main(String[] args) throws Exception {
        ProductCatalog catalog = new ProductCatalog();

        Thread reader1 = new Thread(() -> read(catalog, "P100"), "reader-1");
        Thread reader2 = new Thread(() -> read(catalog, "P100"), "reader-2");
        Thread writer = new Thread(() -> catalog.refreshProduct("P100", "Mechanical Keyboard"),
                "writer");

        reader1.start();
        reader2.start();
        TimeUnit.MILLISECONDS.sleep(50);
        writer.start();

        reader1.join();
        reader2.join();
        writer.join();
    }

    static void read(ProductCatalog catalog, String productId) {
        System.out.println(Thread.currentThread().getName()
                + " read " + catalog.getProductName(productId));
    }

    static final class ProductCatalog {
        private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
        private final Map<String, String> products = new HashMap<>();

        ProductCatalog() {
            products.put("P100", "Keyboard");
            products.put("P200", "Monitor");
        }

        String getProductName(String productId) {
            lock.readLock().lock();
            try {
                sleep(150);
                return products.get(productId);
            } finally {
                lock.readLock().unlock();
            }
        }

        void refreshProduct(String productId, String productName) {
            lock.writeLock().lock();
            try {
                products.put(productId, productName);
                System.out.println("Writer updated " + productId);
            } finally {
                lock.writeLock().unlock();
            }
        }
    }

    static void sleep(long millis) {
        try {
            TimeUnit.MILLISECONDS.sleep(millis);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException(e);
        }
    }
}

The important behavior is:

• readers can overlap with other readers
• writers still require exclusive access

That is the real mental model.

---

Production-Style Example

A realistic use case is a routing or feature-definition cache:

• request threads perform thousands of reads per second
• a refresh task writes a new value only when config changes

In that situation, a normal exclusive lock may serialize far too many harmless lookups.

A read-write lock can help if:

• reads hold the lock long enough for overlap to matter
• writes are infrequent enough not to dominate
• profiling shows reader-reader blocking is real

---

When It Helps

ReentrantReadWriteLock can help when:

• the workload is genuinely read-heavy
• the shared state is expensive enough that reader concurrency matters
• write operations are infrequent and reasonably short
• the code benefits from preserving a mutable shared structure instead of swapping immutable snapshots

These conditions matter together. One alone is not enough.

---

When It Hurts

It can be the wrong tool when:

• writes are frequent
• critical sections are tiny
• the state could be modeled as immutable snapshots with simple publication
• the team adds read-write locking without measuring a bottleneck

If the protected work is very small, read-lock machinery may cost more than it saves.

---

Comparison with Alternatives

Compared with a normal exclusive lock:

• ReentrantReadWriteLock may improve reader concurrency
• but increases complexity

Compared with immutable snapshot replacement:

• ReentrantReadWriteLock preserves one mutable structure
• but immutable replacement may be easier to reason about for many read-mostly datasets

Compared with StampedLock:

• ReentrantReadWriteLock is easier to use correctly
• StampedLock is more specialized and more error-prone

---

Common Mistakes

• choosing it based only on “there are more reads than writes”
• trying to upgrade from read to write in unsafe ways
• using it where lock hold times are too tiny to justify the extra mechanism
• ignoring alternative designs such as immutable snapshot swapping

Read-heavy is necessary, but not sufficient. The real question is whether shared-reader concurrency materially improves throughput or latency.

---

Decision Guide

Use ReentrantReadWriteLock when:

• the state is mutable
• reads are frequent and not trivial
• writes are uncommon
• measurement justifies the extra complexity

Prefer a plain lock when:

• code is simple
• writes are common
• critical sections are short

Prefer immutable snapshots when:

• replacing the whole object is natural
• readers only need a stable view
• write frequency is low enough that snapshot replacement is practical

---

Key Takeaways

• ReentrantReadWriteLock exists for genuine read-heavy mutable shared-state workloads.
• It is not automatically faster than a normal lock.
• Its benefit depends on read/write ratio, lock hold time, and actual contention.
• Measure before adopting it, and compare it against simpler alternatives like plain locking or immutable snapshot replacement.

Next post: Lock Downgrading and Lock Upgrade Limitations in Java