Java性能优化深度解析

需积分: 5 178 浏览量更新于2024-07-28 收藏 1.79MB PDF 举报

"Java性能优化是Java高级程序员、服务端程序员和服务器运维人员必须关注的领域，涉及到如何提升Java应用程序的运行效率、减少资源消耗和提高系统稳定性。本书《Java Performance Tuning》由O'Reilly出版，作者深入探讨了Java性能调优的各种策略和技术。书中可能涵盖了对Java虚拟机（JVM）的深入理解、内存管理、垃圾收集机制、线程优化、代码优化、数据库连接管理、网络优化等多个关键主题。" 在Java性能优化中，有几个核心的知识点： 1. **JVM调优**：理解JVM的工作原理是性能优化的基础。这包括了解不同类型的垃圾收集器，如串行、并行、并发和G1，以及它们在不同场景下的优缺点。调整JVM的堆大小、新生代与老年代的比例、存活对象阈值等参数，可以显著影响应用的性能。 2. **内存管理**：理解内存分配和对象生命周期，包括如何避免内存泄漏和过度对象创建。使用内存分析工具如VisualVM或JProfiler进行内存快照分析，有助于发现内存占用过高或泄露的问题。 3. **代码优化**：编写高效的Java代码是性能优化的关键。这包括避免不必要的对象创建，减少循环内的计算，使用StringBuilder代替String进行字符串拼接，以及充分利用缓存和数据结构来优化算法。 4. **线程优化**：多线程编程中的竞争条件、死锁和活锁可能导致性能下降。正确设置线程池大小，合理使用同步和锁，避免阻塞操作，可以提高并发性能。 5. **数据库连接管理**：优化数据库访问是性能优化的重要环节。减少数据库连接的创建和销毁，使用连接池如C3P0或HikariCP，优化SQL查询，使用索引，都可以显著提升系统性能。 6. **网络优化**：减小数据传输量，使用压缩技术，优化网络协议，如HTTP/2，调整TCP/IP参数，都能改善网络性能。 7. **监控和日志**：通过JMX（Java Management Extensions）监控JVM状态，使用日志记录性能指标，可以帮助定位问题和评估优化效果。 8. **应用架构设计**：合理的架构设计能从整体上提升系统的性能和可扩展性。例如，采用微服务架构，负载均衡，分布式缓存等。每个知识点都需要深入理解和实践，结合实际情况进行调优。同时，性能优化不仅仅是技术问题，还需要考虑到业务需求和用户体验，以找到性能与资源消耗的最佳平衡点。

O’reilly - Java Performance Tuning

- 16 -

Your general benchmark suite should be based on real functions used in the end application, but at

the same time should not rely on user input, as this can make measurements difficult. Any

variability in input times or any other part of the application should either be eliminated from the

benchmarks or precisely identified and specified within the performance targets. There may be

variability, but it must be controlled and reproducible.

1.6.3 The Benchmark Harness

There are tools for testing applications in various ways.

[2]

These tools focus mostly on testing the

robustness of the application, but as long as they measure and report times, they can also be used for

performance testing. However, because their focus tends to be on robustness testing, many tools

interfere with the application's performance, and you may not find a tool you can use adequately or

cost-effectively. If you cannot find an acceptable tool, the alternative is to build your own harness.

[2]

You can search the Web for java+perf+test to find performance-testing tools. In addition, some Java profilers are listed in Chapter 15.

Your benchmark harness can be as simple as a class that sets some values and then starts the main(

)

method of your application. A slightly more sophisticated harness might turn on logging and

timestamp all output for later analysis. GUI-run applications need a more complex harness and

require either an alternative way to execute the graphical functionality without going through the

GUI (which may depend on whether your design can support this), or a screen event capture and

playback tool (several such tools exist

[3]

). In any case, the most important requirement is that your

harness correctly reproduces user activity and data input and output. Normally, whatever

regression-testing apparatus you have (and presumably are already using) can be adapted to form a

benchmark harness.

[3]

