Java设计模式----单例模式(Singleton)

1.什么是单例设计模式

单例模式是一种常用的软件设计模式。在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例

2.实现方式

1.饿汉式：

package cn.limbo.design_patterns.singleton.hungry;

/**
 * 饿汉式，只要有需求就new一个出来
 * Created by limbo on 2016/12/7.
 */
public class HungrySingleton {

	private static final HungrySingleton hungrySingleton = new HungrySingleton();

	private HungrySingleton(){}

	public static HungrySingleton getInstance(){
		return hungrySingleton;
	}

}

这种写法如果完美的话，就没必要在啰嗦那么多双检锁的问题了。缺点是它不是一种懒加载模式（lazy initialization），单例会在加载类后一开始就被初始化，即使客户端没有调用 getInstance()方法。饿汉式的创建方式在一些场景中将无法使用：譬如 Singleton 实例的创建是依赖参数或者配置文件的，在 getInstance() 之前必须调用某个方法设置参数给它，那样这种单例写法就无法使用了。

2.懒汉式，三种实现方式：普通(非线程安全，线程安全，双重锁机制)

package cn.limbo.design_patterns.singleton.lazy;

/**
 * 懒汉式单例模式
 * Created by limbo on 2016/12/8.
 */
public class LazySingleton {

	//防止编译器优化而忽略了
	private volatile static LazySingleton lazySingleton;

	private LazySingleton() {
	}

	//获取单例，但是是线程不安全的
	public static LazySingleton getInstance(){
		if(lazySingleton == null){
			lazySingleton = new LazySingleton();
			return lazySingleton;
		}else {
			return lazySingleton;
		}
	}


	//虽然做到了线程安全，并且解决了多实例的问题，但是它并不高效。
	// 因为在任何时候只能有一个线程调用 getInstance() 方法。
	// 但是同步操作只需要在第一次调用时才被需要，即第一次创建单例实例对象时。
	public static synchronized LazySingleton getInstance2(){
		if(lazySingleton == null){
			lazySingleton = new LazySingleton();
			return lazySingleton;
		}else {
			return lazySingleton;
		}
	}

	//双重检验锁
	public static LazySingleton getInstance3(){
		if(lazySingleton == null){
			synchronized(LazySingleton.class){
				if(lazySingleton == null){
					lazySingleton = new LazySingleton();
				}
			}
		}
		return lazySingleton;
	}
	//这段代码看起来很完美，很可惜，它是有问题。主要在于instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情。
	//1.给 instance 分配内存
	//2.调用 Singleton 的构造函数来初始化成员变量
	//3.将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）
	//但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。
	//我们只需要将 instance 变量声明成 volatile 就可以了。
	//有些人认为使用 volatile 的原因是可见性，也就是可以保证线程在本地不会存有 instance 的副本，每次都是去主内存中读取。但其实是不对的。使用 volatile 的主要原因是其另一个特性：禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完 1-2-3 之后或者 1-3-2 之后，不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。
	//但是特别注意在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM （Java 内存模型）是存在缺陷的，即时将变量声明成 volatile 也不能完全避免重排序，主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复，所以在这之后才可以放心使用 volatile。
}

3.静态内部类（推荐）

package cn.limbo.design_patterns.singleton.static_nested_class;

/**
 * 静态内部类实现方式
 * Created by limbo on 2016/12/8.
 */
public class Singleton {

	private Singleton(){}

	private static class SingletonHolder {
		private static final Singleton INSTANCE = new Singleton();

	}

	public static Singleton getInstance(){
		return SingletonHolder.INSTANCE;
	}

}

这种写法仍然使用JVM本身机制保证了线程安全问题；由于 SingletonHolder 是私有的，除了 getInstance() 之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖 JDK 版本。

4.枚举(最推荐)

package cn.limbo.design_patterns.singleton.enum_singleton;

/**
 * 枚举类型实现单例模式，这个是jdk1.5以上的版本才可以用的，也是开发者最推荐的
 * 实现方式，几乎解决了所有单例可能会遇到的问题，关键是书写简单。
 * 
 * 调用方式，EasySingleton singleton = EasySingleton.INSTANCE
 * 然后singleton就可以调用EasySingleton里面的所有方法了，连构造方法什么的都不用写了
 * Created by limbo on 2016/12/8.
 */
public enum EasySingleton {

	INSTANCE;

	public void show(){
		System.out.println("枚举单例");
	}

}

我们可以通过EasySingleton.INSTANCE来访问实例，这比调用getInstance()方法简单多了。创建枚举默认就是线程安全的，所以不需要担心double checked locking，而且还能防止反序列化导致重新创建新的对象。但是还是很少看到有人这样写，可能是因为不太熟悉吧。

一般来说，单例模式有五种写法：懒汉、饿汉、双重检验锁、静态内部类、枚举。上述所说都是线程安全的实现，文章开头给出的第一种方法不算正确的写法。就我个人而言，一般情况下直接使用饿汉式就好了，如果明确要求要懒加载（lazy initialization）会倾向于使用静态内部类，如果涉及到反序列化创建对象时会试着使用枚举的方式来实现单例。

3.优缺点

1.主要优点

单例模式的主要优点如下：

(1) 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它。

(2) 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。

(3) 允许可变数目的实例。基于单例模式我们可以进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例，既节省系统资源，又解决了单例单例对象共享过多有损性能的问题。

2.主要缺点

单例模式的主要缺点如下：

(1) 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。

(2) 单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。

(3) 现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的共享对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致共享的单例对象状态的丢失。

4.适用场景

在以下情况下可以考虑使用单例模式：

(1) 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器或资源管理器，或者需要考虑资源消耗太大而只允许创建一个对象。

(2) 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例