دام‌ها و الگوهای همزمانیConcurrency Pitfalls & Patterns

Let's be honest with each other: concurrency is where even strong programmers get humbled. Code that runs flawlessly on a single thread can suddenly produce wrong answers or hang forever the moment two threads touch the same data. The good news is that all of these disasters fall into a small number of families, and each family has a battle-tested pattern that defeats it. In this lesson we'll build that whole map in your head — from scratch.

Part 0 — words you must know

Before anything else, let's unpack a few words that recur throughout, each with an analogy, so you never get lost later.

• Thread: an independent line of execution. Picture each thread as a worker busy at the same time as the others.
• Lock: the key to a room. Only one worker can hold the key at a time; the rest wait outside. In Java, synchronized and the ReentrantLock class create this key.
• Reentrant: a worker who holds a room's key can re-enter the same room without blocking. Java's synchronized monitors are reentrant.
• Atomic: an operation that either happens completely or not at all — no other worker can observe a half-finished state mid-operation.
• Interleaving: the order in which the OS weaves together the steps of different workers. You have no control over this order, and that's exactly where bugs are born.

Mental model: liveness vs. safety

Let's start with the biggest idea, because the rest of the lesson lives under its shadow. Every concurrency bug, without exception, violates one of two properties:

• Safety means "nothing bad ever happens." A race condition corrupts state, a HashMap resizes into an infinite loop, a check-then-act sees a stale value. Safety failures produce wrong answers.
• Liveness means "something good eventually happens." Deadlock, livelock, and starvation mean threads stop making progress. Liveness failures produce hangs.

Why does this split matter so much? Because the fixes are opposite in spirit, and if you don't grasp that, fixing one bug spawns another.

Senior engineers internalize this split because the fixes conflict. Safety usually needs more coordination (locks, atomics, happens-before). Liveness usually needs less or smarter coordination (lock ordering, timeouts, fairness, non-blocking algorithms). Over-synchronizing to fix a race can create a deadlock; loosening locks to fix a deadlock can reintroduce a race.

The invisible foundation: the Java Memory Model (JMM)

Now a deeper layer. The Java Memory Model (JMM) underpins all of it. Its key term is happens-before: a guaranteed "edge," or relationship, between two operations that says the first is definitely visible to the second.

Without a happens-before edge between a write on thread A and a read on thread B, B may see a stale value, a partially constructed object, or reordered operations — even on x86. What establishes these edges? Locks (synchronized, ReentrantLock), volatile, final fields (after construction), Thread.start/join, and the java.util.concurrent classes.

Deadlock: the four Coffman conditions

A deadlock is a cycle of threads each holding a resource the next one wants. The wonderfully practical fact is that a deadlock requires all four Coffman conditions simultaneously — and if you break just one, deadlock becomes completely impossible.

Let's see the most classic deadlock bug: two bank accounts and two threads transferring money in opposite directions.

// BUG: lock order depends on argument order → circular wait
void transfer(Account from, Account to, long amount) {
    synchronized (from) {
        synchronized (to) {          // T1: A then B; T2: B then A → deadlock
            from.debit(amount);
            to.credit(amount);
        }
    }
}

What happens? Thread 1 calls transfer(A, B, ...) and grabs lock A. At that same instant thread 2 calls transfer(B, A, ...) and grabs lock B. Now thread 1 waits for B (held by thread 2) and thread 2 waits for A (held by thread 1). The wait cycle is complete; both block forever.

Fix 1: global lock ordering (breaks circular wait)

The idea is simple and elegant: give every lockable object a stable, unique ordering key and always acquire in that order, regardless of the order the caller passed.

void transfer(Account from, Account to, long amount) {
    Account first  = from.id() < to.id() ? from : to;  // total order by id
    Account second = from.id() < to.id() ? to : from;
    synchronized (first) {
        synchronized (second) {
            from.debit(amount);
            to.credit(amount);
        }
    }
}

Now an edge case: if from.id() == to.id() (a self-transfer) you'd synchronized the same monitor twice — harmless because Java monitors are reentrant (remember? a worker holding the key can re-enter), but you should still guard against a same-account transfer semantically. And when no natural unique key exists, use System.identityHashCode and a tie-breaker lock for the rare collision of equal hashes:

private static final Object TIE = new Object();

