Multithreading Interview Questions

A process is an independent program with its own isolated memory space, while a thread is a lightweight unit of execution within a process that shares memory with other threads in the same process. Creating a thread is generally cheaper than creating a process.

Multithreading is the ability of a program to run multiple threads concurrently within a single process, allowing tasks to execute in parallel or interleaved fashion to improve responsiveness or throughput.

Concurrency means multiple tasks make progress during overlapping time periods, potentially interleaved on a single core, while parallelism means multiple tasks literally execute at the same instant on multiple cores. Concurrency is about structure, parallelism is about simultaneous execution.

A race condition occurs when the outcome of a program depends on the unpredictable timing or interleaving of multiple threads accessing shared data, leading to inconsistent or incorrect results depending on execution order.

Thread safety means a piece of code behaves correctly when accessed by multiple threads simultaneously, without causing race conditions or data corruption, typically achieved through synchronization mechanisms.

A critical section is a part of code that accesses shared resources and must not be executed by more than one thread at the same time, protected using synchronization mechanisms like locks.

A mutex, short for mutual exclusion, is a locking mechanism that ensures only one thread can access a critical section at a time, requiring a thread to acquire the lock before entering and release it after leaving.

A semaphore is a synchronization primitive that maintains a count, allowing a fixed number of threads to access a resource concurrently, unlike a mutex which allows only one thread at a time.

A mutex allows only one thread to hold it at a time and is typically owned by the thread that locked it, while a semaphore can allow multiple threads up to a set count and isn't necessarily tied to ownership by a specific thread.

Deadlock occurs when two or more threads are each waiting for a resource held by the other, resulting in all involved threads being permanently blocked with no way to proceed.

The four conditions are mutual exclusion, meaning a resource can only be held by one thread, hold and wait, meaning a thread holds one resource while waiting for another, no preemption, meaning resources can't be forcibly taken away, and circular wait, meaning a cycle of threads each waiting on the next.

Livelock occurs when threads keep changing their state in response to each other without making actual progress, unlike deadlock where threads are simply blocked and not changing state at all.

Starvation happens when a thread is perpetually denied access to a resource it needs, often because other threads with higher priority or better timing keep getting scheduled ahead of it.

A monitor is a synchronization construct that combines a mutex with the ability for threads to wait for a condition and be notified when it changes, commonly used to coordinate access to shared data along with condition-based signaling.

The volatile keyword ensures that reads and writes to a variable are always visible across threads immediately, rather than potentially being cached in a thread's local memory, preventing stale value reads without providing full mutual exclusion.

A thread pool is a group of pre-created worker threads that execute submitted tasks, reused across multiple tasks rather than creating and destroying a new thread for every task, reducing the overhead of thread creation.

Context switching is the process of saving the state of a currently running thread and loading the state of another thread so it can run, allowing a CPU to share time between multiple threads, though it comes with a performance overhead.

A daemon thread is a background thread that doesn't prevent the program from exiting, meaning the runtime can terminate it automatically once all non-daemon threads have finished, commonly used for tasks like garbage collection.

Thread synchronization is the coordination of multiple threads to ensure they access shared resources safely and in the correct order, typically using locks, semaphores, or other primitives to prevent race conditions.

An atomic operation completes as a single, indivisible step from the perspective of other threads, meaning no other thread can observe it in a partially completed state, which avoids the need for explicit locking in many simple cases.

The producer-consumer problem is a classic concurrency scenario where one or more producer threads generate data and place it into a shared buffer, while one or more consumer threads remove and process that data, requiring synchronization to avoid overflow, underflow, and race conditions.

Thread priority is a hint to the scheduler about the relative importance of a thread, influencing how often it gets scheduled to run, though the actual behavior depends heavily on the operating system's scheduling algorithm.

A reentrant lock allows the same thread that already holds the lock to acquire it again without deadlocking itself, tracking a hold count so it must be released the same number of times it was acquired.

User-level threads are managed entirely by a library in user space without the operating system's kernel being aware of them, while kernel-level threads are managed directly by the operating system, which can schedule them across multiple CPU cores.

Thread contention occurs when multiple threads compete for the same lock or resource frequently, causing threads to spend time waiting rather than doing useful work, which can significantly hurt performance under high concurrency.

A spin lock makes a thread repeatedly check, or spin, in a loop until a lock becomes available, rather than yielding the CPU and going to sleep, which can be efficient for very short wait times but wasteful for longer waits.

The join() method makes the calling thread wait until the thread it's called on finishes execution, commonly used when a main thread needs to wait for worker threads to complete before proceeding.

Synchronous execution runs tasks one after another, with each waiting for the previous one to complete, while asynchronous execution allows a task to start and let the caller continue without waiting for it to finish, often notified later through a callback or future.

