Causes the current thread to wait until it is awakened, typically by being
notified or
interrupted, or until a certain amount of real time has elapsed.
The current thread must own this object's monitor lock. See the notify
method for a description of the ways in which a thread can become the owner of a monitor lock.
This method causes the current thread (referred to here as T) to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object. Note that only the locks on this object are relinquished; any other objects on which the current thread may be synchronized remain locked while the thread waits.
Thread T then becomes disabled for thread scheduling purposes and lies dormant until one of the following occurs:
- Some other thread invokes the
notify
method for this object and thread T happens to be arbitrarily chosen as the thread to be awakened.
- Some other thread invokes the
notifyAll
method for this object.
- Some other thread interrupts thread T.
- The specified amount of real time has elapsed, more or less. The amount of real time, in nanoseconds, is given by the expression
1000000 * timeoutMillis + nanos
. If timeoutMillis
and nanos
are both zero, then real time is not taken into consideration and the thread waits until awakened by one of the other causes.
- Thread T is awakened spuriously. (See below.)
The thread T is then removed from the wait set for this object and re-enabled for thread scheduling. It competes in the usual manner with other threads for the right to synchronize on the object; once it has regained control of the object, all its synchronization claims on the object are restored to the status quo ante - that is, to the situation as of the time that the wait
method was invoked. Thread T then returns from the invocation of the wait
method. Thus, on return from the wait
method, the synchronization state of the object and of thread T
is exactly as it was when the wait
method was invoked.
A thread can 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. See the example below.
For more information on this topic, see section 14.2, "Condition Queues," in Brian Goetz and others' Java Concurrency in Practice (Addison-Wesley, 2006) or Item 81 in Joshua Bloch's Effective Java, Third Edition (Addison-Wesley, 2018).
If the current thread is interrupted by any thread before or while it is waiting, then an InterruptedException
is thrown. The interrupted status of the current thread is cleared when this exception is thrown. This exception is not thrown until the lock status of this object has been restored as described above.
Subclasses that override
finalize
to perform cleanup should use alternative cleanup mechanisms and remove thefinalize
method. UseCleaner
andPhantomReference
as safer ways to release resources when an object becomes unreachable. Alternatively, add aclose
method to explicitly release resources, and implementAutoCloseable
to enable use of thetry
-with-resources statement.This method will remain in place until finalizers have been removed from most existing code.