Java Multithreading Interview Questions

Deadlock occurs when threads circularly wait for locks held by others; prevent via lock ordering, timeouts, tryLock(), or ReentrantReadWriteLock patterns.

Object lock1 = new Object();
Object lock2 = new Object();
new Thread(() -> {
  synchronized(lock1) {
    synchronized(lock2) {
    }
  }
}
).start();
new Thread(() -> {
  synchronized(lock2) {
    synchronized(lock1) {
    }
  }
}
).start();

ExecutorService is a thread pool that manages a pool of threads for executing submitted tasks asynchronously. It abstracts away thread creation and lifecycle management, providing methods like submit(), execute(), and shutdown().

ExecutorService executor = Executors.newFixedThreadPool(2);
executor.submit(() -> System.out.println("Task 1"));
executor.submit(() -> System.out.println("Task 2"));
executor.shutdown();

Multi-threading allows multiple threads to execute concurrently within a single process, enabling parallelism and responsive applications, though it requires careful synchronization to avoid race conditions.

synchronized void incrementCount() {
  count++;
}
synchronized void decrementCount() {
  count--;
}
volatile int sharedVar = 0;

Race condition occurs when multiple threads access shared mutable data concurrently and at least one modifies it, causing unpredictable behavior due to non-atomic operations.

class Counter {
  int count = 0;
  void increment() {
    count++;
  }
}
new Thread(() -> {
  for(int i=0;
  i<1000;
  i++) counter.increment();
}
).start();
new Thread(() -> {
  for(int i=0;
  i<1000;
  i++) counter.increment();
}
).start();

A process is an independent program with its own memory space and resources, while a stream is a flow of data; they're unrelated concepts in threading context.

Process p = Runtime.getRuntime().exec("java -version");
InputStream is = p.getInputStream();
int exit = p.waitFor();

Optimistic locking assumes conflicts are rare; it uses version numbers/timestamps checked before commit, throwing exception on conflict. Pessimistic locking acquires exclusive locks immediately preventing concurrent access, slower but guarantees consistency.

class Optimistic {
  int version = 1;
}
class Pessimistic {
  synchronized void method() {
  }
}
AtomicInteger atomic = new AtomicInteger(0);
atomic.compareAndSet(0, 1);

Monitor is a synchronization mechanism ensuring only one thread executes synchronized code at a time. Each object has an intrinsic lock; synchronized blocks/methods use monitors to control access, implementing mutual exclusion and visibility guarantees.

class Counter {
  private int count = 0;
  synchronized void increment() {
    count++;
  }
  synchronized int getCount() {
    return count;
  }
}

Volatile ensures visibility of variable changes across threads by bypassing CPU caches and forcing reads/writes to main memory; it prevents instruction reordering but doesn't provide atomicity.

CompletableFuture is a Future that can be manually completed and supports chaining asynchronous operations with callbacks (thenApply, thenAccept) without blocking.

Create a stream using Stream.of(), collection.stream(), Arrays.stream(), or IntStream.range(); streams are lazy and support functional operations like map, filter, reduce.

Happens-Before establishes memory visibility guarantees: actions before synchronization/volatile/atomic operations are visible to subsequent actions, preventing race conditions.

Synchronization uses locks (monitors) to ensure only one thread accesses a resource at a time, preventing data corruption and race conditions in concurrent environments.

Future represents a result of an asynchronous computation that can be retrieved via get() (blocking) or checked with isDone(); it lacks composition capabilities.

Multithreading enables concurrent task execution improving responsiveness, throughput on multi-core systems, and parallel processing; single-threaded blocks on I/O operations.

Java synchronization options: synchronized blocks/methods (monitor-based), volatile keyword, Lock interface, atomic variables, and concurrent collections for thread-safe access.

Atomic types (AtomicInteger, AtomicLong, AtomicReference) provide non-blocking, thread-safe operations using compare-and-swap (CAS) for better performance than synchronized blocks in high-contention scenarios.

Thread safety means objects are safe for concurrent access without external synchronization; ensure through synchronization, immutability, thread-local storage, or atomic operations.

