همگام‌سازی، قفل‌ها، AQS و مدل حافظهٔ جاواSynchronization, Locks, AQS & the Java Memory Model

Let's be honest: most concurrency bugs happen because a programmer assumes memory behaves like a shared notebook that every thread reads from the same page at the same instant. On a real multi-core machine, memory does not work like that at all. This chapter is going to fully break that wrong mental model and build a correct one in its place — and then construct, one at a time and from scratch, the tools you use to control ordering and visibility.

Part 0 — words you must know first

Before anything else, let's anchor a few terms with analogies so I never drop them on you cold later.

• Reordering: shuffling the execution order of instructions for speed — like a chef doing tasks in the most efficient order rather than the written order.
• Memory barrier / fence: a special instruction telling the hardware "actually finish everything up to here and make it visible before moving on" — like a rule that says "don't start the next dish until the current one is on the pass."
• Atomic: an operation that either happens completely or not at all; no other thread can observe a half-done intermediate state.

Mental model: why the JMM exists

Naively you imagine your program as a single, sequential list of memory reads and writes executed exactly in source order, instantly visible to every thread. Convenient as it is, that model is a lie. Between your source code and the electrons in the chip, there are three reordering agents:

1. The compiler (javac + JIT): may reorder, hoist, eliminate, or fold instructions. "Hoist" means taking something read every loop iteration and reading it once outside the loop into a register — you'll soon see why that can be catastrophic.
2. The CPU: executes out-of-order and sometimes speculatively (it guesses which branch runs and starts it early).
3. The memory hierarchy: store buffers and per-core caches delay when one core's write becomes visible to another — that "stale copy on the chef's counter."

This is where the Java Memory Model (JMM) enters. It's specified in JLS Chapter 17 and was reworked by JSR-133 (Java 5), and it's the contract that tells you exactly which cross-thread reads are allowed to see which writes. Everything else in this chapter — volatile, synchronized, Lock, atomics — is really a way to buy happens-before edges from that contract.

Happens-before: the only rule that really matters

If you take just one thing from this chapter, make it this.

Now let's be precise. The JMM is defined in terms of a partial order called happens-before (HB). "Partial" means not every two actions are comparable; some pairs are ordered and some aren't. The rule: if action A happens-before action B, then all of A's memory effects are visible to and ordered before B.

And here's the dangerous part: if two actions are not ordered by HB and at least one is a write to the same location, you have a data race. In that case the JMM permits the reads to return stale, torn (half the old value, half the new), or even seemingly "impossible" values.

The HB edges you actually get — memorize this list:

• Program order: within a single thread, each action HB every later action in that thread.
• Monitor lock: an unlock on a monitor HB every subsequent lock on that same monitor.
• Volatile: a write to a volatile field HB every subsequent read of that same field.
• Thread start: Thread.start() HB every action in the started thread.
• Thread join: every action in a thread HB another thread's successful return from join() on it.
• Interrupt: a call to interrupt() HB the interrupted thread detecting it.
• Final fields: the end of a constructor HB the freeze of final fields (the basis for safe publication of immutable objects).
• Transitivity: if A HB B and B HB C, then A HB C. Edges chain together.

Let's watch the chain with a concrete example:

Thread 1                         Thread 2
--------                         --------
data = 42;        (1)
ready = true;     (2, volatile write / release)
                                 while(!ready) {}  (3, volatile read / acquire)
                                 print(data);      (4)  -> guaranteed to see 42

Why does it work? Because (2) is a volatile write and (3) a volatile read of the same field, (2) HB (3). By program order (1) HB (2), and also (3) HB (4). Now chain via transitivity: (1) HB (2) HB (3) HB (4), so (1) HB (4). That means the read of data at line (4) must observe 42.

volatile: what it does and what it doesn't

Now that you have happens-before, volatile becomes simple. Picture it as a glass jar everyone must read directly from the main pantry, never from their counter copy — and every time someone puts something in it, they must first commit all their prior work to the pass.

volatile gives you exactly two things:

