深入优化Java性能：第二版精华指南

需积分: 1 137 浏览量更新于2024-07-26 收藏 1.52MB PDF 举报

"Java性能调优——第二版——O'Reilly出版社——2003年" Java性能调优是自Java初版发布以来就一直关注的重要话题。早期的解释型Java程序在速度上的表现对许多开发者来说是一大挑战。然而，随着时间的发展，Java的性能有了显著的提升，现在任何Java程序都可以通过避免主要的性能瓶颈来实现足够快的运行。这本书面向的是希望优化Java程序性能的开发者，它提供了从设定目标、衡量性能、选择编译器到使用剖析工具和调整代码的详细步骤。虽然这不是一本入门级的Java书籍，但即使没有之前的调优经验，读者也能从中获益。书中介绍的许多调优技术可能会增加维护成本，因此不应随意应用。只有在确定了性能瓶颈后，才应修改代码，而且永远不要为了优化而改变设计。性能调优应该是一个有目标、有策略的过程。本书涵盖了以下关键知识点： 1. **性能基准与目标设定**：如何定义性能基准，设置合理的性能目标，以及如何在项目初期就考虑到性能因素。 2. **编译器选择**：讨论不同的Java编译器（如HotSpot）及其对性能的影响，如何根据项目需求选择合适的编译器。 3. **性能测量**：介绍如何有效地度量Java程序的性能，包括CPU使用率、内存占用、磁盘I/O等关键指标。 4. **剖析工具的使用**：详细讲解如何使用如VisualVM、JProfiler等工具进行代码剖析，定位性能问题。 5. **代码优化**：提供具体的代码优化技巧，包括算法改进、数据结构选择、减少不必要的对象创建等。 6. **JVM参数调整**：深入探讨JVM的运行时参数，如堆大小、垃圾收集器设置等，以及如何调整这些参数以优化性能。 7. **并发与多线程优化**：分析多线程环境下可能出现的性能问题，如死锁、竞态条件，以及如何优化并发代码。 8. **内存管理**：讲解Java内存模型，包括堆内存、栈内存和方法区，以及如何优化内存分配和垃圾回收。 9. **热点代码识别**：如何识别并优化执行频繁的“热点”代码，利用JIT编译器提高运行效率。 10. **性能监控与日志**：介绍如何建立有效的性能监控系统，以及如何通过日志记录和分析性能问题。这本书对于任何想要深入理解Java性能优化的开发者来说，都是宝贵的资源，它提供了实践指导和深入的理论知识，帮助开发者避免常见的性能陷阱，提升Java应用程序的效率。

There are almost always small variations between test runs, so always use averages to measure

differences and consider whether those differences are relevant by calculating the variance in the

results.

For distributed applications , you need to break down measurements into times spent on each

component, times spent preparing data for transfer and from transfer (e.g., marshalling and

unmarshalling objects and writing to and reading from a buffer), and times spent in network transfer.

Each separate machine used on the networked system needs to be monitored during the test if any

system parameters are to be included in the measurements. Timestamps must be synchronized across

the system (this can be done by measuring offsets from one reference machine at the beginning of

tests). Taking measurements consistently from distributed systems can be challenging, and it is often

easier to focus on one machine, or one communication layer, at a time. This is usually sufficient for

most tuning.

1.8 Don't Tune What You Don't Need to Tune

The most efficient tuning you can do is not to alter what works well. As they say, "If it ain't broke,

don't fix it." This may seem obvious, but the temptation to tweak something just because you have

thought of an improvement has a tendency to override this obvious statement.

The second most efficient tuning is to discard work that doesn't need doing. It is not at all uncommon

for an application to be started with one set of specifications and to have some of the specifications

change over time. Many times the initial specifications are much more generic than the final product.

However, the earlier generic specifications often still have their stamps in the application. I frequently

find routines, variables, objects, and subsystems that are still being maintained but are never used and

never will be used because some critical aspect is no longer supported. These redundant parts of the

application can usually be chopped without any bad consequences, often resulting in a performance

gain.

In general, you need to ask yourself exactly what the application is doing and why. Then question

whether it needs to do it in that way, or even if it needs to do it at all. If you have third-party products

and tools being used by the application, consider exactly what they are doing. Try to be aware of the

main resources they use (from their documentation). For example, a zippy DLL (shared library) that is

speeding up all your network transfers is using some resources to achieve that speedup. You should

know that it is allocating larger and larger buffers before you start trying to hunt down the source of

your mysteriously disappearing memory. Then you can realize that you need to use the more

complicated interface to the DLL that restricts resource usage rather than a simple and convenient

