![](https://csdnimg.cn/release/download_crawler_static/5004599/bg12.jpg)
o Cache locally items that may be looked at again or recalculated.
• Quality-test the application after any optimizations have been made.
• Document optimizations fully in the code. Retain old code in comments.
Chapter 2. Profiling Tools
If you only have a hammer, you tend to see every problem as a nail.
— Abraham Maslow
Before you can tune your application, you need tools that will help you find the bottlenecks in the
code. I have used many different tools for performance tuning, and so far I have found the
commercially available profilers to be the most useful. You can easily find several of these, together
with reviews, by searching the Web using "java+optimi" and "java+profile" as your search term or by
checking various computer magazines. I also maintain a list at
http://www.JavaPerformanceTuning.com/resources.shtml. These tools are usually available free for an
evaluation period, and you can quickly tell which you prefer using. If your budget covers it, it is worth
getting several profilers: they often have complementary features and provide different details about
the running code. I have included a list of profilers in Chapter 19.
All profilers have some weaknesses, especially when you want to customize them to focus on
particular aspects of the application. Another general problem with profilers is that they frequently fail
to work in nonstandard environments. Nonstandard environments should be rare, considering Java's
emphasis on standardization, but most profiling tools work at the VM level, and there is not currently
a VM profiling standard,
[1]
so incompatibilities do occur. Even if a VM profiling standard is finalized,
I expect there will be some nonstandard VMs you may have to use, possibly a specialized VM of
some sort— there are already many of these.
[1]
The Java Virtual Machine Profiler Interface (JVMPI) was introduced in 1.2, but it is only experimental and
subject to change, a nd looks like it will stay that way officially. There are now two expert groups, JSR 163
and JSR 174, addressing JVM profiling and monitoring issues, and the results of these two expert groups
should eventually supersede JVMPI.
When tuning, I normally use one of the commercial profiling tools, and on occasion when the tools do
not meet my needs, I fall back on a variation of one of the custom tools and information-extraction
methods presented in this chapter. Where a particular VM offers extra APIs that tell you about some
running characteristics of your application, these custom tools are essential to access those extra APIs.
Using a professional profiler and the proprietary tools covered in this chapter, you will have enough
information to figure out where problems lie and how to resolve them. When necessary, you can
successfully tune without a professional profiler, as the Sun VM contains a basic profiler, which I
cover in this chapter. However, this option is not ideal for the most rapid tuning.
From JDK 1.2, Java specifies a VM-level interface, consisting of C function
calls, that allows some external control over the VM. These calls provide
monitoring and control over events in the VM, allowing an application to
query the VM and to be notified about thread activity, object creation, garbage
collection, method call stack, etc. These are the calls required to create a
profiler. The interface is intended to standardize the calls to the VM made by a
profiler, so any profiler works with any VM that supports the JVMPI standard.
However, in JDK 1.2, the JVMPI is experimental and subject to change.