1. Visibility + ordering (release/acquire): a volatile write establishes an HB edge, making not just that variable but all writes that preceded it in program order visible to a thread that subsequently reads the same volatile. This "piggybacking" is what made the data/ready example work.
2. Atomicity of the field itself, even for long/double. Note: under the JLS, a non-volatile 64-bit write may be split into two 32-bit stores; volatile forbids that tearing.

And what volatile does not give you — this is where most people go wrong:

• No mutual exclusion. volatile int x; x++; is really a read-modify-write (read, add, write) and is not atomic. Two threads can both read 5, both compute 6, both write 6 — and one increment is lost. Use an AtomicInteger or a lock.
• No compound-action atomicity. if (v == null) v = new X(); still races even if v is volatile, because there's a gap between the check and the assignment.

synchronized: the intrinsic monitor

If volatile was the shared jar, synchronized is the key to a room only one person enters at a time.

The guarantees of synchronized:

• Mutual exclusion: only one thread holds a given monitor at a time.
• Visibility: unlock HB the subsequent lock on the same monitor, so the whole critical section's writes publish.
• Reentrancy: the same thread may re-acquire a monitor it already holds (a per-thread hold count is kept). That's what lets a synchronized method call another synchronized method on this without deadlocking itself.

A subtle point about what you lock on: synchronized(this) and a synchronized instance method both lock on this; a synchronized static method locks on the Class object.

Lock optimizations — and what got removed

Historically HotSpot layered three locking schemes worth knowing, especially since one was removed and is a favorite interview question:

• Biased locking: assumed a lock is usually re-acquired by the same thread, so it "biased" the object to that thread and skipped atomic CAS entirely on re-entry. It was disabled by default and deprecated in JDK 15 (JEP 374) and the implementation was subsequently obsoleted/removed (JDK 18, JDK-8256425). Why? Its revocation and bookkeeping costs hurt modern workloads with lots of short-lived threads and contended concurrent data structures.
• Lightweight (thin) locking: uncontended locks use a CAS on the object header's mark word to stack-allocate a lock record on the thread's stack — no OS mutex, so very cheap.
• Heavyweight (inflated) locking: under contention the monitor "inflates" to an OS-level ObjectMonitor with a real wait queue and OS parking. Expensive, but needed under pressure.

The Lock family: ReentrantLock, ReadWriteLock, StampedLock

The intrinsic monitor is simple and safe, but rigid: you can't say "give up if the lock isn't free within 2 seconds." The java.util.concurrent.locks package gives explicit locks with that flexibility.

ReentrantLock — the workhorse

ReentrantLock provides the same mutual exclusion as synchronized, but with extra capabilities: tryLock() (with an optional timeout — "if it isn't free by then, come back"), interruptible acquisition via lockInterruptibly(), optional fairness (FIFO ordering for waiting threads, at a throughput cost), and multiple Condition objects per lock (vs. one wait-set per monitor).

But it has one non-negotiable idiom — know it in your sleep:

private final ReentrantLock lock = new ReentrantLock();

void doWork() {
    lock.lock();
    try {
        // critical section
    } finally {
        lock.unlock(); // MUST be in finally — an exception must not leak the lock
    }
}

ReentrantReadWriteLock — separate read/write locks

This is good when reads massively dominate writes and critical sections are non-trivial (not tiny). But two important traps:

• Writer starvation: if readers pour in without pause, a writer may never get a turn. Mitigate with the fair constructor.
• Downgrading allowed, upgrading forbidden: downgrading (write → read) is legal — provided you acquire the read lock before releasing the write lock. But upgrading (read → write) deadlocks and is forbidden. (We fully unpack why in the last interview question.)

StampedLock (Java 8) — optimistic reads

StampedLock is not reentrant, but adds a killer feature: optimistic reads.

private final StampedLock sl = new StampedLock();
private double x, y;

