Hi, Prakash.
Question 1) If I'm correct, ThreadA blocked while sleeping and thus not releasing hte lock on Holder, so ThreadB will never have a chance to get a lock and read the value. Instead it should be use wait and notify. Please correct me.
Correct. Only wait method will release lock for the object. And it will release only a lock for an object on which wait is performed.
This code will release a lock only on an "a" object but not on a "b" object (consider that a != b). So other thread may take an a's lock but not b's lock.
Question 2) After both the threads are started, the main thread called interrupt() after some time and I expected that that will put back ThreadA into dead or inactive state. But after throwing Exception, it seems taht thread is revived and back from grave and continuing. Would not have exception stop the Thread ?
Interruptions are not intended to kill a thread. And there are no api to kill or forcibly terminate a thread at all. Interruption is used only to notify a target thread to "please, terminate". It is up to that tread to handle (or ignore) that request. Throwing InterruptedException is one way to notify about such request. But there is no other magic to terminate a thread. Target thread can ignore that request completely. Or such thread may be run in a context where interrupted exception can't be thrown (heavy math as an example). Such threads should check Thread.interrupted() if it want to handle "termination requests".
Question 3) As you see from the output below, in Exception block, I printed the status of that Thread and see that Thread is alive and Interrupted is false. But was that not interrupted below and should not that return true. Please clarify.
If you got idea that thread.interrupt is only a "please, terminate" request it should be easy. There are two ways in which this request can be delivered. One of them is throwing an InterruptedException. Second way is to set thread "interrupted" status. Each request may be delivered at most once (but it may be lost if a thread is already in interrupted state). JVM selects a way to notify a thread based on it's current method. See Thread.interrupt for a complete list of methods where JVM will use InterruptedException (or it's IO counterpart) to notify a thread about request. In these cases "interrupted" flag is not set (because notification is considered "delivered" by the means of an InterruptedException). In your case interrupted flag is not set because InterruptedException was thrown. Moreover, if you call an "interruptible" method when interrupted flag is set then flag will be reset and an InterruptedException will be thrown. And Thread.interrupted() also will clears this flag (but this methods returns flag's previous state).
In summary.
1. Thread.interrupt is only a request for a thread to terminate gracefully.
2. There are two ways to deliver such request. If InterruptedException is used then interrupted flag is not set.
3. It's up to a thread's code to handle that request. Thread may ignore that request completely.
4. There are no reasons to check interrupted flag immediately after catching InterruptedException or getting true from Thread.interrupted(). Flag will be clear unless you are very lucky and someone interrupted this thread again.
5. If you want to notify outer method about interruption,
you should do it by hand. You may rethrow an InterruptedException (or just don't catch it), use your own exception or a special return value or set interrupted status back by calling Thread.currentThreadInterrupt before returning from a method.