Java性能优化知识点（持续更新）
Java性能优化知识点
原文链接： jaxenter 翻译： ImportNew.com - 一直在路上
译文链接： http://www.importnew.com/16181.html
文章目录
- Java性能优化知识点
- 10种简单的Java性能优化
- 1、字符处理-使用StringBuilder
- 2、避免使用正则表达式
- 小结
- 3、不要使用iterator()方法
- 小结
- 4、不要调用高开销方法
- 小结
- 5、使用原始类型和栈
- 小结
- 例外
- 非堆存储
- 6、避免递归
- 小结
- 7、使用entrySet()
- 小结
- 8、使用EnumSet或EnumMap
- 小结
- 9、优化自定义hasCode()方法和equals()方法
- 10、考虑使用set而并非单个元素
- 总结
- 异常处理
- 优化建议
- 1. 尽量在合适的场合使用单例
- 2. 尽量避免随意使用静态变量
- 3. 尽量避免过多过常地创建Java对象
- 4. 尽量使用final修饰符
- 5. 尽量使用局部变量
- 6. 尽量处理好包装类型和基本类型两者的使用场所
- 7. 慎用synchronized，尽量减小synchronize的方法
- 9. 尽量不要使用finalize方法
- 10. 尽量使用基本数据类型代替对象
- 11. 多线程在未发生线程安全前提下应尽量使用HashMap、ArrayList
- 12. 尽量合理的创建HashMap
- 13. 尽量减少对变量的重复计算
- 14. 尽量避免不必要的创建
- 15. 尽量在finally块中释放资源
- 16. 尽量使用移位来代替a/b运算操作
- 17.尽量使用移位来代替'a*b'的操作
- 18. 尽量确定StringBuffer的容量**
- 19. 尽量早释放无用对象的引用
- 20. 尽量避免使用二维数组
- 21. 尽量避免使用split
- 22. ArrayList & LinkedList
- 23. 尽量使用System.arraycopy ()代替通过来循环复制数组
- 24. 尽量缓存经常使用的对象
- 25. 尽量避免非常大的内存分配
- 26. 慎用异常
- 27. 尽量重用对象
- 28. 不要重复初始化变量
- 29. 在java+Oracle的应用系统开发中，java中内嵌的SQL语言应尽量使用大写形式，以减少Oracle解析器的解析负担。
- 30. 在java编程过程中，进行数据库连接，I/O流操作，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销。
- 31. 过分的创建对象会消耗系统的大量内存，严重时，会导致内存泄漏，因此，保证过期的对象的及时回收具有重要意义。JVM的GC并非十分智能，因此建议在对象使用完毕后，手动设置成null。
- 32. 在使用同步机制时，应尽量使用方法同步代替代码块同步。
- 33. 不要在循环中使用Try/Catch语句，应把Try/Catch放在循环最外层**
- 34. 通过StringBuffer的构造函数来设定它的初始化容量，可以明显提升性能
- 35. 合理使用java.util.Vector
- 38. 不用new关键字创建对象的实例
- 39. 不要将数组声明为：public static final
- 40. HaspMap的遍历
- 41. array(数组)和ArrayList的使用
- 42. 单线程应尽量使用 HashMap, ArrayList,除非必要，否则不推荐使用HashTable,Vector，它们使用了同步机制，而降低了性能。
- 43. StringBuffer,StringBuilder的区别
- 44. 尽量使用基本数据类型代替对象。
- 45. 使用具体类比使用接口效率高，但结构弹性降低了，但现代IDE都可以解决这个问题。
- 46. 考虑使用静态方法，如果你没有必要去访问对象的外部，那么就使你的方法成为静态方法。它会被更快地调用，因为它不需要一个虚拟函数导向表。这同时也是一个很好的实践，因为它告诉你如何区分方法的性质，调用这个方法不会改变对象的状态。
- 47. 应尽可能避免使用内在的GET,SET方法。**
- 48.避免枚举，浮点数的使用。**
- **以下举几个实用优化的例子：**
- **一、避免在循环条件中使用复杂表达式**
- **二、为'Vectors' 和 'Hashtables'定义初始大小**
- **三、在finally块中关闭Stream**
- **四、使用'System.arraycopy ()'代替通过来循环复制数组**
- **五、让访问实例内变量的getter/setter方法变成”final”**
- **六、对于常量字符串，用'String' 代替 'StringBuffer'**
- **七、在字符串相加的时候，使用 ' ' 代替 " "，如果该字符串只有一个字符的话**
10种简单的Java性能优化
大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)。这里所做出的努力并不能扩展，但可以为用户节省时间，将困难的性能改善推迟到后面再进行。
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]
StingBuilder 应该是在我们的Java代码中默认使用的，应该避免使用 + 操作符。或许你会对 StringBuilder 的语法糖（syntax sugar）持有不同意见，比如：
String x = "a" + args.length + "b";
if (args.length == 1)
x = x + args[0];
现在使用到了第二个 StringBuilder，这个 StringBuilder 不会消耗堆中额外的内存，但却给 GC 带来了压力。
StringBuilder x = new StringBuilder("a");
x.append(args.length);
x.append("b");
if (args.length == 1);
x.append(args[0]);
小结
在上面的样例中，如果你是依靠Java编译器来隐式生成实例的话，那么编译的效果几乎和是否使用了 StringBuilder 实例毫无关系。请记住：在 N.O.P.E 分支中，每次CPU的循环的时间到白白的耗费在GC或者为 StringBuilder 分配默认空间上了，我们是在浪费 N x O x P 时间。
一般来说，使用 StringBuilder 的效果要优于使用 + 操作符。如果可能的话请在需要跨多个方法传递引用的情况下选择 StringBuilder，因为 String 要消耗额外的资源。JOOQ在生成复杂的SQL语句便使用了这样的方式。在整个抽象语法树（AST Abstract Syntax Tree）SQL传递过程中仅使用了一个 StringBuilder 。
更加悲剧的是，如果你仍在使用 StringBuffer 的话，那么用 StringBuilder 代替 StringBuffer 吧，毕竟需要同步字符串的情况真的不多。
2、避免使用正则表达式
正则表达式给人的印象是快捷简便。但是在 N.O.P.E 分支中使用正则表达式将是最糟糕的决定。如果万不得已非要在计算密集型代码中使用正则表达式的话，至少要将 Pattern 缓存下来，避免反复编译Pattern。
Pattern HEAVY_REGEX =Pattern.compile("(((X)*Y)*Z)*");
如果仅使用到了如下这样简单的正则表达式的话：
String[] parts = ipAddress.split("\\.");
这是最好还是用普通的 char[] 数组或者是基于索引的操作。比如下面这段可读性比较差的代码其实起到了相同的作用。
int length = ipAddress.length();
int offset = 0;
int part = 0;
for (int i = 0; i < length; i++) {
if (i == length - 1 ||
ipAddress.charAt(i + 1) == '.') {
parts[part] =
ipAddress.substring(offset, i + 1);
part++;
offset = i + 2;
}
}
上面的代码同时表明了过早的优化是没有意义的。虽然与 split() 方法相比较，这段代码的可维护性比较差。
**挑战：**聪明的小伙伴能想出更快的算法吗？
小结
正则表达式是十分有用，但是在使用时也要付出代价。尤其是在 N.O.P.E 分支深处时，要不惜一切代码避免使用正则表达式。还要小心各种使用到正则表达式的JDK字符串方法，比如 String.replaceAll() 或 String.split()。可以选择用比较流行的开发库，比如 Apache Commons Lang 来进行字符串操作。
3、不要使用iterator()方法
这条建议不适用于一般的场合，仅适用于在 N.O.P.E 分支深处的场景。尽管如此也应该有所了解。Java 5格式的循环写法非常的方便，以至于我们可以忘记内部的循环方法，比如：
for (String value : strings) {
// Do something useful here
}
当每次代码运行到这个循环时，如果 strings 变量是一个 Iterable 的话，代码将会自动创建一个Iterator的实例。如果使用的是ArrayList的话，虚拟机会自动在堆上为对象分配3个整数类型大小的内存。
private class Itr implements Iterator<E> {
int cursor;
int lastRet = -1;
int expectedModCount = modCount;
// ...
也可以用下面等价的循环方式来替代上面的 for 循环，仅仅是在栈上“浪费”了区区一个整形，相当划算。
int size = strings.size();
for (int i = 0; i < size; i++) {
String value : strings.get(i);
// Do something useful here
}
如果循环中字符串的值是不怎么变化，也可用数组来实现循环。
for (String value : stringArray) {
// Do something useful here
}
小结
无论是从易读写的角度来说，还是从API设计的角度来说迭代器、Iterable接口和 foreach 循环都是非常好用的。但代价是，使用它们时是会额外在堆上为每个循环子创建一个对象。如果循环要执行很多很多遍，请注意避免生成无意义的实例，最好用基本的指针循环方式来代替上述迭代器、Iterable接口和 foreach 循环。
4、不要调用高开销方法
有些方法的开销很大。以 N.O.P.E 分支为例，我们没有提到叶子的相关方法，不过这个可以有。假设我们的JDBC驱动需要排除万难去计算 ResultSet.wasNull() 方法的返回值。我们自己实现的SQL框架可能像下面这样：
if (type == Integer.class) {
result = (T) wasNull(rs,
Integer.valueOf(rs.getInt(index)));
}
// And then...
static final <T> T wasNull(ResultSet rs, T value)
throws SQLException {
return rs.wasNull() ? null : value;
}
在上面的逻辑中，每次从结果集中取得 int 值时都要调用 ResultSet.wasNull() 方法，但是 getInt() 的方法定义为：
返回类型：变量值；如果SQL查询结果为NULL，则返回0。
所以一个简单有效的改善方法如下：
static final <T extends Number> T wasNull(
ResultSet rs, T value
)
throws SQLException {
return (value == null ||
(value.intValue() == 0 && rs.wasNull()))
? null : value;
}
这是轻而易举的事情。
小结
将方法调用缓存起来替代在叶子节点的高开销方法，或者在方法约定允许的情况下避免调用高开销方法。
5、使用原始类型和栈
上面介绍了来自 jOOQ的例子中使用了大量的泛型，导致的结果是使用了 byte、 short、 int 和 long 的包装类。但至少泛型在Java 10或者Valhalla项目中被专门化之前，不应该成为代码的限制。因为可以通过下面的方法来进行替换：
//存储在堆上
Integer i = 817598;
……如果这样写的话：
// 存储在栈上
int i = 817598;
在使用数组时情况可能会变得更加糟糕：
//在堆上生成了三个对象
Integer[] i = { 1337, 424242 };
……如果这样写的话：
// 仅在堆上生成了一个对象
int[] i = { 1337, 424242 };
小结
当我们处于 _N.O.P.E. _分支的深处时，应该极力避免使用包装类。这样做的坏处是给GC带来了很大的压力。GC将会为清除包装类生成的对象而忙得不可开交。
所以一个有效的优化方法是使用基本数据类型、定长数组，并用一系列分割变量来标识对象在数组中所处的位置。
遵循LGPL协议的 trove4j 是一个Java集合类库，它为我们提供了优于整形数组 int[] 更好的性能实现。
例外
下面的情况对这条规则例外：因为 boolean 和 byte 类型不足以让JDK为其提供缓存方法。我们可以这样写：
Boolean a1 = true; // ... syntax sugar for:
Boolean a2 = Boolean.valueOf(true);
Byte b1 = (byte) 123; // ... syntax sugar for:
Byte b2 = Byte.valueOf((byte) 123);
其它整数基本类型也有类似情况，比如 char、short、int、long。
不要在调用构造方法时将这些整型基本类型自动装箱或者调用 TheType.valueOf() 方法。
也不要在包装类上调用构造方法，除非你想得到一个不在堆上创建的实例。这样做的好处是为你为同事献上一个巨坑的愚人节笑话。
非堆存储
当然了，如果你还想体验下堆外函数库的话，尽管这可能参杂着不少战略决策，而并非最乐观的本地方案。一篇由Peter Lawrey和 Ben Cotton撰写的关于非堆存储的很有意思文章请点击： OpenJDK与HashMap——让老手安全地掌握（非堆存储！）新技巧。
6、避免递归
现在，类似Scala这样的函数式编程语言都鼓励使用递归。因为递归通常意味着能分解到单独个体优化的尾递归（tail-recursing）。如果你使用的编程语言能够支持那是再好不过。不过即使如此，也要注意对算法的细微调整将会使尾递归变为普通递归。
希望编译器能自动探测到这一点，否则本来我们将为只需使用几个本地变量就能搞定的事情而白白浪费大量的堆栈框架（stack frames）。
小结
这节中没什么好说的，除了在 N.O.P.E 分支尽量使用迭代来代替递归。
7、使用entrySet()
当我们想遍历一个用键值对形式保存的 Map 时，必须要为下面的代码找到一个很好的理由：
for (K key : map.keySet()) {
V value : map.get(key);
}
更不用说下面的写法：
for (Entry<K, V> entry : map.entrySet()) {
K key = entry.getKey();
V value = entry.getValue();
}
在我们使用 N.O.P.E. 分支应该慎用map。因为很多看似时间复杂度为 O(1) 的访问操作其实是由一系列的操作组成的。而且访问本身也不是免费的。至少，如果不得不使用map的话，那么要用 entrySet() 方法去迭代！这样的话，我们要访问的就仅仅是Map.Entry的实例。
小结
在需要迭代键值对形式的Map时一定要用 entrySet() 方法。
8、使用EnumSet或EnumMap
在某些情况下，比如在使用配置map时，我们可能会预先知道保存在map中键值。如果这个键值非常小，我们就应该考虑使用 EnumSet 或 EnumMap，而并非使用我们常用的 HashSet 或 HashMap。下面的代码给出了很清楚的解释：
private transient Object[] vals;
public V put(K key, V value) {
// …
int index = key.ordinal();
vals[index] = maskNull(value);
// …
}
上段代码的关键实现在于，我们用数组代替了哈希表。尤其是向map中插入新值时，所要做的仅仅是获得一个由编译器为每个枚举类型生成的常量序列号。如果有一个全局的map配置（例如只有一个实例），在增加访问速度的压力下，EnumMap 会获得比 HashMap 更加杰出的表现。原因在于 EnumMap 使用的堆内存比 HashMap 要少 一位（bit），而且 HashMap 要在每个键值上都要调用 hashCode() 方法和 equals() 方法。
小结
Enum 和 EnumMap 是亲密的小伙伴。在我们用到类似枚举（enum-like）结构的键值时，就应该考虑将这些键值用声明为枚举类型，并将之作为 EnumMap 键。
9、优化自定义hasCode()方法和equals()方法
在不能使用EnumMap的情况下，至少也要优化 hashCode() 和 equals() 方法。一个好的 hashCode() 方法是很有必要的，因为它能防止对高开销 equals() 方法多余的调用。
在每个类的继承结构中，需要容易接受的简单对象。让我们看一下jOOQ的 org.jooq.Table 是如何实现的？
最简单、快速的 hashCode() 实现方法如下：
// AbstractTable一个通用Table的基础实现：
@Override
public int hashCode() {
// [#1938] 与标准的QueryParts相比，这是一个更加高效的hashCode()实现
return name.hashCode();
}
name即为表名。我们甚至不需要考虑schema或者其它表属性，因为表名在数据库中通常是唯一的。并且变量 name 是一个字符串，它本身早就已经缓存了一个 hashCode() 值。
这段代码中注释十分重要，因继承自 AbstractQueryPart 的 AbstractTable 是任意抽象语法树元素的基本实现。普通抽象语法树元素并没有任何属性，所以不能对优化 hashCode() 方法实现抱有任何幻想。覆盖后的 hashCode() 方法如下：·
// AbstractQueryPart一个通用抽象语法树基础实现：
@Override
public int hashCode() {
// 这是一个可工作的默认实现。
// 具体实现的子类应当覆盖此方法以提高性能。
return create().renderInlined(this).hashCode();
}
换句话说，要触发整个SQL渲染工作流程（rendering workflow）来计算一个普通抽象语法树元素的hash代码。
equals() 方法则更加有趣：·
// AbstractTable通用表的基础实现：
@Override
public boolean equals(Object that) {
if (this == that) {
return true;
}
// [#2144] 在调用高开销的AbstractQueryPart.equals()方法前，
// 可以及早知道对象是否不相等。
if (that instanceof AbstractTable) {
if (StringUtils.equals(name,
(((AbstractTable<?>) that).name))) {
return super.equals(that);
}
return false;
}
return false;
}
首先，不要过早使用 equals() 方法（不仅在_N.O.P.E._中），如果：
- this == argument
- this“不兼容：参数
注意：如果我们过早使用 instanceof 来检验兼容类型的话，后面的条件其实包含了argument == null。
在我们对以上几种情况的比较结束后，应该能得出部分结论。比如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() 方法的基本实现。
10、考虑使用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的主要好处是能使我们的代码变的简洁明了。比如下面的写法：
SomeSet INTERSECT SomeOtherSet
而不是
// Java 8以前的写法
Set result = new HashSet();
for (Object candidate : someSet)
if (someOtherSet.contains(candidate))
result.add(candidate);
// 即使采用Java 8也没有很大帮助
someSet.stream()
.filter(someOtherSet::contains)
.collect(Collectors.toSet());
有些人可能会对函数式编程和Java 8能帮助我们写出更加简单、简洁的算法持有不同的意见。但这种看法不一定是对的。我们可以把命令式的Java 7循环转换成Java 8的Stream collection，但是我们还是采用了相同的算法。但SQL风格的表达式则是不同的：
SomeSet INTERSECT SomeOtherSet
上面的代码在不同的引擎上可以有1000种不同的实现。我们今天所研究的是，在调用 INTERSECT 操作之前，更加智能地将两个set自动的转化为 EnumSet 。甚至我们可以在不需要调用底层的 Stream.parallel() 方法的情况下进行并行 INTERSECT 操作。
总结
在这篇文章中，我们讨论了关于_N.O.P.E._分支的优化。比如深入高复杂性的算法。作为jOOQ的开发者，我们很乐于对SQL的生成进行优化。
- 每条查询都用唯一的StringBuilder来生成。
- 模板引擎实际上处理的是字符而并非正则表达式。
- 选择尽可能的使用数组，尤其是在对监听器进行迭代时。
- 对JDBC的方法敬而远之。
- 等等。
jOOQ处在“食物链的底端”，因为它是在离开JVM进入到DBMS时，被我们电脑程序所调用的最后一个API。位于食物链的底端意味着任何一条线路在jOOQ中被执行时都需要 N x O x P 的时间，所以我要尽早进行优化。
我们的业务逻辑可能没有_N.O.P.E._分支那么复杂。但是基础框架有可能十分复杂（本地SQL框架、本地库等）。所以需要按照我们今天提到的原则，用Java Mission Control 或其它工具进行复查，确认是否有需要优化的地方。
异常处理
-
try-catch 代码段会产生额外的性能开销，或者换个角度说，它往往会影响 JVM 对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的 try 包住整段的代码；与此同时，利用异常控制代码流程，也不是一个好主意，远比我们通常意义上的条件语句（if/else、switch）要低效。
-
Java 每实例化一个 Exception，都会对当时的栈进行快照。避免过多的Exception创建。
在JAVA程序中，性能问题的大部分原因并不在于JAVA语言，而是程序本身。养成良好的编码习惯非常重要，能够显著地提升程序性能。
优化建议
1. 尽量在合适的场合使用单例
使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：
第一，控制资源的使用，通过线程同步来控制资源的并发访问；
第二，控制实例的产生，以达到节约资源的目的；
第三，控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。
2. 尽量避免随意使用静态变量
当某个对象被定义为static变量所引用，那么GC通常是不会回收这个对象所占有的内存，如
public class A{
private static B b = new B();
}
此时静态变量b的生命周期与A类同步，如果A类不会卸载，那么b对象会常驻内存，直到程序终止。
3. 尽量避免过多过常地创建Java对象
尽量避免在经常调用的方法，循环中new对象，由于系统不仅要花费时间来创建对象，而且还要花时间对这些对象进行垃圾回收和处理，在我们可以控制的范围内，最大限度地重用对象，最好能用基本的数据类型或数组来替代对象。
4. 尽量使用final修饰符
带有final修饰符的类是不可派生的。在JAVA核心API中，有许多应用final的例子，例如java、lang、String，为String类指定final防止了使用者覆盖length()方法。另外，如果一个类是final的，则该类所有方法都是final的。java编译器会寻找机会内联（inline）所有的final方法（这和具体的编译器实现有关），此举能够使性能平均提高50%。
如：让访问实例内变量的getter/setter方法变成”final：
简单的getter/setter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成”inlined”,例子：
class MAF {
public void setSize (int size) {
_size = size;
}
private int _size;
}
更正：
class DAF_fixed {
final public void setSize (int size) {
_size = size;
}
private int _size;
}
5. 尽量使用局部变量
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快；其他变量，如静态变量、实例变量等，都在堆（Heap）中创建，速度较慢。
6. 尽量处理好包装类型和基本类型两者的使用场所
虽然包装类型和基本类型在使用过程中是可以相互转换，但它们两者所产生的内存区域是完全不同的，基本类型数据产生和处理都在栈中处理，包装类型是对象，是在堆中产生实例。在集合类对象，有对象方面需要的处理适用包装类型，其他的处理提倡使用基本类型。
7. 慎用synchronized，尽量减小synchronize的方法
都知道，实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。synchronize方法被调用时，直接会把当前对象锁了，在方法执行完之前其他线程无法调用当前对象的其他方法。所以，synchronize的方法尽量减小，并且应尽量使用方法同步代替代码块同步。
9. 尽量不要使用finalize方法
实际上，将资源清理放在finalize方法中完成是非常不好的选择，由于GC的工作量很大，尤其是回收Young代内存时，大都会引起应用程序暂停，所以再选择使用finalize方法进行资源清理，会导致GC负担更大，程序运行效率更差。
10. 尽量使用基本数据类型代替对象
String str = “hello”;
上面这种方式会创建一个“hello”字符串，而且JVM的字符缓存池还会缓存这个字符串；
String str = new String(“hello”);
此时程序除创建字符串外，str所引用的String对象底层还包含一个char[]数组，这个char[]数组依次存放了h,e,l,l,o
11. 多线程在未发生线程安全前提下应尽量使用HashMap、ArrayList
HashTable、Vector等使用了同步机制，降低了性能。
12. 尽量合理的创建HashMap
当你要创建一个比较大的hashMap时，充分利用这个构造函数
public HashMap(int initialCapacity, float loadFactor);
避免HashMap多次进行了hash重构,扩容是一件很耗费性能的事，在默认中initialCapacity只有16，而loadFactor是 0.75，需要多大的容量，你最好能准确的估计你所需要的最佳大小，同样的Hashtable，Vectors也是一样的道理。
13. 尽量减少对变量的重复计算
如：
for(int i=0;i
应该改为：
for(int i=0,len=list.size();i
并且在循环中应该避免使用复杂的表达式，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。
14. 尽量避免不必要的创建
如：
A a = new A();
if(i==1){
list.add(a);
}
应该改为：
if(i==1){
A a = new A();
list.add(a);
}
15. 尽量在finally块中释放资源
程序中使用到的资源应当被释放，以避免资源泄漏，这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。
16. 尽量使用移位来代替a/b运算操作
"/"是一个代价很高的操作，使用移位的操作将会更快和更有效
如：
int num = a / 4;
int num = a / 8;
应该改为：
int num = a >> 2;
int num = a >> 3;
但注意的是使用移位应添加注释，因为移位操作不直观，比较难理解。
17.尽量使用移位来代替’a*b’的操作
同样的，对于’*'操作，使用移位的操作将会更快和更有效
如：
int num = a * 4;
int num = a * 8;
应该改为：
int num = a << 2;
int num = a << 3;
18. 尽量确定StringBuffer的容量**
StringBuffer 的构造器会创建一个默认大小（通常是16）的字符数组。在使用中，如果超出这个大小，就会重新分配内存，创建一个更大的数组，并将原先的数组复制过来，再丢弃旧的数组。在大多数情况下，你可以在创建 StringBuffer的时候指定大小，这样就避免了在容量不够的时候自动增长，以提高性能。
如：
StringBuffer buffer = new StringBuffer(1000);
19. 尽量早释放无用对象的引用
大部分时，方法局部引用变量所引用的对象会随着方法结束而变成垃圾，因此，大部分时候程序无需将局部，引用变量显式设为null。
例如：
Java代码
Public void test(){
Object obj = new Object();
……
Obj=null;
}
上面这个就没必要了，随着方法test()的执行完成，程序中obj引用变量的作用域就结束了。但是如果是改成下面：
Public void test(){
Object obj = new Object();
……
Obj=null;
//执行耗时，耗内存操作；或调用耗时，耗内存的方法
……
}
这时候就有必要将obj赋值为null，可以尽早的释放对Object对象的引用。
20. 尽量避免使用二维数组
二维数据占用的内存空间比一维数组多得多，大概10倍以上。
21. 尽量避免使用split
除非是必须的，否则应该避免使用split，split由于支持正则表达式，所以效率比较低，如果是频繁的几十，几百万的调用将会耗费大量资源，如果确实需要频繁的调用split，可以考虑使用apache的StringUtils.split(string,char)，频繁split的可以缓存结果。
22. ArrayList & LinkedList
一个是线性表，一个是链表，一句话，随机查询尽量使用ArrayList，ArrayList优于LinkedList，LinkedList还要移动指针，添加删除的操作LinkedList优于ArrayList，ArrayList还要移动数据，不过这是理论性分析，事实未必如此，重要的是理解好2者得数据结构，对症下药。
23. 尽量使用System.arraycopy ()代替通过来循环复制数组
System.arraycopy() 要比通过循环来复制数组快的多。
24. 尽量缓存经常使用的对象
尽可能将经常使用的对象进行缓存，可以使用数组，或HashMap的容器来进行缓存，但这种方式可能导致系统占用过多的缓存，性能下降，推荐可以使用一些第三方的开源工具，如EhCache，Oscache进行缓存，他们基本都实现了FIFO/FLU等缓存算法。
25. 尽量避免非常大的内存分配
有时候问题不是由当时的堆状态造成的，而是因为分配失败造成的。分配的内存块都必须是连续的，而随着堆越来越满，找到较大的连续块越来越困难。
26. 慎用异常
当创建一个异常时，需要收集一个栈跟踪(stack track)，这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。当需要创建一个 Exception 时，JVM 不得不说：先别动，我想就您现在的样子存一份快照，所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素。
如果您创建一个 Exception ，就得付出代价，好在捕获异常开销不大，因此可以使用 try-catch 将核心内容包起来。从技术上讲，你甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是 throw 操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常，幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。
27. 尽量重用对象
特别是String对象的使用中，出现字符串连接情况时应使用StringBuffer代替，由于系统不仅要花时间生成对象，以后可能还需要花时间对这些对象进行垃圾回收和处理。因此生成过多的对象将会给程序的性能带来很大的影响。
28. 不要重复初始化变量
默认情况下，调用类的构造函数时，java会把变量初始化成确定的值，所有的对象被设置成null，整数变量设置成0，float和double变量设置成0.0，逻辑值设置成false。当一个类从另一个类派生时，这一点尤其应该注意，因为用new关键字创建一个对象时，构造函数链中的所有构造函数都会被自动调用。
这里有个注意，给成员变量设置初始值但需要调用其他方法的时候，最好放在一个方法。比如initXXX()中，因为直接调用某方法赋值可能会因为类尚未初始化而抛空指针异常，如：public int state = this.getState()。
29. 在java+Oracle的应用系统开发中，java中内嵌的SQL语言应尽量使用大写形式，以减少Oracle解析器的解析负担。
30. 在java编程过程中，进行数据库连接，I/O流操作，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销。
31. 过分的创建对象会消耗系统的大量内存，严重时，会导致内存泄漏，因此，保证过期的对象的及时回收具有重要意义。JVM的GC并非十分智能，因此建议在对象使用完毕后，手动设置成null。
32. 在使用同步机制时，应尽量使用方法同步代替代码块同步。
33. 不要在循环中使用Try/Catch语句，应把Try/Catch放在循环最外层**
Error是获取系统错误的类，或者说是虚拟机错误的类。不是所有的错误Exception都能获取到的，虚拟机报错Exception就获取不到，必须用Error获取。
34. 通过StringBuffer的构造函数来设定它的初始化容量，可以明显提升性能
StringBuffer的默认容量为16，当StringBuffer的容量达到最大容量时，它会将自身容量增加到当前的2倍+2，也就是2*n+2。无论何时，只要StringBuffer到达它的最大容量，它就不得不创建一个新的对象数组，然后复制旧的对象数组，这会浪费很多时间。所以给StringBuffer设置一个合理的初始化容量值，是很有必要的！
35. 合理使用java.util.Vector
Vector与StringBuffer类似，每次扩展容量时，所有现有元素都要赋值到新的存储空间中。Vector的默认存储能力为10个元素，扩容加倍。
vector.add(index,obj) 这个方法可以将元素obj插入到index位置，但index以及之后的元素依次都要向下移动一个位置（将其索引加 1）。 除非必要，否则对性能不利。同样规则适用于remove(int index)方法，移除此向量中指定位置的元素。将所有后续元素左移（将其索引减 1）。返回此向量中移除的元素。所以删除vector最后一个元素要比删除第1个元素开销低很多。删除所有元素最好用removeAllElements()方法。
如果要删除vector里的一个元素可以使用 vector.remove(obj)；而不必自己检索元素位置，再删除，如int index = indexOf（obj）;vector.remove(index)。
38. 不用new关键字创建对象的实例
用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。clone()方法不会调用任何类构造函数。
下面是Factory模式的一个典型实现：
public static Credit getNewCredit()
{
return new Credit();
}
改进后的代码使用clone()方法：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit()
{
return (Credit)BaseCredit.clone();
}
39. 不要将数组声明为：public static final
40. HaspMap的遍历
Map paraMap = new HashMap();
for( Entry entry : paraMap.entrySet() )
{
String appFieldDefId = entry.getKey();
String[] values = entry.getValue();
}
利用散列值取出相应的Entry做比较得到结果，取得entry的值之后直接取key和value。
41. array(数组)和ArrayList的使用
array 数组效率最高，但容量固定，无法动态改变，ArrayList容量可以动态增长，但牺牲了效率。
42. 单线程应尽量使用 HashMap, ArrayList,除非必要，否则不推荐使用HashTable,Vector，它们使用了同步机制，而降低了性能。
43. StringBuffer,StringBuilder的区别
java.lang.StringBuffer 线程安全的可变字符序列。一个类似于String的字符串缓冲区，但不能修改。StringBuilder与该类相比，通常应该优先使用StringBuilder类，因为它支持所有相同的操作，但由于它不执行同步，所以速度更快。为了获得更好的性能，在构造StringBuffer或StringBuilder时应尽量指定她的容量。当然如果不超过16个字符时就不用了。 相同情况下，使用StringBuilder比使用StringBuffer仅能获得10%~15%的性能提升，但却要冒多线程不安全的风险。综合考虑还是建议使用StringBuffer。
44. 尽量使用基本数据类型代替对象。
45. 使用具体类比使用接口效率高，但结构弹性降低了，但现代IDE都可以解决这个问题。
46. 考虑使用静态方法，如果你没有必要去访问对象的外部，那么就使你的方法成为静态方法。它会被更快地调用，因为它不需要一个虚拟函数导向表。这同时也是一个很好的实践，因为它告诉你如何区分方法的性质，调用这个方法不会改变对象的状态。
47. 应尽可能避免使用内在的GET,SET方法。**
48.避免枚举，浮点数的使用。**
以下举几个实用优化的例子：
一、避免在循环条件中使用复杂表达式
在不做编译优化的情况下，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。例子：
import java.util.Vector;
class CEL {
void method (Vector vector) {
for (int i = 0; i < vector.size (); i++) // Violation
; // …
}
}
更正：
class CEL_fixed {
void method (Vector vector) {
int size = vector.size ()
for (int i = 0; i < size; i++)
; // …
}
}
二、为’Vectors’ 和 'Hashtables’定义初始大小
JVM为Vector扩充大小的时候需要重新创建一个更大的数组，将原原先数组中的内容复制过来，最后，原先的数组再被回收。可见Vector容量的扩大是一个颇费时间的事。
通常，默认的10个元素大小是不够的。你最好能准确的估计你所需要的最佳大小。例子：
import java.util.Vector;
public class DIC {
public void addObjects (Object[] o) {
// if length > 10, Vector needs to expand
for (int i = 0; i< o.length;i++) {
v.add(o); // capacity before it can add more elements.
}
}
public Vector v = new Vector(); // no initialCapacity.
}
更正：
自己设定初始大小。
public Vector v = new Vector(20);
public Hashtable hash = new Hashtable(10);
三、在finally块中关闭Stream
程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。
四、使用’System.arraycopy ()'代替通过来循环复制数组
例子：
public class IRB
{
void method () {
int[] array1 = new int [100];
for (int i = 0; i < array1.length; i++) {
array1 [i] = i;
}
int[] array2 = new int [100];
for (int i = 0; i < array2.length; i++) {
array2 [i] = array1 [i]; // Violation
}
}
}
更正：
public class IRB
{
void method () {
int[] array1 = new int [100];
for (int i = 0; i < array1.length; i++) {
array1 [i] = i;
}
int[] array2 = new int [100];
System.arraycopy(array1, 0, array2, 0, 100);
}
}
五、让访问实例内变量的getter/setter方法变成”final”
简单的getter/setter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成”inlined”,例子：
class MAF {
public void setSize (int size) {
_size = size;
}
private int _size;
}
更正：
class DAF_fixed {
final public void setSize (int size) {
_size = size;
}
private int _size;
}
六、对于常量字符串，用’String’ 代替 'StringBuffer’
常量字符串并不需要动态改变长度。
例子：
public class USC {
String method () {
StringBuffer s = new StringBuffer (“Hello”);
String t = s + “World!”;
return t;
}
}
更正：把StringBuffer换成String，如果确定这个String不会再变的话，这将会减少运行开销提高性能。
七、在字符串相加的时候，使用 ’ ’ 代替 " "，如果该字符串只有一个字符的话
例子：
public class STR {
public void method(String s) {
String string = s + “d” // violation.
string = “abc” + “d” // violation.
}
}
更正：
将一个字符的字符串替换成’ ’
public class STR {
public void method(String s) {
String string = s + ‘d’
string = “abc” + ‘d’
}
}
以上仅是Java方面编程时的性能优化，性能优化大部分都是在时间、效率、代码结构层次等方面的权衡，各有利弊，不要把上面内容当成教条，或许有些对我们实际工作适用，有些不适用，还望根据实际工作场景进行取舍，活学活用，变通为宜。
针对当前互联网公司的技术需求以及结合主流技术，我自己整理了一套系统的架构技术体系，当你技术过硬的时候，能够解决技术问题才会服众。不少公司都很重视高并发高可用的技术，特别是一线互联网公司，分布式、JVM、spring源码分析、微服务等知识点已是面试的必考题，这些东西可能你们平时在工作中接触过，但是缺少全面系统的学习。
大家可以通过扫码进群，或是关注微信公众号：Java资讯库，回复“架构”，免费领取架构资料。其实我自己也比较喜欢技术，群里有一些阿里大牛，也有一线互联网的资深HR，最近在面试的朋友或者在找工作的可以进来看看哦！