是的，你没有看错，是“最差实践”。关于Java性能优化的方法已经有很多文章讨论过，其中总有一些不值得提倡甚至应该杜绝的方法，需要让开发者时刻保持警觉。

    Ben Evans和Martin Verburg在Java性能优化方面有着丰富的实践经验，他们总结了一些“最差实践”。

    “态度”的最差实践：

    永远不要考虑所谓的可靠性、保障性、优雅、灵活架构、易理解，甚至不要去考虑正确性。最重要的是快速得到结果。谁关心你明天是不是对的？重中之重是尽快得到结果（任何结果）——如果你比别人快，你就可以定义什么是正确。聪明的开发者关注性能，而不是什么其它的东西。

    “使用基准（Benchmark）”的最差实践：

    不要怀疑你在网上查到的基准——它怎么会有错呢？遵循这个基准，当然你也要清楚地认识到基准总是和现实世界中应用程序性能密切相连的（连维基百科都是这么认为的）。微基准（Microbenchmark）是最好的基准方式。微基准做起来很有趣，一旦你了解应用程序的底层细节行为之后，你可以很容易地依此进行推断，得到其余部分的性能表现。通过最好的微基准你可以发现Java虚拟机（JVM）在某些底层方面的性能表现上是有微妙的不同的——当聚合为一个整体时，这个结果是十分重要的。

    “处理数据和结果”的最差实践：

    “不要自我重复”（Don’t Repeat Yourself）原则是现代软件开发的重要组成部分。就性能而言，它意味着开发者不要进行多次性能测试。开发者还有很多其它开发工作要做，不把时间浪费在无聊的重复性能测试上是非常重要的。毕竟你是一个专业的开发者，你可以将测试设置的很完美然后通过一次测试就找到所有的bug。

    忽略那些所谓的“统计学意义”和“分布图”。这很可能是一群永远不能成为酷炫的“摇滚明星”的数学呆子提出来的。执行一次测试，测量均值（这里说的均值，就是对各值取平均），至此你就结束了对这些数据的分析。然后你就可以回归到一个性能工程师的真正工作——让你的应用程序中的每一个算法都发挥出它们最佳的性能。

    测量事物是针对那些没有像你一样敏锐的洞察力的人而言的。是你开发的应用程序，所以你很了解问题都在哪里。算法优化是很难的，这也是专业人士花费时间的地方，不要去考虑收集和分析数据。

    “优化算法”的最差实践：

    你基本能判断出瓶颈的所在。相信你那惊人的分析技巧——这种技巧将引领你找出“罪魁祸首”，这些“罪魁祸首”的代码往往不是你写的。

    幸运的是，优化别人的代码是容易的。首先，找到那些简单的、未优化算法的代码。理想的候选代码是包含长时间运行的循环，并在循环中设有条件检查的代码。谨记，一般例子的算法都是差劲的。你比其它人更了解你的数据集，因此你应该花足够的时间设计一个适合你的数据的算法。像你这样聪明、有才华的人设计出的算法一定远好于那些平庸的、凑合的教科书提供的实例。

    不要担心设计算法会花费很多时间。这是实现性能优化过程中最重要的部分，并且想要做好它必须要像你这样的能人。

    “优化JVM”的最差实践：

    你没有必要再在最新的Java版本上进行测试了，也没有必要追踪最小的版本号。你的程序在不同的Java版本间的表现不会有多少差异。

    不过，通过设置传递给Java的参数配置，你可以让程序实现更好的性能。没必要为此去总结什么系统性的东西——你只需要找出你认为与问题有关的参数配置，然后随意调整他们直到达到最好的组合效果——更好的性能，而且没有额外的副作用。

    在JVM中有一百多个性能优化配置。尽可能多的用吧。有些配置看似做的是相互冲突的、矛盾的事情，但别担心。像你这样的专业人士甚至是可以使用在Java Hot Spot VM源代码中的那些未加文档说明的配置。

[page]    “理解硬件”的最差实践：

    理解CPU是件浪费时间的事情——而且这项工作应该留给硬件工程师。一个天才软件工程师不应该去考虑L3缓存的问题，也不应该去考虑数据是在内存中是如何存储的。固态硬盘在所有情况下都跑的更快，所以一直使用它们。没必要去衡量实际吞吐量和其它可观察量。牢记，性能越高越好，因此多买些RAM，并且扩展堆的大小。

    “采纳性能建议”的最差实践：

    性能建议就像美酒：随着时间的流逝，这个建议会变得更好，而且它永远不会过时。1990年提出来的性能建议至今依旧是十分准确的。你应该深刻地认识到最初提出这些建议的工程师是一群多么卓越的人。他们很可能就是像你一样的人。

    “和团队一起工作”的最差实践：

    牢记，要谨慎地保管你的性能测试和成果。否则，其它人可能盗取你的劳动果实然后宣称是他们自己的。永远不要让他们独自审核你的工作。他们只会在你的工作上添乱，并且让你偏离你原本显而易见的正确结论。

    更好的办法是让别人替你去做那些无聊的工作。如果有人已经做过了类似的工作，并且已经将自己的工作成果写在博文里或者Stack Overflow网站上了（特别是当他们有很高的信誉度时），采用他们的结论吧——这已经很够用了。毕竟，两个程序的表现能多大区别呢？毕竟都是Java（或者都是JVM）的，不是么？

    不管是采用优化算法的办法还是采用新的又快又炫的技术，一旦你得到了如何提高性能的方法，你最好多用些时间“吓唬”你的同事，让他们接受你的方法，而不是浪费时间让他们独立检查你的结论。

    无时不刻的提醒他们谁是老大，而且永远不要用文档说明或者解释你的原因——你最不想要的就是他们把你辛辛苦苦调整好的系统弄乱。

    “检查技术”的最差实践：

    当把应用程序框架当作一个整体来考虑时，永远记得密切关注最新的技术。如果你不能完全理解这项技术（牢记你是天才），那这项技术一定有什么地方不对。

    特别提醒：这些最差实践的内容都是以反语的方式来叙述的，因此需要正确理解，尽量避免这些最差实践。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。