《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.（僅僅針對專家）. 暫時不要作-----這是說，在你有一個完美的清晰的未經優化的解決方案以前.