Java Reference
In-Depth Information
will have; boosting a thread's priority might do nothing or might always cause one thread to
be scheduled in preference to the other, causing starvation.
It is generally wise to resist the temptation to tweak thread priorities. As soon as you start
modifying priorities, the behavior of your application becomes platform-specific and you in-
troduce the risk of starvation. You can often spot a program that is trying to recover from
priority tweaking or other responsiveness problems by the presence of
Thread.sleep
or
Thread.yield
calls in odd places, in an attempt to give more time to lower-priority
threads.
[5]
Avoid the temptation to use thread priorities, since they increase platform dependence and
can cause liveness problems. Most concurrent applications can use the default priority for all
threads.
10.3.2. Poor Responsiveness
One step removed from starvation is poor responsiveness, which is not uncommon in GUI ap-
plications using background threads.
Chapter 9
developed a framework for offloading long-
running tasks onto background threads so as not to freeze the user interface. CPU-intensive
background tasks can still affect responsiveness because they can compete for CPU cycles
with the event thread. This is one case where altering thread priorities makes sense; when
computeintensive background computations would affect responsiveness. If the work done
by other threads are truly background tasks, lowering their priority can make the foreground
tasks more responsive.
Poor responsiveness can also be caused by poor lock management. If a thread holds a lock
for a long time (perhaps while iterating a large collection and performing substantial work for
each element), other threads that need to access that collection may have to wait a very long
time.
10.3.3. Livelock
Livelock
is a form of liveness failure in which a thread, while not blocked, still cannot make
progress because it keeps retrying an operation that will always fail. Livelock often occurs in
transactional messaging applications, where the messaging infrastructure rolls back a transac-
tion if a message cannot be processed successfully, and puts it back at the head of the queue.
If a bug in the message handler for a particular type of message causes it to fail, every time