void transfer(Account from, Account to, long amount) {
    int hf = System.identityHashCode(from), ht = System.identityHashCode(to);
    if (hf < ht)       lockedTransfer(from, to, amount);
    else if (hf > ht)  lockedTransfer(to, from, amount, /*reverse*/ true);
    else synchronized (TIE) { lockedTransfer(from, to, amount); } // hash collision
}

The TIE lock covers the rare case where two distinct objects happen to have equal identityHashCodes and can't be ordered; in that one rare case a single shared lock keeps the ordering consistent.

Fix 2: tryLock with timeout (breaks no preemption)

The second strategy, instead of ordering locks, lets a thread escape an eternal wait: rather than "wait however long it takes," say "try for at most 50 milliseconds; if it fails, give up and retry."

boolean transfer(Account from, Account to, long amount, Duration timeout)
        throws InterruptedException {
    long deadline = System.nanoTime() + timeout.toNanos();
    while (System.nanoTime() < deadline) {
        if (from.lock.tryLock(50, TimeUnit.MILLISECONDS)) {
            try {
                if (to.lock.tryLock(50, TimeUnit.MILLISECONDS)) {
                    try { from.debit(amount); to.credit(amount); return true; }
                    finally { to.lock.unlock(); }
                }
            } finally { from.lock.unlock(); } // ALWAYS release the outer lock
        }
        // couldn't get both: back off a randomized amount to avoid livelock
        Thread.sleep(ThreadLocalRandom.current().nextInt(1, 10));
    }
    return false;
}

Detecting deadlock in production

Suppose that despite all precautions, a server hangs in production. How do you confirm it's a deadlock?

• Thread dump: jstack <pid> (or kill -3) prints a "Found one Java-level deadlock" section with the exact cycle. This is your first move on any hung JVM.
• Programmatic: ThreadMXBean.findDeadlockedThreads() can run on a watchdog thread and alert automatically.

ThreadMXBean mx = ManagementFactory.getThreadMXBean();
long[] deadlocked = mx.findDeadlockedThreads(); // null if none
if (deadlocked != null) log.error("DEADLOCK: {}", Arrays.toString(deadlocked));

Livelock and starvation

Deadlock isn't the only way to hang. It has two close cousins that are more deceptive because the threads appear busy.

Livelock: threads are not blocked — they're actively running — but keep responding to each other and make no progress. In code it appears when threads back off and retry in lockstep, or when message-passing actors keep handing a task back and forth. The cure is asymmetry: randomized backoff (the nextInt(1, 10) above), or a priority/token that breaks the symmetry. If both people in the corridor flipped a coin to decide who goes first, the symmetry breaks and the problem is solved.

Starvation: a thread never gets a resource because others perpetually win the race. Causes include unfair locks under heavy contention, thread-priority abuse, and a busy writeLock starving readers (or vice versa). Fixes:

