Java 英文原文：9 Fallacies of Java Performance

Java功能问题被冠以某种暗中邪术的称呼。一部分是由于其平台的庞杂性，在非常多状况下，没法定位其功能问题本源。但是，在之前关于Java功能的技能，有一种趋势：以为其由人们的聪明，经历组成，而不是使用统计和实证推理。在这篇文章中，我盼望去验证一些最荒唐的技术神话。

1. Java运转慢

在一切最过期的Java功能谬论傍边，这多是最分明的谈吐。

是的，在90年月和20年月早期，Java的确有点慢。

但是，在那以后，我们有超越10年的工夫来改良虚拟机和JIT技术，如今Java全部系统的功能曾经快的使人诧异。

在6个独自的web功能测试基准中，Java框架盘踞了24个傍边的22个前四的地位。

JVM功能剖析组件的运用不只优化了通用的代码途径，并且在优化那些严重范畴也很有成效。JIT编译代码的速度在大大多数状况下跟C++一样快了。

虽然如许，关于Java运转慢的谈吐仍是存在，估量是因为汗青缘由酿成的成见，这个成见来自事先那些运用Java早期版本的人们。

我们建议，在匆仓促下结论之前先保存看法和评价一下最新的功能后果。

2. 单行java代码意味着任何事都是伶仃的

思索以下一小段代码：

MyObject obj = new MyObject();

对一个Java开发者而言，很分明能看出这行代码需求分派一个工具和运转一个对应的结构办法。

从这来看，我们可以Start推出功能鸿沟。我们晓得有一些准确数目的任务必需继续，因而基于我们的揣测，我们可以盘算出功能影响。

这儿有个认知成见，那就是依据以往的经历，任何任务都需求被做。

实践上，javac和JIT编译器都可以优化无效代码。就拿JIT编译器来讲，代码乃至可以基于数据剖析而被优化掉，在这类状况下，该行代码将不会被运转，因而它就不会有甚么功能方面的影响。

并且，在一些Java虚拟机(JVM)中，例如JRockit中,即便代码途径没有完整失效，JIT编译器为了不分派工具乃至可以履行分化工具操作。

这段文字在这里的意义就是当处置Java功能方面的问题时，高低文很主要。并且过早的优化可能会发生预料以外的后果。所认为了取得最好的后果，不要试图过早的优化。与其不时构建你的代码不如用功能调剂技术去定位而且矫正代码功能的潜伏风险区。

3.你认为一个微基准测试代表了一切

正如后面所说，讨论一小段代码功能所得出的后果要比剖析使用全局功能的后果要大略的多。

虽然说如斯，但开发者们依然爱好写一些微基准测试。一些人寻求经过改进平台底层某些方面而取得功能晋升所带给他们的内涵高兴，并乐此不疲。

Richard Feynman曾说过“第一准绳就是不要掩耳盗铃，你就是阿谁最轻易被乱来的人”。如今，当你编写java微基准测试的时分，你真得好好想一想这句话。

要想写出杰出的微基准测试是很艰苦的。以深邃、庞杂著称的Java平台为例，很多微基准测试仅能胜任丈量瞬时效应或许一些平台有关的方面。

例如，一个未颠末杰出设计的微基准测试凡是只重视丈量耗时的子系统或渣滓收受接管的功能而疏忽了在捕获这些变更过程当中所发生的开支。
其它翻译版本 (1) 加载中 只要当开发者和团队有真正基准需求的时分才需求写微基准测试。这些基准测试应当打包到项目（包含源代码）随项目一同宣布，而且这些基准测试应当是可重现的并可供给给别人核阅和进一步的审查。

Java平台的很多优化后果都指的是只运转单一基准测试用例时所失掉的统计后果。一个独自的基准测试必需要屡次运转才干失掉一个比较趋近于真实谜底的后果。

假如你以为到了必需要写微基准测试的时分，起首请读一下Georges, Buytaert, Eeckhout所著的"Statistically Rigorous Java Performance Evaluation"。假如没有统计学的常识，你会很轻易迷途知返的。

