Chapter 9. Threading and
From its first days, some of Java's appeal has been because it is multithreaded. Even in the
days before multicore and multi-CPU systems were the norm, the ability to easily write
threaded programs in Java has been considered one of its hallmark features.
In performance terms, the appeal is obvious: if two CPUs are available, then an application
might be able to do twice as much work, or the same amount of work twice as fast. This as-
sumes that the task can be broken into discrete segments, since Java is not an autoparalleliz-
ing language that will figure out the algorithmic parts. Fortunately, computing today is often
about discrete tasks: a server handling simultaneous requests from discrete clients, a batch
job performing the same operation on a series of data, mathematical algorithms that break in-
to constituent parts, and so on.
This chapter explores how to get the maximum performance out of Java threading and syn-
Thread Pools and ThreadPoolExecutors
Threads can be managed by custom code in Java, or applications can utilize a thread pool.
Java EE application servers are built around the notion of one or more thread pools to handle
requests: each servlet call into the server is handled by a (potentially different) thread from
the pool. Similarly, other applications can use Java's ThreadPoolExecutor to execute tasks
In fact, some Java EE application servers use instances of the ThreadPoolExecutor class to
manage their tasks, though many have written their own thread pools (if only because they
predate the addition of ThreadPoolExecutor to the Java API). Although the implementation
of the pools in these cases might differ, the basic concepts are the same, and both are dis-
cussed in this section.
The key factor in using a thread pool is that tuning the size of the pool is crucial to getting
the best performance. Thread pool performance varies depending on basic choices about