A happens-before relationship is a guarantee in a memory model that specifies the order in which operations from different threads become visible to each other, ensuring certain writes by one thread are guaranteed to be seen by another after a specific synchronization point.

False sharing occurs when threads on different CPU cores modify variables that happen to sit on the same cache line, causing unnecessary cache invalidation and performance degradation even though the threads aren't logically sharing the same data.

A condition variable lets a thread wait until a particular condition becomes true, releasing an associated lock while waiting and reacquiring it once notified, commonly used together with a mutex to coordinate threads around shared state changes.

Thread-local storage provides each thread with its own independent copy of a variable, so changes made by one thread don't affect the value seen by other threads, useful for avoiding synchronization overhead on data that doesn't need to be shared.

The fork-join model splits a task into smaller subtasks that run in parallel, forking off separate threads, then joins their results back together once all subtasks complete, commonly used for divide-and-conquer style parallel algorithms.

A busy-wait is when a thread repeatedly checks a condition in a tight loop while consuming CPU cycles, rather than blocking and yielding the processor to other threads, generally considered wasteful except in very specific low-latency scenarios.

Blocking I/O makes the calling thread wait, unable to do other work, until the I/O operation completes, while non-blocking I/O lets the thread continue with other work and get notified or check back later for completion, which allows a single thread to handle many I/O operations concurrently.

For a simple counter under moderate contention, I'd use an atomic increment operation since it avoids lock overhead entirely and is simpler to reason about. I'd only reach for a full lock if the operation involved multiple related fields that need to update together consistently.

I would use a read-write lock so multiple readers can access the cache concurrently without blocking each other, while writes acquire an exclusive lock, since reads are typically far more frequent than writes in a cache and a plain mutex would unnecessarily serialize reads.

I would enforce a consistent global lock ordering across all threads, meaning every thread always acquires locks in the same predefined sequence, which eliminates the circular wait condition that's necessary for deadlock to occur.

I would size the pool larger than the number of CPU cores, since I/O-bound tasks spend most of their time waiting rather than using CPU, allowing more threads to be productively in flight than would make sense for CPU-bound work.

For CPU-bound tasks, I would size the pool close to the number of available CPU cores, since adding more threads than cores just increases context switching overhead without improving throughput, unlike I/O-bound work where threads spend time waiting rather than competing for CPU.

I would use a blocking queue that makes producers wait when the queue is full and consumers wait when it's empty, using a condition variable or a built-in blocking queue implementation, rather than manually polling with a busy loop.

I would combine unit tests for the logic in isolation with stress tests that run many threads concurrently against shared state, checking invariants hold after execution, and consider using a tool that can detect data races statically or at runtime, since race conditions often don't reproduce reliably in normal test runs.

I would use a read-write lock, which allows concurrent read access while ensuring writes get exclusive access, giving much better throughput than a single mutex when reads vastly outnumber writes.

I would first identify which parts of the job are independent and can run in parallel without shared mutable state, then parallelize just those parts, keeping any necessary aggregation or ordering step as a final synchronized stage rather than trying to parallelize the entire pipeline naively.

I would take a thread dump to see what each thread is currently blocked on and which locks each thread currently holds, then trace the chain of threads waiting on each other to identify the circular dependency causing the deadlock.

I would use a mechanism like a future or a callback that captures the exception when it occurs in the worker thread, then either re-throw it on the calling thread when the result is requested or handle it explicitly through an error callback.

I would use double-checked locking with a volatile field, or rely on the language's own thread-safe lazy initialization mechanism if one exists, like a static holder class in Java, rather than synchronizing the entire getInstance method on every call, which would hurt performance unnecessarily after initialization.

I would stop accepting new tasks first, then allow currently running tasks to complete within a defined timeout, and only forcibly interrupt threads that haven't finished after that grace period, rather than abruptly killing all threads and potentially leaving shared state inconsistent.

I would use a synchronization primitive like a countdown latch or a barrier, depending on whether it's a one-time signal or a repeated rendezvous point, rather than implementing custom busy-wait polling logic.

I would check for lock contention or a shared bottleneck, like a single database connection or a serialized logging call, that's forcing threads to wait on each other despite having more threads available, since adding threads doesn't help when they're mostly waiting on the same constrained resource.

I would use an atomic counter or a token bucket implementation backed by an atomic operation to track the current rate, avoiding a full lock if possible since rate limiting checks happen frequently and lock contention there could become a bottleneck itself.

I would ensure proper synchronization, like using volatile for simple flags or synchronized blocks and locks for more complex state, since without a happens-before relationship established through the memory model, a thread isn't guaranteed to see another thread's writes promptly or at all.

