（翻譯www.java-performance.com）提高Java程式效能--JDK篇（五）

標籤：this   value   span   pes   which   add   pairs   速度   air   

1.永遠不要調用java.lang.Number子類的valueOf(String)函數。如果你需要一個原始類型的值使用parse[Type]函數。如果你確實是需要一個原始類型的封裝類，還是調用parse[Type]函數，然後依賴JVM去自動封裝。因為JVM支援緩衝大多數常用的值。永遠不要調用封裝類的建構函式，因為它總是返回一個新對象，這就會繞開JVM的緩衝功能。下表是一個原始類型的緩衝範圍：
Byte, Short, Long：From -128 to 127
Character：From 0 to 127
Integer：From -128 to java.lang.Integer.IntegerCache.high or 127, whichever is bigger
Float, Double：不緩衝
以Integer舉例：盡量使用Integer.parseInt()而不是Integer.valueOf()
--------------------------------------------------------------------------------
下面是對集合(Collection)中元素存在的判斷一些最佳化:
1. 對於集(Set)，不需要先判斷再增刪(contains() + add()/remove())，直接使用增刪操作(add()/remove())。
2. 對於Map，取值時先直接使用Map的get()，然後通過傳回值是不是null來判斷，而不是先使用contains函數，再get。刪除值時也是直接調用remove函數，再判斷結果。而不要先調用contains函數後，再執行remove操作。
總結：集合的有些操作可以先執行，再根據結果判斷，而不要使用contains()函數判斷了再執行，這樣少了一次尋找操作。
--------------------------------------------------------------------------------
java.util.zip.CRC32, java.util.zip.Adler32 and java.util.zip.Checksum: 未翻譯，見原文。
--------------------------------------------------------------------------------
1. 在實作類別的hashCode函數時，提高hash值的均勻分布遠比雲最佳化hashCode函數的速度重要。永遠不要讓hashCode函數返回一個常數。
2. String類的hashCode函數產生的hash值分布幾乎是完美的，所以某些情況下你可以用字串(String)的hash值來代替字串。If you are working with sets of strings, try to end up with BitSets, as described in this article.

 

原文：

java.lang.Byte, Short, Integer, Long, Character (boxing and unboxing): java.lang.Byte, java.lang.Short, java.lang.Integer, java.lang.Long, java.lang.Character:

Tags: low latency, high throughput, CPU optimization, memory optimization.

• Never call java.lang.Number subclasses valueOf(String) methods. If you need a primitive value - call parse[Type]. If you want an instance of a wrapper class, still call parse[Type]method and rely on the JVM-implemented boxing. It will support caching of most frequently used values. Never call wrapper classes constructors - they always return a newObject, thus bypassing the caching support. Here is the summary of caching support for primitive replacement classes:

Byte, Short, Long	Character	Integer	Float, Double
From -128 to 127	From 0 to 127	From -128 to java.lang.Integer.IntegerCache.high or 127, whichever is bigger	No caching

Map.containsKey/Set.contains: java.util.Map, java.util.Set and most of their implementations:

Tags: low latency, high throughput, CPU optimization, Java collections.

• For sets, contains+add/remove call pairs should be replaced with single add/remove calls even if some extra logic was guarded by contains call.
• For maps, contains+get pair shall always be replaced with get followed by null-check of get result. contains+remove pair should be replaced with a single remove call and check of its result.
• Same ideas are applicable to Trove maps and sets too.

java.util.zip.CRC32 and java.util.zip.Adler32 performance: java.util.zip.CRC32, java.util.zip.Adler32 and java.util.zip.Checksum:

Tags: CPU optimization, checksum.

• If you can choose which checksum implementation you can use - try Adler32 first. If its quality is sufficient for you, use it instead of CRC32. In any case, use Checksum interface in order to access Adler32/CRC32 logic.
• Try to update checksum by at least 500 byte blocks. Shorter blocks will require a noticeable time to be spent in JNI calls.

hashCode method performance tuning: java.lang.String, java.util.HashMap, java.util.HashSet, java.util.Arrays:

Tags: low latency, high throughput, CPU optimization, memory optimization.

• Try to improve distribution of results of your hashCode method. This is far more important than to optimize that method speed. Never write a hashCode method which returns a constant.
• String.hashCode results distribution is nearly perfect, so you can sometimes substitute Strings with their hash codes. If you are working with sets of strings, try to end up withBitSets, as described in this article. Performance of your code will greatly improve.

（翻譯www.java-performance.com）提高Java程式效能--JDK篇（五）