Java性能优化小技巧
前言
1>更少的对象会需要更少的垃圾回收
2>使用的空间越少，应用的性能越好
怎么做：
1>重复利用一个对象，而不是在每次需要的时候都去创建一个功能一样的对象；
（这样做）
String s = “No longer silly”;
（不要这样）
String s = new String(“silly”);
2>不可变类中既提供构造函数，又提供了静态工厂方法的，优先考虑使用静态工厂方法；
3>复用那些一旦初始化（使用静态初始化）就不会改变的对象。
2、避免循环引用
为什么：
1>一组相互引用的对象，如果他们没有被其他对象直接引用的话，它们会变得不可达，这样会导致它们一直都保留在内存里。
怎么做：
为什么：
1>==操作符的性能更好
2>例如，对于字符串比较，equals()方法会去比较字符串对象里的字符。==操作符会比较两个对象的引用，来比较它们是否指向同一个实例。
怎么做：
1>当且仅当a == b 的时候才会有a.equals(b)
为什么：
1>无用的对象引用会导致更多的垃圾回收动作，从而降低性能
1>无用的对象引用会导致更多的内存占用，从而降低性能
怎么做：
1>如果一个引用时废弃的话，把它设置为null
（这样做）
public Object pop() {
if (size == 0){
throw new EmptyStackException();
}
Object result = elements[--size];
elements[size] = null; // 清除无用对象的引用
return result;
}
（不要这样）
public Object pop() {
if (size == 0){
throw new EmptyStackException();
}
return elements[--size];
为什么：
1>垃圾回收器需要单独记录等待终结的对象
2>调用finalize方法也有一定的开销
3>Finalizer是不安全的，因为它有可能会复活一个对象，这样会干扰垃圾回收。
6、避免使用引用对象
为什么：
1>和finalizer一样，垃圾回收器需要特别处理软引用、弱引用以及幽灵引用。
2>尽管引用对象在某些方面很有作用，例如，简化cache的实现，但是大量引用对象的存在会使得垃圾回收运行缓慢。
3>记录一个引用对象的开销远远超过一个普通对象（强引用）的开销。
7、避免使用对象池
为什么：
1>对象池不仅会使得更多的数据对象保持活动，同时会使得对象的存活时间延长；
2>值得注意的是，大量存活的数据对象的处理是GC的瓶颈，GC被优化成适合于处理许多寿命较短的对象；
3>并且，创建新的对象而不是保持旧的对象存活，会对缓存的局部性有益；
4>不过，在一个包含大量大对象的环境下，例如大的数组，性能或许会因为使用对象池而有所提升。
8、选择好的算法和数据结构
为什么：
1>考虑一下通过链表来实现队列的场景
2>即使你的程序不需要遍历整个链表，但是垃圾回收器还是需要这样做的。
3>如果元素的封装者没有把元素没有把元素放在内存中邻近的位置，这样会破坏缓存局部性。因而会导致程序长时间的暂停，尤其是对象的指针分散在一个很大的堆区时，垃圾回收器会在标记阶段追随指针的时候频繁遭遇缓存失效。
1>Java语言规范里没有保证调用System.gc会做什么事情。如果它规定了的话，或许会超出你的期望，也或许每次调用都做不同的事情。
10、避免使用太多的线程
为什么：
1>进程上下文切换的次数会随着要调度的进程的数目相应地增长，这样会对性能有隐性的影响。
2>例如，Intel A-64处理器上的本地线程上下文的大小大概是几千KB。
11、避免使用竞争锁
为什么：
1>竞争锁一般都是程序的瓶颈，因为它的出现意味着多个线程想访问同一个资源或者执行同一段代码。
12、避免不需要的异常
为什么：
1>异常处理会占用一定的事件，并且会打断程序的正常执行流程。
2>作者曾经遇到这样一场景，在客户的应用里，一个正常的执行流程每秒会抛出成千上万的NullPointerException。这个错误被纠正后，应用的性能里面有了一个数量级的提升。
13、避免使用大对象
为什么：
1>大对象有时候需要直接在堆而不是在线程本地存储区（thread local areas, TLA）进行内存分配。
2>大对象直接在堆上分配是有坏处的，因为它会更快地产生内存碎片。
3>在虚拟机（例如JRockit）上分配大对象会降低性能，因为分配内存的时候会使用堆的全局锁。
4>过度使用大对象会造成频繁的全栈压缩，这样做是具有破坏性的，而且这样会导致导致所有的线程暂停很长一段时间。
局部决定整体。一个应用的整体性能取决于每个组件的性能。下面是一些帮助你提高应用性能的Java编程技巧。
1、避免重复创建对象
为什么：1>更少的对象会需要更少的垃圾回收
2>使用的空间越少，应用的性能越好
怎么做：
1>重复利用一个对象，而不是在每次需要的时候都去创建一个功能一样的对象；
（这样做）
String s = “No longer silly”;
（不要这样）
String s = new String(“silly”);
2>不可变类中既提供构造函数，又提供了静态工厂方法的，优先考虑使用静态工厂方法；
3>复用那些一旦初始化（使用静态初始化）就不会改变的对象。
2、避免循环引用
为什么：
1>一组相互引用的对象，如果他们没有被其他对象直接引用的话，它们会变得不可达，这样会导致它们一直都保留在内存里。
怎么做：
1>你可以使用强引用来表示“父到子”的引用关系，使用弱引用来表示“子到父”的引用关系。
为什么：
1>==操作符的性能更好
2>例如，对于字符串比较，equals()方法会去比较字符串对象里的字符。==操作符会比较两个对象的引用，来比较它们是否指向同一个实例。
怎么做：
1>当且仅当a == b 的时候才会有a.equals(b)
2>例如，对于重复调用的地方，使用静态工厂方法来返回相同的对象。
为什么：
1>无用的对象引用会导致更多的垃圾回收动作，从而降低性能
1>无用的对象引用会导致更多的内存占用，从而降低性能
怎么做：
1>如果一个引用时废弃的话，把它设置为null
（这样做）
public Object pop() {
if (size == 0){
throw new EmptyStackException();
}
Object result = elements[--size];
elements[size] = null; // 清除无用对象的引用
return result;
}
（不要这样）
public Object pop() {
if (size == 0){
throw new EmptyStackException();
}
return elements[--size];
}
为什么：
1>垃圾回收器需要单独记录等待终结的对象
2>调用finalize方法也有一定的开销
3>Finalizer是不安全的，因为它有可能会复活一个对象，这样会干扰垃圾回收。
6、避免使用引用对象
为什么：
1>和finalizer一样，垃圾回收器需要特别处理软引用、弱引用以及幽灵引用。
2>尽管引用对象在某些方面很有作用，例如，简化cache的实现，但是大量引用对象的存在会使得垃圾回收运行缓慢。
3>记录一个引用对象的开销远远超过一个普通对象（强引用）的开销。
7、避免使用对象池
为什么：
1>对象池不仅会使得更多的数据对象保持活动，同时会使得对象的存活时间延长；
2>值得注意的是，大量存活的数据对象的处理是GC的瓶颈，GC被优化成适合于处理许多寿命较短的对象；
3>并且，创建新的对象而不是保持旧的对象存活，会对缓存的局部性有益；
4>不过，在一个包含大量大对象的环境下，例如大的数组，性能或许会因为使用对象池而有所提升。
8、选择好的算法和数据结构
为什么：
1>考虑一下通过链表来实现队列的场景
2>即使你的程序不需要遍历整个链表，但是垃圾回收器还是需要这样做的。
3>如果元素的封装者没有把元素没有把元素放在内存中邻近的位置，这样会破坏缓存局部性。因而会导致程序长时间的暂停，尤其是对象的指针分散在一个很大的堆区时，垃圾回收器会在标记阶段追随指针的时候频繁遭遇缓存失效。
9、避免使用System.gc
1>Java语言规范里没有保证调用System.gc会做什么事情。如果它规定了的话，或许会超出你的期望，也或许每次调用都做不同的事情。
10、避免使用太多的线程
为什么：
1>进程上下文切换的次数会随着要调度的进程的数目相应地增长，这样会对性能有隐性的影响。
2>例如，Intel A-64处理器上的本地线程上下文的大小大概是几千KB。
11、避免使用竞争锁
为什么：
1>竞争锁一般都是程序的瓶颈，因为它的出现意味着多个线程想访问同一个资源或者执行同一段代码。
12、避免不需要的异常
为什么：
1>异常处理会占用一定的事件，并且会打断程序的正常执行流程。
2>作者曾经遇到这样一场景，在客户的应用里，一个正常的执行流程每秒会抛出成千上万的NullPointerException。这个错误被纠正后，应用的性能里面有了一个数量级的提升。
13、避免使用大对象
为什么：
1>大对象有时候需要直接在堆而不是在线程本地存储区（thread local areas, TLA）进行内存分配。
2>大对象直接在堆上分配是有坏处的，因为它会更快地产生内存碎片。
3>在虚拟机（例如JRockit）上分配大对象会降低性能，因为分配内存的时候会使用堆的全局锁。
4>过度使用大对象会造成频繁的全栈压缩，这样做是具有破坏性的，而且这样会导致导致所有的线程暂停很长一段时间。