Software EngineeringBackend Engineer to Staff/Principal Systems Engineer17 min read·Updated for 2026 Interview Formats

Concurrency Interview Guide: Threads, Locks, Race Conditions & Deadlocks

From CPU Scheduling to Lock-Free Data Structures: Master the Questions That Separate Senior Engineers From the Rest

Priya Nakamura

Ex-FAANG Staff Engineer & Low-Latency Systems Specialist

13+ Years Building Multi-Threaded Trading & Messaging Systems

Prep Timeline

3 to 5 Weeks

Format

OS Fundamentals, Live Coding, System Design Deep-Dive

Conversion

+71% Concurrency Round Pass Rate

Concurrency Interview Guide: Threads, Locks, Race Conditions & Deadlocks

Executive Summary & Key Takeaways

What You Must Master to Clear This Track

Know the exact cost difference between a process context switch and a thread context switch, and why it matters for scheduler design.
Memorize the 4 necessary conditions for deadlock (Coffman conditions) and be able to name a concrete prevention strategy for each.
Be able to implement a bounded producer-consumer queue from scratch using a lock and condition variable, not just describe it.
Understand the happens-before relationship and why volatile alone does not make a compound operation like i++ thread-safe.
Distinguish lock-free from wait-free algorithms, and explain the ABA problem in compare-and-swap based structures.

Structured Preparation Timeline

Step-by-Step Study Plan

Follow this sequential roadmap designed to take you from core foundations to advanced architecture and mock interviews.

Phase 1 (Week 1)

Processes, Threads & the Locking Toolbox

OS Foundations & Synchronization Primitives

Process vs thread memory model, CPU scheduling, thread lifecycle, and the core primitives: mutex, semaphore, monitor, and read-write locks.

Key Milestones

•Explain why thread context switches are cheaper than process context switches (no TLB flush, shared address space).
•Implement a critical section using a mutex and reason about mutual exclusion, progress, and bounded waiting.
•Differentiate binary semaphores (signaling, no ownership) from mutexes (ownership, priority inheritance).

Recommended Actions

•Draw the 5-state thread lifecycle diagram (New, Runnable, Blocked, Waiting, Terminated) from memory.
•Trace through a round-robin scheduler with a fixed quantum on paper for 3 competing threads.

Phase 2 (Week 2-3)

Diagnosing and Preventing Concurrency Failures

Race Conditions, Deadlocks & Classic Problems

Race condition anatomy, the 4 necessary conditions for deadlock, prevention/avoidance/detection strategies, and the classic producer-consumer and dining philosophers problems.

Key Milestones

•Reproduce a two-thread, two-lock deadlock on a whiteboard and identify which of the 4 Coffman conditions to break.
•Implement the producer-consumer pattern with a bounded buffer, blocking correctly on full/empty conditions.
•Explain lock ordering, try-lock with timeout, and the Banker's Algorithm as three distinct deadlock-avoidance strategies.

Recommended Actions

•Practice tracing thread interleavings for a shared counter increment to spot the exact race window.
•Rewrite the dining philosophers solution using resource (lock) ordering instead of a waiter/arbitrator.

Phase 3 (Week 4-5)

Visibility Guarantees & High-Throughput Concurrency Patterns

Memory Models & Lock-Free Systems

Happens-before relationships, volatile vs atomic vs synchronized, compare-and-swap, lock-free/wait-free data structures, and thread pool design.

Key Milestones

•Explain why volatile guarantees visibility but not atomicity, and when that distinction breaks production code.
•Implement a lock-free counter using compare-and-swap (CAS) and describe the ABA problem and its fix (versioned references).
•Size a thread pool correctly for CPU-bound vs I/O-bound workloads using the utilization formula.

Recommended Actions

•Mock-interview yourself explaining the JMM happens-before rules for volatile writes, lock releases, and thread starts.
•Compare a lock-based queue against a lock-free ring buffer under contention and articulate the trade-offs out loud.

Deep-Dive Architecture & Concepts

1. Processes vs. Threads & CPU Scheduling

