Java理论与实践: 性能管理 ― 您有策划吗?[Java编程]

性能管理普通被视为一种巫术,因为性能问题普通在利用程序开辟完成之后 才会呈现.到当时,就难以肯定它们的本源.但是,一旦非常精确地肯定了性能 问题的起因,那么改正它常常是对比简单的事情.工程师在探求更有效的办法来 履行特别任务方面普通具有相当的创造性（有时他们的创造性过了头）.关于任 何给定的性能问题,通过利用高速缓存来削减冗余计算大概只是增添更多的硬件 ,办理筹划大概会与用更有效的算法举行替换一样简单.但是,要清楚地肯定性 能问题的本源会很艰难,而计划复杂程序乃至 越发艰难,所以首先要使它们没 有性能问题.

固然编程抉择 ― 如算法或数据表示的次优（sub-optimal）挑选,无法重用 先前计算的后果,大概糟糕的资源管理 ― 普通被认为是性能问题的直接起因, 但大大都性能问题还有一个更深的起因:无法首先将性能管理、目标和丈量集成 到开辟历程中.

问题?什么问题?

您若何知道什么时刻有性能问题呢?关于大大都开辟团队,答复（用美国高级法 院法官 Potter Stewart 对恶行描写的话来说）是:在碰到时才知道.这是问题 的核心 ― 性能目标、器量和丈量常常没被考虑到,直到发现时,已经太晚了.

最常见的性能管理战略是……也没什么,它普通采取下列两种情势之一:

在利用程序开辟完成之前完好忽视性能

开辟时举行优化,这普通意味着只关注极细小的性能考虑事项,而忽视较大 的方面

这两种战略共有同一个基本问题 ― 它们没有将性能管理视作开辟历程的一 个集成部份.

有缺陷的性能战略 A:完好忽视性能

第一种办法是完好忽视性能,该办法将性能视作可以在项目完毕时处理的事 情,比方象编写发行阐明或构建安装程序.该战略基本上靠运气,因为计算机运 算速度一年比一年快,所以在性能方面总可以对付得过去.

这种靠运气的问题（即便当成功的大概性非常大时）就是:当呈现性能问题 时,您没有处理它、肯定其本源或以分外方法办理它的框架.您也没有在开辟规 划中安置用于性能丈量和调优的时间.这有点象网站,除了安装具有缺省配置的 防火墙外,没有尝试利用一个联贯的安全性战略,然后发现它们已经被盗取.您 从何处着手呢?

有缺陷的性能战略 B:开辟时举行优化

另一个常见但乃至更糟的办法是让极细小的性能考虑事项驱动体系构造和设 计抉择.开辟人员喜好优化代码,其合理来由就是它令人称心和带来爱好.但是 ,就关注的代码以及在开辟周期中办理性能问题的机会而言,知道什么时刻优化更为 重要.遗憾的是,开辟人员普通无法凭直觉判断性能问题将实际呈目前利用程序 的哪个位置.后果,他们浪费了大量精神对很少履行的代码途径举行优化,大概 更糟的是,他们侵害好的计划和开辟实践来优化早先没有任何性能问题的组件. 当您用心编写代码时,很简单在性能问题上只见树而不见林.

使各个代码途径尽大概快地运行并不保证终究产品会很好地履行.再怎么进 行部分优化都不大概补偿根本上效率低的计划,即便将每个组件实现为尽大概的 快,也是如此.开辟时优化战略用关注初级别的性能考虑事项来替换对整个项目 实施的性能战略,并且让您无法确信您真正有一本性能战略.

开辟时举行优化的很多问题之一是它忽视了优化中的固有风险.少数优化也 会使计划更佳,错误更少,但这些都是例外情形.普通,优化触及性能和别的考 虑事项（如干净的计划、明确性、机动性和功效性）之间的衡量.优化会付出一 定的本钱微风险:它大概会引入错误、限制代码的功效性大概使利用或保护变得 越发艰难.在承受这些本钱之前,请确保值得这样做.

将性能管理作为开辟历程的一部份

从一开始就应当将性能丈量和筹划集成到开辟历程中,对开辟和性能丈量和 调优举行单独、交叉的迭代.这意味着设定性能目标、预备性能丈量筹划以及在 开辟代码经常常复查代码性能.最好将旧的测试后果保存在数据库中,这样您可 以简单地对比当您更改代码时性能的改变情形.

对开辟和性能举行单独的迭代,可以让您在开辟迭代期间集合精神编写起作用 的无错误的代码,假如需求的话,您还会知道不久将有一个得当的机会来改良性 能.假如您想起一个使代码运行更快的巧妙诀窍,那么在代码中加一个注释以详 细描写您的设法,但目前不要实现!目前不是举行优化的时刻. 假如终究必须 这么做,则当您关注性能时再返回来.性能优化应当由性能目标驱动,并受性能 丈量支持.别的东西不过是“次要的”.

丈量两次,然后再丈量几次

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

在性能迭代期间,丈量利用程序或其组件的性能,并将它们与先前迭代的测 量对比.有些方面慢下来了吗?找出缘由.假如它达不到性能目标,那么您不一 定非得更改它,但目前您已经得到了有代价的、有关您更改后对性能影响的反馈 信息.

到达目标了吗?

假如您没有定量的性能目标和支持它们的丈量筹划,那么性能调优仿佛是无 意义的.您若何知道您已经到达目标了?别的开辟阶段（如编码、测试和打包） 都定义了目标 ― 实现这组功效、改正这些错误等等.性能阶段也应当有构造和 目标.

当对性能的关注是源自于外部时（不管是客户还是公司内的另一个部门）, 具有性能目标尤为重要.当某人奉告您使程序运行得更快时,您应当先问一下“ 我必须使它快多少?”不然,您大概会在调优方面投入过量的资源,但仍不能使 客户称心.投入十二分的精神来使程序运行速度提高 30%,不料却有人反映“哎 呀,我原但愿速度能提高 50%.”,这会让人很绝望.

完毕语

性能管理不但包含优化,还包含很多别的东西.它有一个用于决意什么时刻优化 什么时刻不优化的框架.您应当按照明确的性能目标、丈量和筹划来做这些抉择,而 不是直觉.