double distanceFromOrigin() {
    long stamp = sl.tryOptimisticRead();      // no CAS, no blocking
    double cx = x, cy = y;                     // read snapshot
    if (!sl.validate(stamp)) {                 // a writer may have run
        stamp = sl.readLock();                 // fall back to a pessimistic read lock
        try { cx = x; cy = y; }
        finally { sl.unlockRead(stamp); }
    }
    return Math.sqrt(cx * cx + cy * cy);
}

The big win: when writes are rare, the read path never even touches the lock's cache line, so cache-line contention is eliminated entirely.

AbstractQueuedSynchronizer (AQS): the engine underneath

Now let's pull back the curtain. ReentrantLock, Semaphore, CountDownLatch, ReentrantReadWriteLock, and even ThreadPoolExecutor's worker gate — all are thin wrappers over one shared engine called AQS. Understand this one piece and you practically know the source of half of java.util.concurrent.

The precise mental model:

• AQS holds a single volatile int state and a CLH-based FIFO wait queue of threads. (CLH is a particular linked-list-based queue where each thread spins/sleeps on its own node.)
• A subclass defines what state means and implements tryAcquire(int) / tryRelease(int) (exclusive) or tryAcquireShared / tryReleaseShared (shared).
• AQS itself does the hard machining: atomically CAS-ing state, enqueuing losers as queue nodes, parking them via LockSupport.park(), and unparking the successor on release.

Now see how the same engine builds several different classes:

• ReentrantLock: state is the hold count — 0 = free, N = held N times reentrantly. tryAcquire CAS-es 0→1, or, if the current thread already owns it, bumps the count.
• Semaphore: state is the permit count, using shared acquisition.
• CountDownLatch: state is the count, and when it hits 0 it lets all waiters through at once — this is the "shared release," which is why one latch can release many threads simultaneously.

CAS, the Atomic* classes, and the ABA problem

So far everything was about locks. But there's a layer above them — and often faster: lock-free programming.

CAS is a single hardware instruction (lock cmpxchg on x86, LL/SC on ARM) that atomically does: "if this memory equals expected, set it to new and report success; otherwise leave it and report failure." The java.util.concurrent.atomic package exposes it: AtomicInteger, AtomicLong, AtomicReference, and array/field-updater variants.

AtomicInteger counter = new AtomicInteger();

int incrementAndGet() {
    int prev, next;
    do {
        prev = counter.get();
        next = prev + 1;
    } while (!counter.compareAndSet(prev, next)); // retry until we win the race
    return next;
}

This loop is optimistic: no thread blocks; contention just causes retries.

The ABA problem

CAS has a subtle weakness: it checks value equality, not whether the value changed and changed back.

Precisely: if a thread reads A, another thread flips A→B→A, then the first thread's compareAndSet(A, ...) succeeds — even though the world moved underneath it. For an int counter this is harmless. But for a pointer-swapping structure (say a lock-free stack popping a node that was freed and reallocated in the meantime) it corrupts state. The fix is to pair the value with a monotonic stamp/version: AtomicStampedReference (value + int stamp) or AtomicMarkableReference (value + boolean).

False sharing: the invisible tax

This is one of those performance bugs that leaves no trace in the code and only a profiler finds it.

This is false sharing, and it can silently cost you an order of magnitude (10x).

The fix: pad hot fields onto their own cache line so each gets its own tray. Java 8+ provides @jdk.internal.vm.annotation.Contended (application code needs the -XX:-RestrictContended flag); LongAdder's internal Cell is annotated exactly this way — which is why LongAdder scales so well. Manual padding (long p1..p7) also works, but the JIT may eliminate unused fields, so @Contended is preferred where available.

Double-checked locking, done right

This is the most famous "looks correct but is broken" pattern in Java concurrency. The goal: build an expensive object only once and lazily, then return it quickly without locking.

The classic broken idiom:

// BROKEN before Java 5 and still broken today without volatile
private Helper helper;
Helper getHelper() {
    if (helper == null) {                 // 1st check (no lock)
        synchronized (this) {
            if (helper == null)           // 2nd check (locked)
                helper = new Helper();    // publish
        }
    }
    return helper;
}

