Multithreading Interview Questions and Answers for 2026

1. writing to a non-volatile int; 
2. writing to a volatile int; 
3. writing to a non-volatile long; 
4. writing to a volatile long; 
5. incrementing a volatile long? 

Writing to an int (32-bit) variable is guaranteed to be atomic, mutable or not. A long (6 -bit) variable can be written in two separate steps, for example on 32-bit architectures, so there is no guarantee of atomicity by default. However, if you specify a volatile modifier, access to the long variable is guaranteed on an atomic basis.

The increment operation is usually done in several steps (getting the value, changing it, and writing it back), so it is never guaranteed to be atomic, regardless of whether the variable is mutable or not. If you want to implement atomic addition of a value, you should use classes AtomicInteger, AtomicLong, etc.

A staple in Multithreading questions, be prepared to answer this one.  

The synchronized keyword before a block means that any thread entering this block has to acquire the monitor (the object in brackets). If the monitor is already acquired by another thread, the former thread will enter the BLOCKED state and wait until the monitor is released. 

synchronized(object) {    
    // ... 
}");  

A synchronized instance method has the same semantics, but the instance itself acts as a monitor. 

synchronized void instanceMethod() { 
   // ... 
}");  

For a static synchronized method, the monitor is the Class object representing the declaring class. 

static synchronized void staticMethod() { 
   // ... 
}");  

If a method is an instance method, the instance acts as a method monitor. Two threads that call the method on different occasions get different screens so that neither of them blocks.

If the method is static, the monitor is an object of the class. Both threads have the same monitor, so one of them will probably block and wait for the other to exit the synchronized method.

A thread that owns an object's monitor (for example, a thread that has entered a synchronized section protected by the object) can call object.wait() to temporarily release the monitor and allow other threads to acquire the monitor.

This can be done, for example, to wait for a certain condition. If another thread that acquired the monitor meets the condition, it can call object.notify() or object.notifyAll() and release the monitor. The notify method wakes up one thread in the waiting state, and the notifyAll method wakes up all the threads waiting for that monitor, all of which compete to regain the lock.

It's no surprise that this one pops up often in Multi threading interview questions.  

A deadlock is a state in a thread pool that cannot progress because each thread in the pool must acquire a resource that another thread in the pool has already acquired. The simplest case is when two threads each need to lock two resources to progress, the first resource is already locked by one thread, and the second is already locked by the other thread. These threads never lock either resource and, therefore, never progress.

Livelock is a case where multiple threads respond to conditions or events of their own making. An event occurs in one thread and must be processed in another thread. During this processing, a new event occurs, which must be processed in the first thread, and so on. Such threads live and do not block but still do not progress because they burden each other with unnecessary work.

Starvation is when a thread cannot obtain a resource because another thread (or threads) is using it for too long or has a higher priority. The thread cannot progress and thus cannot do any useful work.

A common question in Java thread interview questions, don't miss this one.  

The Fork/Join framework allows recursive algorithms to be parallelized. The main problem with a recursively parallel ThreadPoolExecutor is that it can quickly run out of threads because each recursive step requires its own thread while the threads on the stack are idle and waiting.

The starting point of the Fork/join framework is the ForkJoinPool class, which is an implementation of ExecutorService. It implements a job reservation algorithm where idle threads try to "steal" work from busy threads. This allows computation to be spread across different threads and progress using fewer threads than a normal thread pool would require.

We know that every object has a monitor that allows a thread to hold a lock on the object. But thread class does not contain monitors. A thread usually waits for control of an object (a lock) by calling the wait method of the object, and notifies other threads waiting on the same lock using the notify() or notifyAll() method. Therefore, these three methods are only called on objects and allow all threads to communicate with each thread created for that object.

One of the most frequently posed Java Multithreading interview questions, be ready for it.  

The Problems With Synchronized Keyword: 

• For the shared resources, a thread may only obtain a lock on an item once. 
• Other threads cannot lock after a thread has completed a synchronized block. 
• Let's take a scenario and understand the starvation problem with multiple threads using the synchronized keyword. Suppose there are 10 threads (t1 to t10) and threads (t1 to t9) that acquire a lock and release the lock after executing a synchronized block. 
• But there may be a situation where the t10 thread does not have a chance to execute a synchronized block when other threads are competing for the lock. So it can cause starvation and t10 has to wait a very long time to start the sync block. 

The Solution: Reentrant Lock: 

Java provides a better way to deal with the above problems that handle synchronization. 

