《Effective Java》第八章:平常编程的一些小建议

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));

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

https://stackoverflow.com/questions/34585444/java-lambdas-20-times-slower-than-anonymous-classes

http://blog.takipi.com/benchmark-how-java-8-lambdas-and-streams-can-make-your-code-5-times-slower/

不要被标题吓到了，使用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 a
perfectly clear and unoptimized solution.
—M. A. Jackson [Jackson75]
//在优化方面咱们遵循两条原则：
//原则1. 不作优化;
//原则2.（仅仅针对专家）. 暂时不要作-----这是说，在你有一个完美的清晰的未经优化的解决方案以前.