Multithreading and Concurrency Interview Questions for Java
25 Multithreading and Concurrency questions with answers for java roles — 4 easy, 13 medium, 8 hard.
About Multithreading and Concurrency
Modern backends handle thousands of requests at once, so concurrency is key for mid and senior roles. Learn threads, synchronization, volatile, locks, the Java Memory Model, deadlocks, ExecutorService, CompletableFuture, concurrent collections, atomic classes and Java 21 virtual threads, along with how to debug hangs and race conditions in production.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
You can extend Thread and override run(), or implement Runnable or Callable and pass it to a Thread or an ExecutorService. Callable returns a result and can throw checked exceptions, giving a Future. Modern code rarely creates threads directly; it uses executors, CompletableFuture or, from Java 21, virtual threads with Thread.ofVirtual().start(task).
start() asks the JVM to create a new thread and then calls run() on that new thread, so the code executes concurrently. Calling run() directly is just a normal method call on the current thread, so no new thread is created. Calling start() twice on the same Thread throws IllegalThreadStateException.
03
What is the difference between wait() and sleep()?
wait() is an Object method called inside synchronized code; it releases the monitor and waits until notify(), notifyAll() or a timeout. sleep() is a Thread static method that pauses the current thread for a time but keeps any locks it holds. wait() is for coordination between threads, while sleep() simply delays. Modern code prefers Condition, BlockingQueue or CountDownLatch.
Situation: our team was still on Java 8 while LTS releases moved ahead. Task: make a case for upgrading. Action: I followed release notes and JEPs, tried records, pattern matching and virtual threads in a side project, and built a proof of concept moving one service to Java 21 with measured gains. Result: the team approved the upgrade and I ran an internal session on the new features.
volatile guarantees visibility and ordering: a write to a volatile field is immediately visible to other threads, and it prevents reordering around that access under the Java Memory Model. It does not make compound operations like count++ atomic, because that is a read, modify and write. Use it for flags such as a stop signal, and use AtomicInteger or locks for counters.
06
What is the difference between synchronized and ReentrantLock?
synchronized is a built-in keyword that locks a monitor and releases it automatically at block exit. ReentrantLock is an explicit lock that adds tryLock with timeout, interruptible locking, fairness options and multiple Condition objects, but you must unlock in a finally block. Both are reentrant. Prefer synchronized for simple cases and ReentrantLock when you need its extra features.
A deadlock happens when two or more threads each hold a lock and wait for a lock held by the other, so none can continue. It needs mutual exclusion, hold and wait, no preemption and circular wait. Prevent it by always acquiring locks in the same global order, using tryLock with a timeout, holding locks briefly and avoiding calls to unknown code while holding a lock.
08
What are virtual threads and when should you use them?
Virtual threads, final in Java 21, are lightweight threads managed by the JVM and mounted on a small pool of carrier OS threads. When one blocks on I/O, it unmounts so the carrier can run another. You can run millions of them, which suits thread-per-request servers doing lots of blocking calls. They do not speed up CPU-bound work, and you should not pool them.
09
How does ExecutorService work and why use a thread pool?
ExecutorService manages a pool of worker threads and a task queue. You submit Runnable or Callable tasks and get Futures, and workers reuse threads instead of creating one per task, which saves creation cost and limits concurrency. Configure core size, max size, queue and rejection policy through ThreadPoolExecutor. Always call shutdown() and awaitTermination() when done.
10
A counter shared between threads shows wrong totals. How do you fix it?
count++ is not atomic; two threads can read the same value and both write the same result, so updates are lost. Use AtomicInteger.incrementAndGet(), which uses CAS, or LongAdder for very high contention, as it spreads updates over cells. A synchronized method also works but is slower. volatile alone does not fix it because it gives visibility, not atomicity.
11
An API calls three independent downstream services one after another and takes 900 ms. How would you speed it up?
Since the calls are independent, run them in parallel with CompletableFuture.supplyAsync on a dedicated executor or with virtual threads, then join with allOf. Total latency becomes roughly the slowest call, about 300 ms. Add a timeout per call with orTimeout and a fallback for failures so one slow service does not block the whole response. Structured concurrency is another option in newer Java.
12
Implement a producer-consumer using BlockingQueue.
Use a shared lock with wait and notify.
class Printer {
int n = 1;
synchronized void print(boolean odd) throws InterruptedException {
while (n <= 10) {
if ((n % 2 == 1) == odd) {
System.out.println(Thread.currentThread().getName() + " " + n++);
notifyAll();
} else wait();
}
notifyAll();
}
}
Start one thread with print(true) and another with print(false).
15
Write code that runs 10,000 blocking tasks using virtual threads.
Use the virtual-thread-per-task executor in Java 21.
try (var ex = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < 10_000; i++) {
int id = i;
ex.submit(() -> {
Thread.sleep(Duration.ofMillis(200));
return id;
});
}
} // close() waits for all tasks
All tasks finish in about 200 ms because blocked virtual threads free their carriers.
16
Use CountDownLatch to wait for three worker threads to finish.
The main thread waits until the count reaches zero.
CountDownLatch latch = new CountDownLatch(3);
for (int i = 0; i < 3; i++) {
new Thread(() -> {
try { doWork(); }
finally { latch.countDown(); }
}).start();
}
latch.await(30, TimeUnit.SECONDS);
System.out.println("all done");
countDown in finally makes sure the latch is released even on error.
17
Describe a situation where you had to deliver under a tight deadline.
Situation: a bulk upload feature had to go live in four days for a client launch. Task: build it safely in time. Action: I split it into must-have and later items, used an ExecutorService to process rows in parallel, wrote focused tests for validation and kept the product owner updated daily. Result: we shipped on time, it handled 50,000 rows in under two minutes and we added the extras next sprint.
18
Explain the happens-before relationship in the Java Memory Model.
Happens-before is the rule that guarantees one action's effects are visible to another. Examples: unlocking a monitor happens-before a later lock of the same monitor, a volatile write happens-before later reads of it, Thread.start() happens-before actions in the started thread, and actions in a thread happen-before another thread's successful join() on it. Without such an edge, threads may see stale or reordered values.
19
What is CompletableFuture and how is it better than Future?
Future only lets you block with get() to obtain a result. CompletableFuture supports non-blocking composition: thenApply to transform, thenCompose to chain async calls, thenCombine or allOf to join several, and exceptionally or handle for errors. It runs on the common ForkJoinPool by default, but pass your own executor for blocking I/O to avoid starving the pool.
20
Your application hangs and CPU is near zero. How do you find out why?
Low CPU with a hang suggests threads are blocked, often a deadlock or waiting on a slow resource. Take several thread dumps with jcmd pid Thread.print. The JVM reports detected deadlocks at the end of the dump. Otherwise look for many threads BLOCKED on the same lock or WAITING on a connection pool or socket read, then fix lock order, add timeouts or increase the pool.
21
After moving to virtual threads, throughput did not improve and some requests stalled. What could cause it?
Common causes are pinning, where a virtual thread blocks inside a synchronized block or native call and holds its carrier thread; this was largely fixed in Java 24 for synchronized, but native calls still pin. Another cause is a fixed downstream bottleneck such as a small JDBC pool, so more threads just wait. Detect pinning with JFR events, use ReentrantLock in older versions and size pools to real capacity.
22
A thread pool fills up and tasks get rejected during traffic spikes. How do you handle it?
First check why tasks are slow, since slow tasks fill pools. Then choose a policy: a bounded queue with CallerRunsPolicy applies backpressure by running the task in the submitting thread; otherwise return a fast 503 so clients retry. Tune pool and queue sizes from load tests. Never use an unbounded queue, because it hides the problem until memory runs out.
23
Two scheduled jobs on different servers process the same records twice. How do you prevent this?
In-JVM locks do not work across servers. Use a distributed lock such as ShedLock with a database table or Redis, so only one instance runs the job at a time. Make the processing idempotent too, for example by marking records with a status and updating with WHERE status = 'NEW' so only one worker claims each row. Database SELECT FOR UPDATE SKIP LOCKED also works well.
24
How would you write a simple thread safe rate limiter in Java?
A token bucket with synchronized refill is simple and correct.
class RateLimiter {
private final long capacity, refillPerSec;
private double tokens; private long last = System.nanoTime();
RateLimiter(long cap, long rps) { capacity = cap; refillPerSec = rps; tokens = cap; }
synchronized boolean tryAcquire() {
long now = System.nanoTime();
tokens = Math.min(capacity, tokens + (now - last) / 1e9 * refillPerSec);
last = now;
if (tokens >= 1) { tokens--; return true; }
return false;
}
}
Across servers, keep the bucket in Redis.
25
Tell me about a time you solved a concurrency bug.
Situation: our wallet service sometimes showed wrong balances under load. Task: find the race and fix it without slowing the API. Action: I reproduced it with a JMeter test, found a read-then-update pattern in two concurrent requests, and replaced it with an atomic SQL update plus optimistic locking with a version column. Result: zero balance mismatches across festival traffic and a reusable load test for future changes.
Frequently asked questions
How important is Multithreading and Concurrency in Java interviews?
Modern backends handle thousands of requests at once, so concurrency is key for mid and senior roles. Learn threads, synchronization, volatile, locks, the Java Memory Model, deadlocks, ExecutorService, CompletableFuture, concurrent collections, atomic classes and Java 21 virtual threads, along with how to debug hangs and race conditions in production.
How should I use the Multithreading and Concurrency sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.