Multithreading Interview Questions

Multithreading is the execution of multiple threads concurrently inside one process. A thread is a lightweight unit of execution with its own stack and program counter, while threads in the same process share heap objects and other resources. An application may use different threads for requests, database work, notifications, logging, and background tasks. The JVM and operating system decide the execution order, so code must not depend on a particular order unless it explicitly coordinates the threads.

A process is an independent running program with its own memory space and operating-system resources. A thread is an execution path inside a process. Threads are cheaper to create and communicate through shared heap objects, but a thread failure can affect the whole process. Each thread has its own stack and program counter, while threads share the process heap, static data, and open resources. Processes provide stronger isolation; threads provide lightweight concurrency within that isolation.

Multithreading can keep an application responsive while background work runs, improve throughput on multi-core CPUs, and allow other tasks to progress while one thread waits for I/O. It is useful for handling multiple requests, processing files, and running independent jobs. The trade-off is added complexity: shared mutable state can cause race conditions, deadlocks, starvation, visibility bugs, and difficult-to-reproduce failures. Use concurrency when the workload benefits from it and prefer high-level concurrency utilities where possible.

You can extend Thread, implement Runnable, use a Runnable lambda, submit Runnable or Callable tasks to ExecutorService, or create asynchronous stages with CompletableFuture. Extending Thread couples the task to a thread object. Runnable represents work without a result, while Callable can return a result and throw checked exceptions. In production code, submitting tasks to a properly sized executor is usually better than creating an unlimited number of raw Thread objects.

Extending Thread makes the class both the task and the thread, so it cannot extend another class and is harder to reuse. Implementing Runnable separates the work from the execution mechanism. The same Runnable can run in a Thread, an ExecutorService, or a scheduled executor, and the task class can still extend another class. Therefore, implementing Runnable or using a Callable is generally preferred unless a custom Thread type is specifically required.

Thread.State defines NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED. NEW means start() has not been called. RUNNABLE means the thread is ready or running. BLOCKED means it is waiting for an intrinsic lock. WAITING means it waits indefinitely for another action, such as notify or join. TIMED_WAITING means it waits for a duration, such as sleep. TERMINATED means run() has completed. A terminated Thread cannot be started again.

start() asks the JVM to create and schedule a new thread, which then invokes run(). Calling run() directly is only a normal method call and executes on the current thread. Therefore, start() provides concurrent execution, while run() does not create another execution path. A Thread can be started only once; calling start() a second time throws IllegalThreadStateException. Directly calling run() is appropriate only when synchronous execution is intentional.

sleep() is a static Thread method that pauses the current thread for a duration and does not release monitors it holds. wait() is an Object method that must be called while owning that object’s monitor; it releases that monitor and waits for notification, interruption, or timeout. join() makes the current thread wait until another thread finishes. InterruptedException should normally be handled by restoring the interrupt flag with Thread.currentThread().interrupt().

Synchronization coordinates access to shared mutable state. It provides mutual exclusion so only one thread enters a protected critical section at a time and establishes visibility between threads that use the same lock. For example, count++ is a read, modify, and write sequence, so two threads can lose an update without protection. Use synchronized blocks or methods, locks, atomic classes, concurrent collections, immutability, or thread confinement based on the problem.

A synchronized instance method locks this for its complete body, while a synchronized static method locks the Class object. A synchronized block protects only the selected code and can use a private lock object. Blocks are more flexible and can keep the critical section shorter, which often improves concurrency. Avoid locking on publicly accessible objects because unrelated code can accidentally acquire the same lock. Use a method when the whole method is the critical section and a block when only part needs protection.

A race condition occurs when the result depends on the unpredictable timing of threads accessing shared mutable data. A common example is two threads checking a bank balance and then withdrawing money before either update is visible to the other. Compound operations such as count++, check-then-act logic, and containsKey followed by put are vulnerable. Prevent races with synchronized sections, locks, atomic operations, concurrent collections, immutability, or thread confinement.

A deadlock occurs when threads wait forever for locks held by one another. For example, Thread A holds lock A and waits for lock B while Thread B holds lock B and waits for lock A. Prevent it by acquiring multiple locks in one consistent global order, avoiding unnecessary nested locks, keeping critical sections short, avoiding external calls while locked, and using tryLock with a timeout where appropriate. Thread dumps can help confirm a deadlock in production.

Deadlock means threads are blocked forever in a circular wait. Livelock means threads remain active and keep reacting or retrying but make no useful progress. Starvation means one thread repeatedly fails to obtain CPU time, a lock, or another resource while other threads continue. Reduce these problems with consistent lock ordering, bounded retries with backoff, fair locks when justified, short critical sections, suitable pool sizes, and separation of long-running tasks.

volatile guarantees visibility of a variable between threads and provides ordering rules around its reads and writes. It is useful for a stop flag, status value, or safely published reference when each operation is independent. It does not make compound operations atomic. For example, volatile int count does not make count++ safe because increment still reads, changes, and writes the value. Use synchronization or an atomic class when an update depends on the previous value or several fields must remain consistent.

volatile provides visibility and ordering for a single variable but does not lock or make compound operations atomic. synchronized provides visibility, mutual exclusion, and atomicity for the protected critical section. Use volatile for an independent state flag such as running. Use synchronized when a read-modify-write operation is required, multiple fields form one invariant, or only one thread may execute a section at a time. Atomic classes are another option for individual lock-free updates.

Atomic classes in java.util.concurrent.atomic provide thread-safe operations on individual values without explicit synchronized blocks. Examples include AtomicInteger, AtomicLong, AtomicBoolean, AtomicReference, LongAdder, and LongAccumulator. Methods such as incrementAndGet and compareAndSet use atomic read-modify-write operations. LongAdder can improve throughput for highly contended counters. Atomic classes are not enough when several variables must be changed together as one transaction; that situation needs a lock or another coordination design.

The Executor Framework is a high-level API for submitting tasks without manually managing every thread. ExecutorService manages worker threads, queues, task execution, Future results, and shutdown. ScheduledExecutorService supports delayed and periodic tasks, while ThreadPoolExecutor gives precise control over pool size, queue capacity, keep-alive time, thread creation, and rejection policy. Always shut down executors that the application owns and choose bounded resources for production workloads.

Runnable represents a task whose run() method returns no value and cannot declare checked exceptions. Callable represents a task whose call() method returns a value and can throw checked exceptions. Both can be submitted to an ExecutorService, but Callable commonly produces a Future result. Use Runnable for fire-and-forget work and Callable when the caller needs a result or needs the task to report a checked failure.

Future represents a result that may be available later and commonly requires blocking get(). CompletableFuture supports callback-style stages such as thenApply, thenCompose, thenCombine, allOf, and exceptionally. It can chain asynchronous operations, combine independent results, and handle failures without manually blocking at every step. Both can still be misused: blocking inside an asynchronous stage or using an unsuitable executor can exhaust threads and remove the expected performance benefit.

A thread pool is a managed group of reusable worker threads. Tasks wait in a queue and are executed by available workers, avoiding the memory and scheduling cost of creating a thread for every task. Common choices are fixed pools for bounded concurrency, single-thread executors for ordered work, scheduled pools for delayed or periodic jobs, work-stealing pools for parallel tasks, and custom ThreadPoolExecutor instances for explicit queue and rejection policies. Pool size should be measured against CPU, I/O, queue growth, and downstream capacity.