interface. And you will have realized this before doing extensive (and useless) object profiling

because you would have been trying to determine why yourapplication is being a memory hog.

When benchmarking third-party components, you need to apply a good simulation of exactly how you

will use those products. Determine characteristics from your benchmarks and put the numbers into

your overall model to determine if performance can be reached. Be aware that vendor benchmarks are

typically useless for a particular application. Break your application down into a hugely simplified

version for a preliminary benchmark implementation to test third-party components. You should make

a strong attempt to include all the scaling necessary so that you are benchmarking a fully scaled usage

of the components, not some reduced version that reveals little about the components in full use.

1.9 Performance Checklist

• Specify the required performance.

o Ensure performance objectives are clear.

o Specify target response times for as much of the system as possible.

o Specify all variations in benchmarks, including expected response ranges (e.g., 80%

of responses for X must fall within 3 seconds).

o Include benchmarks for the full range of scaling expected (e.g., low to high numbers

of users, data, files, file sizes, objects, etc.).

o Specify and use a benchmark suite based on real user behavior. This is particularly

important for multiuser benchmarks.

o Agree on all target times with users, customers, managers, etc., before tuning.

• Make your benchmarks long enough: over five seconds is a good target.

o Use elapsed time (wall-clock time) for the primary time measurements.

o Ensure the benchmark harness does not interfere with the performance of the

application.

o Run benchmarks before starting tuning, and again after each tuning exercise.

o Take care that you are not measuring artificial situations, such as full caches

containing exactly the data needed for the test.

• Break down distributed application measurements into components, transfer layers, and

network transfer times.

• Tune systematically: understand what affects the performance; define targets; tune; monitor

and redefine targets when necessary.

o Approach tuning scientifically: measure performance; identify bottlenecks;

hypothesize on causes; test hypothesis; make changes; measure improved

performance.

o Determine which resources are limiting performance: CPU, memory, or I/O.

o Accurately identify the causes of the performance problems before trying to tune

them.

o Use the strategy of identifying the main bottlenecks, fixing the easiest, then repeating.

o Don't tune what does not need tuning. Avoid "fixing" nonbottlenecked parts of the

application.

o Measure that the tuning exercise has improved speed.

o Target one bottleneck at a time. The application running characteristics can change

after eachalteration.

o Improve a CPU limitation with faster code, better algorithms, and fewer short-lived

objects.

o Improve a system-memory limitation by using fewer objects or smaller long-lived

objects.

o Improve I/O limitations by targeted redesigns or speeding up I/O, perhaps by

multithreading the I/O.

• Work with user expectations to provide the appearance of better performance.

o Hold back releasing tuning improvements until there is at least a 20% improvement

in response times.

o Avoid giving users a false expectation that a task will be finished sooner than it will.

o Reduce the variation in response times. Bear in mind that users perceive the mean

response time as the actual 90th percentile value of the response times.

o Keep the user interface responsive at all times.

o Aim to always give user feedback. The interface should not be dead for more than

two seconds when carrying out tasks.

o Provide the ability to abort or carry on alternative tasks.

o Provide user-selectable tuning parameters where this makes sense.

o Use threads to separate potentially blocking functions.

o Calculate "look-ahead" possibilities while the user response is awaited.

o Provide partial data for viewing as soon as possible, without waiting for all requested

data to be received.

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.

In addition to Java-specific profilers, there are other more generic tools that can be useful for profiling:

• J2EE server-side monitors, useful to monitor server performance both in development and in

production

• Network packet sniffers (both hardware and software types, e.g., netstat)

• Process and thread-listing utilities (top and ps on Unix; the task manager and performance

monitor on Windows)

• System performance measuring utilities (vmstat, iostat, sar, top on Unix; the task manager

and performance monitor on Windows)

2.1 Measurements and Timings

When looking at timings, be aware that different tools affect the performance of applications in

different ways. Any profiler slows down the application it is profiling. The degree of slowdown can

vary from a few percent to a few hundred percent. Using System.currentTimeMillis( )

in the code to get timestamps is the only reliable way to determine the time taken by each part of the

application. In addition, System.currentTimeMillis( )is quick and has no effect on

application timing (as long as you are not measuring too many intervals or ridiculously short intervals;

see the discussion in Section 1.7).

Another variation on timing the application depends on the underlying operating system . The

operating system can allocate different priorities for different processes, and these priorities determine

the importance the operating system applies to a particular process. This in turn affects the amount of

CPU time allocated to a particular process compared to other processes. Furthermore, these priorities

can change over the lifetime of the process. It is usual for server operating systems to gradually

