Java Concurrency & Multithreading, End to End

Concurrency isn't a language feature bolted onto Java — it's a direct answer to a hardware problem. Every idea below, from volatile to CompletableFuture, exists because of the same underlying fact: CPU cores got fast, memory didn't keep up, and caches created a world where two threads can honestly disagree about the value of a variable. Keep that one sentence in mind and the rest of this guide reads as consequences, not trivia.

00JVM memory architecture

Before threads, you need the map they live on. Each Java program you run is one OS process and one JVM instance — completely isolated from every other JVM instance, even one running the exact same program. Two JVMs never share heap memory; the same virtual address in each points to different physical RAM.

Inside a single JVM process, memory splits into segments that are either shared across every thread or private to one thread:

From bytecode to a CPU register

Source compiles to bytecode (.class), which the JVM interprets at first, then profiles for "hot" methods and compiles to native machine code via the JIT. Each thread has its own register set and Program Counter — the PC tracks exactly which instruction a thread is on, and registers hold the JIT's optimized intermediate values. Both are saved and restored on every context switch.

Context switching, briefly

When the OS scheduler moves a core from Thread A to Thread B, it saves A's registers, program counter, and stack pointer to a control block in RAM, then restores B's. This is expensive for two reasons beyond the save/restore cost itself: the cache is now "cold" for the new thread, so its next few memory accesses pay full RAM latency, and — when switching processes rather than threads — the CPU's address-translation cache is flushed too. This is part of why Project Loom's virtual threads, scheduled by the JVM rather than the OS, are cheaper to switch.

01Why concurrency exists

Concurrency is not a software abstraction invented for convenience — it's a consequence of hardware history.

• Single-core era: the OS faked parallelism via time-slicing; only one instruction ever executed at a time.
• The memory wall: through the 1990s–2000s, clock speeds grew far faster than RAM access speed. CPU caches were built to bridge that gap.
• The multi-core turn (~2005): manufacturers hit a power/heat ceiling on clock speed and added cores instead. A modern laptop has 8–16; a server may have 128.

A single-threaded Java program on a 16-core machine uses roughly 6% of available CPU. Concurrency is the tool that unlocks the other 94% — at the cost of introducing race conditions, deadlocks, visibility bugs, and liveness failures that don't exist in single-threaded code. The rest of this guide is about taming exactly those costs.

02Thread life cycle — all six states

Every Java thread moves through exactly six states, defined by Thread.State.

Java doesn't distinguish "ready to run" from "actually running on a core" — both are just RUNNABLE. The JVM delegates scheduling entirely to the OS, and tracking the exact sub-state would require expensive, platform-specific calls the abstraction deliberately avoids.

03Creating threads

new Thread(() -> ...) does nothing at the OS level. It allocates a plain Java object on the heap, copies thread-group, daemon status, and priority from the calling thread, stores the Runnable in a field, sets an internal threadStatus to 0 (NEW), and assigns an ID. Zero system calls.

Calling .start() is the real event: it's a thin wrapper around a native start0() that asks the OS (pthread_create on Linux, CreateThread on Windows) to create a kernel thread, allocate a native stack (often 512KB–1MB), and register it with the scheduler.

Thread t1 = new Thread(myRunnable);                       // auto-named "Thread-0"
Thread t2 = new Thread(myRunnable, "payment-processor-1"); // always do this in prod
Thread t3 = new Thread(group, myRunnable, "io-worker-1");  // + ThreadGroup
class MyThread extends Thread { public void run(){ /*...*/ } }  // avoid — see §4

Naming threads is not cosmetic. A 2 a.m. thread dump full of Thread-47 tells you nothing; payment-processor-3 tells you exactly where to look.

Daemon vs. non-daemon

The JVM exits once every non-daemon thread has terminated — daemon threads are killed outright, mid-task, without ceremony. Use non-daemon for work that must finish (writing files, committing transactions); daemon for interruptible housekeeping (log flushing, heartbeats). Thread pool threads are non-daemon by default — this is exactly why forgetting executor.shutdown() keeps a JVM alive forever.

04Runnable vs. extending Thread

Both work. Only one scales.

05The synchronized keyword

Every Java object carries a monitor (intrinsic lock) as part of its header. At most one thread can own a given monitor at a time; everyone else trying to acquire it goes BLOCKED.

What synchronized actually guarantees

• Atomicity — the block runs as one indivisible unit from every other thread's point of view.
• Visibility — releasing a monitor flushes writes to main memory; acquiring one invalidates the local cache and re-reads from memory.
• Happens-before ordering — everything before a release is visible to whoever acquires next.
• Mutual exclusion — exactly one owner at a time.
• Reentrancy — the owning thread can re-acquire its own lock; the JVM tracks a hold count.

public class SafeCounter {
    private final Object lock = new Object(); // nobody outside can grab this
    private int count = 0;
    public void increment() {
        synchronized (lock) { count++; }
    }
}

Deadlock — the classic setup

