The Thread.sleep() method effectively "pauses" the current thread for a given period of time.
We used it in our very first threading example to make threads display
a message periodically, sleeping between messages. From the outset, it's important to
be aware of the following:
- it is always the current thread that is put to sleep;
- the thread might not sleep for the required time (or even at all);
- the sleep duration will be subject to some system-specific granularity,
- while sleeping, the thread still owns synchronization locks it has
- the sleep can be interrupted (sometimes useful
for implementing a cancellation function);
- calling sleep() with certain values can have some subtle, global effects on the OS (see below),
and vice versa, other threads and processes running on the system can have subtle effects on the
observed sleep duration.
With these caveats, the general idea is that we call Thread.sleep(), passing in
a number of milliseconds (or milliseconds plus nanoseconds) that we want to sleep for:
// sleep for about 2 seconds
// sleep for about 2.5 seconds
Sleep behaviour and granularity
On both Windows and Linux, the VM can generally offer a maximum sleep granularity
of 1ms, and will achieve this quite accurately on a "quiet" system. Figure 1 shows
the mean observed sleep duration against requested duration on a uniprocessor machine
running Windows XP (each point is the mean of around 50 measured sleeps of the
The sleep behaviour illustrated by this graph and reasons for it will be discussed in more detail in the
The aim of the nanosecond version is (presumably) to offer potential support for
"real time" operating systems that can offer this level of fine-tuned sleep.
In practice, no mainstream operating system that I'm aware
of can sleep with a granularity of lower than 1ms, and Sun's J2SE implementation
actually just rounds to the nearest millisecond!
Figure 1: Mean sleep duration against requested duration under different load circumstances in Windows XP.
How does sleep work?
To understand some of the behaviour we see in Figure 1, it's worth understanding a little
about how thread sleeping actually works.
The Thread.sleep() method essentially interacts with the
thread scheduler to put the current
thread into a wait state for the required interval. In order to allow interruption,
the implementation may not actually use the explicit sleep function that most
OS's provide. (For example, Sun's VM under Windows implements Thread.sleep() by waiting for
a thread interrupt event with a timeout, via WaitForMultipleObjects).
The granularity of sleeps is generally bound by the
thread scheduler's interrupt period. In Linux, this interrupt period
is generally 1ms in recent kernels (2.6.8 onwards).
In Windows, the scheduler's interrupt period is normally around 10 or 15 milliseconds
(which I believe is dictated by the processor), but a higher period can be requested in software
and the Hotspot JVM does so when it deems necessary (but see the section on bugs below).
Assuming an interrupt every 1ms, then when the required whole number of milliseconds has elapsed,
whether the thread is "woken up" (i.e. scheduled on to a CPU) on that particular interrupt depends
essentially on whether there is a higher-priority thread that is ready to run at that moment.
On Windows, the thread that is ready to be woken will be given a small temporary priority boost so
that it is more likely to "cut in" at the right moment. But if that still isn't enough, then the
wakeup will be delayed. In Figure 1, the shape of the red line shows the pattern in mean sleep when
a DVD player application is running in the foreground at the same time as the sleep test. Since the
DVD player (presumably) has some above-normal priority threads to manage video and audio, there is
often a chance that the woken thread will still have to wait its turn. The yellow and green
lines show what happens when we lower and raise the priority of the sleeping Java thread (to
MIN_PRIORITY and MAX_PRIORITY respectively): raising the priority alleviates
the problem to some extent, but does not eliminate delay. Some of the spikes on the graph, particularly
in the case of the normal-priority thread (in red) are probably due to slightly complex interactions between
requested sleep time and quantum. With certain combinations of
thread priority and requested sleep duration, we seem more likely to hit "worse cases" where our thread
must wait for a higher-priority thread to complete its quantum. And every 6 sleeps, our thread will also
run out of quantum and have to wait for threads of equal priority. On the test machine, the interrupt period
was 15ms, and so the default thread quantum 30ms: note a high spike around 30ms, and lower spikes
around 15 and 45ms.
Issues with Thread.sleep()
On the next page, we examine various issues and bugs with Thread.sleep() not
fully discussed above.