• The ReentrantLock class implements the Lock interface. This class is provided in java. util.concurrent package. import java.util.concurrent.locks.ReentrantLock; 
• We must create an object of the ReentrantLock class and wrap the shared resource with the lock and unlock methods of this object. 
• A thread wishing to execute a shared resource must lock it, and therefore all other threads trying to lock the object must wait for the current thread to release it. 
• The beauty of ReentrantLock is that it allows the current thread to take multiple locks on the same lock object. Note that the wait count value is set to one the first time the current thread calls the lock() method. The wait counter is incremented by one each time this thread calls lock(). 
• For each unlock request, the pending count is decremented by one, and if the pending count is 0, the resource is unlocked. 

Now let us see how we can use this mechanism: 

public void methodName(){ 
   bufferLock.lock(); 
   try { 
           //sharedResource 
   } catch(Exception e) { 
           e.printStackTrace(); 
   } finally { 
           bufferLock.unlock();  
} 
} 

In the above code snippet, you can notice that the thread must be locked before the shared resource can be executed. And after executing the try block, the thread finally releases the block lock using the unlock() method. Note that regardless of whether an exception occurs or not, the finally block is always executed. 

When we use a Java application, the operating system allocates some memory to that application to store and run the program. This application is called a process when it is running. Now there can be multiple threads in the same application and each thread can perform different tasks like IO, DB operations etc. 

All threads of the same process (application) share the mass memory of that process. On the other hand, each thread in this application has its own memory called thread stack and stores local variables in it. 

Note that when we create an object of a class, that object is stored on the heap, not the thread stack. The thread stack is private memory reserved for each thread, which only stores local variable

This question is a regular feature in Java thread interview questions, be ready to tackle it.  

Thread stack and heap: 

First, the Java Virtual Machine divides its memory into stack and heap memories. 

It stores all objects on the heap and stack local primitives and local object references. 

Most importantly, each thread, including the main thread, has its own private stack. Local primitives and local reference variables are stored on this stack (essentially the thread stack). 

Therefore one thread does not share its local variables with any other thread because these local variables and references are on the thread's private stack. Therefore, local variables are always thread-safe. 

Let us give a simple example to understand this: 

Thread-Safety for local variables: 

public class ThreadExample implements Runnable{ 
 public Integer counter; 
   @Override 
   public void run() { 
       counter = new Random().nextInt(); 
       Integer count = new Random().nextInt(); 
       System.out.println("counter : "+counter+" count : "+count); 
   } 
   public static void main(String[] args) { 
       ThreadExample threadExample = new ThreadExample(); 
       Thread thread1 = new Thread(threadExample); 
       Thread thread2 = new Thread(threadExample); 
       thread1.start(); 
       thread2.start(); 
   } 
} 

The output of the above program: 

counter : -2066897874 count : 1775146445 
counter : 170327989 count : -1649657772 

In the example above, a ThreadExample instance is created on line 11, and two Thread objects are created on the next two lines (12 and 13), starting on lines 1 and 15. These threads execute the execute method of the same instance “threadExample”. 

When these two threads execute the execute method, they create their own copy of the local count variable on their private stack. Because those stacks are private, no two threads can share the same copy of the count variable. That's why it is thread-safe. Also, the counter variable is assigned a random integer, so it probably won't assign the same integer to the count variable. 

But both threads refer to the same instance ‘threadExample’ of ThreadExample class. This instance is on the heap and hence its field the counter is also on the heap. So there is only one copy of the field counter on the heap which is shared between these two threads. And hence there is a chance of collision between the threads which can lead to a race condition. That’s why the counter field is not thread-safe. 

• start(): Simply put, the start() method is used to start or initiate a newly created thread. When the start() method is called, a new thread is created and this newly created thread executes the action stored in the run() method. The start() method can only be called once. 
• run(): Simply put, the 'run()' method will act as any normal method and will not start or run thread. When the run()un  method is called, a new thread is not created, as is the case with the start() method. This method is called by the current thread. The run() method can be called multiple times. 

This is a frequently asked question in Multi threading interview questions.  

A thread pool is simply a set of worker threads, pre-initialized at startup, that can be used to perform tasks and return to the pool when they are finished. This is called pool threads, where a pool of threads of fixed size is created.  

By reducing the number of threads in an application and managing their life cycle, the performance problem can be mitigated by thread pooling. Using threads can improve performance and improve system stability. The java.util.concurrent.Executors class typically provides factory methods for creating thread pools.

The join() method is usually used to pause the execution of the current thread unless the specified thread on which the join is called is dead or completed. This method can be used to block a thread until another thread finishes. It connects the beginning of the execution of a thread to the end of the execution of another thread. This is considered the last method of the thread class.

