Performance and Scalability - Java Concurrency in Practice - page 257

Chapter 11. Performance and Scalability
One of the primary reasons to use threads is to improve performance. [1] Using threads can
improve resource utilization by letting applications more easily exploit available processing
capacity, and can improve responsiveness by letting applications begin processing new tasks
immediately while existing tasks are still running.
This chapter explores techniques for analyzing, monitoring, and improving the performance
of concurrent programs. Unfortunately, many of the techniques for improving performance
also increase complexity, thus increasing the likelihood of safety and liveness failures. Worse,
some techniques intended to improve performance are actually counterproductive or trade one
sort of performance problem for another. While better performance is often desirable—and
improving performance can be very satisfying—safety always comes first. First make your
program right, then make it fast—and then only if your performance requirements and meas-
urements tell you it needs to be faster. In designing a concurrent application, squeezing out the
last bit of performance is often the least of your concerns.
11.1. Thinking about Performance
Improving performance means doing more work with fewer resources. The meaning of “re-
sources” can vary; for a given activity, some specific resource is usually in shortest supply,
whether it is CPU cycles, memory, network bandwidth, I/O bandwidth, database requests, disk
space, or any number of other resources. When the performance of an activity is limited by
availability of a particular resource, we say it is bound by that resource: CPU-bound, database-
bound, etc.
While the goal may be to improve performance overall, using multiple threads always intro-
duces some performance costs compared to the single-threaded approach. These include the
overhead associated with coordinating between threads (locking, signaling, and memory syn-
chronization), increased context switching, thread creation and teardown, and scheduling over-
head. When threading is employed effectively, these costs are more than made up for by great-
er throughput, responsiveness, or capacity. On the other hand, a poorly designed concurrent
application can perform even worse than a comparable sequential one. [2]
In using concurrency to achieve better performance, we are trying to do two things: utilize the
processing resources we have more effectively, and enable our program to exploit additional
processing resources if they become available. From a performance monitoring perspective,
this means we are looking to keep the CPUs as busy as possible. (Of course, this doesn't mean