Why is it broken without volatile? Because helper = new Helper() is not one atomic operation but three steps: (1) allocate memory, (2) run the constructor and initialize fields, (3) assign the reference to helper. And the JMM permits step 3 (the reference assignment) to become visible before step 2 (the constructor's writes).

The fix is to make the field volatile. That inserts the release/acquire barrier which guarantees the constructor's writes HB any read of the reference:

private volatile Helper helper;           // volatile is mandatory
Helper getHelper() {
    Helper result = helper;               // read volatile once into a local
    if (result == null) {
        synchronized (this) {
            result = helper;
            if (result == null)
                helper = result = new Helper();
        }
    }
    return result;
}

Reading into the local result is a real optimization: on the hot path it collapses two volatile reads into one.

class Singleton {
    private Singleton() {}
    private static class Holder { static final Singleton INSTANCE = new Singleton(); }
    static Singleton getInstance() { return Holder.INSTANCE; } // JVM guarantees safe, lazy init
}

Common pitfalls & gotchas

Keep these as a checklist when reviewing concurrent code:

• Relying on time instead of HB. "There's a Thread.sleep, surely the other thread finished by now." sleep creates no HB edge; stale reads remain perfectly legal.
• volatile on a mutable object reference. It publishes the reference safely, but subsequent mutations of that object's fields are not covered. Publish an immutable snapshot instead.
• Non-final fields in "immutable" objects. Only final fields get the constructor freeze guarantee; a non-final field can be seen with its default value if the object is published via a data race.
• Locking on this in a library. Callers can lock on your object too, causing surprise contention or deadlock. Use a private lock.
• check-then-act on concurrent collections. if (!map.containsKey(k)) map.put(k, v); races; use putIfAbsent/computeIfAbsent instead.
• Forgetting unlock() isn't automatic. Explicit Locks need try/finally; a synchronized block cannot leak.
• Assuming size()/isEmpty() on concurrent collections are exact. They're weakly consistent snapshots, not precise instantaneous counts.

Best practices

• Prefer immutability and confinement (keeping data within one thread) over locking; the cheapest lock is the one you never take.
• Reach for higher-level tools before hand-rolling locks: java.util.concurrent collections, CompletableFuture, ExecutorService.
• Keep critical sections short and free of I/O. Never call foreign/callback code while holding a lock — that's a direct invitation to deadlock.
• Establish and document a global lock ordering and acquire locks in that consistent order everywhere; this prevents deadlock.
• For counters/accumulators under contention, reach for LongAdder, not AtomicLong.
• Deliberately publish every field that crosses threads — via final, volatile, a lock, or a concurrent collection. If you can't name the HB edge, it's a bug.

Interview Questions

boolean running = true;      // not volatile
void stop() { running = false; }
void run() { while (running) { /* work */ } }

static int a = 0, b = 0;
// Thread 1: a = 1; int r1 = b;
// Thread 2: b = 1; int r2 = a;

Senior notes & advanced edge cases

You now hold the correct mental model and the tools. This section covers the layer that separates a genuine senior from a good programmer: the deeper JMM guarantees, safe publication, the modern access-mode ladder with VarHandle, the real semantics of wait/notify, the taxonomy of progress guarantees, and bugs that only surface under production load and a profiler.

1) The SC-DRF theorem: what the JMM actually promises

The chapter showed racy code can see stale or torn values. The reassuring part: the JMM has one central theorem, SC-DRF (Sequential Consistency for Data-Race-Free programs).

This simplifies your real job: never reason about individual reorderings, just prove you're DRF — which is exactly what makes the chapter's golden line land: "if you can't name the HB edge, you have a bug." The flip side: for racy code, the JMM still has an unsolved theoretical problem.

2) Coherence vs consistency — a subtle correction

The "stale copy on the chef's counter" analogy is great for intuition, but a senior must be more precise. Modern hardware guarantees cache coherence via protocols like MESI: for a single address all cores agree on one global write order, and a write invalidates other cores' copies. So caches don't actually stay stale "forever."

3) Safe publication and this-escape

The chapter stated "deliberate publication" as the golden rule. More precisely, there are four canonical ways to safely publish an object:

