Working with Locks and Atomic Variables

1. Using ReentrantLock

lock.lock();
try { criticalSection(); }
finally { lock.unlock(); }

Lock	Allows
readLock	Multiple concurrent readers
writeLock	Exclusive (no readers, no writers)
Downgrade	Write → read OK
Upgrade	Read → write FORBIDDEN (deadlock)

Mode	Use
`writeLock`	Exclusive, returns stamp
`readLock`	Shared, returns stamp
`tryOptimisticRead`	Lock-free; validate with `validate(stamp)`
Not	Reentrant; not Condition-friendly

Mode	Behavior
Non-fair (default)	Higher throughput; possible starvation
Fair	FIFO; lower throughput, predictable
Rule	Use fair only when starvation observed

API	Use
`cond.await()`	Release lock, wait, re-acquire
`cond.signal / signalAll`	Wake waiters
Multiple conditions	One per logical state (notFull, notEmpty)

Method	Effect
`get / set`	Volatile
`incrementAndGet / decrementAndGet`	Atomic +/- 1
`addAndGet(delta)`	Atomic +delta
`compareAndSet(exp, new)`	CAS
`updateAndGet(unaryOp)`	CAS-loop with function

Method	Use
`compareAndSet(exp, new)`	Identity-based CAS
`updateAndGet(fn)`	Functional update
ABA	Use `AtomicStampedReference`

Use	Pattern
Init guard	`if (started.compareAndSet(false, true))`
Cancel flag	Set true; check in loop

Concept	Detail
Atomic op	HW instruction (cmpxchg)
Pattern	Read-Modify-Write loop until success
Pros	Lock-free, no context switch
Cons	Contention causes retries

Class	Use
LongAdder	High-contention counters; cells per thread
LongAccumulator	Generalized: any binary op + identity
vs AtomicLong	Better under contention; `sum()` is approximate snapshot

Strategy	Detail
Lock ordering	Global order all threads follow
`tryLock` + back-off	Avoid hold-and-wait
Timeout	Detect potential deadlock
Reduce scope	Hold locks briefly
ThreadMXBean	Detect at runtime: `findDeadlockedThreads()`

Pattern	Building Block
Counter	LongAdder
Stack	Treiber stack via AtomicReference
Queue	Michael-Scott (ConcurrentLinkedQueue)
Map	ConcurrentHashMap (locked bins)