内容提要
- 性能的重要性
- 新的垃圾收集器G1
- VisualVM：内存可视化工具
- 即时编译
糟糕的性能会“杀死”你的应用程序，使你名声扫地，在客户中的信誉大受影响。除非你具有绝对垄断地位，否则你的客户将夺门而出，直奔你的竞争对手而去。要让糟糕的性能不再糟蹋你的项目，你需要理解性能分析，还要知道如何利用它。
性能分析与调优是个非常庞大的课题，但是现在有太多处理方式都在误人子弟。所以我们准备把性能调优的秘诀透漏给你。
秘诀来了——性能调优唯一的惊天秘诀就是：你必须量体裁衣。没有评测，就没有合适的调优。
原因：人们总是猜不对系统变慢的是哪里。所有人都猜不对。你，我，甚至是James Gosling大神——我们总会心生偏见，并倾向于那些可能根本不存在的模式。
实际上，“我的哪些Java代码需要优化？”这个问题的答案经常是“哪个也不用，都挺好的” 。
假设有一个经典（相当保守）的电子商务Web应用为注册客户提供服务。它有一个SQL数据库，一个面向Java应用服务器的Apache Web服务器，以及连接这一切的标准网络配置。系统真正的瓶颈经常是非Java部分（数据库、文件系统、网络），但不经过评测，Java开发人员永远都不会知道问题出在哪里。开发人员不去解决真正的问题，而是把时间浪费在对于改进系统性能毫无意义的代码微调上。
你希望能够回答如下几类基本问题。
- 如果你们搞了次促销，客户突然暴增十倍，系统有足够的内存来应付这种局面吗？
- 客户从应用程序中看到的平均响应时间是多长？
- 跟竞争对手比起来怎么样？
要做性能调优，你就不能猜测导致系统变慢的原因。你必须知道并且确保你真正实现性能调优的唯一办法就是性能评测。
你还需要明白性能调优不是：
- 一堆技巧和窍门；
- 秘密武器；
- 你在项目结束时撒一把的仙粉。
对“技巧和窍门”要特别小心。JVM是一个非常复杂，并经过高度优化的环境，如果脱离了上下文，这些技巧基本都没什么用，而且可能还会带来麻烦。随着JVM在代码优化方面越来越智能，它们也很快就会过时。
性能分析实际上是种试验性的科学。你可以把代码看成是某种科学试验，有输入，会产生“输出”——性能指标表明系统执行任务的效率。性能工程师的工作是研究这些输出，并找出其中的模式。所以性能调优是统计应用的一个分支，而不是一群老太婆的闲言碎语。
本章将是你的新起点，我们会向你介绍Java性能调优实战。但这是个大课题，由于篇幅有限，我们只能把你领进门，帮助你分析其中的重要原理和标志性内容。我们也会尽量解答大部分基本问题。
- 性能为什么这么重要？
- 性能分析为什么这么难？
- JVM的哪些方面会让调优变得复杂？
- 应该如何考虑和完成性能调优？
- 哪些是导致系统迟缓的最常见原因？
我们还会介绍JVM中与性能相关的两个最重要子系统：
- 垃圾收集子系统
- JIT编译器
有了这些，你就可以开始着手解决编码时遇到的实际问题了。
我们先来快速浏览一些基本词汇，以便你可以表达并框定自己的性能问题和目标。