Exactly when preemption can occur depends on the virtual machine you have. There are no guarantees, only a
general expectation that preference is typically given to running higher-priority threads. Use priority only to
affect scheduling policy for efficiency. Do not rely on thread priority for algorithm correctness. To write
correct, cross-platform multithreaded code you must assume that a thread could be preempted at any time, and
so you always protect access to shared resources. If you require that preemption occur at some specific time,
you must use explicit thread communication mechanisms such as wait and notify. You also can make no
assumptions about the order in which locks are granted to threads, nor the order in which waiting threads will
receive notificationsthese are all system dependent.
A thread's priority is initially the same as the priority of the thread that created it. You can change the priority
using setPriority with a value between THRead's constants MIN_PRIORITY and MAX_PRIORITY.
The standard priority for the default thread is NORM_PRIORITY. The priority of a running thread can be
changed at any time. If you assign a thread a priority lower than its current one, the system may let another
thread run because the original thread may no longer be among those with the highest priority. The
getPriority method returns the priority of a thread.
Generally, if you are to worry about priorities at all, the continuously running part of your application should
run in a lower-priority thread than the thread dealing with rarer events such as user input. When users push a
"Cancel" button, for example, they expect the application to cancel what it's doing. If display update and user
input are at the same priority and the display is updating, considerable time may pass before the user input
thread reacts to the button. If you put the display thread at a lower priority, it will still run most of the time
because the user interface thread will be blocked waiting for user input. When user input is available, the user
interface thread will typically preempt the display thread to act on the user's request. For this reason, a thread
that does continual updates is often set to NORM_PRIORITY-1 so that it doesn't hog all available cycles,
while a user interface thread is often set to NORM_PRIORITY+1.
Using small "delta" values around the normal priority level is usually preferable to using MIN_PRIORITY or
MAX_PRIORITY directly. Exactly what effect priorities have depends on the system you are running on. In
some systems your thread priorities not only assign an importance relative to your program, they assign an
importance relative to other applications running on the system.[1] Extreme priority settings may result in
undesirable behavior and so should be avoided unless their effects are known and needed.
[1] Check the release notes for your virtual-machine implementation; some implementations
treat ranges of priority values as the same, thus reducing the number of distinct scheduling
classes.Some algorithms are sensitive to the number of processors available to the virtual machine to run threads on.
For example, an algorithm might split work up into smaller chunks to take advantage of more parallel
processing power. The availableProcessors method of the Runtime class (see Chapter 23) returns
the number of processors currently available. Note that the number of processors can change at any time, so
you want to check this number when it is important rather than remember the number from a previous check.
14.6.1. Voluntary Rescheduling
Several methods of the Thread class allow a thread to relinquish its use of the CPU. By convention, static
methods of the THRead class always apply to the currently executing thread, and since you can never take the
CPU from another thread, these voluntary rescheduling methods are all static:
public static voidsleep(long millis)tHRows
InterruptedExceptionPuts the currently executing thread to sleep for at least the specified number
of milliseconds. "At least" means there is no guarantee the thread will wake