// Thread 1: synchronized(lockA) { ... synchronized(lockB) { work(); } }
// Thread 2: synchronized(lockB) { ... synchronized(lockA) { work(); } }
// Each holds what the other wants. Neither proceeds.

Prevent it with a consistent global lock order, tryLock(timeout) instead of blocking forever, the smallest possible lock scope, and by avoiding holding two locks at once wherever you can.

06The volatile keyword

volatile exists to defeat exactly the cache visibility problem from §00: writes go straight through to main memory, reads come straight from it, and a memory barrier stops the compiler/CPU reordering instructions across the access.

The double-checked-locking singleton

public class Singleton {
    private static volatile Singleton instance;   // volatile is load-bearing here
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();   // alloc → init → assign
                }
            }
        }
        return instance;
    }
}

Without volatile, the JVM may reorder "initialize the object" and "assign the reference," letting another thread see a non-null, half-constructed instance. The memory barrier forbids exactly that reordering.

07wait() and notify()

Polling a condition in a loop with Thread.sleep(10) wastes CPU and adds latency. wait()/notify() suspend a thread completely — zero CPU — until precisely signaled.

Three iron rules

1. Must be called from inside a synchronized block on the same object — otherwise IllegalMonitorStateException.
2. wait() atomically releases the monitor and suspends — there is no gap where you'd hold the lock but miss a signal.
3. After being notified, the thread must re-acquire the monitor before it runs again — it goes BLOCKED first, never straight to RUNNABLE.

public synchronized void produce(T item) throws InterruptedException {
    while (queue.size() == capacity) wait();   // WHILE, never if
    queue.offer(item);
    notifyAll();
}
public synchronized T consume() throws InterruptedException {
    while (queue.isEmpty()) wait();
    T item = queue.poll();
    notifyAll();
    return item;
}

08wait() vs. sleep()

sleep() inside a synchronized block holds the lock the entire time — every other thread trying to enter is blocked for the full duration. That's a common, easy-to-miss source of accidental serialization. Also worth knowing: Thread.sleep() is static — calling it on a thread reference (t.sleep(1000)) actually sleeps the current thread, not t.

09Thread.join()

t.join() blocks the caller until t reaches TERMINATED. Internally it's implemented with wait() on the Thread object itself — the JVM calls notifyAll() on it when the thread finishes.

Thread t1 = new Thread(() -> sort(data, 0, mid));
Thread t2 = new Thread(() -> sort(data, mid, data.length));
t1.start(); t2.start();     // run in parallel
t1.join();  t2.join();      // barrier — both halves guaranteed sorted
merge(data, mid);

In modern code, prefer CompletableFuture.allOf(...).join(), CountDownLatch.await(), or ExecutorService.invokeAll() — all more flexible than raw join().

10Runnable vs. Callable

Callable<Integer> job = () -> expensiveCalculation();
Future<Integer> future = executor.submit(job);
Integer result = future.get();  // blocks for the result

// Bare Thread only accepts Runnable — bridge with FutureTask
FutureTask<String> task = new FutureTask<>(callable);
new Thread(task).start();   // FutureTask implements Runnable
String r = task.get();      // ...and Future<V>

Exceptions thrown from call() are wrapped in ExecutionException and surface at future.get() — they don't crash the pool thread.

11Stopping a thread, correctly

volatile boolean running = true;
while (running) { doWork(); }
// caller: running = false;

catch (InterruptedException e) {
    Thread.currentThread().interrupt(); // restore it!
}

Restoring the flag matters: catching InterruptedException clears it automatically, so if you swallow the exception silently, every caller further up the stack loses the fact that an interrupt ever happened.

For pools, prefer executor.shutdown() (graceful) and, if needed, shutdownNow(), which sends interrupt() to every running task — one more reason interrupt-responsive code matters even when you never touch a raw Thread.

12Thread pools — internals

Creating a thread costs a system call, a native stack allocation, and scheduler registration. At 1,000 requests/second, a thread-per-request model means 1,000 thread creations a second. Pools amortize that cost by reusing a fixed, warm set of threads.

All four are convenience wrappers around ThreadPoolExecutor, which you should configure explicitly in production:

new ThreadPoolExecutor(
    4, 8, 60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(200),        // bounded — gives back-pressure
    myThreadFactory,                      // name your threads
    new ThreadPoolExecutor.CallerRunsPolicy()  // rejection policy
);

The four rejection policies

• AbortPolicy (default) — throws RejectedExecutionException.
• CallerRunsPolicy — the submitting thread runs the task itself, a natural, self-throttling back-pressure.
• DiscardPolicy — silently drops the task.
• DiscardOldestPolicy — drops the oldest queued task and retries submission.

Sizing rules of thumb

CPU-bound: corePoolSize = maxPoolSize = number of cores — more threads than cores just adds context-switch overhead with no throughput gain. IO-bound: cores × (1 + wait_time / compute_time) — a thread that's 90% waiting on IO needs roughly 10x more threads than cores to keep one core saturated. Either way: estimate, then load-test and tune from real measurements, never a guess.