Garbage collection is basically a process of managing memory automatically. It uses several GC algorithms among which the popular one includes Mark and Sweep. The process includes three phases i.e., marking, deletion, and compaction/copying. In simple words, a garbage collector finds objects that are no longer required by the program and then delete or remove these unused objects to free up the memory space.

Expect to come across this popular question in Multithreading questions.  

The Lock interface was introduced in Java 1.5 and is generally used as a synchronization mechanism to provide important locking functionality. 

Advantages of using the Lock interface compared to the sync block: 

• The methods of the Lock interface, ie. Lock() and Unlock(), can be called by different methods. This is the main advantage of the lock interface over the synchronized block because the synchronized block is completely contained in a single method. 
• The Lock interface is more flexible and, unlike the synchronization block, ensures that the longest waiting thread has a fair chance to start when the fair flag is set to true. 

A deadlock is a situation where each thread is waiting for resources held by other waiting threads. This situation causes the thread to fail to start, which causes the program to pause and break the code at runtime.

It's no surprise that this one pops up often in Java Thread interview questions.  

A Deadlock situation can be detected by running the executable code on cmd and subsequently collecting the thread dump. If a deadlock situation is present, the cmd will throw up a message.

This is one of the most common Java Multithreading interview questions asked in technical interviews. 

Deadlock situations in Java can be avoided by:

By way of avoiding nested thread locks and providing locks to only one thread at a time can help in reducing the risk of deadlock occurrence.

By using thread join – this function helps the thread to wait for other threads to execute before its own execution, thereby preventing multiple threads from waiting for resources used by other threads.

Individual threads do have their stacks in multithreaded programming. Each thread is independent of the other and maintains its own stack in the memory.

Thready safety can be achieved if multiple threads can use a particular class function without the occurrence of the race condition. In Multithreaded programming, thread safety can be achieved by: 

• Using of atomic wrapper class 
• Using of a volatile keyword 
• Using a lock-based mechanism 
• Using Synchronization mechanism

Atomic operations are performed in a single task unit without interfering with other operations. In multi-threaded environments, atomic operations are required to avoid data inconsistencies. int is not an atomic operation. So, when one thread reads this value and increments it by one, the other thread reads the original value, resulting in an incorrect result.  

To solve this problem, we need to make sure that the number of sum operations is atomic. We can do this using synchronization, but java.util.concurrent.atomic in Java 5 provides wrapper classes for int and long that can be used to achieve this. atomically without synchronization.

In synchronization, we don’t know how much time a thread will get a chance after a previous thread has released the lock. This can lead to the problem of starvation whereas, in the case of the lock, we have its implementing class reentrant lock which has one of its constructors which lets you pass fairness property as one of its arguments that let the longest waiting thread get the chance to acquire the lock.  

In synchronization, if a thread is waiting for another thread, then the waiting thread won’t do any other activity which doesn’t require lock access but with the lock interface, there is a trylock() method with which you can try to access the lock and if you don’t get the lock you can perform other alternate tasks. This helps to improve the performance of the application.  

There is no API to check how many threads are waiting for a particular lock whereas this is possible with lock interface implementation class ReentrantLock methods.  

Using the lock interface One can get better control of locks, with the methods such as holdCount() method which is not found with synchronization.

One of the most frequently posed Thread interview questions, be ready for it.  

Java 5 introduced the Executor framework with the java.util.concurrent. Executor interface. The Executor Framework is a framework for standardizing the invocation, scheduling, execution and management of asynchronous tasks according to execution conventions. Creating many threads without a maximum limit can cause the application to run out of memory and hence the application will crash.  

So creating a ThreadPool is a better solution because a limited number of threads can be pooled and reused once they are put again in the thread pool. The Executor framework makes it easy to create thread pools in java for multi-threading applications.

This is a frequently asked question in Java Multithreading interview questions for experienced.  

Actually, Java 5 introduced java.util.concurrent.Callable interface in concurrency package that is similar to Runnable interface but can return any Object and throw Exception. The Callable interface uses java generics to define the return type of the Object. Executors class provides useful methods to execute Callable in a thread pool.  

Since callable tasks run parallel, we have to wait for the returned Object. Callable tasks return java.util.concurrent.Future object. Using Future we can find out the status of the Callable task and get the returned Object. It provides the get() method that can wait for the Callable to finish and then return the result.

