设计模式—单例模式（Singleton pattern）

1.单例模式

先来看一个例子，一台计算机上可以连好几个打印机，但是这个计算机上的打印程序只能有一个，这里就可以通过单例模式来避免两个打印作业同时输出到打印机中，即在整个的打印过程中我只有一个打印程序的实例。简单说来，单例模式（也叫单件模式）的作用就是保证在整个应用程序的生命周期中，任何一个时刻，单例类的实例都只存在一个（当然也可以不存在）。

2.单例模式结构图

看看下面的结构图

从图中我们可以看出，在单例类中有一个私有的构造函数Singleton（“-”号表示私有），有一个公开的GetInstance()方法，由此我们不难看出单例模式的特点，从而给出单例模式的定义：单例模式保证一个类仅有一个实例，同时这个类还必须提供一个访问该类的全局访问点。

3.单例模式的写法

3.1饿汉式单例类

//饿汉式单例类.在类初始化时，已经自行实例化  

public class SingletonClass {   private static final SingletonClass instance = new SingletonClass();       private SingletonClass() {        }   public static SingletonClass getInstance() {     return instance;   } }

问题：SingletonClass在加载的时候就已经实例化了，而我们还不知道这个类会不会被用到，那么做的就是无用功啊。                         

3.2懒汉式单例类

//懒汉式单例类.在第一次调用的时候实例化 public class SingletonClass {   //注意，这里没有final  private static SingletonClass instance = null;          private SingletonClass() {        }        public static SingletonClass getInstance() {     if(instance == null) {       instance = new SingletonClass();     }     return instance;   } }

代码的变化有两处，instance初始化为null，直到第一词使用的时候通过判断是否为空来创建对象。因为创建过程不在声明处，所以那个final的修饰必须去掉。

我们来想象一下这个过程。要使用SingletonClass，调用getInstance()方法。第一次的时候发现instance是null，然后就新建一个对象，返回出去；第二次再使用的时候，因为这个instance是static的，所以已经不是null了，因此不会再创建对象，直接将其返回。这个过程就成为lazy loaded，也就是迟加载——直到使用的时候才进行加载。

3.3同步

上面的代码在单线程的情况下是没有问题的，可是在多线程的情况下，问题就来了。

现在有线程A希望使用SingletonClass，调用getInstance()方法。因为是第一次调用，A就发现instance是null的，于是它开始创建实例，就在这个时候，CPU发生时间片切换，线程B开始执行，它要使用SingletonClass，调用getInstance()方法，同样检测到instance是null——注意，这是在A检测完之后切换的，也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后，切换到A继续执行，因为它已经检测完了，所以A不会再检测一遍，它会直接创建对象。这样，线程A和B各自拥有一个SingletonClass的对象——单例失败！

解决方法有，就是加锁，是要getInstance()加上同步锁，一个线程必须等待另外一个线程创建完成后才能使用这个方法，这就保证了单例的唯一性。

public class SingletonClass {   private static SingletonClass instance = null;   public synchronized static SingletonClass getInstance() {     if(instance == null) {       instance = new SingletonClass();     }     return instance;   }   private SingletonClass() {   } }

3.4.性能

  上面的解决方案既清楚又简单，但是还是有问题的，那就是性能问题，synchronized修饰的同步块可是要比一般的代码段慢上几倍的！如果存在很多次getInstance()的调用，那性能问题就不得不考虑了！
   让我们来分析一下，究竟是整个方法都必须加锁，还是仅仅其中某一句加锁就足够了？我们为什么要加锁呢？分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行，那么单例就已经保证了。于是，我们开始修改代码：

public class SingletonClass {    private static SingletonClass instance = null;     public static SingletonClass getInstance() {     synchronized (SingletonClass.class) {       if(instance == null) {         instance = new SingletonClass();       }     }         return instance;   }   private SingletonClass() {   } }

首先去掉getInstance()的同步操作，然后把同步锁加载if语句上。但是这样的修改起不到任何作用：因为每次调用getInstance()的时候必然要同步，性能问题还是存在。如果……如果我们事先判断一下是不是为null再去同步呢？

public class SingletonClass {   private static SingletonClass instance = null;   public static SingletonClass getInstance() {     if (instance == null) {       synchronized (SingletonClass.class) {         if (instance == null) {           instance = new SingletonClass();         }       }     }     return instance;   }    private SingletonClass() {  } }

还有问题吗？首先判断instance是不是为null，如果为null，加锁初始化；如果不为null，直接返回instance。

这就是double-checked locking设计实现单例模式。到此为止，一切都很完美。我们用一种很聪明的方式实现了单例模式

3.5静态内部类

public class Singleton {    private static class SingletonHolder {private static final Singleton INSTANCE = new Singleton();    }    private Singleton (){}    public static final Singleton getInstance() {return SingletonHolder.INSTANCE;    }}

   这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，它跟第三种和第四种方式不同的是（很细微的差别）：第三种和第四种方式是只要Singleton类被装载了，那么instance就会被实例化（没有达到lazy loading效果），而这种方式是Singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。想象一下，如果实例化instance很消耗资源，我想让他延迟加载，另外一方面，我不希望在Singleton类加载时就实例化，因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化instance显然是不合适的。这个时候，这种方式相比第三和第四种方式就显得很合理。