Java Thread Interview Questions

Learn Java Thread Interview Questions and answers for all levels of interview.
There are series of questions asked in an interview from the Java threads.

Why can’t you declare constructors synchronized?

The JVM ensures that only one thread can invoke a constructor call (for a specific constructor) at a given point in time. That is why, no need to declare a constructor synchronized. However, if you want, you can use synchronized blocks inside constructors.

You cannot declare constructors synchronized, it will result in a compiler error.

what is Synchronized Blocks vs. Synchronized Methods?

synchronized blocks and synchronized methods, you can use either of them to solve the data race problem.
you need to choose between synchronized methods and blocks depending on the needs of a particular situation.

If you want to acquire a lock on an object for only a small block of code and not the whole method, then
synchronized blocks are sufficient.

If you want to acquire a lock on the entire body of a small method, then using synchronized as a
method.

Thumb rule, it is better to acquire locks for small segments of code instead of locking methods unnecessarily.

What is Deadlocks?

A deadlock arises when locking threads result in a situation where they cannot proceed and thus wait indefinitely for others to terminate.

Say, one thread acquires a lock on resource r1 and waits to acquire another on resource r2. At the same time, say there is another thread that has already acquired r2 and is waiting to obtain a lock on r1. Neither of the threads can proceed until the other one releases the lock, which never happens—so they are stuck in a deadlock.

For more details with example Click here.

Is order of multiple locks is important?

If multiple locks are acquired in the same order, then a deadlock will not occur, however, if
you acquire them in a different order, then deadlocks may occur. As you know, Deadlocks are non-deterministic , therefore you cannot consistently reproduce deadlocks.

NOTE:

Avoid acquiring multiple locks. If you want to acquire multiple locks, make sure that they are acquired in the same order everywhere to avoid deadlocks.

Can we call start() method twice?

No, calling again start() method , it means, you are trying to start a thread that has already started. When you call start(), the thread moves to the new state. There is no proper state transition from the new state if you call start() again, so the JVM throws an IllegalThreadStateException.

Never call the start() method twice on the same thread.

NOTE: Never write a catch block for handling IllegalThreadStateException which extends RuntimeException. If you get this exception, there is certainly a bug in the code.

Can we call wait() method without acquiring lock?

NO, Once lock has been acquired then call wait() method (with timeout or without timeout) should be called , else it throws java.lang.IllegalMonitorStateException

 
class ThreadStateProblem extends Thread {
	public void run() {
		try {
			wait(1000);
		} catch (InterruptedException ie) {
			ie.printStackTrace();
		}
	}

	public static void main(String[] s) {
		new ThreadStateProblem().start();
	}
}
 

The correct fix is to acquire the lock before calling wait(). In this case, you can declare the run() method synchronized:

synchronized public void run() {
	try {
		wait(1000);
	} catch (InterruptedException ie) {
		ie.printStackTrace();
	}
} 

Since the run() method is synchronized, wait() will add itself to the this object reference lock. Since there is no
one calling the notify()/notifyAll() method, after a timeout of 1 second (1000 milliseconds) is over, it will return from the run() method. So, the wait(1000); statement behaves almost like a sleep(1000) statement; the difference is that calling wait() releases the lock on this object when it waits while sleep() call will not release the lock when it sleeps.

Call wait and notify/notifyAll only after acquiring the relevant lock.

What is Starvation ?

The situation in which low-priority threads keep waiting for a long time to acquire the lock and execute the code in critical sections is known as starvation.

e.g In a multithreading application, you find that the tasks that are not critical or urgent are the ones that keep waiting for an unusually long time. Since critical or urgent tasks are high priority, they run most of the time. This multi-threading problems correctly describes this situation as Starvation.

Visit Oracle Java threads for more details.

I hope you ejnoyed this Java thread interview questions , visit Core Java tutorial for more details.