I would give each worker thread its own local task queue to reduce contention, and let idle workers steal tasks from the back of another worker's queue when their own queue is empty, which balances load across threads without requiring a single shared queue that all threads contend on.

I would move the expensive computation outside the critical section wherever possible, computing values before acquiring the lock and only holding it for the minimal work that actually needs mutual exclusion, since long-held locks directly increase contention for other waiting threads.

I would use a blocking queue to hold available resources, where threads borrow a resource by taking from the queue, blocking if none are available, and return it by putting it back, which naturally handles both the pooling and the concurrency safety.

I would consider a striped or sharded counter approach, where each thread updates one of several sub-counters and the total is summed only when read, reducing contention compared to every thread fighting over a single atomic variable.

I would check for excessive synchronization overhead, context switching cost from too many threads, or false sharing between threads accessing nearby memory, since adding threads doesn't automatically improve performance if the overhead of coordination outweighs the parallel work gained.

I would run a sustained load test with a mix of high and low priority tasks and monitor whether low priority tasks ever get a chance to execute, since starvation issues often only show up under realistic, sustained contention rather than in a quick functional test.

I would consider the actual conflict rate, since optimistic concurrency, which retries on conflict rather than blocking, works well when conflicts are rare, but under high contention the repeated retries can cost more than simply taking a lock upfront with pessimistic locking.

I would use an event-driven, non-blocking I/O model with a small pool of threads handling many connections through multiplexing, since a thread-per-connection model doesn't scale well once thread count gets into the thousands due to memory and context-switching overhead.

I would check whether the code relies on assumptions about memory ordering that aren't actually guaranteed by the language's memory model, since different CPU architectures have different native memory ordering guarantees, and code that happens to work on a strongly ordered architecture can fail on a weaker one without explicit synchronization.

I would consider a copy-on-write approach if modifications are infrequent relative to reads, since it lets iteration proceed safely against a stable snapshot without locking, though for frequent modifications I'd evaluate whether a concurrent-safe structure with weakly consistent iteration semantics fits the use case better.

Coarse-grained locking is simpler to reason about and less error-prone but limits concurrency, while fine-grained locking allows more parallelism but increases the risk of subtle bugs like deadlock from inconsistent lock ordering. I'd start coarse-grained for correctness and narrow the locking scope only where profiling shows real contention.

I would use a proven coordination service, like one built on a consensus protocol, rather than implementing distributed locking from scratch, since correctly handling failure scenarios like network partitions and lock expiration in a homegrown implementation is deceptively difficult.

I would check whether the finer-grained locks introduced more total lock acquisition overhead than they saved in reduced contention, since splitting one lock into many can sometimes hurt performance if each individual lock is acquired very frequently and the original contention wasn't actually the bottleneck.

I would use a priority queue with aging, where a task's effective priority gradually increases the longer it waits, ensuring lower priority tasks eventually get scheduled rather than being perpetually preempted by a continuous stream of higher priority work.

I would try to reproduce the issue under controlled concurrent load with detailed tracing, since a true race condition's timing sensitivity means it may not reproduce consistently, while a logic error under load, like resource exhaustion, tends to reproduce reliably once the same load conditions are recreated.

I would use an immutable configuration object referenced through a volatile or atomic reference, where updating configuration means atomically swapping the reference to a new immutable object rather than mutating shared configuration state in place, avoiding the need for locks on every configuration read.

I would design for a bounded queue with a sensible rejection or backpressure policy once the pool and queue are saturated, since an unbounded queue during a load spike just delays failure and can exhaust memory, whereas failing fast with backpressure keeps the system stable and communicates overload clearly to callers.

I would weigh the I/O concurrency benefit against the added complexity of asynchronous code, like harder debugging and more complex error handling, since for services with modest concurrency needs, simple threaded synchronous code is often easier to maintain without a meaningful performance cost.

I would require idempotency keys on operations so a retried request can be safely detected and deduplicated on the receiving side, since relying purely on client-side retry logic without server-side idempotency handling risks duplicate side effects under concurrent or repeated requests.

I would track how often production incidents trace back to concurrency bugs in that system over time, since a rising incident rate despite incremental fixes usually signals the underlying threading model itself, not individual bugs, is the real problem worth addressing directly.

I would quantify the time currently spent diagnosing intermittent, hard-to-reproduce production incidents that are ultimately traced to race conditions, since that diagnostic cost, made concrete, usually justifies tooling investment more persuasively than an abstract quality argument.

I would require additional review specifically from someone experienced in concurrent systems for any change touching shared state or locking logic in critical systems, since concurrency bugs are disproportionately expensive to catch after deployment compared to the relatively low cost of a focused review.