• Use fair locks where latency tails matter: new ReentrantLock(true). A fair lock is like the orderly bakery queue — first come, first served. Fairness trades throughput for bounded waiting, so measure before defaulting to it.
• Prefer ReentrantReadWriteLock with a fairness/downgrade policy, or StampedLock for read-heavy workloads. Note: StampedLock is not reentrant and its optimistic reads must be validated (we'll see it shortly).

Race conditions and check-then-act

A race condition is when a program's correctness depends on the interleaving of threads — an order you don't control.

The most common shape of a race is check-then-act: you observe a value and act on it, but the value changes in between.

// BUG: classic check-then-act — two threads can both pass the null check
private Connection conn;
Connection get() {
    if (conn == null) {          // check
        conn = open();           // act — two connections leak, or worse
    }
    return conn;
}

ConcurrentHashMap invites a subtler version of the same trap — subtle because the map itself is thread-safe, so people assume the danger is gone:

// BUG: get-then-put is not atomic; two threads compute twice, one wins
Value v = map.get(key);
if (v == null) {
    v = expensiveCompute(key);
    map.put(key, v);             // last write wins; wasted work; inconsistent v
}

The point is this: each ConcurrentHashMap operation is atomic on its own, but when you place a get and a put side by side, that combination is no longer atomic. The fix is to use a single atomic operation — which is precisely why the concurrent collections exist:

// computeIfAbsent runs the mapping function atomically per key
Value v = map.computeIfAbsent(key, this::expensiveCompute);

Now a small but ubiquitous race — the compound "read-modify-write" on a counter:

count++;                         // BUG: read, add, write — three steps, not atomic

That innocent ++ is actually three steps: read the value, add one, write it back. Two threads can read the old value at the same time and both write old+1 — one increment is lost. Fixes, in ascending order of scalability:

synchronized (lock) { count++; }             // correct, contended
AtomicLong count = ...; count.incrementAndGet(); // CAS, better under moderate contention
LongAdder adder = ...; adder.increment();        // striped, best under HIGH contention

Producer–consumer with BlockingQueue

Hand-rolling wait/notify producer-consumer is a rite of passage and a source of endless bugs (missed signals, lost wakeups, notify vs notifyAll). In production you almost always use a BlockingQueue, which encapsulates the bounded buffer, the condition waiting, and the backpressure all in one.

BlockingQueue<Task> queue = new ArrayBlockingQueue<>(1000); // bounded → backpressure

// Producer
void produce(Task t) throws InterruptedException {
    queue.put(t);   // BLOCKS when full — this is desirable backpressure
}

// Consumer with a poison-pill shutdown
static final Task POISON = new Task.Poison();
void consumeLoop() throws InterruptedException {
    while (true) {
        Task t = queue.take();        // BLOCKS when empty
        if (t == POISON) { queue.put(POISON); return; } // re-insert for siblings
        handle(t);
    }
}

"Backpressure" is an important term worth unpacking right here: it means that when the consumer is slow, that slowness propagates backward — to the producer — and calms it down too. Without backpressure, a fast producer fills memory until the program crashes. Key choices:

• Bounded (ArrayBlockingQueue, bounded LinkedBlockingQueue) gives backpressure — producers slow down instead of the heap exploding. Prefer bounded. An unbounded queue turns a load spike into an OutOfMemoryError.
• SynchronousQueue has zero capacity: every put hands directly to a take — like passing a hot plate hand-to-hand rather than setting it on the counter. It's the engine behind Executors.newCachedThreadPool and forces true rendezvous.
• Poison pill is the clean shutdown idiom: enqueue a sentinel so consumers exit after draining the real work, rather than being interrupted mid-work. Re-insert it so multiple consumers all see it.

The hand-rolled version (know it for interviews)

Even though you'll use BlockingQueue in practice, interviewers love to see you build a bounded buffer by hand. This is the correct version:

// Correct bounded buffer with a single lock and two conditions
class BoundedBuffer<E> {
    private final Object[] buf;
    private int count, head, tail;
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notFull  = lock.newCondition();
    private final Condition notEmpty = lock.newCondition();

    BoundedBuffer(int cap) { buf = new Object[cap]; }

    void put(E e) throws InterruptedException {
        lock.lock();
        try {
            while (count == buf.length) notFull.await(); // while, NOT if
            buf[tail] = e; tail = (tail + 1) % buf.length; count++;
            notEmpty.signal();
        } finally { lock.unlock(); }
    }
    @SuppressWarnings("unchecked")
    E take() throws InterruptedException {
        lock.lock();
        try {
            while (count == 0) notEmpty.await();
            E e = (E) buf[head]; buf[head] = null;       // null out for GC
            head = (head + 1) % buf.length; count--;
            notFull.signal();
            return e;
        } finally { lock.unlock(); }
    }
}

Two senior-level rules are baked into this code. First: always wait in a while, never an if. Why? Because between the moment you're signaled and the moment you reacquire the lock, another thread may have snatched that empty slot; and per the Java spec, a "spurious wakeup" is also allowed — meaning you can sometimes wake with no signal at all. The only safe pattern is re-checking the predicate in a loop. Second: use two separate conditions (notFull and notEmpty) so a signal on "not full" never wastefully wakes a consumer waiting on "not empty."

Coordination primitives: latches, barriers, semaphores, phasers

So far we worked with locks. But sometimes you don't want "exclusive access" — you want to coordinate threads, like "everyone start together" or "everyone wait until the last one arrives." Java ships ready-made tools for this.

Let's see CountDownLatch in action — the classic "start everyone together, then wait for everyone to finish" pattern:

// CountDownLatch: start N workers together, wait for all to finish
CountDownLatch ready = new CountDownLatch(1);   // release gate
CountDownLatch done  = new CountDownLatch(N);
for (int i = 0; i < N; i++) new Thread(() -> {
    ready.await();          // all block until the gate opens
    work();
    done.countDown();       // signal completion
}).start();
ready.countDown();          // fire the starting gun
done.await();               // main waits for everyone

Here ready is a gate that opens when its count hits zero; all workers wait behind it until main fires the pistol. done starts at N, and each worker counts it down as it finishes; when it hits zero, main is released.

CountDownLatch counts down to zero and stays there — it cannot be reset, it's one-shot. When you need a repeatable rendezvous, use CyclicBarrier, which can run a barrier action when the last thread arrives and then resets itself:

CyclicBarrier barrier = new CyclicBarrier(N, () -> mergePhaseResults());
// each worker calls barrier.await() at the end of every phase

Now Semaphore, which bounds concurrency — the canonical connection-pool or rate-limiter:

Semaphore permits = new Semaphore(10, /*fair*/ true);
void call() throws InterruptedException {
    permits.acquire();
    try { doRemoteCall(); } finally { permits.release(); } // release in finally, always
}

And finally Phaser: it generalizes both latch and barrier. Parties can register/deregister dynamically, and it supports multiple phases without reconstruction — ideal for fork/join-style staged pipelines where the number of participants changes during execution.

The three classic problems

Every concurrency textbook has three famous puzzles, each illuminating one of the Coffman conditions. We already solved the first.

Bounded buffer — solved above (producer-consumer).

Readers–writers

Many readers may share; a writer needs exclusivity. ReentrantReadWriteLock handles it, but naive use starves writers under constant read traffic (if there's always some reader reading, the writer never gets its turn).

ReentrantReadWriteLock rw = new ReentrantReadWriteLock(true); // fair → no writer starvation
Lock r = rw.readLock(), w = rw.writeLock();

Object read()  { r.lock(); try { return data; } finally { r.unlock(); } }
void  write(Object x) { w.lock(); try { data = x; } finally { w.unlock(); } }

For read-dominated data, StampedLock has a superb trick: optimistic read, which takes no lock at all on the happy path.

StampedLock sl = new StampedLock();
double distanceFromOrigin() {
    long stamp = sl.tryOptimisticRead();      // no lock taken
    double cx = x, cy = y;                     // read fields
    if (!sl.validate(stamp)) {                 // a writer intervened?
        stamp = sl.readLock();                 // fall back to a real read lock
        try { cx = x; cy = y; } finally { sl.unlockRead(stamp); }
    }
    return Math.sqrt(cx * cx + cy * cy);
}

The logic is: grab a "stamp," read without locking, then ask "did a writer come by in the meantime?" If not, your read was valid and it cost nothing. If so, fall back to a real read lock. Note: StampedLock is not reentrant and not Condition-capable — respect those limits.

Dining philosophers

The naive "grab left, then right" deadlocks when all grab left simultaneously. We have two clean fixes, each breaking a different Coffman condition:

// Fix A: break symmetry — one philosopher picks up right-first (resource ordering)
void dine(int id, Lock left, Lock right) {
    Lock first = (id == LAST) ? right : left;   // one philosopher inverts
    Lock second = (id == LAST) ? left : right;
    first.lock();
    try { second.lock();
        try { eat(); } finally { second.unlock(); }
    } finally { first.unlock(); }
}

// Fix B: limit concurrency to N-1 seated philosophers via a semaphore
Semaphore seats = new Semaphore(PHILOSOPHERS - 1);
void dine(...) throws InterruptedException {
    seats.acquire();               // at most 4 of 5 may contend for forks
    try { left.lock(); right.lock();
        try { eat(); } finally { right.unlock(); left.unlock(); }
    } finally { seats.release(); }
}

Immutability and confinement as strategies

We've learned plenty of tools for managing sharing. But the best strategy is to have no shared mutable state at all.

Immutability.

An object whose fields are all final and never escape during construction is safely published through the JMM's final-field guarantee and can be shared freely without synchronization. Java records make this natural:

record Money(long cents, String currency) {          // deeply immutable
    Money add(Money o) {                              // returns a NEW instance
        if (!currency.equals(o.currency)) throw new IllegalArgumentException();
        return new Money(cents + o.cents, currency);
    }
}

Confinement. Keep data on one thread so no synchronization is needed at all. It has three forms:

• Thread confinement via ThreadLocal — each thread gets its own copy. But beware leaks: on a thread pool, a ThreadLocal you don't remove() lives as long as the worker thread and can pin large objects or classloaders — a classic web-app memory leak. Always remove() in a finally.
• Stack confinement — local variables and objects that never escape a method are automatically thread-safe, because each thread has its own stack. Prefer this by default; it's free.
• Instance confinement — guard mutable state behind an object's own lock and never let a reference escape. This is the Java monitor pattern done deliberately and consciously.

Concurrency testing tips

Techniques that actually find these bugs:

• jcstress — the OpenJDK harness built specifically to expose JMM/reordering bugs by running billions of interleavings and classifying outcomes. Use it for any low-level lock-free code you write.
• Stress with contention: run many threads (> cores) in a tight loop for seconds, use a CyclicBarrier to make them all start at the exact same instant (maximizing overlap), and assert an invariant afterward.
• -Xint / -XX:-TieredCompilation and running on ARM/weak-memory hardware surface reordering that x86's strong memory model hides.
• Deadlock watchdog in tests: a background ThreadMXBean.findDeadlockedThreads() poll that fails the test the moment a cycle appears, instead of hanging CI.
• Thread.sleep in tests is a smell — it makes tests slow and still flaky. Use latches/barriers to express the actual ordering you want to force.
• Fuzz the scheduler: tools like Thread.yield() injection, or JPF (Java PathFinder) model checking for exhaustive small-scope interleavings.

The honest truth: you reason correctness in with happens-before, keep the shared surface tiny, and use tests only to catch regressions.

Interview Questions

Now it's time to gather everything into real interview questions. Read each with its full answer and try to answer it yourself before you look.

List<Integer> list = new ArrayList<>();
IntStream.range(0, 4).parallel().forEach(list::add);
System.out.println(list.size());

if (!map.containsKey(k)) map.put(k, compute(k)); // map is ConcurrentHashMap

Senior notes & advanced edge cases

So far we built the map of concurrency bugs and their defensive patterns. But what separates a real senior from a merely good programmer is not knowing synchronized and BlockingQueue — everyone knows those. The difference lives where code breaks in production under real load: the thread pool that silently ignores your extra threads, the swallowed InterruptedException that quietly kills cancellation for the whole system, the CompletableFuture blocking on the wrong pool, and the bugs that live at the level of the CPU cache line. This section is exactly that layer.

The thread pool — where most production incidents are born

Most of the concurrency code you actually write never touches a raw Thread. You build an ExecutorService and hand it tasks. Behind Executors.newFixedThreadPool(...) sits a ThreadPoolExecutor, and that class has a task-admission logic that will ambush you one day if you don't know it.

The admission order for a new task is precisely this, and its order is exactly where people go wrong:

1) if active threads < corePoolSize  → create a core thread and run it
2) else, offer the task to the queue (queue.offer)
3) if the queue is full  → create extra threads up to maximumPoolSize
4) if that too is full   → invoke the RejectedExecutionHandler

