单例模式
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
}
...
}
优点：
内存中只有一个对象，减少内存开支；
单例可避免对资源的多重占用，例如写文件动作，可避免对同一资源文件的同时写操作。
缺点：
单例模式一般没有接口，扩展很困难； ——单例并不是用来继承的。
不利于测试，并行开发时，若单例未完成，则不能进行测试；
与单一职责原则冲突，把“要单例”和业务逻辑融合在一个类中。
使用场景：
若出现多个对象就会出现“不良反应”，应该用单例，具体场景如下：
要求生成唯一序列号的环境；
在整个项目中需要一个共享访问点或共享数据。例如页面计数器；
创建一个对象需要消耗的资源过多时；
需要定义大量的静态常量和静态方法的环境。
为什么不直接用全局变量来实现单例？
有缺点：全局变量必须在程序一开始就创建好。而单例模式可以延迟初始化。
类加载器对单例的影响：
不同的类加载器可能会加载同一个类。
如果程序有多个类加载器，可在单例中指定某个加载器，并指定同一个加载器。
多线程的影响：
上文代码示例在多线程环境下有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;
nbsp;}
但这样做并不能解决问题：
当 instance 为 null 时，两个线程可以并发地进入if 语句内部。
然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。
当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个Singleton 对象。
注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。
还是会创建2个对象！！！！
解决方法三：双重检查加锁
针对上述方法的缺点，我们在//2代码行时 再检查一次null，就能保证只创建一个对象：
//注意volatile！！！！！！！！！！！！！！！！！
private volatile static Singleton instace;
public static Singleton getInstance(){
//第一次null检查
if(instance == null){
synchronized(Singleton.class) { //1
//第二次null检查
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 的！
什么？这一说法可能让您始料未及，但事实确实如此。
在解释这个现象如何发生前，请先暂时接受这一事实，我们先来考察一下双重检查锁定是如何被破坏的。假设上述代码执行以下事件序列：
线程 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 处的代码，导致还是会有无序写入带来的问题！！！
通过enum实现单例
JDK1.5之后，还有另一种方法来实现Singleton，只要简单地编写一个只包含一个元素的枚举类型：
//Enum singletion - the preferred approach
public enum Elvis{
INSTANCE;
public void leaveTheBuilding(){...}
}
该方法与公共域方法类似，不过它更加简洁，无偿提供序列化机制，并且绝对保证不会被多次实例化，即使是在面对复杂的序列化或反射攻击的时候也这样。虽然这种方法尚未被广泛采用，但单元素的枚举类型是实现Singleton的最佳方式。
