Interview Q&A: Multithreading & Concurrency

Concurrency is managing multiple tasks (can happen on single core via time-slicing). Parallelism is simultaneous execution on multiple cores. You can have concurrency without parallelism, but not vice versa.

Processes are OS-level, isolated, with separate memory (~50MB each). Threads are lightweight, within a process, share memory (~1MB stack each). Threads are cheaper to create and context-switch.

The JMM defines how threads interact through memory and when changes become visible. It ensures even on multi-CPU systems, Java code behaves predictably through "happens-before" relationships.

volatile ensures visibility (memory barriers, no caching) and prevents reordering, but does NOT provide atomicity. Use for flags; use Atomic* or synchronized for shared mutable data.

No. It's actually three operations: read, add, write. Threads can interleave, causing lost updates. Use AtomicInteger.incrementAndGet() instead.

Implement Runnable (or use lambda). Extending Thread is inflexible since Java doesn't support multiple inheritance. Reserve extension for truly Thread-specific behavior (rare).

Runnable returns void, cannot throw checked exceptions. Callable returns V, can throw checked exceptions. Use Callable when you need a result or expect checked exceptions.

NEW → RUNNABLE → (BLOCKED/WAITING/TIMED_WAITING) → TERMINATED. RUNNABLE means ready or running, BLOCKED waits for lock, WAITING waits for notify, TIMED_WAITING waits with timeout.

It executes in the current thread (not a separate thread). You must call start() to create a new thread.

JVM exits immediately if only daemon threads remain. Use non-daemon for important work (default), daemon for background tasks (cleanup, monitoring). Must call setDaemon() before start().

Synchronized method locks the entire method; lock is this for instance, Class for static. Synchronized block locks a specific section; you choose the lock object. Block is more fine-grained.

Multiple threads access shared mutable data without synchronization, causing non-deterministic outcomes. Example: count++ on shared counter can yield wrong final count due to interleaving.

Unsynchronized access to same memory location where at least one thread writes. Data races violate the Java Memory Model and cause visibility issues.

When you need timeout (tryLock(timeout)), fairness guarantee, or multiple condition variables. Otherwise, use synchronized (simpler, automatic release).

Circular lock dependency: Thread A waits for lock held by B, B waits for lock held by A. Prevent by: consistent lock ordering, timeouts, or avoiding nested locks.

ExecutorService provides thread pooling (reuse), resource limits, graceful shutdown, Future support, exception handling. Managing threads manually is error-prone.

execute() returns void, no exception handling. submit() returns Future, allows result retrieval and exception handling via get().

Call shutdown() (stop accepting new tasks), then awaitTermination() to wait for in-flight tasks. Use shutdownNow() to force if timeout.

If you didn't specify queue size in ThreadPoolExecutor, it grows unbounded. With 1M tasks and small thread pool, the queue consumes all memory. Always specify bounded queues or use cached pool carefully.

ConcurrentHashMap uses segment-based locking (partial locking), allowing multiple threads to write to different segments. Synchronized locks entire map, worse contention.

When you have many readers and few writers. Reads are lock-free (iterate on snapshot), writes are expensive (copy entire array). For balanced read-write, use synchronizedList.

Producer-consumer pattern. put() blocks if full, take() blocks if empty. Automatic coordination, no manual wait/notify needed.

thenApply runs on same thread that produced the value. thenApplyAsync runs on executor (default ForkJoinPool). Use async when you want parallel execution.

Use thenCombine: future1.thenCombine(future2, (r1, r2) -> combine(r1, r2)). Use thenCompose for dependent futures (flat mapping).

Use exceptionally to recover with default value. Use handle for both success and error cases. Use whenComplete for cleanup.

For I/O-bound workloads (blocking I/O). Create millions, let JVM schedule. NOT for CPU-bound work (no CPU advantage, scheduling overhead wasted).

Yes, but each has a stack frame. Millions of virtual threads = millions of stacks (still memory). More practical than millions of platform threads though.

Virtual threads "mount" on carrier (platform) threads to execute. When blocked on I/O, they "unmount" (carrier available for other virtual threads). No OS context switching.

Prefer ScopedValue (new, automatic cleanup). ThreadLocal still works but semantics are different with virtual threads. ScopedValue is intended for virtual threads.

One thread(s) produce data into shared queue, other thread(s) consume. Decouples production rate from consumption. Use BlockingQueue for automatic coordination.

❌ Never call Thread.stop() (deprecated, dangerous). ❌ Don't rely on thread priority (OS-dependent). ❌ Don't synchronize entire methods (lock only critical sections). ❌ Don't swallow InterruptedException.

Call interrupt(). In thread, check isInterrupted() and clean up voluntarily. Never force-stop.

No. Lock only critical sections to minimize contention. Synchronize entire method only if entire method is critical or simple.

Always acquire locks in consistent order. If Thread A acquires lock1 then lock2, Thread B must also acquire lock1 then lock2. Prevents circular deadlock.

On low contention (few threads competing), synchronized can be faster due to lock biasing and optimization. On high contention, Atomic (CAS) wins.

Platform threads are expensive to create/schedule (OS overhead). Virtual threads are cheap, JVM-scheduled. 100K concurrent connections with virtual threads possible; platform threads would need 100K OS threads = ~100GB RAM.

Use jcmd <pid> Thread.dump or JVM debugger. Look for cycles in lock dependencies. Use tryLock() with timeout to detect and recover.

volatile: Just visibility (flags). AtomicInteger: Single value, high frequency. synchronized: Complex critical sections, multiple memory locations. Choose based on contention and complexity.

Platform: CPU-bound work (match core count), or when OS integration needed. Virtual: I/O-bound services, want simplicity at scale. Modern Java: virtual threads usually win for services.

Blocking: Simple code, few concurrent connections. Non-blocking: High concurrency (10K+ connections). Virtual threads + blocking: Best of both (Java 21+).