网上有非常多好的Tools和社区来协助你实行基准测试，例如Google的Caliper。假如你不能不写基准测试时，不要静心苦干，你需求从别人那边吸取看法和经历。

4.算法慢是功能问题的最广泛缘由

在顺序员（和通俗群众）中广泛存在一个错误观念就是他们老是天经地义地以为本人所担任的那部分系统步崆最主要的。

就Java功能这个问题来讲，Java开发者以为算法的质量是功能问题的首要缘由。开发者会思索怎么编码，因而他们天性上就会潜认识地去思索算法。

实践上，当处置现实中的功能问题时，算法设计占用了处理根本问题不到10%的工夫。

相反，相对算法，渣滓收受接管，数据库拜访和设置装备摆设错误会更可能形成顺序迟缓。

大大多数使用顺序处置绝对少数的数据，因而即便主算法出缺陷也不会招致严重的功能问题。因而，我们得供认算法关于功能问题来讲是次要的;由于算法带来的低效相对其他部分酿成的影响来讲是绝对较小的，大多的功能问题来自于使用顺序栈的其他部分。

因而我们的最好建议就是依托经历和产品数据来找到惹起功能问题的真正缘由。要入手收集数据而不是平空猜想。

缓存能处理一切问题

“关于盘算机科学的每个问题都可以经过附加别的一个层面直接的方法被处理”

这句顺序员的格言，谰?纶David Wheeler（幸而有因特网，最少有别的两位盘算机科学家），是惊人的类似，特殊是在web开发者中。

凡是呈现这类谬论是由于劈面对一个现有的，了解不敷透辟的架构时呈现的剖析瘫痪。

与其处置一个使人生畏的现存系统，开发者常常会选择规避它经过添加一个缓存而且抱着最大的盼望。固然，这个办法仅仅使全部架构变的更庞杂，而且对试图了解产品架构近况的下一名开发者而言是一件很蹩脚的工作。

夸张的说，不规矩架构每次被写入一行和一个子系统。但是，在很多状况下，更容易的重构架构会有更好的功能，并且它们简直也更容易于被了解。

因而当你评价是否是需求缓存时，方案去搜集根本用法统计（缺失率，射中率等）去证实实践上缓存层是个附加值。

6. 一切使用都要思索到STW

(译注：“stop-the-world” 机制简称STW,即,在履行渣滓搜集算法时,Java使用顺序的其他一切除渣滓搜集协助器线程以外的线程都被挂起)

Java平台的一个存在现实是，一切使用线程必需周期性的中止以便让渣滓汇集器GC运转。这有时被夸张为严重的弱点，即便是在缺少真实证据的状况下。

实证研讨曾经阐明，人类凡是没法发觉到频率超越每200毫秒一次的数字数据的变更（例如价钱变化）。

因而对以人类作为重要用户的使用，一条有效的经历就是200毫秒或低于200毫秒的 Stop-The-World (STW)进展凡是无需思索。有点使用（例如视频流）需求比这个更低的GC动摇，可是非常多GUI使用不是的。

有少量使用（比方低延迟交易，或许机械把持系统）对200毫秒进展是不成承受的。除非你的使用属于阿谁少量，不然你的用户发觉就任何由渣滓收受接管带来的影响是不太可能的。

值得留意的是，在具有比物理内核更多使用线程的系统中，操作系统Task方案将会干预对CPU的工夫分片拜访。Stop-The-World听起来吓人，但实践上，每一个使用（不管是否是JVM）都必需处置对稀缺盘算资本的内容拜访。

假如不做丈量，JVM的办法对使用功能带来的额定影响具有多么意义将没法看清。

整体来讲，判别进展的次数实践对使用的影响是经过翻开GC日记的方法。剖析这天志（或许手工，或许用剧本或Tools）来断定进展的次数。然后再断定这些能否的确给你的使用域带来问题。最主要的是，问本人一个最锋利的问题：有效户的确埋怨了吗？