JDK 1.3 introduced a new java.awt.Robot class, which provides for generating native system-input events, primarily to support automated

testing of Java GUIs.

The benchmark harness should not test the quality or robustness of the system. Operations should

be normal: startup, shutdown, noninterrupted functionality. The harness should support the different

configurations your application operates under, and any randomized inputs should be controlled;

but note that the random sequence used in tests should be reproducible. You should use a realistic

amount of randomized data and input. It is helpful if the benchmark harness includes support for

logging statistics and easily allows new tests to be added. The harness should be able to reproduce

and simulate all user input, including GUI input, and should test the system across all scales of

intended use, up to the maximum numbers of users, objects, throughputs, etc. You should also

validate your benchmarks, checking some of the values against actual clock time to ensure that no

systematic or random bias has crept into the benchmark harness.

For the multiuser case, the benchmark harness must be able to simulate multiple users working,

including variations in user access and execution patterns. Without this support for variations in

activity, the multiuser tests inevitably miss many bottlenecks encountered in actual deployment and,

conversely, do encounter artificial bottlenecks that are never encountered in deployment, wasting

time and resources. It is critical in multiuser and distributed applications that the benchmark harness

correctly reproduces user-activity variations, delays, and data flows.

1.6.4 Taking Measurements

Each run of your benchmarks needs to be under conditions that are as identical as possible;

otherwise it becomes difficult to pinpoint why something is running faster (or slower) than in

another test. The benchmarks should be run multiple times, and the full list of results retained, not

just the average and deviation or the ranged percentages. Also note the time of day that benchmarks

O’reilly - Java Performance Tuning

- 17 -

are being run and any special conditions that apply, e.g., weekend or after hours in the office.

Sometimes the variation can give you useful information. It is essential that you always run an

initial benchmark to precisely determine the initial times. This is important because, together with

your targets, the initial benchmarks specify how far you need to go and highlight how much you

have achieved when you finish tuning.

It is more important to run all benchmarks under the same conditions than to achieve the end-user

environment for those benchmarks, though you should try to target the expected environment. It is

possible to switch environments by running all benchmarks on an identical implementation of the

application in two environments, thus rebasing your measurements. But this can be problematic: it

requires detailed analysis because different environments usually have different relative

performance between functions (thus your initial benchmarks could be relatively skewed compared

with the current measurements).

Each set of changes (and preferably each individual change) should be followed by a run of

benchmarks to precisely identify improvements (or degradations) in the performance across all

functions. A particular optimization may improve the performance of some functions while at the

same time degrading the performance of others, and obviously you need to know this. Each set of

changes should be driven by identifying exactly which bottleneck is to be improved and how much

a speedup is expected. Using this methodology rigorously provides a precise target of your effort.

You need to verify that any particular change does improve performance. It is tempting to change

something small that you are sure will give an "obvious" improvement, without bothering to