13corePoolSize vs. maxPoolSize

Spring's ThreadPoolTaskExecutor follows the exact same algorithm as §12 above. With corePoolSize=4, maxPoolSize=8, queue capacity 100: tasks 1–4 start core threads; tasks 5–104 simply queue with no new threads; only task 105 (queue now full) creates the pool's fifth thread; task 109 with 8 threads busy and the queue still full finally triggers the rejection policy.

@Bean
public ThreadPoolTaskExecutor taskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(4);
    executor.setMaxPoolSize(8);
    executor.setQueueCapacity(200);
    executor.setThreadNamePrefix("my-service-");
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    executor.initialize();
    return executor;
}

Expose getPoolSize(), getActiveCount(), and getQueue().size() as metrics — and alert well before the queue nears capacity, not after.

14java.util.concurrent — the full toolkit

Prefer these battle-tested building blocks over hand-rolled synchronized whenever they fit.

Locks

Atomics — compare-and-swap, no locking

AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();                    // atomic i++
counter.compareAndSet(10, 20);                // CAS: only if current == 10
counter.updateAndGet(x -> x * 2);              // atomic functional update

CAS is a single CPU instruction — no OS lock, no thread parking, no context switch — which is why atomics dramatically outperform synchronized for simple counters under contention.

Concurrent collections

Synchronizers

// CountDownLatch — one-shot barrier
CountDownLatch latch = new CountDownLatch(3);
executor.submit(() -> { doWork(); latch.countDown(); });
latch.await();  // blocks until count hits 0

// CyclicBarrier — reusable rendezvous point for N threads
CyclicBarrier barrier = new CyclicBarrier(4, () -> System.out.println("all arrived"));

// Semaphore — bounded concurrent access
Semaphore semaphore = new Semaphore(3);
semaphore.acquire(); try { useResource(); } finally { semaphore.release(); }

15Mutex patterns in Java

Java has no class literally called Mutex — three things implement the same one-owner-at-a-time semantics, each with a real trade-off.

ReentrantLock's biggest structural win over synchronized: multiple named Conditions. A bounded buffer needs to wake producers and consumers separately — synchronized only gives you one wait set and forces a blanket notifyAll(); ReentrantLock lets you notFull.signal() and notEmpty.signal() independently, waking only the threads that can actually proceed.

16java.util.concurrent.Future

Future<V> is a handle to a background computation submitted via Callable.

Integer result = future.get();                       // blocks indefinitely
Integer result = future.get(5, TimeUnit.SECONDS);    // bounded wait
boolean done = future.isDone();                      // non-blocking check
future.cancel(true);                                 // interrupt if running

Its real limitation is that get() is blocking with no callback, chaining, or combining story — exactly the gap CompletableFuture was built to close.

17ThreadLocal

Every Thread object owns a private ThreadLocalMap keyed by ThreadLocal instances. Two threads reading the same ThreadLocal get completely independent values — no sharing, no synchronization required.

private static final ThreadLocal<SimpleDateFormat> FORMAT =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));
// each thread gets its own formatter — SimpleDateFormat itself isn't thread-safe

InheritableThreadLocal copies a value to a child thread at creation time — which means it does not propagate into thread-pool workers, since those threads are created once at pool startup, not per task. For request-context propagation into a pool, use a framework's TaskDecorator equivalent instead.

18CompletableFuture

CompletableFuture<V> lets you describe what happens when a result becomes available, without blocking anything to wait for it.

CompletableFuture.supplyAsync(() -> fetchUser(id))
    .thenCompose(user -> fetchOrder(user.getId()))   // next step IS async → thenCompose
    .thenApply(order -> order.getTotal())            // pure transform → thenApply
    .exceptionally(ex -> BigDecimal.ZERO)             // fallback on any failure
    .thenAccept(total -> render(total));

// Waiting for several independent futures
CompletableFuture.allOf(cf1, cf2, cf3).join();

19The Java Memory Model

The JMM specifies exactly when a write by one thread becomes visible to another. Its central idea is happens-before: if action A happens-before action B, every effect of A is guaranteed visible to B.

• Program order — actions within one thread happen-before each other, in order.
• Monitor release/acquire — releasing a lock happens-before the next thread acquiring that same lock.
• volatile write/read — a volatile write happens-before any subsequent read of it.
• Thread start/join — start() happens-before anything in the new thread; everything in a thread happens-before a successful join() on it.
• Transitivity — A before B, B before C, therefore A before C.

Safe publication means an object becomes visible to other threads only in a state the JMM guarantees is fully initialized — via final fields, a volatile write after construction, or static initialization (which the class-loading mechanism guarantees is safe on its own).

20Common concurrency bugs

21Interview questions

Core concepts

Synchronization

Thread pools

CompletableFuture & ThreadLocal

Advanced

Quick reference

Resources

For going deeper than any single-page guide can, in roughly the order this page introduces the topics: