设计模式—单例模式（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 显然是不合适的。这个时候，这种方式相比第三和第四种方式就显得很合理。