How do you choose between synchronized, ReentrantReadWriteLock, and StampedLock for protecting shared state?

### The decision is about contention shape, not preference The right synchronization primitive depends on **how** threads contend for the data — the ratio of reads to writes, the length of the critical section, and whether you need features like reentrancy or condition waiting. Here is a principled walk through the options. ### 1. `synchronized` (and plain `ReentrantLock`) — the default `synchronized` is a mutual-exclusion lock: one thread in the critical section at a time. Reasons it is the default: - **Simplest and least error-prone** — automatic release at block exit (no `finally` to forget); the JVM optimizes it well (biased/thin locks historically, lock elision). - **Reentrant** — a holding thread can re-enter. - Correct for **low-to-moderate contention** and **short** sections regardless of read/write mix. `ReentrantLock` adds `tryLock`, timeouts, interruptibility, fairness, and `Condition`s when you need them, at the cost of manual `try/finally`. **Limitation:** all access serializes, even pure reads. ### 2. `ReentrantReadWriteLock` — when reads dominate Splits into a shared read lock and an exclusive write lock: many readers in parallel, or one writer. Choose it when **both** hold: - Reads **greatly outnumber** writes (e.g. a cache, config holder, lookup table), **and** - Read critical sections are **long enough** that running them concurrently is a real win (the lock's own overhead must be amortized). It is **reentrant**, supports **lock downgrading** (write→read) and **Conditions**. Caveats: higher per-acquire cost than synchronized, **writer starvation** possible in non-fair mode, and **no benefit** (often a loss) when writes are frequent. ### 3. `StampedLock` — hot, short, read-mostly paths Adds the **optimistic read**: read with no lock, then `validate`. This removes the compare-and-swap that even a shared read lock performs, eliminating cross-core cache contention on the lock state. Choose it when: - Sections are **very short** and **read-mostly**, and the read-lock overhead itself is the measured bottleneck, **and** - You do **not** need reentrancy, and do **not** need `Condition`s. Price: **non-reentrant** (self-deadlock risk), **no Conditions**, and the discipline of snapshot-into-locals-then-validate plus correct stamp handling. It also offers **mode conversion** for safe-ish upgrades. It is an expert tool; misuse is easy. ### 4. Sometimes: no lock at all For a **single** variable, prefer `volatile` (visibility only) or an `Atomic*` class / `VarHandle` (atomic compound updates via CAS) — these beat any lock for that narrow case. For an aggregate read-only after construction, make it **immutable** and skip locking entirely. For high-contention counters, `LongAdder` outperforms a locked `long`. ### A practical decision flow 1. Can the state be **immutable** or confined to one thread? → No lock needed. 2. Is it a **single field** with simple atomic updates? → `volatile` / `Atomic*` / `LongAdder`. 3. Otherwise, default to **`synchronized`**. 4. Profiling shows **read-heavy** contention with non-trivial read sections? → **`ReentrantReadWriteLock`**. 5. Profiling shows the **read-lock overhead itself** dominates a hot, tiny, read-mostly path, and you need neither reentrancy nor Conditions? → **`StampedLock`** with optimistic reads. ### Why 'measure first' is the recurring theme Read/write and stamped locks add bookkeeping. Under frequent writes every reader is blocked anyway, so the extra machinery is pure loss versus `synchronized`. Under tiny sections the lock overhead dwarfs the protected work. Benchmarks (ideally JMH, with representative read/write ratios and thread counts) routinely overturn intuition — the 'fancier' lock is frequently slower. Pick the simplest primitive that meets the need, then upgrade only with evidence.