设计模式总结：单例模式（以及多线程、无序写入、volatile对单例的影响）
单例模式
http://www.ibm.com/developerworks/cn/java/j-dcl.html
定义：
Ensure a class has only one instance, and provide a global point of access to it.
确保某个类只有一个实例，并提供一个全局访问点。
类图：
public class Singleton{
private static final Singleton instance;
private Singleton(){
}
public static Singleton getInstance(){
if(instance == null){ //1
instance = new Singleton();//2
}
return instance; //3
}
...
}优点：
1）内存中只有一个对象，减少内存开支；
2）单例可避免对资源的多重占用，例如写文件动作，可避免对同一资源文件的同时写操作。
缺点：
1）单例模式一般没有接口，扩展很困难；
——单例并不是用来继承的。
2）不利于测试，并行开发时，若单例未完成，则不能进行测试；
3）与单一职责原则冲突，把“要单例”和业务逻辑融合在一个类中。
使用场景：
若出现多个对象就会出现“不良反应”，应该用单例，具体场景如下：
1）要求生成唯一序列号的环境；
2）在整个项目中需要一个共享访问点或共享数据。例如页面计数器；
3）创建一个对象需要消耗的资源过多时；
4）需要定义大量的静态常量和静态方法的环境。
为什么不直接用全局变量来实现单例？
有缺点：全局变量必须在程序一开始就创建好。而单例模式可以延迟初始化。
类加载器对单例的影响：
不同的类加载器可能会加载同一个类。
如果程序有多个类加载器，可在单例中指定某个加载器，并指定同一个加载器。
多线程的影响：
上文代码示例在多线程环境下有bug：
线程 1 调用
getInstance()方法并决定instance在 //1 处为null。线程 1 进入
if代码块，但在执行 //2 处的代码行时被线程 2 预占。线程 2 调用
getInstance()方法并在 //1 处决定instance为null。线程 2 进入
if代码块并创建一个新的Singleton对象并在 //2 处将变量instance分配给这个新对象。线程 2 在 //3 处返回
Singleton对象引用。线程 2 被线程 1 预占。
线程 1 在它停止的地方启动，并执行 //2 代码行，这导致创建另一个
Singleton对象。线程 1 在 //3 处返回这个对象。
结果是 getInstance() 方法创建了两个 Singleton 对象。
解决方法一：不用延迟初始化
public class Singleton{
private static final Singleton instance = new Singleton();
private Singleton(){
}
public static Singleton getInstance(){
return instance;
}
...
}解决方法二：同步getInstance
public class Singleton{
private static final Singleton instance;
private Singleton(){
}
//同步getInstance
public static synchronized Singleton getInstance(){
if(instance == null){ //1
instance = new Singleton();//2
}
return instance; //3
}
...
}但是 synchronized方法会降低性能，尤其这里仅当第一次调用getInstance时才需要同步，只有执行//2代码行时才需要同步。
你可能想到只同步方法块，即只对//2进行同步：
public static Singleton getInstance(){
if(instance == null){
synchronized(Singleton.class) {
instance = new Singleton();
}
}
return instance;
}但这样做并不难解决问题：
当 instance 为 null 时，两个线程可以并发地进入if 语句内部。
然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。
当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个Singleton 对象。
注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。
还是会创建2个对象！！！！
解决方法三：双重检查加锁
针对上述方法的缺点，我们在//2代码行时 再检查一次null，就能保证只创建一个对象：
//注意volatile
private volatile static Singleton instace;
public static Singleton getInstance(){
if(instance == null){
synchronized(Singleton.class) { //1
if(instance == null){ //2
instance = new Singleton();//3
}
}
}
return instance;
}
假设有下列事件序列：
线程 1 进入 getInstance() 方法。
由于 instance 为 null，线程 1 在 //1 处进入synchronized 块。
线程 1 被线程 2 预占。
线程 2 进入 getInstance() 方法。
由于 instance 仍旧为 null，线程 2 试图获取 //1 处的锁。然而，由于线程 1 持有该锁，线程 2 在 //1 处阻塞。
线程 2 被线程 1 预占。
线程 1 执行，由于在 //2 处实例仍旧为 null，线程 1 还创建一个Singleton 对象并将其引用赋值给instance。
线程 1 退出 synchronized 块并从 getInstance() 方法返回实例。
线程 1 被线程 2 预占。
线程 2 获取 //1 处的锁并检查 instance 是否为 null。
由于 instance 是非 null 的，并没有创建第二个Singleton 对象，由线程 1 创建的对象被返回。
为什么要用volatile：无序写入
如果不用volatile，则因为内存模型允许所谓的“无序写入”，可能导致失败。——某个线程可能会获得一个为完全初始化的实例。
考察上述代码中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 instance 来引用此对象。这行代码的问题是：在Singleton 构造函数体执行之前，变量instance 可能成为非 null 的。
什么？这一说法可能让您始料未及，但事实确实如此。
在解释这个现象如何发生前，请先暂时接受这一事实，我们先来考察一下双重检查锁定是如何被破坏的。假设清单 4 中代码执行以下事件序列：
线程 1 进入 getInstance() 方法。
由于 instance 为 null，线程 1 在 //1 处进入synchronized 块。
线程 1 前进到 //3 处，但在构造函数执行之前，使实例成为非null。
线程 1 被线程 2 预占。
线程 2 检查实例是否为 null。因为实例不为 null，线程 2 将instance 引用返回，返回一个构造完整但部分初始化了的Singleton 对象。
线程 2 被线程 1 预占。
线程 1 通过运行 Singleton 对象的构造函数并将引用返回给它，来完成对该对象的初始化。
注意，1.4之前许多JVM对volatile关键字的实现有问题，还是会导致“双重检查加锁”的失效。
如果想不用volatile：
如果想不用volatile，并且避免无序写入带来的问题，可以用如下代码：
public static Singleton getInstance()
{
if (instance == null)
{
synchronized(Singleton.class) { //1
Singleton inst = instance; //2
if (inst == null)
{
synchronized(Singleton.class) { //3
inst = new Singleton(); //4
}
instance = inst; //5
}
}
}
return instance;
}这里的关键行是 //5。此行应该确保 instance 只为 null 或引用一个构造完整的Singleton 对象
BUT，Java 语言规范（Java Language Specification，JLS）要求不能将synchronized 块中的代码移出来。但是，并没有说不能将synchronized 块外面的代码移入synchronized 块中。JIT 编译器会在这里看到一个优化的机会。此优化会删除 //4 和 //5 处的代码，导致还是会有无序写入带来的问题！！！