Java Reference
In-Depth Information
entail compromising good object-oriented design principles, such as breaking encapsulation;
sometimes they involve greater risk of error, because faster algorithms are usually more com-
plicated. (If you can't spot the costs or risks, you probably haven't thought it through carefully
enough to proceed.)
Most performance decisions involve multiple variables and are highly situational. Before de-
ciding that one approach is “faster” than another, ask yourself some questions:
•
What do you mean by “faster”?
•
Under what conditions will this approach
actually
be faster? Under light or heavy
load? With large or small data sets? Can you support your answer with measure-
ments?
•
How often are these conditions likely to arise in your situation? Can you support
your answer with measurements?
•
Is this code likely to be used in other situations where the conditions may be differ-
ent?
•
What hidden costs, such as increased development or maintenance risk, are you trad-
ing for this improved performance? Is this a good tradeoff?
These considerations apply to any performance-related engineering decision, but this is a
book about concurrency. Why are we recommending such a conservative approach to op-
timization?
The quest for performance is probably the single greatest source of concurrency
bugs.
The belief that synchronization was “too slow” led to many clever-looking but danger-
ous idioms for reducing synchronization (such as double-checked locking, discussed in
Sec-
tion 16.2.4
)
, and is often cited as an excuse for not following the rules regarding synchron-
ization. Because concurrency bugs are among the most difficult to track down and eliminate,
however, anything that risks introducing them must be undertaken very carefully.
Worse, when you trade safety for performance, you may get neither. Especially when it comes
to concurrency, the intuition of many developers about where a performance problem lies or
which approach will be faster or more scalable is often incorrect. It is therefore imperative
that any performance tuning exercise be accompanied by concrete performance requirements
(so you know both when to tune and when to
stop
tuning) and with a measurement program
in place using a realistic configuration and load profile. Measure again after tuning to verify
that you've achieved the desired improvements. The safety and maintenance risks associated
