深入优化Java性能：第二版精华指南
需积分: 1 201 浏览量
更新于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.
剩余495页未读，继续阅读
点击了解资源详情
点击了解资源详情
点击了解资源详情
2009-04-07 上传
2021-08-07 上传
2020-09-17 上传
2023-05-18 上传
2020-04-13 上传
2009-01-17 上传
走在架构的小路上
- 粉丝: 27
- 资源: 70
我的内容管理
展开