I would prioritize documentation and cross-training on that system's concurrency design specifically, beyond just its general architecture, since concurrency bugs are uniquely hard for someone unfamiliar with the original design intent to safely fix without introducing new races.

I would provide sizing guidelines tied to workload type, CPU-bound versus I/O-bound, rather than a single fixed number, and require services to expose thread pool metrics so misconfiguration can be caught through monitoring rather than only discovered during an incident.

I would provide clear guidance on the tradeoffs, favoring higher-level abstractions for new systems with complex concurrent coordination needs, while allowing raw threading for simpler, well-understood use cases where the abstraction's overhead and learning curve wouldn't pay off.

I would check whether postmortems for concurrency incidents result in concrete changes to shared patterns or tooling, beyond just fixes to the specific bug, since concurrency bugs tend to be systemic rather than isolated, and a postmortem that doesn't generalize the lesson often sees the same category of bug recur elsewhere.

I would require profiling data showing an actual bottleneck before approving fine-grained concurrency optimizations, since the increased bug risk and maintenance cost of complex locking schemes is rarely justified without concrete evidence the simpler approach is actually the limiting factor.

I would require a track record of production use and active maintenance before approval, since concurrency bugs in an immature or poorly maintained library are especially costly given how hard they are to detect and reproduce.

I would quantify the current infrastructure cost of the thread-per-request model under peak load, since the memory and context-switching overhead of thousands of threads translates into a concrete infrastructure cost that a more efficient concurrency model would measurably reduce.

I would classify concurrency incidents by their potential for silent data corruption versus visible failure, prioritizing silent-corruption risks higher even if they occur less frequently, since a visible crash is at least immediately detected while silent data corruption from a race condition can go unnoticed for a long time.

I would start by cataloging where concurrency-related incidents have actually caused production impact across teams, then build shared tooling and reference implementations addressing those specific patterns, rather than producing a generic concurrency guide disconnected from what's actually gone wrong in practice.

I frame it in terms of incident cost avoided, using a specific past outage caused by a race condition as a concrete reference point, since leadership responds better to a demonstrated cost of getting concurrency wrong than an abstract argument about code correctness.

I would move from relying on a handful of engineers who deeply understand concurrency toward documented patterns, automated tooling like race detectors in CI, and training, since expertise that lives only in a few people's heads doesn't scale once no single team has direct access to them.

I try to ground the disagreement in the system's actual expected load and failure modes rather than abstract preference for one paradigm over another, since experienced engineers often converge once they're evaluating the same concrete workload characteristics rather than debating philosophy in the abstract.

I would require the design rationale behind non-obvious locking or synchronization decisions to be documented explicitly, beyond just the code itself, and rotate ownership periodically so more engineers build the deep familiarity needed to safely modify concurrent code without introducing new races.

I present the specific risk in terms of the kind of production incident that inadequate concurrency testing has caused before, letting leadership make an informed decision, rather than silently absorbing the risk of shipping undertested concurrent code under time pressure.

I would identify engineers who already show the habit of reasoning explicitly about shared state and interleavings rather than just writing code that passes tests, and give them ownership of smaller concurrent systems first, since that specific judgment is much harder to build quickly than general technical skill.

I focus on making sure engineers understand the underlying memory model and guarantees of whatever they're using, rather than assuming patterns that worked in one language's threading model transfer directly to a different runtime's concurrency primitives, since that assumption is a common source of new bugs during technology transitions.

I would present a clear timeline of what happened, the specific race condition or design flaw that caused it, the immediate remediation, and the longer-term prevention plan, since executives need enough concrete detail to assess the scope of data impact and communicate confidently with their own stakeholders.

I would look at whether concurrency-related incidents keep recurring in code that passed review, since a review process that isn't specifically trained to spot shared-state and lock-ordering issues can look thorough while still missing the exact class of bug that matters most in concurrent systems.

I would quantify both the ongoing incident cost tied to the legacy locking scheme and the increasing difficulty of hiring or onboarding engineers comfortable maintaining it, since that combination of rising risk and rising cost typically makes a clearer case than either argument alone.

I try to distinguish real performance requirements from assumed ones, since teams sometimes over-optimize concurrency prematurely without profiling data confirming the standard pattern would actually fall short. Where the requirement is genuinely unusual, I'd rather support a documented custom approach than force a bad fit.

I would push the organization toward designing for concurrency and parallelism as a default assumption rather than an afterthought bolted onto originally single-threaded designs, since hardware trends keep increasing available parallelism, and systems that aren't architected with that in mind from the start tend to hit scaling walls that are expensive to retrofit around.