Multithreading & Concurrency

wait()/notify()/notifyAll() (inherited from Object) are the original, low-level thread coordination primitives, tied directly to intrinsic locks:

synchronized (lock) {
    while (!conditionMet) {
        lock.wait(); // must be in a while-loop, not if — spurious wakeups are possible
    }
    // proceed
}

// elsewhere
synchronized (lock) {
    conditionMet = true;
    lock.notifyAll(); // notify(), not notifyAll(), risks waking the "wrong" waiter and losing a signal
}

Pitfalls that make this error-prone: you must call wait()/notify() while holding the object's monitor (IllegalMonitorStateException otherwise), a notify() can wake an arbitrary one of several waiting threads (use notifyAll() unless you're certain only one kind of waiter exists), spurious wakeups mean the condition must be rechecked in a loop, and signals sent before a thread starts waiting are simply lost (no queuing).

java.util.concurrent (since Java 5) provides higher-level, more composable alternatives for the same problems:

• Lock/Condition (ReentrantLock.newCondition()): like wait/notify but supports multiple independent condition queues per lock, timed waits, and interruptible/tryLock acquisition.
• CountDownLatch/CyclicBarrier/Semaphore: purpose-built for common coordination patterns (wait for N tasks, rendezvous, limit concurrent access) without hand-rolling wait/notify logic.
• BlockingQueue: encapsulates the entire producer-consumer wait/notify dance behind put()/take().
• CompletableFuture: composable async pipelines, replacing manual thread coordination with declarative .thenApply()/.thenCombine() chains.

Practical guidance: reach for java.util.concurrent utilities first; hand-written wait/notify is now mostly relevant for understanding fundamentals and for rare cases needing that exact low-level control.

ExecutorService is the standard abstraction for running asynchronous tasks: you submit work (Runnable/Callable), and a managed pool of worker threads executes it, handling thread creation, reuse, and shutdown for you.

ExecutorService pool = Executors.newFixedThreadPool(4);
Future<Integer> future = pool.submit(() -> compute());
pool.execute(() -> doSomething()); // fire-and-forget
pool.shutdown(); // stop accepting new tasks, let queued/running ones finish

Executors provides several convenience factories (all really just pre-configured ThreadPoolExecutors):

• newFixedThreadPool(n): a fixed number of threads; extra tasks queue up on an unbounded queue until a thread frees up. Good for CPU-bound work with a known, stable concurrency level.
• newCachedThreadPool(): creates new threads as needed, reuses idle ones, and kills threads idle for 60s. Good for many short-lived, bursty tasks, but can create unbounded threads under sustained load if tasks queue up faster than they finish.
• newSingleThreadExecutor(): exactly one worker thread, tasks run serially in submission order — useful when you need strict ordering.
• newScheduledThreadPool(n): supports delayed and periodic task execution (schedule, scheduleAtFixedRate, scheduleWithFixedDelay).

Modern guidance: many teams now avoid the Executors factory methods in production, because newFixedThreadPool/newCachedThreadPool use unbounded queues or unbounded thread creation respectively — both are potential resource-exhaustion risks under load. Constructing new ThreadPoolExecutor(...) directly lets you specify a bounded work queue and an explicit rejection policy, giving predictable backpressure instead of silently accumulating memory.

Always call shutdown() (graceful) or shutdownNow() (attempts to cancel in-flight tasks) when done, and typically awaitTermination(...) to wait for a clean stop — otherwise the JVM may hang on exit waiting for non-daemon pool threads.

Future<V> (Java 5+) represents a value that will be available later, from an asynchronous computation submitted to an ExecutorService:

Future<Integer> future = executor.submit(() -> compute());
future.isDone();      // check without blocking
int result = future.get(); // blocks until the result is ready (or throws)
future.cancel(true);   // attempt to cancel

Its big limitation: there's no way to react to completion without blocking — no callback registration, no chaining a follow-up computation, no combining two futures' results. You either poll isDone() in a loop or block on get().

CompletableFuture<T> (Java 8+) implements Future but adds a rich, functional, non-blocking composition API:

CompletableFuture<Integer> cf = CompletableFuture
    .supplyAsync(() -> fetchUserId())
    .thenApply(id -> id * 2)                       // transform the result
    .thenCompose(id -> fetchProfileAsync(id))      // chain another async call
    .exceptionally(ex -> { log(ex); return null; }); // handle failure

