My Language - Bits and Bytes!

All application these days are multi threaded applications . Analyzing thread dumps in from production can really get tedious. The applications using various frameworks and increased usage of asynchronous programming has made analyzing thread dumps a night mare. I have been analyzing thread dumps for a  couple of years and that has been my favorite activity so far. Definitely you have to reconcile couple of other evidences to nail down the actual issue. But getting all possible details from the thread dump helps find pin point the issue faster. This blog is not to explain how to analyse thread dumps. Instead this explains a simple trick to ease out the analysis of thread dumps.  What is the first issue you see analyzing thread dumps? 1. To decide whether a thread is hanging or processing for a long time.  2. Which thread is waiting on which thread? Resolving issue 1 is much easier. Having proper thread state helps resolve that problem.  For ex...

Does wait() method have to be called from synchronized method or block? Yes, It has to be.  It throws IllegalMonitorStateException otherwsie. I have explained the answer with a vanilla implementation of producer consumer problem. I have used one thread  each.  THe program uses a boolen flag, so the capacity is just one item. In this case let us assume if the wait in producer was called without synchronized block, then there are high chances that the consumer thread can interfere and  producer thread can go to invariable wait. This is called missing communications/signals. To avoid this, we should always call wait(), notify() and notifyAll() inside synchronized block. import java.util.concurrent.locks.ReentrantLock; public class MSProducerConsumer { private volatile boolean flag = false; ReentrantLock lock = new ReentrantLock(); void produce() { try { while(true) { synchronized (this) { try { lock.lock(); while(fl...