1. Initialize it from a static initializer (class-init guarantee).
2. Store its reference in a volatile field (or an AtomicReference).
3. Store its reference in a final field assigned in a constructor.
4. Store its reference guarded by a lock (or place it in a concurrent collection).

public class Listener {
    private final int id;
    public Listener(EventBus bus) {
        bus.register(this);    // ❌ this escaped — constructor isn't done yet
        this.id = computeId(); // another thread may observe id == 0
    }
}

4) VarHandle and the access-mode ladder — the modern memory model

The chapter demonstrated CAS with AtomicInteger. But since Java 9 (JEP 193) the low-level, official machinery underneath it all is VarHandle — the safe, supported successor to sun.misc.Unsafe and the Atomic*FieldUpdater classes (the java.util.concurrent classes themselves migrated onto it in JDK 9).

Its key gift: instead of the "plain or volatile" binary, it offers a four-rung ladder of ordering strength, weakest to strongest.

The VarHandle access-mode strength ladder (weak to strong):

flowchart LR
  Plain["Plain<br/>get/set"] --> Opaque["Opaque<br/>getOpaque/setOpaque"]
  Opaque --> RelAcq["Release/Acquire<br/>setRelease/getAcquire"]
  RelAcq --> Volatile["Volatile (SC)<br/>getVolatile/setVolatile"]

• Plain: no cross-thread ordering or visibility — just atomicity of the access itself (except plain long/double). Like a normal field read.
• Opaque: accesses aren't elided and stay coherent for a single address, but are reorderable relative to other addresses — for a stop flag or a stats counter that only needs to be seen "eventually," cheaper than volatile.
• Release/Acquire: the same release/acquire half-fence from happens-before, but without the heavy StoreLoad fence — the "sign / see the signature" edge without full SC cost.
• Volatile: the strongest — equivalent to the volatile keyword, with a global SC order.

class Node {
    Object item;
    volatile Node next;      // ordinary field, manipulated via VarHandle
    private static final VarHandle NEXT;
    static {
        try {
            NEXT = MethodHandles.lookup()
                .findVarHandle(Node.class, "next", Node.class);
        } catch (ReflectiveOperationException e) { throw new ExceptionInInitializerError(e); }
    }
    boolean casNext(Node expect, Node update) {
        return NEXT.compareAndSet(this, expect, update);
    }
    void publish(Node n) { NEXT.setRelease(this, n); } // release, cheaper than setVolatile
}

5) wait / notify / Condition — correct semantics

The chapter covered locks and AQS but never touched thread coordination via wait/notify — one of the buggiest spots in real code.

Three iron rules:

1. Call wait/notify/notifyAll only while you hold that object's monitor, or you get an IllegalMonitorStateException.
2. Always put wait inside a loop that re-checks the condition, not an if. Two reasons: spurious wakeups, which the JLS explicitly permits, and that by the time it's your turn the condition may be false again.

synchronized (queue) {
    while (queue.isEmpty()) {   // ✅ while, not if
        queue.wait();
    }
    return queue.remove();
}

6) Progress-guarantee taxonomy: wait-free / lock-free / obstruction-free

The chapter called CAS "lock-free." A senior must know this term precisely because interviewers set traps around it.

7) Deadlock vs livelock vs starvation, and the JIT's lock optimizations

The chapter mentioned "global lock ordering" to prevent deadlock. Distinguish the three concurrency failures:

• Deadlock: threads wait for each other forever (a wait cycle). The four Coffman conditions must all hold (mutual exclusion, hold-and-wait, no-preemption, circular-wait); breaking one suffices — usually circular-wait, via a global lock order.
• Livelock: threads aren't blocked and keep working but make no progress — like a tryLock loop that releases and immediately retries on every failure; the fix is randomized backoff.
• Starvation: some threads progress but one never gets a turn (writer starvation in ReadWriteLock).

8) Invisible gotchas that bite in production

volatile int[] data;   // only the array reference itself is volatile
data[5] = 42;          // ❌ this write has no volatile semantics!