Every concurrency interview starts by testing whether you understand what the operating system is actually juggling underneath your code: isolated processes with their own address space, versus lightweight threads that share one.

Process: The Isolation Boundary

A process owns its own virtual address space, file descriptors, and heap. Switching between processes requires flushing the Translation Lookaside Buffer (TLB) and swapping page tables, which is expensive due to cache and TLB misses.

Thread: The Execution Unit

Threads within a process share the heap, global data, and file handles, but each gets its own stack, program counter, and register set. Thread switches only save/restore registers, making them far cheaper than process switches.

CPU Scheduling Strategies

Preemptive schedulers (Round Robin with a fixed time quantum, Completely Fair Scheduler in Linux using a red-black tree of virtual runtimes) forcibly interrupt running threads; cooperative schedulers rely on threads yielding voluntarily.

Thread Lifecycle States

New -> Runnable (ready or actively executing) -> Blocked (waiting on I/O or a lock) -> Waiting/Timed Waiting (waiting on a condition or join) -> Terminated. Interviewers probe whether you know Blocked and Waiting are distinct states.

Interviewer Insights & Pro Tips

When asked to size a thread pool, quote the formula: Threads = N_cpu * U_target * (1 + Wait/Compute), and explain that I/O-bound work justifies a much larger pool than CPU-bound work.
If asked 'why not just spawn a thread per request', bring up per-thread stack memory cost (typically 512KB-1MB) and OS scheduler overhead at high thread counts, then pivot to thread pools or event loops.

Red Flags & Common Pitfalls

Saying threads are 'always faster' without acknowledging that CPU-bound work on more threads than cores adds context-switch overhead, not speed.
Confusing concurrency (interleaved progress, possible on one core) with parallelism (simultaneous execution, requires multiple cores).

Deep-Dive Architecture & Concepts

2. Synchronization Primitives: Mutex, Semaphore, Monitor & Read-Write Locks

Once you can name the actors (processes and threads), interviewers pivot to the tools that make shared state safe. Expect to be asked to implement, not just describe, at least one of these live.

Mutex (Mutual Exclusion Lock)

Binary, ownership-based lock: only the thread that acquired it may release it. Most runtimes support reentrancy (ReentrantLock in Java) so the owning thread can re-acquire without deadlocking itself.

Semaphore (Counting)

Maintains an integer permit count; any thread can signal (release) regardless of which thread acquired. Used to bound concurrent access to a pool of N identical resources (e.g. a connection pool of size 10).

Monitor & Condition Variables

A monitor bundles a lock with one or more condition variables (wait/notify/notifyAll or await/signal) so a thread can atomically release the lock and block until a predicate becomes true, then re-acquire before proceeding.

Read-Write Lock

Allows unlimited concurrent readers OR one exclusive writer, never both. Ideal for read-heavy caches, but naive implementations can starve writers if reads keep arriving; fair variants queue new readers behind a waiting writer.

Bounded Producer-Consumer Queue with Lock + Condition

java

public class BoundedBuffer<T> {
      private final Queue<T> queue = new ArrayDeque<>();
      private final int capacity;
      private final Lock lock = new ReentrantLock();
      private final Condition notFull = lock.newCondition();
      private final Condition notEmpty = lock.newCondition();
  
      public BoundedBuffer(int capacity) {
          this.capacity = capacity;
      }
  
      public void put(T item) throws InterruptedException {
          lock.lock();
          try {
              while (queue.size() == capacity) {
                  notFull.await(); // release lock, block until space frees up
              }
              queue.offer(item);
              notEmpty.signal(); // wake one waiting consumer
          } finally {
              lock.unlock();
          }
      }
  
      public T take() throws InterruptedException {
          lock.lock();
          try {
              while (queue.isEmpty()) {
                  notEmpty.await(); // release lock, block until an item arrives
              }
              T item = queue.poll();
              notFull.signal(); // wake one waiting producer
              return item;
          } finally {
              lock.unlock();
          }
      }
  }

Why it matters: The while-loop guard (not an if) is essential: on wake-up the thread must re-check the predicate because spurious wake-ups and multiple waiters mean the condition may already be false again by the time it re-acquires the lock.

