StampedLock and Optimistic Reads
Fast recall
Quick revision
Core answer
Awareness of the performance limitations of ReentrantReadWriteLock and knowledge of the optimistic concurrency model introduced in Java 8.
Using StampedLock without validating the stamp after an optimistic read — forgetting validate() means reading potentially torn data.
Note that StampedLock is NOT re-entrant and does not support Condition variables. Also mention that optimistic reads are effectively lock-free — they don't actually acquire any lock, just record a stamp.
Interview-ready guide
Interview answer
StampedLock adds optimistic reading — you read without acquiring any lock, then validate whether a write happened during the read.
Optimistic read pattern:
tryOptimisticRead()returns a stamp without locking — read the data, thenvalidate(stamp)- Validation succeeds: no write occurred, data is consistent — proceed
- Validation fails: fall back to a pessimistic read lock or retry
- Near-free when writes are rare — avoids CAS and shared-lock tracking entirely
Critical requirement:
- Must validate the stamp after every optimistic read — forgetting creates a silent data race that works most of the time but corrupts under write contention
Limitations:
- Not reentrant — re-acquiring the write lock from the same thread deadlocks
- Does not implement the
Lockinterface — noConditionsupport
Advantage over ReadWriteLock:
tryConvertToWriteLock()can upgrade a read to a write lock without deadlocking — impossible with ReentrantReadWriteLock
I recommend StampedLock for geometry-style data (coordinates, spatial data) with very frequent reads and rare writes. ReentrantReadWriteLock is safer and simpler for most other scenarios.
StampedLock and Optimistic Reads
Direct Answer
StampedLock adds an optimistic read mode: tryOptimisticRead() returns a stamp without acquiring any lock. After reading, you call validate(stamp) — if it returns true, no write occurred and the data is safe. If false, you fall back to a pessimistic read lock. This avoids read-write contention entirely in the common case.
Deep Dive & Architecture
Synchronization is how Java serializes access to shared mutable state so that concurrent code stays correct.
It provides two guarantees: mutual exclusion (only one thread executes the protected section at a time) and memory visibility (writes made inside a synchronized block by one thread are visible to any thread that later acquires the same lock).
StampedLock adds an optimistic read mode: tryOptimisticRead() returns a stamp without acquiring any lock. After reading, you call validate(stamp) — if it returns true, no write occurred and the data is safe. If false, you fall back to a pessimistic read lock. This avoids read-write contention entirely in the common case.
Mentioning only mutual exclusion. Missing the visibility / memory-model angle entirely. Confusing volatile (visibility only) with synchronized (both)
Common Mistakes & Pitfalls
Using StampedLock without validating the stamp after an optimistic read — forgetting validate() means reading potentially torn data.
Check your understanding
Answer these without looking back at the article.
- What is synchronization in Java? Why is it needed, and what guarantees does it provide?
- Explain how the synchronized keyword works in Java. What is a monitor, and what guarantees does synchronization provide?
- What's the difference between a synchronized method and a synchronized block in Java? When should you use each?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.