5 Ways to debug Java thread-safety issues

Interviewers often judge your experience with debugging skills. For example, debugging jar hell issues, debugging SSL issues, debugging hibernate issues, debugging transaction management issues, etc. All these are covered in detail under the key areas “Key Area – Debug xxxx

How will you debug thread-safety issues in Java?

A very popular Java job interview question for intermediate to senior developers. Debugging concurrency issues are not easy. 5 tips to debug thread-safety issues in Java.

Before debugging ensure that you have the enough unit test (E.g. JUnit) coverage.

#1 List all possible causes and add extensive log statements and write additional test cases to prove or disprove your theories. The log statements will have something like

#2 Using your IDE debugging capability by setting a conditional break point.  Thread.currentThread().getName().equals(“Thread-0”). For example, stopping for particular thread as demonstrated below step by step in eclipse IDE.


Get the code used above:

Java Producer-Consumer multi threading code.

The above code continuously produces output like:

You can add a break point to the ProducerConsumer that is used by both worker threads ProducerThread and ConsumerThread. Both these worker threads are spawned by the default main thread.

Step 1: Create a conditional debug point as shown below in the first line of the produce method.


Step 2: Run the ProducerConsumerTest in debug mode. The execution stops on the break point when worker “Thread-0” enters the break point. In the above example only one thread enters produce( ) method. But in industrial applications you can have many threads.

You also have options to suspend and resume the threads you want as shown below with right-click context menu in the debug window. When you are suspended, you can also copy the stack at that suspended point in time.

Debugging multi-threaded app

Debugging multi-threaded app

You can also inspect and watch shared variables to ascertain any thread-safety issues.


The above diagram adds a watch expression on a shared variable.

#3 Thread dumps are very useful for diagnosing synchronization problems such as deadlocks. The trick is to take 5 or 6 sets of thread dumps at an interval of 5 seconds between each to have a log file that has 25 to 30 seconds worth of run-time action.

For thread dumps, use kill -3 in Unix and CTRL+BREAK in Windows. There are tools like Thread Dump Analyzer (TDA), Samurai, etc. to derive useful information from the thread dumps to find where the problem is. For example, Samurai colors idle threads in grey, blocked threads in red, and running threads in green. You must pay more attention to those red threads.

Creating a thread dump in windows

Step 1: While the ProducerConsumerTest  is running, open a DOS command prompt at type jconsole.


Note down the process id: 4800. Connect to 4800, and 

Step 2: You can detect any deadlocks by clicking on the “Detect Deadlock” button in the threads tab.

Step 3: To get a thread dump, open a DOS command prompt and type jstat [pid]

This will produce a stack trace. The stack trace looks something like


You need to pay attention to blocked threads, and there are tools like  Thread Dump Analyzer (TDA), Samurai, etc to analyze thread dumps. These tools color code waiting threads, running threads, etc.

jstack and jconsole are provided with your JDK installation under jdk[version]/bin.

#4 There are static analysis tools like Sonar, ThreadCheck, etc for catching concurrency bugs at compile-time by analyzing the byte code. Sonar produces reports with recommendations.

#5 Manually reviewing the code for any obvious thread-safety issues. Good knowledge of multi-threading is required. Here are a few scenarios based examples & tutorials to improve your understanding.

1. Review the multi-threaded code shown below and then answer the following 5 questions relating to thread-safety?

2. Understanding Spring bean scopes. A “prototype” scoped bean will be created each time it is “injected”, whereas a “singleton” scoped bean will be created once and shared within the application context. Any Bean without a STATE can be singleton. For example beans that easily qualify to be singleton are DAO, Service, and Controller. Choosing a “Singleton” type for a bean that needs to maintain it’s state will cause “thread-safety” issues because each thread would try to impose it’s own state on that bean there by corrupting the data. 9 Spring Bean scopes interview Q&A

3. More Java Multithreading scenarios interview questions answered covers writing thread-safe lazily initialized singletons, writing thread-safe Counters or custom database sequence number generators, writing thread-safe producer & consumer communication, thread starvation & deadlock issues, & production issues debugging.

Concurrency issues debugging:

1. JConsole for debugging deadlocks in Java applications

2. jvisualvm to debug deadlocks in Java applications

3. 7 Java debugging interview questions & answers

800+ Java Interview Q&As Menu

Learn by categories on the go...
Learn by categories such as FAQs – Core Java, Key Area – Low Latency, Core Java – Java 8, JEE – Microservices, Big Data – NoSQL, Architecture – Distributed, Big Data – Spark, etc. Some posts belong to multiple categories.