1. Loss of Atomicity#

A “read-modify-write” operation must execute as an indivisible unit. When OS time-slicing interrupts execution mid-sequence, atomicity is violated.

2. Visibility Failure#

When Thread A writes 900 back to main memory, Thread B may keep reading its own stale cached value of 1000. Modifications made by one thread stay invisible to others.

3. Instruction Reordering#

To maximize instruction throughput, compilers and CPUs aggressively reorder instructions. This is safe in single-threaded code, but reordering can cause race conditions across threads. For instance, if a compiler reorders the write to a data buffer and a readyFlag, another thread may observe readyFlag == true before data has actually been initialized.

Key takeaway: Concurrency defects originate from CPU caches, OS thread scheduling, and compiler/CPU instruction reordering. Together they break atomicity, visibility, and ordering. Java’s concurrency constructs exist to restore these three properties.

2.1 volatile: Lightweight Visibility and Ordering#

Applying the volatile modifier enforces two behaviors:

• Visibility: reads bypass CPU caches and fetch directly from main memory; writes flush immediately to main memory.
• Ordering: memory barriers prevent instruction reordering across the field access.

Limitation: volatile does not guarantee atomicity. Individual reads or writes to a volatile field are atomic, but compound operations—such as count++—are not.

1
// Ideal volatile use case: a single-writer state flag
2
public class TaskRunner {
3
    private volatile boolean running = true;
4

5
    public void stop() { running = false; } // writer thread
6
    public void run() {
7
        while (running) { /* process */ }   // reader thread(s) notice the change immediately
8
    }
9
}

2.2 synchronized: Intrinsic Mutual Exclusion#

When atomicity is required, locks are necessary. Java’s intrinsic synchronized keyword guarantees all three memory properties:

• Atomicity: only one thread executes a synchronized block at a time.
• Visibility: flushes local memory to main memory on lock release, and refreshes local memory on lock acquisition.
• Ordering: prevents instructions inside the synchronized block from being reordered across its boundaries.

2.3 ReentrantLock: Advanced Synchronization Control#

ReentrantLock complements synchronized by offering explicit, more flexible synchronization control:

• Interruptible acquisition: lockInterruptibly() lets a thread abort if it’s interrupted while waiting.
• Timed acquisition: tryLock(timeout, unit) bounds the wait and helps avoid deadlocks.
• Multiple condition objects: newCondition() supports multiple wait-sets per lock instance (e.g., separate notFull and notEmpty conditions).

3.1 Semaphore: Concurrency Throttling#

• Use case: resource pooling (e.g., capping database connections at 10) or rate limiting.
• Mechanism: maintains an internal permit counter backed by AQS shared mode. acquire() decrements permits (blocking if none are available); release() increments permits and wakes a parked thread.

3.2 CountDownLatch: One-Time Event Barrier#

• Use case: blocking a main thread until $N$ background tasks complete.
• Mechanism: initialized with a count. Each call to countDown() decrements it; threads calling await() block until the count reaches zero.
• Constraint: not reusable—the counter cannot be reset once it hits zero.

3.3 CyclicBarrier: Reusable Phase Synchronization#

• Use case: synchronizing $N$ parallel execution paths (e.g., multi-step parallel processing) where all threads must reach a checkpoint before any can proceed.
• Mechanism: initialized with a participant count (parties). Calling await() blocks until all $N$ threads reach the barrier, then releases them simultaneously. It accepts an optional Runnable that runs once, executed by the last thread to arrive—and the barrier automatically resets for the next cycle.

3.4 Exchanger: Point-to-Point Data Handoff#

• Use case: two-thread pipeline handoffs where a pair of threads swaps buffers.
• Mechanism: both threads call exchange(data). The runtime blocks the first arrival until the second arrives, then atomically swaps payloads between them.

3.5 Phaser: Dynamic Multi-Phase Coordination#

• Use case: complex iterative computations where the number of participating tasks changes across distinct lifecycle stages.
• Mechanism: extends the capabilities of CyclicBarrier and CountDownLatch by allowing parties to dynamically register and deregister across advancing phases.

4.1 Compare-And-Swap (CAS) Mechanics#

CAS executes as an atomic CPU instruction (e.g., CMPXCHG on x86).

CAS takes three inputs:

1. Memory location ($V$)
2. Expected old value ($E$)
3. New value ($N$)

$V$ is updated to $N$ if and only if $V == E$. Otherwise, the operation fails without modifying $V$, and the caller typically retries.

4.2 Atomic Primitives (java.util.concurrent.atomic)#

Classes like AtomicInteger, AtomicLong, and AtomicReference use CAS retry loops for lock-free, single-variable mutation.

1
// Lock-free increment pattern inside AtomicInteger
2
public final int incrementAndGet() {
3
    for (;;) {
4
        int current = get();
5
        int next = current + 1;
6
        if (compareAndSet(current, next))
7
            return next;
8
    }
9
}

5.1 ConcurrentHashMap#

• JDK 7 implementation: used an array of Segments (segmented locking), spreading contention across isolated lock regions.
• JDK 8+ implementation: drops segments in favor of CAS for lock-free bucket initialization, combined with per-bucket synchronized locking on the head node of each bin. Lock granularity is scoped to individual buckets, significantly improving concurrent throughput.

5.2 CopyOnWriteArrayList#

• Mechanism: reads execute lock-free against an immutable array reference. Writes copy the underlying array, apply the mutation, and atomically swap in the new array reference.
• Use case: optimized for read-heavy, write-rare workloads (e.g., event listener registries).

5.3 Blocking Queues (BlockingQueue)#

• Implementations such as ArrayBlockingQueue and LinkedBlockingQueue handle producer-consumer coordination out of the box, offering bounded put() (blocks when full) and take() (blocks when empty) without manual wait/notify boilerplate.

Reference Table#