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:
notify
method for this
object and thread T happens to be arbitrarily chosen as
the thread to be awakened.
notifyAll
method for this
object.
1000000 * timeout + nanos
. If timeout
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.
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 69 in Joshua Bloch's Effective Java, Second Edition (Addison-Wesley, 2008).
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.
timeout | the maximum time to wait, in milliseconds | |
nanos | additional time, in nanoseconds, in the range range 0-999999 inclusive |
IllegalArgumentException | if the value of timeout is negative,
or if the value of nanos is out of range | |
IllegalMonitorStateException | if the current thread is not the owner of the object's monitor | |
InterruptedException | if any thread interrupted the current thread before or while the current thread was waiting. The interrupted status of the current thread is cleared when this exception is thrown. |
notify(), notifyAll(), wait(), wait(long)
@apiNote
The recommended approach to waiting is to check the condition being awaited in
a while
loop around the call to wait
, as shown in the example
below. Among other things, this approach avoids problems that can be caused
by spurious wakeups.
synchronized (obj) {
while (<condition does not hold> and <timeout not exceeded>) {
long timeout = ... ; // recompute timeout values
int nanos = ... ;
obj.wait(timeout, nanos);
... // Perform action appropriate to condition or timeout
}
}
Diagram: Object