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:

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篇（五）