1.在必要之前,先不要优化
1.5同步代码块的范围也小于同步方法,建议使用,相比之下能够提高性能。
2.使用分析器来找到真正的瓶颈
3 .为整个应用程序创建性能测试套件
4.首先解决最大的瓶颈问题
5.使用StringBuilder以编程方式连接字符串
在Java中有许多不同的连接字符串的选项。例如,可以使用一个简单的+或+ =、老的StringBuffer或StringBuilder。
那么,你应该选择哪种方法呢?
答案取决于连接字符串的代码。如果你以编程方式向字符串中添加新内容,例如,在for循环中,你应该使用StringBuilder。它比StringBuffer更容易使用和提供更好的性能。但是请记住,StringBuilder与StringBuffer不同,它不是线程安全的,而且可能不适合所有用例。
你只需要实例化一个新的StringBuilder,并调用append方法在字符串中添加一个新的部分。当你添加了所有的部分后,可以调用toString()方法来检索连接字符串。
下面的代码片段展示了一个简单的示例。在每次迭代过程中,这个循环将i转换成一个字符串,并将其添加到StringBuilder sb的空间中,因此到最后,这段代码写入“this is test0123456789”到日志文件。
1 2 3 4 5 6 |
|
正如在代码片段中看到的,你可以为构造函数方法提供字符串的第一个元素。这将创建一个新的StringBuilder,其中包含提供的字符串和16个额外字符的容量。当你向StringBuilder中添加更多字符时,JVM将动态地改变StringBuilder的大小。
如果你已经知道自己的字符串包含多少字符,那么你可以向不同的构造函数方法提供这个数字,以实例化一个具有被定义容量的StringBuilder。这进一步提高了它的效率,因为它不需要动态扩展它的容量。
6.在声明中使用+连接字符串
当你在Java中实现第一个应用程序时,可能有人告诉你不应该用+来连接字符串。如果在应用程序逻辑中连接字符串这是正确的。字符串是不可变的,每个字符串连接的结果存储在一个新的字符串对象中。这需要额外的内存,并降低应用程序的速度,特别是在循环中连接多个字符串时。
在这些情况下,你应该遵循tip 5并使用StringBuilder。
但如果你只是将一个字符串分解成多行来提高代码的可读性,那就不是这样了。
1 2 3 |
|
在这些情况下,你应该用一个简单的+来连接你的字符串。Java编译器将优化它并在编译时执行连接。因此,在运行时,代码只使用1个字符,不需要连接。
7.尽可能使用基本数据类型
另一种避免开销,提高应用程序性能的快速方法就是使用原始数据类型而不是它们的包装类。因此,最好是使用int而不是Integer,或者是double而不是Double。这将让JVM将值存储在堆栈中,以减少内存消耗,并更有效地处理它。
8.尽量避免BigInteger和BigDecimal
由于我们已经讨论了数据类型,我们再来看下BigInteger和BigDecimal。尤其是后者,由于其精度高而受欢迎。但这是有代价的。
BigInteger和BigDecimal比简单的long或double需要更多的内存,并且大大降低所有的计算速度。因此,如果你需要额外的精度,或者你的数字超过了一个long范围,最好三思而后行。这可能是你在提升性能问题中唯一需要更改的地方,特别是当你正在实现一个数学算法。
9.首先检查当前日志级别
10.使用Apache Commons StringUtils.Replace 代替String.replace
11.缓存昂贵的资源,比如数据库连接
缓存是一种流行的解决方案来避免重复执行昂贵或频繁使用的代码片段。一般的想法很简单:重复使用这些资源比一次又一次地创建一个新的资源要便宜得多。
一个典型的例子就是在池中缓存数据库连接。创建新连接需要时间,如果重用现有连接,则可以避免。
还可以在Java语言本身中找到其他示例。例如,Integer类的valueOf方法缓存了- 128和127之间的值。你可能会说,创建一个新整数并不太贵,但它经常使用,缓存最常用的值提供了性能方面的好处。
但当你考虑缓存时,请记住,缓存实现也会产生开销。你需要花费额外的内存来存储可重用资源,因此可能需要管理你的缓存,以使资源能够访问或删除过时的资源。
因此,在你开始缓存任何资源之前,请确保是经常使用。
12、避免使用正则表达式
正则表达式给人的印象是快捷简便。但是在 N.O.P.E 分支中使用正则表达式将是最糟糕的决定。如果万不得已非要在计算密集型代码中使用正则表达式的话,至少要将 Pattern 缓存下来,避免反复编译Pattern。
1 2 |
|
如果仅使用到了如下这样简单的正则表达式的话:
1 |
|
这是最好还是用普通的 char[] 数组或者是基于索引的操作。比如下面这段可读性比较差的代码其实起到了相同的作用。
1 2 3 4 5 6 7 8 9 10 11 12 |
|
上面的代码同时表明了过早的优化是没有意义的。虽然与 split() 方法相比较,这段代码的可维护性比较差。
正则表达式是十分有用,但是在使用时也要付出代价。尤其是在 N.O.P.E 分支深处时,要不惜一切代码避免使用正则表达式。还要小心各种使用到正则表达式的JDK字符串方法,比如 String.replaceAll() 或 String.split()。可以选择用比较流行的开发库,比如 Apache Commons Lang 来进行字符串操作。
13、不要使用iterator()方法
这条建议不适用于一般的场合,仅适用于在 N.O.P.E 分支深处的场景。尽管如此也应该有所了解。Java 5格式的循环写法非常的方便,以至于我们可以忘记内部的循环方法,比如:
1 2 3 |
|
当每次代码运行到这个循环时,如果 strings 变量是一个 Iterable 的话,代码将会自动创建一个Iterator 的实例。如果使用的是 ArrayList 的话,虚拟机会自动在堆上为对象分配3个整数类型大小的内存。
1 2 3 4 5 |
|
也可以用下面等价的循环方式来替代上面的 for 循环,仅仅是在栈上“浪费”了区区一个整形,相当划算。
1 2 3 4 5 |
|
如果循环中字符串的值是不怎么变化,也可用数组来实现循环。
1 2 3 |
|
小结
无论是从易读写的角度来说,还是从API设计的角度来说迭代器、Iterable接口和 foreach 循环都是非常好用的。但代价是,使用它们时是会额外在堆上为每个循环子创建一个对象。如果循环要执行很多很多遍,请注意避免生成无意义的实例,最好用基本的指针循环方式来代替上述迭代器、Iterable接口和 foreach 循环
14、避免递归
现在,类似Scala这样的函数式编程语言都鼓励使用递归。因为递归通常意味着能分解到单独个体优化的尾递归(tail-recursing)。如果你使用的编程语言能够支持那是再好不过。不过即使如此,也要注意对算法的细微调整将会使尾递归变为普通递归。
希望编译器能自动探测到这一点,否则本来我们将为只需使用几个本地变量就能搞定的事情而白白浪费大量的堆栈框架(stack frames)。
小结
这节中没什么好说的,除了在 N.O.P.E 分支尽量使用迭代来代替递归。
15、使用entrySet()
当我们想遍历一个用键值对形式保存的 Map 时,必须要为下面的代码找到一个很好的理由:
1 2 3 |
|
更不用说下面的写法:
1 2 3 4 |
|
在我们使用 N.O.P.E. 分支应该慎用map。因为很多看似时间复杂度为 O(1) 的访问操作其实是由一系列的操作组成的。而且访问本身也不是免费的。至少,如果不得不使用map的话,那么要用 entrySet() 方法去迭代!这样的话,我们要访问的就仅仅是Map.Entry的实例。
小结
在需要迭代键值对形式的Map时一定要用 entrySet() 方法。
16、使用EnumSet或EnumMap
在某些情况下,比如在使用配置map时,我们可能会预先知道保存在map中键值。如果这个键值非常小,我们就应该考虑使用 EnumSet 或 EnumMap,而并非使用我们常用的 HashSet 或 HashMap。下面的代码给出了很清楚的解释:
1 2 3 4 5 6 7 8 |
|
上段代码的关键实现在于,我们用数组代替了哈希表。尤其是向map中插入新值时,所要做的仅仅是获得一个由编译器为每个枚举类型生成的常量序列号。如果有一个全局的map配置(例如只有一个实例),在增加访问速度的压力下,EnumMap 会获得比 HashMap 更加杰出的表现。原因在于 EnumMap 使用的堆内存比 HashMap 要少 一位(bit),而且 HashMap 要在每个键值上都要调用 hashCode() 方法和 equals() 方法。
小结
Enum 和 EnumMap 是亲密的小伙伴。在我们用到类似枚举(enum-like)结构的键值时,就应该考虑将这些键值用声明为枚举类型,并将之作为 EnumMap 键。
17、优化自定义hasCode()方法和equals()方法
在不能使用EnumMap的情况下,至少也要优化 hashCode() 和 equals() 方法。一个好的 hashCode() 方法是很有必要的,因为它能防止对高开销 equals() 方法多余的调用。
在每个类的继承结构中,需要容易接受的简单对象。让我们看一下jOOQ的 org.jooq.Table 是如何实现的?
最简单、快速的 hashCode() 实现方法如下:
1 2 3 4 5 6 7 8 |
|
name即为表名。我们甚至不需要考虑schema或者其它表属性,因为表名在数据库中通常是唯一的。并且变量 name 是一个字符串,它本身早就已经缓存了一个 hashCode() 值。
这段代码中注释十分重要,因继承自 AbstractQueryPart 的 AbstractTable 是任意抽象语法树元素的基本实现。普通抽象语法树元素并没有任何属性,所以不能对优化 hashCode() 方法实现抱有任何幻想。覆盖后的 hashCode() 方法如下:
1 2 3 4 5 6 7 8 |
|
换句话说,要触发整个SQL渲染工作流程(rendering workflow)来计算一个普通抽象语法树元素的hash代码。
equals() 方法则更加有趣:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
首先,不要过早使用 equals() 方法(不仅在N.O.P.E.中),如果:
- this == argument
- this“不兼容:参数
注意:如果我们过早使用 instanceof 来检验兼容类型的话,后面的条件其实包含了argument == null。我在以前的博客中已经对这一点进行了说明,请参考10个精妙的Java编码最佳实践。
在我们对以上几种情况的比较结束后,应该能得出部分结论。比如jOOQ的 Table.equals() 方法说明是,用来比较两张表是否相同。不论具体实现类型如何,它们必须要有相同的字段名。比如下面两个元素是不可能相同的:
- com.example.generated.Tables.MY_TABLE
- DSL.tableByName(“MY_OTHER_TABLE”)
如果我们能方便地判断传入参数是否等于实例本身(this),就可以在返回结果为 false 的情况下放弃操作。如果返回结果为 true,我们还可以进一步对父类(super)实现进行判断。在比较过的大多数对象都不等的情况下,我们可以尽早结束方法来节省CPU的执行时间。
一些对象的相似度比其它对象更高。
在jOOQ中,大多数的表实例是由jOOQ的代码生成器生成的,这些实例的 equals() 方法都经过了深度优化。而数十种其它的表类型(衍生表 (derived tables)、表值函数(table-valued functions)、数组表(array tables)、连接表(joined tables)、数据透视表(pivot tables)、公用表表达式(common table expressions)等,则保持 equals() 方法的基本实现。
18、考虑使用set而并非单个元素
最后,还有一种情况可以适用于所有语言而并非仅仅同Java有关。除此以外,我们以前研究的N.O.P.E. 分支也会对了解从 O(N3) 到 O(n log n)有所帮助。
不幸的是,很多程序员的用简单的、本地算法来考虑问题。他们习惯按部就班地解决问题。这是命令式(imperative)的“是/或”形式的函数式编程风格。这种编程风格在由纯粹命令式编程向面对象式编程向函数式编程转换时,很容易将“更大的场景(bigger picture)”模型化,但是这些风格都缺少了只有在SQL和R语言中存在的:
声明式编程。
在SQL中,我们可以在不考虑算法影响下声明要求数据库得到的效果。数据库可以根据数据类型,比如约束(constraints)、键(key)、索引(indexes)等不同来采取最佳的算法。
在理论上,我们最初在SQL和关系演算(relational calculus)后就有了基本的想法。在实践中,SQL的供应商们在过去的几十年中已经实现了基于开销的高效优化器CBOs (Cost-Based Optimisers) 。然后到了2010版,我们才终于将SQL的所有潜力全部挖掘出来。
但是我们还不需要用set方式来实现SQL。所有的语言和库都支持Sets、collections、bags、lists。使用set的主要好处是能使我们的代码变的简洁明了。比如下面的写法:
1 |
|
而不是
1 2 3 4 5 6 7 8 9 10 |
|
有些人可能会对函数式编程和Java 8能帮助我们写出更加简单、简洁的算法持有不同的意见。但这种看法不一定是对的。我们可以把命令式的Java 7循环转换成Java 8的Stream collection,但是我们还是采用了相同的算法。但SQL风格的表达式则是不同的:
1 |
|
上面的代码在不同的引擎上可以有1000种不同的实现。我们今天所研究的是,在调用 INTERSECT 操作之前,更加智能地将两个set自动的转化为 EnumSet 。甚至我们可以在不需要调用底层的 Stream.parallel() 方法的情况下进行并行 INTERSECT 操作。