Java Concurrency Interview

Threads and lifecycle

The warm-up round. Most interviews open here, and most candidates lose points not because they cannot name the thread states but because they cannot say what the JVM actually does at each transition.

The Java memory model

The rules every other topic depends on. An answer here that says "volatile makes it thread safe" ends the interview early; an answer that can name the happens-before edge passes almost any follow-up.

synchronized, monitors, wait and notify

The oldest tool in the language, and still the one most production code uses. The questions here separate people who have written synchronized from people who know what the JVM does with it.

Locks, conditions and AQS

Everything in java.util.concurrent.locks is one class in a trench coat: AbstractQueuedSynchronizer. Knowing that turns a dozen separate facts into one mechanism you can reason about.

Synchronizers: latches, barriers, semaphores

The coordination primitives, and the topic with the single most predictable interview question in Java: the difference between a latch and a barrier. Knowing the whole family is what separates a memorised answer from a chosen one.

Atomics and compare-and-swap

Lock-free code is not magic, it is one CPU instruction plus a retry loop. Interviewers use this topic to find out whether "lock-free" is a word you have read or a mechanism you can draw.

Concurrent collections

Choosing the wrong collection is the most common real-world concurrency bug, because it does not crash. It just loses data occasionally. Interviewers ask this topic to see whether you know the difference between "thread safe" and "correct for my access pattern".

Executors and thread pools

The topic where interview answers most often come from a tutorial rather than from an incident. Every question below has cost somebody a production outage at some point.

CompletableFuture and async composition

Where interviews go once "I would use a thread pool" is settled. The trap in this topic is that everything compiles and runs, and only the thread it runs on and the exception you never see are wrong.

Fork/join and parallel streams

One method call turns a stream parallel, which is why this topic is full of code that is slower than the sequential version it replaced. Interviewers ask it to see whether you can say no.

Virtual threads and structured concurrency

Java 21 made threads cheap. That invalidates a decade of advice, and interviewers now use this topic to find out whether a candidate has actually used them or only read the announcement.

Concurrency in real systems

Where core Java meets the frameworks people actually ship. These questions are the ones a backend interview reaches after the language questions are settled, and the answers are usually about which thread your code is on and which pool is about to run out.

Deadlock, livelock and diagnostics

The half of concurrency that only exists in production. Interviewers like this topic because it cannot be answered from a tutorial: either you have read a thread dump at 3am or you have not.

Patterns and antipatterns

Design judgement, which is what a senior interview is actually testing. The right answer here is usually the one that removes shared mutable state rather than the one that guards it more cleverly.

Testing concurrent code

Asked far less often than it should be, and a strong differentiator when you can answer it. Most candidates describe a test with a Thread.sleep in it, which is exactly the thing that does not work.

Live coding puzzles

The whiteboard round. Each of these has a canonical solution short enough to write in ten minutes, and an obvious wrong version the interviewer is hoping you avoid.