CompletableFuture<Void> both = CompletableFuture.allOf(cf1, cf2, cf3); // wait for several
CompletableFuture<Integer> combined = cf1.thenCombine(cf2, (a, b) -> a + b);

Key additions over plain Future:

• thenApply/thenAccept/thenRun: chain transformations without blocking.
• thenCompose: flatten a future-returning function (avoids Future<Future<T>>).
• thenCombine/allOf/anyOf: combine results from multiple independent futures.
• exceptionally/handle: structured error handling in the pipeline itself, instead of a try/catch around a blocking get().
• Manual completion: complete(value) lets non-executor code (e.g., a callback-based API) resolve the future directly.

CompletableFuture is the standard building block for non-blocking async pipelines in modern Java, similar in spirit to Promises in JavaScript.

Three widely-used coordination utilities from java.util.concurrent, each solving a distinct pattern:

CountDownLatch — one or more threads wait for a set of operations (potentially in other threads) to finish, tracked by a countdown from an initial number to zero. One-shot: once it reaches zero, it stays open forever; it cannot be reset or reused.

CountDownLatch latch = new CountDownLatch(3);
// 3 worker threads each call latch.countDown() when done
latch.await(); // main thread blocks until count reaches 0

Typical use: wait for several parallel startup tasks to finish before proceeding, or have a main thread wait for N worker threads to complete.

CyclicBarrier — a fixed number of threads all wait for each other at a common barrier point; once the last one arrives, all are released simultaneously. Unlike CountDownLatch, it's reusable — it automatically resets for the next "round" once released (hence "cyclic"), and supports an optional action run once all parties arrive.

CyclicBarrier barrier = new CyclicBarrier(3, () -> System.out.println("all arrived"));
barrier.await(); // each of 3 threads blocks here until all 3 have called await()

Typical use: parallel simulation steps where every worker must finish step N before any starts step N+1.

Semaphore — maintains a set number of permits; threads acquire() a permit (blocking if none are available) and release() it when done, limiting how many threads can access a resource concurrently. A Semaphore with 1 permit behaves like a (non-reentrant) lock; with N permits, it caps concurrent access at N.

Semaphore semaphore = new Semaphore(5); // at most 5 concurrent accesses
semaphore.acquire();
try { accessLimitedResource(); } finally { semaphore.release(); }

Typical use: throttling concurrent connections to a database or external service to a fixed maximum.

Older Hashtable/synchronizedMap wrap every operation in a single lock covering the whole map — only one thread can touch the map at all, even for unrelated keys.

ConcurrentHashMap (redesigned in Java 8) instead achieves much finer-grained concurrency:

• Per-bin (bucket) synchronization: updates that need to modify a bucket's linked list/tree only synchronize on that specific bucket's head node, not the whole table. Two threads writing to different buckets don't block each other at all.
• CAS (compare-and-swap) for simple cases: for many operations — like inserting into an empty bucket — ConcurrentHashMap uses lock-free CAS operations (Unsafe/VarHandle compare-and-set) instead of acquiring a lock at all, since a single-element bucket insert can be done atomically without synchronization.
• Reads are (mostly) lock-free: get() doesn't lock at all — it relies on volatile reads of bucket references and node values, so reads never block on writes and writes never block on reads (though a read might occasionally see a slightly stale view during a resize, which is acceptable for its "weakly consistent" iteration guarantee).
• Incremental resizing: when the table needs to grow, multiple threads can cooperatively help move nodes from the old table to the new one in the background, rather than one thread performing a full stop-the-world rehash.

The net effect: contention is limited to threads that happen to hit the same bucket at the same time — for a well-sized, well-distributed map, real contention is rare, giving throughput far closer to an unsynchronized HashMap than to a globally-locked Hashtable.

java.util.concurrent.atomic provides wrapper classes (AtomicInteger, AtomicLong, AtomicBoolean, AtomicReference<V>, ...) offering thread-safe, lock-free operations on a single variable:

AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();       // atomic ++counter, no synchronized needed
counter.compareAndSet(5, 10);    // atomically: if current value == 5, set to 10
counter.getAndAdd(3);            // atomic counter += 3, returns old value

