Concurrency & Threads

// Traditional: limited by OS thread overhead, typically capped around a few thousand concurrent threads
ExecutorService platformPool = Executors.newFixedThreadPool(200);

// Virtual threads: can create millions, each cheap, automatically unmounted during blocking I/O
try (ExecutorService virtualExecutor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++) {
        virtualExecutor.submit(() -> {
            // blocking I/O call here doesn't tie up a scarce OS thread
            makeBlockingHttpCall();
        });
    }
}

Common follow-ups: What specific blocking operations cause a virtual thread to be unmounted from its carrier thread, and are there operations that still "pin" a virtual thread (blocking the carrier)?;How does this change the calculus around whether to adopt a reactive programming model versus simple thread-per-request going forward?

// Error-prone raw wait/notify pattern (requires careful, easy-to-get-wrong discipline)
synchronized (lock) {
    while (!conditionMet) {  // MUST be a while loop, not if, due to spurious wakeups
        lock.wait();
    }
    // proceed once condition is met
}

// Preferred modern alternative: BlockingQueue handles all this coordination internally
BlockingQueue<Task> queue = new LinkedBlockingQueue<>();
Task task = queue.take();  // blocks safely until an item is available, no manual wait/notify needed

Common follow-ups: What is a spurious wakeup, and why does this necessitate the while-loop condition re-check pattern?;How does BlockingQueue implement producer-consumer coordination internally, and does it still ultimately rely on similar low-level primitives?

Thread t = new Thread(() -> System.out.println("Running on: " + Thread.currentThread().getName()));

t.start();  // correct: prints a NEW thread name, e.g. "Thread-0", runs concurrently
t.run();    // mistake: prints "main", runs synchronously on the CURRENT thread, no concurrency at all

Common follow-ups: Can you call start() more than once on the same Thread object?;What exception is thrown if you attempt to call start() twice on the same Thread instance?

// Race condition example: unsynchronized shared counter increment
int[] counter = {0};
Runnable increment = () -> counter[0]++;  // read-modify-write, not atomic
// Running this concurrently from multiple threads produces an unpredictable, often INCORRECT final count

// Deadlock example: two threads waiting on each other's locks (see lock ordering question for full example)
// Produces NO progress at all, rather than a wrong-but-completed result

Common follow-ups: What tools or techniques would you use to detect each type of bug (race condition versus deadlock) in a running application?;Can a single bug exhibit characteristics of both a race condition and a deadlock simultaneously?

# Generate a thread dump for a running Java process
jstack <pid> > threaddump.txt

# The output includes an explicit section like:
# "Found one Java-level deadlock:"
# "Thread-0" waiting to lock monitor 0x... (object lockB), which is held by "Thread-1"
# "Thread-1" waiting to lock monitor 0x... (object lockA), which is held by "Thread-0"

Common follow-ups: What's the difference between a thread in BLOCKED state versus WAITING versus TIMED_WAITING in a thread dump?;How would you capture a thread dump automatically as part of an incident response runbook without manual intervention?