measure the performance change for that modification (because "it's too much trouble to keep

running tests"). But you could easily be wrong. Jon Bentley once discovered that eliminating code

from some simple loops can actually slow them down.

[4]

If a change does not improve performance,

you should revert back to the previous version.

[4]

"Code Tuning in Context" by Jon Bentley, Dr. Dobb's Journal, May 1999. An empty loop in C ran slower than one that contained an integer increment

operation.

The benchmark suite should not interfere with the application. Be on the lookout for artificial

performance problems caused by the benchmarks themselves. This is very common if no thought is

given to normal variation in usage. A typical situation might be benchmarking multiuser systems

with lack of user simulation (e.g., user delays not simulated causing much higher throughput than

would ever be seen; user data variation not simulated causing all tests to try to use the same data at

the same time; activities artificially synchronized giving bursts of activity and inactivity; etc.). Be

careful not to measure artificial situations, such as full caches with exactly the data needed for the

test (e.g., running the test multiple times sequentially without clearing caches between runs). There

is little point in performing tests that hit only the cache, unless this is the type of work the users will

always perform.

When tuning, you need to alter any benchmarks that are quick (under five seconds) so that the code

applicable to the benchmark is tested repeatedly in a loop to get a more consistent measure of where

any problems lie. By comparing timings of the looped version with a single-run test, you can

sometimes identify whether caches and startup effects are altering times in any significant way.

Optimizing code can introduce new bugs, so the application should be tested during the

optimization phase. A particular optimization should not be considered valid until the application

using that optimization's code path has passed quality assessment.

O’reilly - Java Performance Tuning

- 18 -

Optimizations should also be completely documented. It is often useful to retain the previous code

in comments for maintenance purposes, especially as some kinds of optimized code can be more

difficult to understand (and therefore to maintain).

It is typically better (and easier) to tune multiuser applications in single-user mode first. Many

multiuser applications can obtain 90% of their final tuned performance if you tune in single-user

mode and then identify and tune just a few major multiuser bottlenecks (which are typically a sort

of give-and-take between single-user performance and general system throughput). Occasionally,

though, there will be serious conflicts that are revealed only during multiuser testing, such as

transaction conflicts that can slow an application to a crawl. These may require a redesign or

rearchitecting of the application. For this reason, some basic multiuser tests should be run as early

as possible to flush out potential multiuser-specific performance problems.

Tuning distributed applications requires access to the data being transferred across the various parts

of the application. At the lowest level, this can be a packet sniffer on the network or server machine.

One step up from this is to wrap all the external communication points of the application so that you

can record all data transfers. Relay servers are also useful. These are small applications that just re-

route data between two communication points. Most useful of all is a trace or debug mode in the

communications layer that allows you to examine the higher-level calls and communication

between distributed parts.

1.7 What to Measure

The main measurement is always wall-clock time. You should use this measurement to specify

almost all benchmarks, as it's the real-time interval that is most appreciated by the user. (There are

certain situations, however, in which system throughput might be considered more important than

the wall-clock time; e.g., servers, enterprise transaction systems, and batch or background systems.)

The obvious way to measure wall-clock time is to get a timestamp using

System.currentTimeMillis( ) and then subtract this from a later timestamp to determine the

elapsed time. This works well for elapsed time measurements that are not short.

[5]

Other types of

measurements have to be system-specific and often application-specific. You can measure:

[5]

System.currentTimeMillis( ) can take up to half a millisecond to execute. Any measurement including the two calls needed to

measure the time difference should be over an interval greater than 100 milliseconds to ensure that the cost of the

System.currentTimeMillis( ) calls are less than 1% of the total measurement. I generally recommend that you do not make more than

one time measurement (i.e., two calls to

System.currentTimeMillis( )) per second.

• CPU time (the time allocated on the CPU for a particular procedure)

• The number of runnable processes waiting for the CPU (this gives you an idea of CPU

contention)

• Paging of processes

• Memory sizes

• Disk throughput

• Disk scanning times

• Network traffic, throughput, and latency

• Transaction rates

• Other system values

However, Java doesn't provide mechanisms for measuring these values directly, and measuring

them requires at least some system knowledge, and usually some application-specific knowledge

(e.g., what is a transaction for your application?).

O’reilly - Java Performance Tuning

- 19 -

You need to be careful when running tests that have small differences in timings. The first test is usually

slightly slower than any other tests. Try doubling the test run so that each test is run twice within the VM

(e.g., rename main( ) to maintest( ), and call maintest( ) twice from a new main( )).

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, since some critical aspect of these resources

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 your application 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 will reveal

little about the components in full use.

O’reilly - Java Performance Tuning

- 20 -

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 each alteration.

o Improve a CPU limitation with faster code and 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.

剩余317页未读，继续阅读

码缘难舍

粉丝: 5
资源: 14

Java性能优化深度解析

java程序性能优化

java 性能优化的方向

java性能优化详解

大话java性能优化pdf

java性能优化权威指南英文版pdf

聚焦java性能优化 打造亿级流量秒杀系统

java 应用性能优化

java 的性能优化

java performance: the definitive guide by scott oaks

java路线推荐书籍

最新资源

聚焦java性能优化打造亿级流量秒杀系统