Volatile ensures visibility of variable changes across threads by preventing compiler optimizations and CPU caching; doesn't provide atomicity, only memory visibility guarantees.

Use setPriority(int) method on Thread objects with values 1-10; higher priority threads get more CPU time, but scheduling depends on the OS scheduler.

Runnable is a functional interface with a single run() method that defines the task to execute; it's implemented by a class whose instances can be executed as threads.

A Semaphore is a synchronization primitive that maintains a counter of permits; threads acquire() a permit (blocking if none available) and release() it when done, useful for limiting concurrent access.

Wait() suspends the current thread and releases the lock on the object, allowing other threads to access it; the thread resumes when notify() or notifyAll() is called.

A daemon thread (setDaemon(true)) runs in the background and doesn't prevent JVM shutdown; JVM terminates when only daemon threads remain.

ReadWriteLock allows multiple concurrent readers or a single writer; readers use readLock() for shared access, writers use writeLock() for exclusive access, improving performance for read-heavy scenarios.

Concurrency is multiple tasks interleaved on single core via context switching; parallelism executes tasks simultaneously on multiple cores, true parallel execution.

Cooperative multitasking relies on tasks voluntarily yielding control; Java uses preemptive multitasking where the OS forcibly switches threads based on time slices and priorities.

Java uses preemptive multitasking because it's safer and more responsive than cooperative; the JVM/OS guarantees fairness and prevents task starvation without relying on developer cooperation.

Ordering refers to the visibility and execution order of memory operations across threads; Java's Memory Model defines happens-before relationships ensuring predictable behavior.

As-if-serial semantics guarantees that within a single thread, program execution appears sequentially consistent despite compiler/processor reordering, as long as data races don't occur.

Sequential consistency means all threads see the same consistent order of operations; memory operations appear to execute atomically in some total order respecting each thread's program order.

Visibility ensures changes to shared variables by one thread are observable by other threads; Java achieves this via volatile, synchronized, and final keywords triggering memory barriers.

Atomicity means an operation executes completely without interruption; Java provides atomic operations through synchronized blocks, atomic variables, and volatile reads/writes.

Mutual exclusion prevents multiple threads from accessing shared resources simultaneously; synchronized blocks and locks enforce that only one thread holds the lock at a time.

Safe publication ensures an object constructed by one thread is safely visible to another; achieved via synchronized access, volatile, or happens-before edges (e.g., thread.start()).

Green threads are user-level threads managed by JVM rather than OS; older Java versions used them, but modern Java (since 1.3) uses OS native threads for better performance and parallelism.

start() creates a new thread executing run() asynchronously; calling run() directly executes it synchronously in the current thread without creating a new thread.

Streams (threads) cannot be forcibly started from outside; use Thread.interrupt() to signal, Thread.join() to wait, or design with shutdown flags for cooperative termination.

Thread states are NEW (created, not started), RUNNABLE (eligible to run), BLOCKED (waiting for monitor lock), WAITING (waiting on Object.wait/join/park), TIMED_WAITING (waiting with timeout), TERMINATED.

Yes, new instances can be created; static synchronized methods lock the class object, not instances, so other threads can instantiate new objects while the method executes.

Private mutex enforces encapsulation of synchronization logic and prevents external threads from acquiring the lock, ensuring controlled access patterns and avoiding deadlocks from unintended external locking.

notify() wakes one waiting thread, notifyAll() wakes all waiting threads; notifyAll() is safer to prevent missed signals but costlier.

wait() and notify() must be in synchronized blocks because they require the monitor lock to safely coordinate between threads without race conditions.

wait() without parameter blocks indefinitely until notified, wait(long timeout) blocks for specified milliseconds then auto-wakes if not notified.

Thread.sleep() pauses current thread for specified time holding its locks, Thread.yield() hints to scheduler to pause but doesn't guarantee and releases no locks.

Thread.join() blocks the calling thread until the target thread completes execution, synchronizing thread completion.

Livelock occurs when threads continuously change state in response to each other without blocking, causing busy-waiting with no progress.

