Mastering Java ReadWriteLock: Build Efficient Caches and Avoid Concurrency Pitfalls

In modern high‑concurrency web services, the workload is often "read‑many, write‑few," making caching a common technique. Java's JUC library provides ReadWriteLock to support this pattern.

Student: "Do you know what a read‑write lock is?"

The read‑write lock aims to achieve three goals:

Allow multiple threads to read a shared variable simultaneously.

Allow only one thread to write the shared variable at a time.

When a write thread holds the lock, all read threads are blocked from accessing the variable.

Student: "What is the difference between a read‑write lock and a mutex lock?"

A read‑write lock permits concurrent reads, while a mutex lock does not, giving read‑write locks an advantage in read‑heavy scenarios. The write side of a read‑write lock is exclusive: when a thread is writing, no other thread may read or write.

Student: "How can we use ReadWriteLock to implement a cache?"

Two loading strategies are discussed:

Full load : If the source data set is small, load all data into the cache at application startup with a single put() operation.

Lazy load : If the source data set is large, load data on demand. When a cache miss occurs, the thread fetches the data from the source and stores it in the cache.

In a high‑concurrency situation, multiple threads may contend for the write lock. For example, if the cache is empty and three threads (t1, t2, t3) call get() simultaneously, they all reach the code that acquires the write lock, but only one (e.g., t1) succeeds. After t1 loads data from the database and releases the lock, another thread (e.g., t2) may acquire the lock and reload the same data, causing unnecessary DB queries. Therefore, a second verification (double‑check) after acquiring the write lock is essential to avoid redundant database access.

Student: "How do we solve data‑consistency problems?"

Simple solutions include:

Setting a timeout for cached entries so they expire and are refreshed from the source.

When the source data changes, proactively invalidate or update the cache (e.g., using MySQL binlog parsing to push updates).

Dual‑write approaches between database and cache (not detailed here).

Student: "Can you explain lock upgrade and downgrade?"

In the lazy‑load code, one might think of acquiring a read lock first and then upgrading to a write lock to update the cache. However, ReadWriteLock does not support lock upgrade; attempting to acquire a write lock while holding a read lock can cause a permanent deadlock.

Lock downgrade, on the other hand, is possible: a thread can acquire the write lock, update the cache, then acquire the read lock before releasing the write lock, effectively downgrading. Only the write lock supports condition variables; calling newCondition() on a read lock throws UnsupportedOperationException.