如果线程在调用Object.wait（）之前被中断，该线程甚至会在抛出InterruptedException之前费心地释放锁。

Question

The JDK Documentation kind of mentioned it,

If the current thread is interrupted by any thread before or while it is waiting, then an > InterruptedException is thrown. This exception is not thrown until the lock status of this >object has been restored as described above.

I just want to be absolutely certain that the use of word "restored" means the lock must be released and reacquired, instead of being hold continuously by the thread calling Object.wait(). In other words, there is a chance that the lock is granted to other threads first.

Answer 1

I just want to be absolutely certain that the use of word "restored" means the lock must be released and reacquired, instead of being hold continuously by the thread calling Object.wait(). In other words, there is a chance that the lock is granted to other threads first.

There is never a guaranty that the lock is granted to other threads first. Even if the thread releases the lock and re-acquires it afterwards, it might succeed in re-acquiring the lock before any other thread waiting for the same lock gets a chance.

An implementation might allow bypassing the release and re-acquire of the lock in case of an early thread interruption and it might do so even without interruption in the case of a spurious wakeup that the specification allows to occur.

In other words, when wait ends, regardless of normally or exceptionally, there is no guaranty that any other thread has been run.

The documentation clearly says :

A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup . While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:

 synchronized (obj) { while (<condition does not hold>) obj.wait(timeout); ... // Perform action appropriate to condition } 

This also hold for the case that an InterruptionException has been thrown. When following this general rule of how to use the intrinsic locking, your question becomes irrelevant: if one thread keeps wait ing while the condition does not hold, other threads which do not wait for this condition (or are responsible for establishing the condition) will eventually run.