Multithreading & Concurrency

Every Java object has an implicit monitor (intrinsic lock) associated with it — that's what synchronized acquires and releases. Only one thread can hold a given object's monitor at a time; any other thread trying to enter a synchronized block on that same object blocks until it's released. It's reentrant — a thread already holding the lock can re-enter another synchronized block guarded by the same monitor without deadlocking itself (the JVM tracks a hold count).

• Deadlock — threads are stuck, doing nothing, waiting on each other forever.
• Livelock — threads are actively doing work (not blocked), but keep responding to each other in a way that prevents any of them from making real progress — e.g. two people repeatedly stepping aside for each other in a hallway, forever.
• Starvation — a thread never gets CPU time or a lock because other threads (often higher priority, or just "greedier") keep getting scheduled/served ahead of it.

See the Deadlock / Livelock / Starvation deep dive → for detection and mitigation strategies.

Classic answer: a shared bounded buffer, producers wait() when it's full, consumers wait() when it's empty, and each side notifyAll() the other after changing the buffer's state. In modern code you almost never hand-roll this — BlockingQueue already implements exactly this pattern internally.

BlockingQueue<Task> queue = new LinkedBlockingQueue<>(100);

// Producer thread
queue.put(task); // blocks if full

// Consumer thread
Task t = queue.take(); // blocks if empty

ThreadLocal<T> gives each thread its own independent copy of a variable — reads/writes on one thread never affect another thread's copy, so no synchronization is needed. Common uses: per-request context (e.g. the current user or a request ID in a web app, propagated through code that doesn't want to thread a parameter through every method call), SimpleDateFormat instances (not thread-safe, so one per thread avoids sharing), and database connection/transaction binding.

Gotcha: with thread pools, threads are reused across requests — if you forget to remove() the value at the end, stale data can leak into the next task that happens to reuse that pooled thread.

Classes like AtomicInteger use compare-and-swap (CAS), a hardware CPU instruction, instead of locks: "if the current value still equals what I last read, replace it with my new value — atomically, in one step." If another thread changed the value in between, the CAS fails and the atomic class simply retries the read-modify-write in a loop, without ever blocking a thread.

loop:
  current = value           // read
  next    = current + 1
  if CAS(value, current, next) succeeds:
      return next
  else:                      // someone else updated value first
      goto loop              // retry with the fresh value

This is "lock-free" — no thread ever blocks waiting for another — which typically scales better than locking under high contention on a single value.

A Semaphore maintains a set of permits — acquire() blocks if no permits are available and takes one when they are; release() gives one back. Unlike a lock (which is binary — held or not, by exactly one thread), a semaphore can allow N concurrent holders, making it a natural fit for capping concurrent access to a limited resource pool (e.g. "at most 10 concurrent connections to this downstream service"). A semaphore with 1 permit behaves like a lock, except it isn't reentrant and — unlike synchronized/ReentrantLock — the thread that releases a permit doesn't have to be the one that acquired it, which is useful for signaling between different threads.

Future<V> represents a pending async result, but its API is limited: you can only block on it (get()), poll (isDone()), or cancel — there's no way to attach a callback or chain further work without blocking a thread. CompletableFuture<V> (Java 8) implements Future but adds a full functional-style API: thenApply, thenCompose, thenCombine, exceptionally, letting you build a non-blocking pipeline of dependent async steps that only executes a callback once the upstream stage completes.

CompletableFuture.supplyAsync(() -> fetchUser(id))
    .thenApply(User::getName)
    .thenAccept(System.out::println)
    .exceptionally(ex -> { log.error("failed", ex); return null; });

See the CompletableFuture & Async Composition deep dive →.

BlockingQueue extends Queue with operations that block instead of failing/returning a sentinel when the queue can't service the call immediately: put() blocks while full, take() blocks while empty. This makes it the natural building block for producer-consumer pipelines and bounded work queues (which is exactly what backs ThreadPoolExecutor internally). Common implementations: ArrayBlockingQueue (fixed-capacity array), LinkedBlockingQueue (optionally unbounded, linked nodes), and PriorityBlockingQueue (unbounded, orders by priority instead of FIFO).

See the BlockingQueue deep dive →.

Collections.synchronizedList(list) wraps a plain list, synchronizing every individual method call on one shared lock — safe for single operations, but a compound action (like "check if empty, then add") still needs external synchronized around the whole sequence, and every access serializes through that one lock regardless of how many threads just want to read. The java.util.concurrent collections (ConcurrentHashMap, CopyOnWriteArrayList, concurrent queues) are purpose-built for concurrent access: finer-grained internal locking (or none at all for reads), atomic compound operations (computeIfAbsent, putIfAbsent), and fail-safe iteration — generally both faster and safer under real contention.

The simplest thread-safe approach is an enum singleton — the JVM guarantees enum instances are created exactly once, safely, with no extra code. The classic interview answer, though, is double-checked locking with a volatile field:

class Singleton {
    private static volatile Singleton instance; // volatile is essential

    static Singleton getInstance() {
        if (instance == null) {                  // 1st check, no locking (fast path)
            synchronized (Singleton.class) {
                if (instance == null) {           // 2nd check, now holding the lock
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Without volatile, the JIT/CPU could reorder the constructor's writes relative to the assignment of instance, letting another thread observe a non-null but partially-constructed object. An even simpler alternative that avoids all of this: the initialization-on-demand holder pattern, which leans on the JVM's own guaranteed-once-and-thread-safe class initialization instead of hand-rolled locking.