Concurrency And Multithreading Fundamentals

What's being tested

This tests thread-safety reasoning: recognizing shared mutable state, choosing the right synchronization primitive, and avoiding races, deadlocks, and visibility bugs. Interviewers look for whether you can write correct concurrent code, explain invariants, and reason about interleavings beyond the happy path.

Patterns & templates

• Mutex-protected critical section — guard every read/write of shared state with Lock / synchronized; keep locked regions small and exception-safe.

• Producer-consumer queue — use BlockingQueue, Condition, or wait/notify; handle spurious wakeups with while, not if.

• Read/write separation — use ReadWriteLock when reads dominate writes; beware writer starvation and upgrade deadlocks.

• Atomic counters and CAS — use AtomicInteger, compareAndSet, or fetch_add for simple state; avoid composing multiple atomics without a lock.

• Thread pool template — submit independent tasks to ExecutorService; bound queue size to avoid unbounded memory growth under load.

• Deadlock prevention — acquire locks in a global order; avoid calling external/user code while holding a lock.

• Visibility guarantees — use volatile, locks, or atomics for happens-before ordering; do not rely on timing or sleep.

Common pitfalls

Pitfall: Treating volatile as a replacement for a lock; it gives visibility, not atomic compound operations like check-then-act.

Pitfall: Using if around wait() / Condition.await(); spurious wakeups and stolen notifications require rechecking the predicate.

Pitfall: Over-synchronizing the whole method and accidentally serializing all work, hiding correctness bugs while failing performance expectations.

Practice these

The practice cards below cover the canonical concurrency variants — solve all of them and time yourself.