decrease the priority of a process over that process's lifetime. This means that the process has shorter

periods of the CPU allocated to it before it is put back in the runnable queue. An adaptive VM (like

Sun's HotSpot) can give you the reverse situation, speeding up code shortly after it has started running

(see Section 3.7).

Whether or not a process runs in the foreground can also be important. For example, on a machine

with the workstation version of Windows (most varieties including NT, 95, 98, and 2000), foreground

processes are given maximum priority. This ensures that the window currently being worked on is

maximally responsive. However, if you start a test and then put it in the background so that you can do

something else while it runs, the measured times can be very different from the results you would get

if you left that test running in the foreground. This applies even if you do not actually do anything else

while the test is running in the background. Similarly, on server machines, certain processes may be

allocated maximum priority (for example, Windows NT and 2000 server version, as well as most Unix

server configured machines, allocate maximum priority to network I/O processes).

This means that to get pure absolute times, you need to run tests in the foreground on a machine with

no other significant processes running, and useSystem.currentTimeMillis( )to

measure the elapsed times. Any other configuration implies some overhead added to timings, and you

must be aware of this. As long as you are aware of any extra overhead, you can usually determine

whether a particular measurement is relevant or not.

Most profiles provide useful relative timings, and you are usually better off ignoring the absolute

times when looking at profile results. Be careful when comparing absolute times run under different

conditions, e.g., with and without a profiler, in the foreground versus in the background, on a very

lightly loaded server (for example, in the evening) compared to a moderately loaded one (during the

day). All these types of comparisons can be misleading.

You also need to take into account cache effects . There will be effects from caches in the hardware, in

the operating system, across various points in a network, and in the application. Starting the

application for the first time on a newly booted system usually gives different timings as compared to

starting for the first time on a system that has been running for a while, and both give different timings

compared to an application that has been run several times previously on the system. All these

variations need to be considered, and a consistent test scenario used. Typically, you need to manage

the caches in the application, perhaps explicitly emptying (or filling) them for each test run to get

repeatable results. The other caches are difficult to manipulate, and you should try to approximate the

targeted running environment as closely as possible, rather than testing each possible variation in the

environment.

2.2 Garbage Collection

The Java runtime system normally includes a garbage collector.

[2]

Some of the commercial profilers

provide statistics showing what the garbage collector is doing. You can also use the -verbosegc

option with the VM. This option prints out time and space values for objects reclaimed and space

recycled as the reclamations occur. The 1.4 VM introduced an additional option to log the output to a

file instead of standard error: the -Xloggc:<file> option. Printing directly to a file is slightly

more efficient than redirecting the VM output to a file because the direct file write buffering is slightly

more efficient than the piped redirect buffering. The printout includes explicit synchronous calls to the

garbage collector (using System.gc( )) as well as asynchronous executions of the garbage

collector, as occurs in normal operation when free memory available to the VM gets low.

[2]

Some embedded runtimes do not include a garbage collector. All objects may have to fit into memory

without any garbage collection for these runtimes.

System.gc( )does not necessarily force a synchronous garbage

collection. Instead, the gc( ) call is really a hint to the runtime that now is a

good time to run the garbage collector. The runtime decides whether to

execute the garbage collection at that time and what type of garbage collection

to run. In more recent VMs, the effects of calling System.gc( )can be

completely disabled using the runtime flag XX:+DisableExplicitGC.

2.2.1 Using -verbosegc to Analyze Garbage Collection

It is worth looking at some output from running with -verbosegc. The following code fragment

creates lots of objects to force the garbage collector to work, and also includes some synchronous calls

to the garbage collector:

package tuning.gc;

public class Test {

public static void main(String[ ] args)

{

int SIZE = 4000;

StringBuffer s;

java.util.Vector v;

//Create some objects so that the garbage collector

//has something to do

剩余495页未读，继续阅读

走在架构的小路上

粉丝: 27
资源: 70

深入优化Java性能：第二版精华指南

Java.EE.7.Performance.Tuning.and.Optimization.178217642X

Java performance tuning - getting started

2-day-performance-tuning-guide.pdf

database-2-day-performance-tuning-guide.pdf

Performance-Tuning-Guide-for-Mellanox-Network-Adapters.pdf

AIX-Performance-Tuning-VUG-May2418.pdf

Performance Tuning --oracle 9i 性能调整与优化

Digital.Press-Oracle.High.Performance.Tuning.for.9i.and.10g.part1.rar

Digital.Press-Oracle.High.Performance.Tuning.for.9i.and.10g.part2.rar

Oracle 11G Performance Tuning - sg3

最新资源