7. 手工处置的工具池对很大范畴内的使用都是适宜的

对Stop-The-World进展的坏觉得惹起一个常用的应对，即在java堆的范畴内，为使用顺序组创造它们本人的内存管理技术。常常这会归结为完成一个工具池（或乃至是全面援用计数）的办法，而且需求让任何运用了范畴工具的代码介入出去。

这类技术简直老是被误导。它凡是具有本身长远之前的本源，那时工具定位价格昂贵，忽然的变更被以为是不主要的。但如今的天下曾经十分分歧。

当代的硬件具有不可思议的定位效力；迩来桌面或Server硬件的内存容量最少到达了2到3GB。这是一个很大的数字；除专业的运用情况，让实践的使用充溢那末大的容量不是很轻易。

工具池普通很难准确的完成（特殊是有多个线程在任务的时分），而且有几个消极的请求使得把它作为普通场景运用成为一个困难选择：

• 一切接触到代码的开发者都必需明白工具池并准确的处置它
• “对池苏醒”代码与“对池不苏醒”代码之间的界线必需要知晓并明文规则
• 一切这些附加的庞杂性必需坚持最新，并定时评价
• 假如这里任何地方失败了，无声破坏的风险（相似C中的指针重用）将被再次引入

总之，只要在GC进展不克不及被承受，并且在调试与重构过程当中聪慧的测验考试也不克不及缩减进展到可承受程度的时分，工具池才可使用。

8. 在GC中CMS老是比Parallel Old更好

Oracle JDK默许运用一个并行的，全体中止（stop-the-world STW)渣滓搜集器来搜集暮年代的渣滓。

别的一个选择是并发标志肃清（CMS）搜集器。这个搜集器答应顺序线程在大部分的GC周期中依然继续任务，但它需求支出一些价格和带来一些正告。

答应顺序线程和GC线程一同运转不成防止地招致工具表的变异同时又影响到工具的活泼性。这不能不在发作落后行明白，所以CMS实践上有两个STW阶段（凡是十分短）。

这会带来一些结果：

1. 一切顺序线程不能不放进一个平安点而且在每次完整搜集时中止两次；
2. 在搜集并发运转地同时，顺序吞吐量会减少（凡是是50%）
3. 在JVM从事经过CMS来搜集渣滓的整体数据上（包含CPU周期）比并行搜集愈加高的。

根据顺序的状况这些本钱或许是值得的或许又不是。但并没有收费的午饭。CMS搜集器是一个杰出的工程品，但它不是全能药。

所以在引见前，CMS是你准确的GC战略，你得起首思索Parallel Old的STW是不成接纳的和不克不及谐和的。最初，（我不克不及足够地夸大），断定一切的目标都从相当的生产系统上失掉。

9. 增加堆内存会处理你内存溢出的问题

当一个使用顺序解体，GC中断运转时，很多使用组会经过增加堆内存来处理问题。在很多状况下，这可以很快处理问题，并争夺工夫来思索出一个更深的处理计划。但是，在没有真正了解功能发生的本源时，这类处理战略实践上会使状况更蹩脚。

试想一下，一个编码很烂的使用结构了十分多的范畴工具（性命周期大约保持2，3秒）。假如内存分派率足够高，渣滓收受接管就会很快地履行，并把这些范畴工具放到年轻代。一旦进入了暮年代，工具就会立刻死去，但直到下一次完整收受接管才会被渣滓收受接管器收受接管。

假如这个使用增加其堆内存，那末我们能做的是增加空间，为了寄存那些绝对短时间存在，然后消失的范畴工具。这会使得 Stop-The-World 的工夫更长，对使用毫无好处。

在改动堆内存和或其他参数之前，了解一下工具的静态分派和性命周期是很有需要的。没做查询拜访就举动，只会使工作更糟。在这里，渣滓收受接管器的暮年散布信息长短常主要的。

本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。 2KB翻译任务按照 CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务