How it works: instead of a lock, these classes use the CPU's native CAS (compare-and-swap) instruction, exposed via sun.misc.Unsafe/java.lang.invoke.VarHandle. CAS atomically checks "is the current value still what I last read?" and, if so, swaps in the new value — all as one indivisible hardware operation. If another thread changed the value in between, the CAS fails and the atomic class's method retries the read-modify-write loop internally until it succeeds.

// conceptually what incrementAndGet() does:
do {
    int current = get();
    int next = current + 1;
} while (!compareAndSet(current, next));

Why this beats a plain synchronized int counter for simple cases: no thread ever blocks waiting for a lock — under contention, a losing thread just retries its CAS loop rather than parking and waking up (which involves OS scheduling overhead). For low-to-moderate contention, this is significantly faster than lock-based synchronization.

Limitation: atomics only cover a single variable's atomicity. If you need multiple related variables updated together consistently (e.g., a bank account's balance and its transaction count), you still need a lock (or a single AtomicReference to an immutable object holding both fields together).

A ThreadLocal<T> provides a variable where each thread that accesses it sees its own independently initialized copy — reads and writes from one thread are invisible to, and unaffected by, any other thread's use of the same ThreadLocal instance.

private static final ThreadLocal<SimpleDateFormat> FORMATTER =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

String format(Date d) {
    return FORMATTER.get().format(d); // each thread gets its own SimpleDateFormat instance
}

Common use cases:

• Per-request context in a web server: stashing the current user, request ID, or locale so it's accessible anywhere in the call stack without threading it through every method signature — frameworks like Spring's RequestContextHolder use this internally.
• Non-thread-safe utility objects: classes like the legacy SimpleDateFormat aren't thread-safe; giving each thread its own instance via ThreadLocal avoids both external synchronization and the cost of creating a new instance per call.
• Per-thread transaction/connection tracking in database access frameworks.

Implementation, briefly: each Thread object internally holds a small map (ThreadLocalMap) keyed by ThreadLocal instance, so get()/set() look up the calling thread's own entry.

Pitfall — memory leaks in thread pools: because pooled threads are long-lived and reused across many tasks, a ThreadLocal value set by one task can persist and leak into a later, unrelated task on the same pooled thread if not cleaned up. Always call threadLocal.remove() (typically in a finally block) once the per-task work is done, especially in server/pool environments — otherwise you risk both a memory leak (the value keeps the referenced object alive) and stale-context bugs.

Without any synchronization, the Java Memory Model (JMM) gives almost no guarantee that one thread will see another thread's writes in any particular order, or at all — the compiler, JIT, and CPU are all allowed to reorder instructions and cache values in registers/CPU caches for performance, as long as a single-threaded program's observable behavior is unaffected. That freedom is exactly what causes subtle multithreaded bugs when code assumes an ordering the JMM never promised.

The happens-before relationship is the JMM's formal way of defining which cross-thread orderings are guaranteed. If action A happens-before action B, then: (1) A's effects (writes to memory) are visible to B, and (2) A is guaranteed to be ordered before B from the perspective of any thread observing both. Critically, happens-before does not mean "happened earlier in wall-clock time" — it's a guarantee the JMM enforces, not an incidental timing observation.

Key rules that establish happens-before (a partial list):

• Program order rule: within a single thread, each action happens-before every subsequent action in that thread's program order.
• Monitor lock rule: an unlock on a monitor happens-before every subsequent lock on that same monitor (by any thread) — this is why synchronized gives both mutual exclusion and visibility.
• Volatile variable rule: a write to a volatile field happens-before every subsequent read of that same field.
• Thread start rule: Thread.start() happens-before any action in the started thread.
• Thread join rule: every action in a thread happens-before another thread successfully returns from join() on it.

volatile boolean ready = false;
int data = 0;

// Thread 1
data = 42;
ready = true;   // volatile write — happens-before any later read of `ready`

// Thread 2
if (ready) {    // volatile read
    print(data); // guaranteed to see 42, NOT 0, because of the happens-before edge
}

Without the volatile (or an equivalent lock), Thread 2 could legally observe ready == true but data == 0 — the JMM permits that reordering in the absence of an explicit happens-before edge. This is the theoretical foundation behind why synchronized, volatile, and the java.util.concurrent utilities all work: they each establish specific happens-before edges the JMM otherwise doesn't guarantee.