The diagram below shows this decision flow (Task admission flow):

flowchart TD
  A[New task submitted] --> B{active < corePoolSize?}
  B -- yes --> C[Start core thread]
  B -- no --> D{queue.offer succeeds?}
  D -- yes --> E[Task waits in queue]
  D -- no --> F{active < maximumPoolSize?}
  F -- yes --> G[Start extra thread]
  F -- no --> H[RejectedExecutionHandler]

Now the killer trap. Step 2 says "while the queue has room, enqueue." If your queue is unbounded (like a capacity-less LinkedBlockingQueue — which is exactly what newFixedThreadPool builds), offer never fails. That means step 3 never runs, and your maximumPoolSize is a purely decorative number.

The saturation policies (invoked when both queue and threads are full) must be chosen deliberately:

• AbortPolicy (default): throws RejectedExecutionException — the caller finds out.
• CallerRunsPolicy: runs the task in the calling thread itself. This is a brilliant automatic backpressure brake — the web thread that wanted to submit is forced to do the work itself and cannot accept new tasks while it does.
• DiscardPolicy / DiscardOldestPolicy: silently drops work — almost always wrong, because you lose data with no signal.

And two shutdown facts I constantly see wrong in review:

Interruption is a protocol, not a kill switch

The biggest misconception among young seniors is thinking thread.interrupt() "kills" a thread. It doesn't. Interrupt merely sets a boolean flag on the thread; it is a polite cancellation request that the code itself must respond to. The entire cancellation mechanism in Java is built on this contract.

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    // ... nothing
}