Use ThreadMXBean.getThreadInfo() or DebuggerAPI to inspect monitor ownership, or check in debugger for 'Locked on' information.

Static synchronized methods synchronize on the Class object, not instance objects.

synchronized is used to protect critical sections and ensure mutual exclusion, preventing race conditions and maintaining memory visibility between threads.

volatile ensures visibility of variable changes across threads but not atomicity; atomic variables provide both visibility and atomic operations via CAS.

compareAndSwap() is a strong CAS that always returns correct result, weakCompareAndSwap() may return false spuriously without actually failing the compare operation.

No, the main thread cannot be a daemon thread; attempting to set daemon status on main thread has no effect since it's already running.

A thread 'sleep' means it's paused via Thread.sleep() and released from execution but still holds acquired locks.

FutureTask is a Runnable/Future adapter that wraps a Callable, allowing asynchronous computation with result retrieval via get().

CyclicBarrier allows threads to wait for each other at a point and is reusable, CountDownLatch is one-way only and threads countdown to zero.

Race conditions can be solved via synchronization, volatile variables, atomic classes, locks (ReentrantLock), or immutable objects.

Use Thread.interrupt() to signal a thread and handle InterruptedException, or check isInterrupted() in loops; avoid deprecated stop().

Thread.stop() is unsafe as it forcibly terminates threads causing inconsistent state, lock releases, and unpredictable behavior.

Uncaught exceptions in threads are handled by UncaughtExceptionHandler; if none exists, the default handler prints to stderr and the thread terminates.

interrupted() is static and clears the interrupt flag after checking, isInterrupted() is instance method and doesn't clear the flag.

A thread pool is a collection of pre-created threads that execute tasks from a queue, reducing overhead of creating/destroying threads for each task.

Thread pool size depends on workload: for CPU-bound tasks use Runtime.getRuntime().availableProcessors(), for I/O-bound tasks use higher values (2-3x processors).

If the queue is full, the RejectedExecutionHandler determines behavior: abort policy throws exception, discard policy drops task, caller runs policy executes in caller thread, or discard oldest drops oldest task.

execute() returns void and throws RejectedExecutionException if task can't be submitted; submit() returns Future<T> and queues exceptions instead of throwing them.

Stack is thread-local (each thread has own stack for local variables), heap is shared across threads (requires synchronization); stack memory is faster and automatically freed, heap requires garbage collection.

Share data via synchronized blocks/methods, volatile variables for visibility, ConcurrentHashMap, BlockingQueue, or thread-safe collections; use immutable objects or atomic classes when possible.

Use jstack command: `jstack <pid>` outputs thread dump showing all threads, locks, and stack traces; helps diagnose deadlocks and thread behavior.

ThreadLocal stores thread-specific data isolated per thread; each thread gets its own independent instance, preventing accidental sharing; use remove() to prevent memory leaks.

synchronized is a keyword (implicit lock, automatic release), non-reentrant by default, simpler; ReentrantLock is explicit (acquire/release), reentrant, allows fairness policy, condition variables, and interruptible locks.

A blocking method is one that doesn't return until its task completes (e.g., wait(), read()), temporarily halting thread execution; differs from non-blocking methods that return immediately.

Fork/Join framework divides large tasks recursively into smaller subtasks (fork), solves them in parallel, then combines results (join) using work-stealing algorithm; optimized for divide-and-conquer problems.

Double-checked locking minimizes synchronization overhead: check null without lock, if null synchronize and check again before initialization; avoid it in Java (use eager/lazy-safe alternatives instead).

Create thread-safe singleton using enum (preferred): `public enum Singleton { INSTANCE; }` guarantees single instance and thread-safety by default.

Immutable objects are inherently thread-safe (no synchronization needed), prevent accidental mutations, enable safe sharing across threads, and simplify concurrent code reasoning.

Busy spin continuously loops checking a condition without yielding (e.g., `while(!flag)`), wastes CPU cycles; better to use wait/notify, BlockingQueue, or CountDownLatch.