Optimistic vs Pessimistic Locks and CAS Implementation in Java

Pessimistic lock assumes the worst case: every data access acquires a lock because other threads might modify the data, leading to blocking, context switches, and possible priority inversion. Traditional relational databases and Java's synchronized keyword are typical examples.

Optimistic lock assumes conflicts are rare; it reads data without locking and validates at update time using mechanisms like version numbers. It improves throughput for read‑heavy workloads and is the basis of Java's atomic classes that rely on CAS.

CAS (Compare‑And‑Swap) is the core hardware primitive for optimistic locking. It atomically compares a memory location with an expected value and, if they match, swaps in a new value. The Java java.util.concurrent.atomic package implements CAS via native methods that ultimately invoke CPU instructions such as cmpxchg .

Example of an atomic class using CAS: public class AtomicInteger extends Number implements java.io.Serializable { private volatile int value; public final int get() { return value; } public final int getAndIncrement() { for (;;) { int current = get(); int next = current + 1; if (compareAndSet(current, next)) return current; } } public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); } }

CAS also has drawbacks: the ABA problem (a value may change from A to B and back to A, misleading the CAS), high CPU cost when spinning for long periods, and inability to atomically update multiple variables without additional techniques such as AtomicStampedReference or combining fields.

Java provides AtomicStampedReference to attach a stamp (version) to a reference, solving the ABA issue by requiring both the reference and its stamp to match before updating.

When choosing between CAS and synchronized , CAS is faster under low contention because it avoids kernel transitions, but under high contention the spin‑retry overhead can make synchronized (which now uses lock‑free queues and adaptive spinning) more efficient.

The java.util.concurrent package builds higher‑level constructs (locks, executors, queues) on top of volatile variables, CAS operations, and atomic classes, following a pattern of declaring shared state as volatile, updating it with CAS, and using the memory semantics of volatile reads/writes for thread communication.

In the JVM, object allocation also uses CAS: threads allocate memory from the heap either via pointer bumping or a free‑list, and CAS ensures the allocation pointer update is atomic. To reduce contention, the JVM employs Thread‑Local Allocation Buffers (TLABs), which allocate most objects without CAS, falling back to CAS only when a buffer is exhausted.