Java理论与实践: 性能管理 ― 您有规划吗？

性能管理通常被视为一种巫术，因为性能问题通常在应用程序开发完成之后 才会出现。到那时，就难以确定它们的根源。然而，一旦十分准确地确定了性能 问题的起因，那么修正它常常是比较简单的事情。工程师在寻找更有效的方法来 执行特殊任务方面通常具有相当的创造性（有时他们的创造性过了头）。对于任 何给定的性能问题，通过使用高速缓存来减少冗余计算或者只是添加更多的硬件 ，解决方案可能会与用更有效的算法进行替换一样简单。但是，要清楚地确定性 能问题的根源会很困难，而设计复杂程序甚至 更加困难，所以首先要使它们没 有性能问题。

虽然编程决策 ― 如算法或数据表示的次优（sub-optimal）选择，无法重用 先前计算的结果，或者糟糕的资源管理 ― 通常被认为是性能问题的直接起因， 但大多数性能问题还有一个更深的起因：无法首先将性能管理、目标和测量集成 到开发过程中。

问题？什么问题？

您如何知道何时有性能问题呢？对于大多数开发团队，回答（用美国高级法 院法官 Potter Stewart 对罪行描述的话来讲）是：在遇到时才知道。这是问题 的核心 ― 性能目标、度量和测量常常没被考虑到，直到发现时，已经太晚了。

最常见的性能管理策略是……也没什么，它通常采用下列两种形式之一：

在应用程序开发完成之前完全忽略性能

开发时进行优化，这通常意味着只关注极微小的性能考虑事项，而忽略较大 的方面

这两种策略共有同一个基本问题 ― 它们没有将性能管理视作开发过程的一 个集成部分。

有缺陷的性能策略 A：完全忽略性能

第一种方法是完全忽略性能，该方法将性能视作可以在项目结束时处理的事 情，比如象编写发行说明或构建安装程序。该策略基本上靠运气，因为计算机运 算速度一年比一年快，所以在性能方面总能够应付得过去。

这种靠运气的问题（即使当成功的可能性非常大时）就是：当出现性能问题 时，您没有处理它、确定其根源或以特别方式解决它的框架。您也没有在开发规 划中安排用于性能测量和调优的时间。这有点象网站，除了安装具有缺省配置的 防火墙外，没有尝试使用一个连贯的安全性策略，然后发现它们已经被窃取。您 从何处着手呢？

有缺陷的性能策略 B：开发时进行优化

另一个常见但甚至更糟的方法是让极微小的性能考虑事项驱动体系结构和设 计决策。开发人员喜欢优化代码，其正当理由就是它令人满意和带来乐趣。但是 ，就关注的代码以及在开发周期中解决性能问题的时机而言，知道何时优化更为 重要。遗憾的是，开发人员一般无法凭直觉判断性能问题将实际出现在应用程序 的哪个位置。结果，他们浪费了大量精力对很少执行的代码路径进行优化，或者 更糟的是，他们损害好的设计和开发实践来优化早先没有任何性能问题的组件。 当您埋头编写代码时，很容易在性能问题上只见树而不见林。

使各个代码路径尽可能快地运行并不保证最终产品会很好地执行。再怎么进 行局部优化都不可能弥补根本上效率低的设计，即使将每个组件实现为尽可能的 快，也是如此。开发时优化策略用关注低级别的性能考虑事项来替代对整个项目 实施的性能策略，而且让您无法确信您真正有一个性能策略。

开发时进行优化的许多问题之一是它忽略了优化中的固有风险。少数优化也 会使设计更佳，错误更少，但这些都是例外情况。通常，优化涉及性能和其它考 虑事项（如干净的设计、明确性、灵活性和功能性）之间的权衡。优化会付出一 定的成本和风险：它可能会引入错误、限制代码的功能性或者使使用或维护变得 更加困难。在承受这些成本之前，请确保值得这样做。

将性能管理作为开发过程的一部分

从一开始就应该将性能测量和规划集成到开发过程中，对开发和性能测量和 调优进行单独、交错的迭代。这意味着设定性能目标、准备性能测量方案以及在 开发代码时经常复查代码性能。最好将旧的测试结果保存在数据库中，这样您可 以容易地比较当您更改代码时性能的变化情况。

对开发和性能进行单独的迭代，可让您在开发迭代期间集中精力编写起作用 的无错误的代码，如果需要的话，您还会知道不久将有一个适当的机会来改进性 能。如果您想起一个使代码运行更快的巧妙窍门，那么在代码中加一个注释以详 细描述您的想法，但现在不要实现！现在不是进行优化的时候。 如果最终必需 这么做，则当您关注性能时再返回来。性能优化应该由性能目标驱动，并受性能 测量支持。别的东西不过是“次要的”。

测量两次，然后再测量几次

测量是性能管理的关键元素。想一下：一个给定的妙计将使代码运行得更快 吗？我们准备验证这一点。在实施妙计的 前后，使用性能测量工具来测试性能 。如果您没有测到有改进，该怎么办？那么，准备收回您的妙计。如果您测不出 有好处，那为什么要冒破坏工作代码的风险呢？

在性能迭代期间，测量应用程序或其组件的性能，并将它们与先前迭代的测 量比较。有些方面慢下来了吗？找出原因。如果它达不到性能目标，那么您不一 定非得更改它，但现在您已经获得了有价值的、有关您更改后对性能影响的反馈 信息。

达到目标了吗？

如果您没有定量的性能目标和支持它们的测量规划，那么性能调优似乎是无 意义的。您如何知道您已经达到目标了？其它开发阶段（如编码、测试和打包） 都定义了目标 ― 实现这组功能、修正这些错误等等。性能阶段也应该有结构和 目标。

当对性能的关注是源自于外部时（不管是客户还是公司内的另一个部门）， 具有性能目标尤为重要。当某人告诉您使程序运行得更快时，您应该先问一下“ 我必须使它快多少？”否则，您可能会在调优方面投入过多的资源，但仍不能使 客户满意。投入十二分的精力来使程序运行速度提高 30%，不料却有人反应“哎 呀，我原希望速度能提高 50%。”，这会让人很失望。

结束语

性能管理不仅包括优化，还包含许多其它东西。它有一个用于决定何时优化 何时不优化的框架。您应该根据明确的性能目标、测量和规划来做这些决策，而 不是直觉。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!