The correct rule has two cases. If you can propagate the InterruptedException upward, do so (let your method throw it). If you cannot (e.g. inside a Runnable whose signature forbids it), you must restore the flag:

try {
    queue.take();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt(); // restore the flag
    return; // and exit the loop/task
}

And for long compute loops that contain no blocking method (so never receive an InterruptedException), you must poll the flag yourself:

while (!Thread.currentThread().isInterrupted()) {
    doOneChunkOfWork();
}

CompletableFuture: async composition and its traps

The main chapter covered Future and executors but not the modern async-composition tool — CompletableFuture (since Java 8). This is what lets you build a non-blocking chain of stages instead of blocking on future.get().

The first distinction interviewers ask: thenApply vs thenCompose.

// thenApply: synchronous function, value → value
CompletableFuture<Integer> len = fetchUser(id).thenApply(User::name).thenApply(String::length);

// thenCompose: a function that itself returns a CompletableFuture → flattens it (flatMap)
CompletableFuture<Order> order = fetchUser(id).thenCompose(u -> fetchLatestOrder(u)); // no nested future

If you pass thenApply a function that itself returns a CompletableFuture, you get a CompletableFuture<CompletableFuture<T>> — exactly like map vs flatMap on a stream. thenCompose is the flatMap.

Exception handling has its own trap: in a chain, an exception skips the following stages until it reaches exceptionally/handle.