Interviewer Insights & Pro Tips

If an interviewer asks 'mutex vs semaphore', lead with ownership: a mutex has an owner and only that owner can unlock it; a binary semaphore has no owner concept and any thread can signal it, which is why semaphores double as signaling mechanisms between threads.

Red Flags & Common Pitfalls

Using if instead of while around a condition variable's await() call, which breaks correctness the moment there is more than one waiter.
Forgetting to unlock in a finally block, so an exception thrown inside a critical section leaves the lock permanently held.

Deep-Dive Architecture & Concepts

3. Race Conditions & the Anatomy of Deadlocks

This is the section where interviewers separate candidates who have memorized vocabulary from those who can actually reason about interleavings. Expect a live whiteboard trace of a deadlock forming between two threads.

Race Condition

Occurs when the correctness of a result depends on the non-deterministic timing/interleaving of two or more threads accessing shared state, at least one of them writing. A classic example: two threads executing count++ (read, increment, write) can lose an update.

Critical Section Requirements

A correct solution must guarantee Mutual Exclusion (only one thread inside at a time), Progress (a decision on who enters next isn't postponed indefinitely), and Bounded Waiting (a limit on how many times other threads can cut in line).

The 4 Necessary Conditions for Deadlock (Coffman Conditions)

Mutual Exclusion (resources aren't shareable), Hold and Wait (a thread holds one resource while waiting for another), No Preemption (a resource can't be forcibly taken away), and Circular Wait (a cycle of threads each waiting on the next). All four must hold simultaneously for deadlock to occur.

Deadlock Prevention & Avoidance

Break Hold-and-Wait by acquiring all locks upfront; break Circular Wait via a strict global lock ordering; break No-Preemption with try-lock-and-backoff/timeouts; or use the Banker's Algorithm to avoid ever entering an unsafe state by simulating resource allocation before granting it.

How a Two-Thread, Two-Lock Deadlock Forms

The classic circular-wait sequence: two threads each acquire one lock and then block waiting for the other's lock, with no path forward for either.

Thread-1 acquires Lock A

Thread-1 enters a critical section and successfully locks Account A for a transfer.

Thread-2 acquires Lock B

Concurrently, Thread-2 locks Account B to perform the reverse transfer, B to A.

Thread-1 requests Lock B

Thread-1 now tries to lock Account B to complete its transfer, but Lock B is held by Thread-2, so Thread-1 blocks (Hold and Wait).

Thread-2 requests Lock A

Thread-2 tries to lock Account A to complete its transfer, but Lock A is held by Thread-1, so Thread-2 also blocks.

Circular wait completes: deadlock

Thread-1 waits on Thread-2, and Thread-2 waits on Thread-1. Neither can release its held lock because neither can finish, so both threads are permanently stuck.

Interviewer Insights & Pro Tips

When asked to fix the two-account transfer deadlock above, the textbook answer is to always acquire locks in a fixed global order (e.g. by account ID ascending), which eliminates circular wait entirely regardless of transfer direction.
Distinguish deadlock (all involved threads are permanently blocked) from livelock (threads keep changing state in response to each other but make no progress, e.g. two people repeatedly stepping aside in the same direction) from starvation (a thread is perpetually denied a resource due to unfair scheduling, but other threads do make progress).

Red Flags & Common Pitfalls

Naming only 2 or 3 of the 4 Coffman conditions, which signals memorization gaps under interview pressure.
Proposing 'just add more logging' or 'just restart the service' as a deadlock fix instead of addressing lock ordering or acquisition strategy.
Confusing a database deadlock (two transactions holding row locks and waiting on each other, detected by a wait-for graph) with an OS-level deadlock, when in fact the underlying circular-wait mechanism is identical.

Deep-Dive Architecture & Concepts

4. Memory Models, Lock-Free Structures & Practical Concurrency Patterns

Senior and staff-level rounds push past locking into visibility guarantees and high-throughput designs: what does another thread actually see after a write, and how do you avoid locks altogether under extreme contention?

Happens-Before Relationship

The Java Memory Model (and equivalents in C++11/Rust) define happens-before edges: a write to a volatile field happens-before every subsequent read of that field; unlocking a monitor happens-before a later thread locking the same monitor; thread.start() happens-before any action in the started thread.

volatile vs Atomic vs synchronized

volatile guarantees visibility and prevents instruction reordering around it, but not atomicity of compound operations (i++ on a volatile int is still a data race). Atomic classes (AtomicInteger) use CAS loops for lock-free atomic read-modify-write. synchronized gives both visibility and mutual exclusion at the cost of blocking.

Compare-And-Swap (CAS) & the ABA Problem

CAS atomically updates a memory location only if it still holds an expected value. The ABA problem occurs when a value changes from A to B and back to A between a thread's read and its CAS, fooling the CAS into succeeding incorrectly; fixed with versioned/tagged references (AtomicStampedReference).

Lock-Free, Wait-Free & Thread Pools

Lock-free guarantees system-wide progress (some thread always completes) even if individual threads retry; wait-free guarantees every thread completes in a bounded number of steps, a much stronger and rarer guarantee. Thread pools (fixed, cached, work-stealing ForkJoinPool) amortize thread-creation cost and cap concurrency.

Lock-Free Counter Using Compare-And-Swap

java

public class LockFreeCounter {
      private final AtomicInteger value = new AtomicInteger(0);
  
      public int incrementAndGet() {
          while (true) {
              int current = value.get();
              int next = current + 1;
              // CAS retries automatically if another thread updated 'value'
              // between our read and this compareAndSet call.
              if (value.compareAndSet(current, next)) {
                  return next;
              }
              // else: lost the race, loop and retry with the fresh value
          }
      }
  }

Why it matters: No lock is ever held: contending threads simply retry compareAndSet until it succeeds, which avoids context-switch and priority-inversion costs but can waste CPU cycles under very high contention (mitigated by backoff strategies).

Interviewer Insights & Pro Tips

If asked to justify a lock-free design, be honest about the trade-off: lock-free structures trade worst-case fairness and simplicity for better average-case throughput and immunity to a thread dying mid-critical-section.
For thread pool sizing questions, explicitly separate CPU-bound pools (size ~= number of cores) from I/O-bound pools (size scaled up by the wait/compute ratio, or replaced entirely by an async/event-loop model).

Red Flags & Common Pitfalls

Claiming volatile makes a counter thread-safe for increments; it only prevents caching stale values, it does not make read-modify-write atomic.
Describing lock-free and wait-free as synonyms; wait-free is a strictly stronger, harder-to-achieve guarantee.

Real-World Example

Resolving a Production Deadlock in a Payment Reconciliation Service

A fintech backend team's nightly reconciliation batch job began intermittently freezing in production, holding open database connections until a health-check killed the pod. The freezes only occurred when reconciliation for two merchant accounts ran concurrently and happened to reference each other's ledger entries in the same batch window.

1Pulled thread dumps during a live freeze and found two worker threads each BLOCKED waiting to acquire a row lock the other thread already held, a textbook circular wait.
2Traced the code path and confirmed each transfer transaction locked the source account row first, then the destination account row, with no consistent ordering between the two.
3Reproduced the deadlock reliably in a local test by forcing two threads to process a same-pair transfer in opposite directions concurrently.
4Refactored the transfer logic to always acquire row locks in ascending account-ID order regardless of transfer direction, eliminating circular wait structurally.
5Added a defensive lock-acquisition timeout with automatic retry-with-backoff as a second line of defense in case a future code path reintroduced inconsistent ordering.
6Rolled the fix out behind a feature flag to one region first and monitored lock-wait metrics before a full deployment.

Outcome: Zero reconciliation deadlocks occurred in the 90 days following the fix, down from an average of 3-4 pod restarts per week caused by the freeze.

Real-World Interview Questions

Mistakes That Sink Otherwise Strong Candidates

Using if instead of while when checking a condition variable's predicate after wait()/await() returns.

Why it happens: Developers assume the thread wakes only when the condition is truly satisfied, forgetting spurious wake-ups and the fact that another thread may have already consumed the resource between the signal and this thread re-acquiring the lock.

The fix: Always wrap the wait() call in a while loop that re-checks the exact predicate before proceeding, never a one-time if check.

Assuming volatile makes compound operations like counter++ thread-safe.

Why it happens: volatile does prevent stale cached reads, so it 'feels' like it should fix a shared counter, but it says nothing about atomicity of the underlying read-modify-write sequence.

The fix: Use AtomicInteger/AtomicLong (CAS-based) for simple counters, or a lock for anything spanning multiple variables that must update together.

Acquiring multiple locks in inconsistent order across different code paths.

Why it happens: Different features or team members write independent code paths that each lock the same two resources but in a different order based on local convenience, unaware of the global interaction.

The fix: Establish and document a single canonical lock-acquisition order (e.g. by resource ID) across the entire codebase, and enforce it in code review or via a lint rule.

Forgetting to release a lock in a finally block, so an exception leaves it held forever.

Why it happens: The happy-path unlock() call is added right after the critical section without considering that an exception thrown mid-section skips it entirely.

The fix: Always pair lock() with a try/finally (or use try-with-resources equivalents) so unlock() executes on every code path, including exceptions.

Treating a thread pool size as a one-size-fits-all constant regardless of workload type.

Why it happens: Teams copy a 'reasonable-looking' pool size from another service without checking whether their workload is CPU-bound or I/O-bound.

The fix: Explicitly classify the workload and size CPU-bound pools near the core count, and I/O-bound pools using the wait/compute ratio formula, then load-test to confirm.

Confusing lock-free with 'no synchronization needed at all'.

Why it happens: The term 'lock-free' sounds like it means no coordination is required, but it actually still requires careful CAS-based coordination and reasoning about memory ordering.

The fix: Treat lock-free code with at least as much scrutiny as lock-based code; verify it with stress tests under real contention, not just single-threaded correctness tests.

Ignoring the ABA problem when reusing freed nodes in a lock-free structure.

Why it happens: A CAS check that only compares a reference's identity looks correct in isolation but misses the case where the underlying node was freed, reused, and coincidentally ends up at the same address.

The fix: Use a versioned/stamped reference (e.g. AtomicStampedReference) or hazard pointers so CAS validates both identity and a change counter.

Debugging concurrency bugs by adding print statements or sleeps, which change the timing and hide the bug.

Why it happens: Under time pressure, adding a sleep() 'to fix a race condition' appears to work because it changes the interleaving probability, giving false confidence.

The fix: Use proper tools: thread dumps, race detectors (ThreadSanitizer, Java's jstack/jcmd), and stress tests with high thread counts and no artificial delays, to find and fix the actual ordering dependency.

Cheat Sheet

Quick-Reference Cheat Sheet

The 4 Necessary Conditions for Deadlock

Mutual ExclusionResource can't be shared; only one thread holds it at a time.

Hold and WaitA thread holds at least one resource while requesting another.

No PreemptionA held resource can't be forcibly taken away by the OS/runtime.

Circular WaitA cycle of threads exists where each waits on a resource the next one holds.

Lock Types Compared

MutexBinary, ownership-based; only the acquiring thread can release it.

Counting SemaphoreN permits, no ownership; any thread can signal/release.

Read-Write LockUnlimited concurrent readers OR one exclusive writer, never both.

SpinlockBusy-waits instead of blocking; best for very short critical sections.

Reentrant LockOwning thread can re-acquire without self-deadlocking.

Optimistic LockNo blocking; validates a version/CAS at commit time, retries on conflict.

Memory Model Terms

Happens-BeforeOrdering guarantee that one action's writes are visible to another.

volatileGuarantees visibility and ordering, not atomicity of compound ops.

CASAtomic 'update only if unchanged' hardware instruction behind lock-free code.

Memory Barrier/FencePrevents specific instruction reordering across the barrier point.

MESI ProtocolCache-coherence protocol keeping per-core caches consistent (Modified/Exclusive/Shared/Invalid).

False SharingUnrelated variables on the same cache line cause needless coherence traffic.

Thread Lifecycle States

NewCreated but start() not yet called.

RunnableEligible for or actively using the CPU.

BlockedWaiting to acquire a lock held by another thread.

WaitingPaused indefinitely on join()/wait() with no timeout.

Timed WaitingPaused with a timeout (sleep(ms), wait(ms)).

Terminatedrun() has completed or thrown uncaught.

Concurrency Patterns

Producer-ConsumerBounded queue + lock + notFull/notEmpty condition variables.

Thread PoolFixed worker set reused across tasks to cap concurrency and cost.

Work-StealingPer-thread deques; idle workers steal from busy ones (ForkJoinPool).

Future/PromisePlaceholder for an async result, composed with then/get.

Actor ModelState owned by one actor at a time; communication via async messages only.

Fork/JoinRecursively split work, compute in parallel, then merge results.

Deadlock Prevention Strategies

Lock OrderingAcquire all locks in one fixed global order to break circular wait.

Timeout / Try-LockBack off and retry if a lock isn't acquired within a bound, breaking no-preemption.

Acquire-All-UpfrontGrab every needed lock before starting work, breaking hold-and-wait.

Banker's AlgorithmOnly grant a request if the resulting state is provably safe.

Assessment Integration

Recommended Practice Quizzes on QuizCluster

Test your retention and prepare for timed live coding and MCQ technical screening rounds:

32 Quizzes

OS, Concurrency & Thread Safety

Drill deadlock detection, lock types, memory visibility, and thread-safety MCQs at interview pace.

Start Practice Test

350 Quizzes

Java & Spring Boot Core Assessment

Apply java.util.concurrent primitives, ExecutorService tuning, and JMM visibility rules in realistic scenarios.

Start Practice Test

Frequently Asked Questions

Do I need to write actual multi-threaded code in a concurrency interview, or just discuss concepts?

Both. Expect at least one live-coding segment (commonly producer-consumer, a thread-safe counter, or a simple thread pool) plus verbal reasoning about deadlock scenarios, memory visibility, and trade-offs between locking strategies.

Is it acceptable to say 'I would just use a ConcurrentHashMap / higher-level library' instead of implementing raw locks?

Yes for production code judgment, but interviewers still expect you to explain what the library does internally (e.g. lock striping, CAS) and to be able to implement the primitive version by hand when explicitly asked to demonstrate fundamentals.

How deep does memory model knowledge need to go for a mid-level backend interview?

You should confidently explain volatile vs synchronized vs Atomic and the happens-before relationship for common cases (volatile writes, lock release/acquire, thread start/join). Deep CPU-level memory barrier semantics are usually reserved for staff/principal-level or infrastructure-team interviews.

What's the single highest-leverage topic to prepare if I only have a few days?

The 4 necessary conditions for deadlock plus one concrete prevention strategy for each, and the producer-consumer pattern implemented from scratch with a lock and condition variable. These two show up, in some form, in nearly every concurrency round.

Explore Other Preparation Guides

Software Engineering

How to Prepare for SDE Interview: Complete 2026 Roadmap

16 min readRead →

Java Ecosystem

How to Prepare for Java Developer Interview: Core to Spring Boot & JVM

18 min readRead →

Microservices & Distributed Systems

How to Prepare for Microservices Developer Interview: Distributed Architecture & Cloud

17 min readRead →

System Design

System Design Interview Guide: Complete 2026 Roadmap

21 min readRead →

Databases

SQL Interview Questions & Preparation Guide: Beginner to Advanced

17 min readRead →

Programming Languages

Python Interview Preparation: Complete Guide for 2026

17 min readRead →

Frontend Engineering

React Interview Preparation: React 19 & Next.js Guide

17 min readRead →

Cloud & DevOps

Kubernetes Interview Guide: Architecture, Pods, Networking & Troubleshooting

17 min readRead →

Cloud & DevOps

AWS Solutions Architect Interview Guide: Real Architecture Scenarios

17 min readRead →

Databases

Database System Design: SQL vs NoSQL, Sharding, Replication & Indexing

19 min readRead →

Microservices & Distributed Systems

Kafka Interview Guide: Architecture, Consumers, Partitions & Exactly-Once Semantics

17 min readRead →

Backend Engineering

REST API Design Interview Guide: Authentication, Pagination, Versioning & Rate Limiting

15 min readRead →

Cloud & DevOps

Docker Interview Guide: Images, Containers, Networking & Production Debugging

15 min readRead →

Programming Languages

JavaScript & TypeScript Interview Guide: From Closures to the Event Loop

17 min readRead →

Backend Engineering

Node.js Backend Interview Guide: Event Loop, Streams, APIs & Scaling

17 min readRead →

Databases

Redis System Design Guide: Caching, Eviction, Persistence & Distributed Locks

17 min readRead →

Software Engineering

Dynamic Programming Patterns: How to Recognize and Solve DP Problems

17 min readRead →

Concurrency Interview Guide: Threads, Locks, Race Conditions & Deadlocks

What You Must Master to Clear This Track

Step-by-Step Study Plan

Processes, Threads & the Locking Toolbox

Diagnosing and Preventing Concurrency Failures

Visibility Guarantees & High-Throughput Concurrency Patterns

1. Processes vs. Threads & CPU Scheduling

2. Synchronization Primitives: Mutex, Semaphore, Monitor & Read-Write Locks

3. Race Conditions & the Anatomy of Deadlocks

4. Memory Models, Lock-Free Structures & Practical Concurrency Patterns

Resolving a Production Deadlock in a Payment Reconciliation Service

Top Must-Know Interview Questions & Model Answers

Q1: What is the fundamental difference between a process and a thread, and why are thread context switches cheaper?

Q2: Walk through the 5 states in a typical thread lifecycle.

Q3: Compare preemptive Round Robin scheduling to Linux's Completely Fair Scheduler (CFS).

Q4: How would you size a thread pool for a mixed CPU-bound and I/O-bound workload?

Q5: Define a race condition and give a minimal example where it silently loses data.

Q6: What three properties must a correct critical-section solution guarantee?

Q7: What is the difference between a mutex and a semaphore?

Q8: What is a monitor, and how do wait() and notify()/notifyAll() work inside one?

Q9: When would you use a read-write lock instead of a plain mutex, and what is its main risk?

Q10: What is a spinlock, and when is it preferable to a blocking mutex?

Q11: Name the 4 necessary conditions for deadlock and explain each briefly.

Q12: What's the difference between deadlock prevention, avoidance, and detection?

Q13: Explain the Banker's Algorithm and the resource-allocation state it protects against.

Q14: How does enforcing a global lock ordering prevent deadlock?

Q15: Distinguish deadlock, livelock, and starvation.

Q16: Describe the dining philosophers problem and one clean solution.

Q17: How would you implement the producer-consumer pattern correctly with a bounded buffer?

Q18: What is the happens-before relationship in the Java Memory Model (or equivalent in C++/Rust)?

Q19: Why doesn't marking a counter volatile make count++ thread-safe?

Q20: Compare volatile, AtomicInteger, and synchronized for protecting shared state.

Q21: What is instruction/memory reordering, and why can it break naively 'obvious' concurrent code?

Q22: What is compare-and-swap (CAS), and how does it enable lock-free programming?

Q23: Explain the ABA problem in CAS-based algorithms and how it's fixed.

Q24: What is the difference between lock-free and wait-free algorithms?

Q25: How does work-stealing improve thread pool utilization compared to a single shared task queue?

Q26: How does a database deadlock differ mechanically from the classic OS-level deadlock?

Q27: What is false sharing, and how does it silently degrade concurrent performance?

Mistakes That Sink Otherwise Strong Candidates

Quick-Reference Cheat Sheet

Recommended Practice Quizzes on QuizCluster

OS, Concurrency & Thread Safety

Java & Spring Boot Core Assessment

Frequently Asked Questions

Do I need to write actual multi-threaded code in a concurrency interview, or just discuss concepts?

Is it acceptable to say 'I would just use a ConcurrentHashMap / higher-level library' instead of implementing raw locks?

How deep does memory model knowledge need to go for a mid-level backend interview?

What's the single highest-leverage topic to prepare if I only have a few days?

Explore Other Preparation Guides