你是否正打算优化hashCode()方法？是否想要绕开正则表达式？Lukas Eder介绍了很多简单方便的性能优化小贴士以及扩展程序性能的技巧。
　　近“全网域（Web Scale）”一词被炒得火热，人们也正在通过扩展他们的应用程序架构来使他们的系统变得更加“全网域”。但是究竟什么是全网域？或者说如何确保全网域？
　　扩展的不同方面
　　全网域被炒作的多的是扩展负载（Scaling load），比如支持单个用户访问的系统也可以支持10 个、100个、甚至100万个用户访问。在理想情况下，我们的系统应该保持尽可能的“无状态化（stateless）”。即使必须存在状态，也可以在网络的不同处理终端上转化并进行传输。当负载成为瓶颈时候，可能不会出现延迟。所以对于单个请求来说，耗费50到100毫秒也是可以接受的。这是所谓的横向扩展（Scaling out）。
　　扩展在全网域优化中的表现则完全不同，比如确保成功处理一条数据的算法也可成功处理10条、100条甚至100万条数据。无论这种度量类型是是否可行，事件复杂度（大O符号）是佳描述。延迟是性能扩展杀手。你会想尽办法将所有的运算处理在同一台机器上进行。这是所谓的纵向扩展（Scaling up）。
　　如果天上能掉馅饼的话（当然这是不可能的），我们或许能把横向扩展和纵向扩展组合起来。但是，我们只打算介绍下面几条提升效率的简单方法。
　　大O符号
　　Java 7的 ForkJoinPool 和Java8 的并行数据流（parallel Stream） 都对并行处理有所帮助。当在多核处理器上部署Java程序时表现尤为明显，因所有的处理器都可以访问相同的内存。
　　所以，这种并行处理较之在跨网络的不同机器上进行扩展，根本的好处是几乎可以完全消除延迟。
　　但不要被并行处理的效果所迷惑！请谨记下面两点：
　　并行处理会吃光处理器资源。并行处理为批处理带来了极大的好处，但同时也是非同步服务器（如HTTP）的噩梦。有很多原因可以解释，为什么在过去的几十年中我们一直在使用单线程的Servlet模型。并行处理仅在纵向扩展时才能带来实际的好处。
　　并行处理对算法复杂度没有影响。如果你的算法的时间复杂度为 O(nlogn)，让算法在 c 个处理器上运行，事件复杂度仍然为 O(nlogn/c)， 因为 c 只是算法中的一个无关紧要的常量。你节省的仅仅是时钟时间（wall-clock time），实际的算法复杂度并没有降低。
　　降低算法复杂度毫无疑问是改善性能行之有效的办法。比如对于一个 HashMap 实例的 lookup() 方法来说，事件复杂度 O(1) 或者空间复杂度 O(1) 是快的。但这种情况往往是不可能的，更别提轻易地实现。
　　如果你不能降低算法的复杂度，也可以通过找到算法中的关键点并加以改善的方法，来起到改善性能的作用。假设我们有下面这样的算法示意图：

　　该算法的整体时间复杂度为 O(N3)，如果按照单独访问顺序计算也可得出复杂度为 O(N x O x P)。但是不管怎样，在我们分析这段代码时会发现一些奇怪的场景：
　　在开发环境中，通过测试数据可以看到：左分支（N->M->Heavy operation）的时间复杂度 M 的值要大于右边的 O 和 P，所以在我们的分析器中仅仅看到了左分支。
　　在生产环境中，你的维护团队可能会通过 AppDynamics、DynaTrace 或其它小工具发现，真正导致问题的罪魁祸首是右分支（N -> O -> P -> Easy operation or also N.O.P.E.）。
　　在没有生产数据参照的情况下，我们可能会轻易的得出要优化“高开销操作”的结论。但我们做出的优化对交付的产品没有起到任何效果。
　　优化的金科玉律不外乎以下内容：
　　良好的设计将会使优化变得更加容易。
　　过早的优化并不能解决多有的性能问题，但是不良的设计将会导致优化难度的增加。
　　理论先谈到这里。假设我们已经发现了问题出现在了右分支上，很有可能是因产品中的简单处理因耗费了大量的时间而失去响应（假设N、O和 P 的值非常大）， 请注意文章中提及的左分支的时间复杂度为 O(N3)。这里所做出的努力并不能扩展，但可以为用户节省时间，将困难的性能改善推迟到后面再进行。
　　这里有10条改善Java性能的小建议：
　　1、使用StringBuilder
　　StingBuilder 应该是在我们的Java代码中默认使用的，应该避免使用 + 操作符。或许你会对 StringBuilder 的语法糖（syntax sugar）持有不同意见，比如：
　　String x = "a" + args.length + "b";
　　将会被编译为：
　　0  new java.lang.StringBuilder [16]
　　3  dup
　　4  ldc <String "a"> [18]
　　6  invokespecial java.lang.StringBuilder(java.lang.String) [20]
　　9  aload_0 [args]
　　10  arraylength
　　11  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
　　14  ldc <String "b"> [27]
　　16  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
　　19  invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
　　22  astore_1 [x]
　　但究竟发生了什么？接下来是否需要用下面的部分来对 String 进行改善呢？
　　String x = "a" + args.length + "b";
　　if (args.length == 1)
　　x = x + args[0];