1.最小化局部变量的作用域

  最小化局部变量的作用域有助于增加代码的可读性和可维护性，同时降低犯错的可能性；

  最好的最小化局部变量的作用域的方法就是：在第一次使用该变量的时候声明它。

2.用for-each循环替代传统的循环

  在Java5以前，循环都是这种形式的：

for (int i = 0; i < a.length; i++) {    doSomething(a[i]);}

 但是在5之后，你可以写成下面的形式:

for (Element e : elements) {    doSomething(e);}

  Java8发布以后，你还可以这样写:

a.forEach(a -> doSomthing(a));

详细的性能测试可以参考下面的文章：

不要被标题吓到了，使用java8的lambda显得比较慢的原因是因为第一次初始化的开销，事实证明，使用后两种循环方案不仅性能比第一种好，而且可读性更好，编写的代码也更少。第一种方案每次循环的边界检查会带来额外的开销，除非你确切的需要数组的下标，不要使用第一种循环。

3.了解并使用现有的库

4.如果需要知道确切的答案，不要使用float和double

  常见的就是涉及到钱的运算，JDK内置了BigDecimal类来支持这种运算，在加减乘除的过程中，BigDecimal能够让你完全控制小数点的取舍，在一般的情况下也不会带来太大的性能损失。使用浮点型会带来一些计算的黑洞。

5.优先使用基本型而不是包装类型

  使用基本类型运算上会带来更高的性能，也不会有空指针异常。自动拆装箱虽然是很好的语法糖，但是在某些情况下甚至会带来数十倍的性能差距。同时，也会引发空指针，（Integer） == （Integer）这种常见的BUG。

6.如果别的表示类型的方法更适用，就不要使用String

  试着使用enum或者泛型。

7.对于字符串连接操作的性能有所了解

  Java唯一重载了的运算符‘+’在连接字符串的时候特别方便，但是这个操作符每执行一次，就会创建一个新的字符串对象。在性能要求不高的场合这样很方便，但在性能敏感或者字符串数目较多的场合，推荐使用StringBuilder(它相比于StringBuffer不是线程安全的，但大部分字符串连接操作都是线程内部的，不需要线程安全，StringBuffer由于同步带来的性能原因已经不再被推荐使用)。

8.相对于反射，优先使用接口

  反射给了你对一个类运行时的控制机会，但是它有一些缺点:

• 编译时期的类型检查带来的好处你一个也享受不到
• 反射的代码不直观，容易犯错
• 反射的代码无法做编译器优化（如JIT），带来的性能损失甚至是百十倍的

作为一条规则，一般的对象在通常的应用场景下在运行时不应该通过反射进行获取。

9.谨慎地使用native方法

  现在，已经不怎么建议使用native方法来改善性能了，在早期版本的JVM上，也许这样做是必要的，但现代的JVM所做的编译器优化在很多下已经能够媲美native code了；相反的，如果你使用native method，不但增加了项目复杂度，而且将牺牲掉Java跨平台的特性，如果不是对内存有足够的了解，带来的OOM也将是灾难性的。

  并不是说不要使用native方法，只是希望你能在使用native方法之前，仔细权衡，三思而后行。

10.谨慎地优化

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason—including blind stupidity.—William A. Wulf [Wulf72]//美其名曰的“为了性能”（然而实际上并没有达到这个目标）带来的罪恶超过包括盲目和无知在内的其它任何理由We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.—Donald E. Knuth [Knuth74]//在97%的情况下我们应该忘掉那些小性能：优化是万恶之本We follow two rules in the matter of optimization:Rule 1. Don’t do it.Rule 2 (for experts only). Don’t do it yet—that is, not until you have aperfectly clear and unoptimized solution.—M. A. Jackson [Jackson75]//在优化方面我们遵循两条原则：//原则1. 不做优化;//原则2.（仅仅针对专家）. 暂时不要做-----这是说，在你有一个完美的清晰的未经优化的解决方案之前.