JavaPerformanceThe Definitive Guide

当O’Reilly第一次找我写一本关于Java性能调优的书时，

我不确定。Java性能，我想——我们还没有完成吗？是的，我还在工作

关于Java（和其他）应用程序的日常性能，但我喜欢这样认为

我大部分时间都在处理算法效率和外部系统

而不是任何与Java调优直接相关的问题。

片刻的思考使我确信我（像往常一样）在开玩笑。当然是

确实，端到端系统性能占用了我很多时间，而且我有时

遇到使用O（n2） 当它可以使用一个带有O（log N）的算法时

表演尽管如此，事实证明，我每天都在思考GC的性能，或者

JVM编译器的性能，或者如何从Java En中获得最佳性能

terprise Edition API。

这并不是为了最小化在性能方面取得的巨大进展

在过去的15多年里，Java和JVM的发展。当我在Sun做Java福音传道者时

20世纪90年代末，唯一真正的“基准”是Pendra的CaffeineMark2.0

gon软件。由于各种原因，该基准的设计很快限制了其

价值然而，在它的时代，我们喜欢告诉每个人Java 1.1.8的性能

比基于该基准测试的Java 1.0性能快8倍

true——Java 1.1.8有一个实际的实时编译器，其中Java 1.0相当完全解释。

然后，标准委员会开始开发更严格的基准，Java

表演开始围绕他们展开。结果是持续改进

JVM的所有领域——垃圾收集、编译和API内。

当然，这一过程今天仍在继续，但关于绩效的一个有趣事实是

绩效工作是不断变得更难。实现人均收入增长八倍

引入实时编译器的性能是一个简单的问题

工程，即使编译器不断改进，我们也不会看到

又是这样的进步。将垃圾收集器并行化是一项巨大的任务

性能有所提高，但最近的变化更为渐进。