Thread or process context switching is basically an important feature of multithreading. It is referred to as switching of CPU from one thread or process to another one. It allows multiple processes to share the same CPU cores. In context switching, the state of thread or process is stored on PCB or TCB, so that the execution of the thread can be resumed later if required.

FutureTask is the base implementation class of the Future interface and we can use it with Executors for asynchronous processing. Most of the time we don't need to use FutureTask class but it comes really handy if we want to override some of the methods of the Future interface and want to keep most of the base implementation. We can just extend this class and override the methods according to our requirements.

Expect to come across this popular question in Java multithreading questions.  

BlockingQueue is typically used for one thread to create objects to be consumed by another thread. Here is a diagram that illustrates this principle:

The "producing thread" continues to create new objects and add them to the BlockingQueue until the queue reaches some upper limit. It's a limit, in other words. When the blocking queue reaches its upper limit, the creating thread is blocked from adding a new object. It remains blocked until the consuming thread lives the object.  

"Consumer thread" removes objects from the block queue to process them. If a consuming thread tries to remove an object from an empty queue, the consuming thread is blocked until the producing thread enqueues the object. 

CyclicBarrier and CountDownLatch, both required to handle multi-threaded programming. But there are differences between them as shown below: 

• CyclicBarrier: It is a tool to synchronize the processing of threads using some algorithm. This allows a set of threads to wait for each other until they reach a common execution point or breakpoints and then resume execution. The same CyclicBarrier can be reused, even if the barrier is broken by placing it. 
• CountDownLatch: This is a tool that allows main threads to wait for other threads to perform mandatory operations and finish them. Simply put, it ensures that a thread waits for another thread to finish before executing. The same CountDownLatch cannot be reused when the count reaches zero. 

It's no surprise that this one pops up often in Multithreading interview questions.  

The Executors class provides helper methods for the Executor, ExecutorService, ScheduledExecutorService, ThreadFactory, and Callable classes. The Executors class can be used to easily create a thread pool in Java and is also the only class that supports running Callable applications.

Some important concurrent API enhancements are: 

1. ConcurrentHashMap compute(), forEach(), forEachEntry(), forEachKey(), forEachValue(), reduce(), merge()  and search() methods. 
2. CompletableFuture that may be explicitly completed (setting its value and status). 
3. Executors newWorkStealingPool() method to create a work-stealing thread pool using all available processors as its target parallelism level. 

Interthread communication, as the name suggests, is a process or mechanism that allows multiple threads to communicate with each other. It is specifically used in Java to prevent thread polling and can be obtained by the wait(), notify() and notifyAll() methods.

• ConcurrentHashMap: The underlined data structure for ConcurrentHashMap is Hashtable. ConcurrentHashMap class is thread-safe i.e. multiple threads can operate on a single object without any complications. At a time any number of threads are applicable for a read operation without locking the ConcurrentHashMap object which is not there in HashMap. In ConcurrentHashMap, the Object is divided into a number of segments according to the concurrency level. 
• Hashtable: This is a thread-safe inheritance class introduced in old Java versions to store key or value pairs using a hashtable. Unlike ConcurrentHashMap, it does not provide unlocked reads. It just locks the entire map on replay. ConcurrentHashMap and Hashtable are both thread-safe, but unlike Hashtable, ConcurrentHashMap generally avoids read locks and improves performance. 

ConcurrentHashMap also provides non-locking numbers, unlike Hashtable. Therefore, ConcurrentHashMap is considered faster than Hashtable, especially when the number of readers is more than the number of writers.

Expect to come across this popular question in Java Multithreading interview questions for experienced.  

A semaphore is considered a thread synchronization construct that is typically needed to control and manage access to a shared resource using counters. It just sets the thread limit. The semaphore class is defined in the java.util.concurrent package and can be used to send signals between threads to prevent missing signals or to protect critical parts. It can also be used to implement resources or a limited pool.

So nothing happens unless we override the run() method. The compiler does not show an error. This calls the run() method of the thread class and we just don't get the result because the run() method has an empty implementation.  
 
Example: 

class ThreadExample extends Thread {  
  //don't override run() method  
}  
public class DontOverrideRun {  
  public static void main(String[] args) {  
         System.out.println("Main thread has started");  
         ThreadExample thread1=new ThreadExample ();  
         thread1.start();  
         System.out.println("Main thread has completed");  
  }  
} 

Output: 

Main thread has started 
Main thread has completed

Multithreading is a concept that appears in many programming languages. Although multithreaded languages can run on a single thread, multithreading cannot be disabled in languages that do not support this feature. C, JAVA, C# etc. are languages that support multithreading. JavaScript is a single-threaded language.