Java Concurrency Interview Questions: From Keywords to Contended Systems

The first half is language level. What volatile guarantees and what it does not, why synchronized is both mutual exclusion and a memory barrier, what happens-before means in practice. These have precise answers and interviewers expect precision.

The second half is systems level, and it is where the round is decided: a service that is fine at low load and degrades sharply at high load, and why. Nothing about that is recall. It is whether you can reason about contention.

Say what the problem is before the keyword that solves it. Without ordering guarantees, one thread can observe another thread's writes out of order or not at all, because compilers and CPUs reorder freely in the absence of a rule.

Then volatile: visibility and ordering, no atomicity. The canonical trap is a volatile counter being incremented, which is three operations wearing one keyword. Be ready to say why that is broken rather than only that it is.

Then happens-before as the rule that makes reasoning possible at all, and where you get it: lock release to acquire, volatile write to read, thread start, thread join.

Know when an atomic class beats a lock and when it loses. Compare-and-swap is excellent under low contention and degrades under high contention, because failed attempts retry and burn CPU. That reversal is a favourite follow-up.

Know what a concurrent collection actually promises. Its per-operation guarantees are not a guarantee about a sequence of operations, and check-then-act across two calls on a thread-safe map is still a race.

Know why thread pool sizing differs for CPU-bound and IO-bound work, and what an unbounded queue does to a service under overload: it converts a fast failure into a slow memory exhaustion, which is worse.

Throughput stops scaling with more threads. Be able to walk through it: is the bottleneck lock contention, connection pool exhaustion, a downstream limit, or context switching. Say what you would measure for each rather than guessing between them.

Have one real concurrency bug prepared. Intermittent, hard to reproduce, and eventually explained. What made it visible, how you narrowed it, what the actual race was, and what you changed so the class of bug could not return.

If the fix was to remove shared state rather than guard it better, say so. Recognising that the strongest concurrency fix is often less concurrency is a senior signal.