— Scott McNealy, Sun Microsystems Chairman, President and ceo

The thread 
scheduler makes all 
the decisions about 
who runs and who 
doesn’t. He usually 
makes the threads take 
turns, nicely. But 
there’s no guarantee 
about that. He might 
let one thread run 
to its heart’s content 
while the other 
threads ‘starve’.
The thread scheduler makes all the decisions about 
who moves from runnable to running, and about when 
(and under what circumstances) a thread leaves the 
running state. The scheduler decides who runs, and for 
how long, and where the threads go when the scheduler 
decides to kick them out of the currently-running state.
You can’t control the scheduler. There is no API for 
calling methods on the scheduler. Most importantly, 
there are no guarantees about scheduling! (There are a 
few almost-guarantees, but even those are a little fuzzy.)
The bottom line is this: do not base your program’s 
correctness on the scheduler working in a particular way!
The scheduler implementations are different for 
different JVM’s, and even running the same program 
on the same machine can give you different results. 
One of the worst mistakes new Java programmers 
make is to test their multi-threaded program on a 
single machine, and assume the thread scheduler will 
always work that way, regardless of where the program 
runs. 
So what does this mean for write-once-run-anywhere? 
It means that to write platform-independent Java code, 
your multi-threaded program must work no matter how 
the thread scheduler behaves. That means that you can’t 
be dependent on, for example, the scheduler making 
sure all the threads take nice, perfectly fair and equal 
turns at the running state. Although highly unlikely 
today, your program might end up running on a JVM 
with a scheduler that says, “OK thread five, you’re up, 
and as far as I’m concerned, you can stay here until 
you’re done, when your run() method completes.”
The secret to almost everything is sleep. That’s 
right, sleep. Putting a thread to sleep, even for a few 
milliseconds, forces the currently-running thread to 
leave the running state, thus giving another thread a 
chance to run. The thread’s sleep() method does come 
with one guarantee: a sleeping thread will not become 
the currently-running thread before the the length of 
its sleep time has expired. For example, if you tell your 
thread to sleep for two seconds (2,000 milliseconds), 
that thread can never become the running thread again 
until sometime after the two seconds have passed.

---