fetchUser(id)
    .thenApply(this::risky)
    .exceptionally(ex -> User.GUEST)      // catches only the error path, supplies a value
    .thenAccept(this::render);
// handle(value, ex) catches both paths; whenComplete is a side-effect and does not alter the exception

Since Java 9, orTimeout(...) and completeOnTimeout(...) were added so you no longer have to hand-roll timeouts.

ConcurrentHashMap<K, CompletableFuture<V>> cache = new ConcurrentHashMap<>();
V get(K key) {
    CompletableFuture<V> f = cache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> compute(k)));
    return f.join();
}

Double-checked locking and the holder idiom

A classic pattern the chapter didn't cover: lazy, thread-safe initialization without taking a lock on the hot path. The naive version was broken for years:

private Helper helper; // BUG: no volatile
Helper get() {
    if (helper == null) {                 // check 1 (no lock)
        synchronized (this) {
            if (helper == null)           // check 2 (with lock)
                helper = new Helper();
        }
    }
    return helper;
}

But there's a cleaner, better way that needs no volatile and no double-check at all — the initialization-on-demand holder idiom:

class Config {
    private Config() { /* expensive */ }
    private static class Holder { static final Config INSTANCE = new Config(); }
    static Config get() { return Holder.INSTANCE; } // lazy + thread-safe, free
}

The hardware layer: false sharing

Some performance bugs have nothing to do with your code's logic and live in the CPU's cache line. The processor moves memory not byte-by-byte but in 64-byte blocks (cache lines).

If two independent variables that different threads write to happen to land on the same cache line, every write by one invalidates the other's cache, and the CPU's coherency protocol keeps ping-ponging that line between cores. The code is correct but perhaps 5–10× slower. It's called false sharing because there's no actual sharing.

CAS and the ABA problem

The chapter covered AtomicLong and CAS but not one of the subtlest bugs in non-blocking algorithms: the ABA problem. CAS says "if the value is still A, change it to B." But what if, between your read and your CAS, the value went from A to X and back to A? Your CAS succeeds, because it only sees the value, not the history.

In lock-free linked structures (like a Treiber stack that reuses nodes from a free-list), ABA can reattach a freed node and corrupt the structure. The fix: attach a version number (stamp) to each value.

AtomicStampedReference<Node> top = new AtomicStampedReference<>(head, 0);
int[] stampHolder = new int[1];
Node cur = top.get(stampHolder);
// ... CAS with the value *and* the next stamp; even if the value returns to cur, the stamp differs
top.compareAndSet(cur, next, stampHolder[0], stampHolder[0] + 1);

AtomicStampedReference makes the value and an int counter atomic together; now A→X→A no longer fools you because the stamp has advanced. (AtomicMarkableReference is the boolean variant for logical-deletion marking.)

The modern-Java concurrency map (2025–2026)

A few big changes every senior should know in a 2026 interview:

private static final ScopedValue<User> CURRENT = ScopedValue.newInstance();
ScopedValue.where(CURRENT, user).run(() -> handleRequest()); // readable in scope, not outside

Hard senior interview questions

try { doBlockingWork(); }
catch (InterruptedException e) { log.warn("interrupted"); }