设计模式之单例模式

设计模式之单件模式

一、模式说明

1.1 意图

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

1.2 动机

​ 对一些类来说，只有一个实例是很重要的。虽然系统中可以有许多打印机，但却只应该有一个打印假脱机，只应该有一个文件系统和一个窗口管理器。一个数字滤波器只能有一个 A / D 转换器。一个会计系统只能专用于一个公司。

​ 我们怎么样才能保证一个类只有一个实例并且这个实例易于被访问呢？一个全局变量使得一个对象可以被访问，但它不能防止你实例化多个对象。 一个更好的办法是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建（通过截取创建新对象的请求），并且它可以提供一个访问该实例的方法。这就是单例模式。

1.3 适用性

在下面的情况下可以使用 Singleton 模式 。

当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

1.4 结构

略。

1.5 参与者

Singleton：定义一个 Instance 操作，允许客户访问它的唯一实例。 可能负责创建它自己的唯一实例。

1.6 协作

客户只能通过 Singletion 的 Instance 操作访问一个 Singletion 的实例。

1.7 效果

单例模式有许多优点：

对唯一实例的受控访问： 因为 Singleton 类封装它的唯一实例，所以它可以严格的控制客户怎样以及何时访问它。缩小名空间： 单例模式是对全局变量的一种改进。它避免了那些存储唯一实例的全局变量污染名空间。允许对操作和表示的精化：Singleton 类可以有子类，而且用这个扩展类的实例来配置一个应用是很容易的。你可以用你所需要的类的实例在运行时刻配置应用。允许可变数目的实例：这个模式使得你易于改变你的想法，并允许单例类的多个实例。此外，你可以用相同的方法来控制应用所使用的实例的数目。只有允许访问 Singleton 实例的操作需要改变。比类操作更灵活：另一种封装单件功能的方式是使用类操作（即 C + +中的静态成员函数 或者是S m a l l t a l k中的类方法）。但这两种语言技术都难以改变设计以允许一个类有多个实例。 此外，C + +中的静态成员函数不是虚函数，因此子类不能多态的重定义它们。

1.8 相关模式

很多模式可以使用 Singleton 模式实现。工厂模式、建造者模式，和 原型模式。

二、模式的实现

根据上面介绍，我们知道，要实现单例模式，需要提供一个全局访问点，并且保证只有一个实例。来看看怎么实现吧。

/** * 简单单例 */ public class Singleton01 { // 全局变量 private static Singleton01 uniqueInstance; // 私有构造器，保证类只有自己控制创建对象 private Singleton01(){} // 提供全局唯一访问点 public static Singleton01 getInstance(){ if(uniqueInstance == null){ uniqueInstance = new Singleton01(); } return uniqueInstance; } }

看吧，单例模式多简单！不过你要小心了，上述代码可能会出问题！继续往下看吧。

2.1 懒汉式

上述例子就是懒汉式，这种实现上最大的问题就是不支持多线程。严格意义上，它并不算是单例模式。

/** * 懒汉式 * 多线程情况下不能正常工作 * 例如，有两个线程同时执行到了代码第13行，都检测到 uniqueInstance == null ，那么接下来的操作，产生了两个对象。 * 失去单例的意义 */ public class Singleton01 { private static Singleton01 uniqueInstance; private Singleton01(){} public static Singleton01 getInstance(){ if(uniqueInstance == null){ uniqueInstance = new Singleton01(); } return uniqueInstance; } }

2.2 懒汉式-线程安全

为了解决懒汉式线程不安全的问题，只要把 getInstance() 方法变成同步方法就可以了，多线程灾难几乎就可以解决了。

/** * 懒汉式-线程安全 */ public class Singleton02 { private static Singleton02 uniqueInstance; private Singleton02(){} // 通过增加 synchronized 关键字，保证了不会有两个线程可以同时进入这个方法 public static synchronized Singleton02 getInstance(){ if(uniqueInstance == null){ uniqueInstance = new Singleton02(); } return uniqueInstance; } }

看起来一切很顺利啊，但是这里有个比较严重的问题：其实只有第一次执行此方法时，才真正需要同步。换句话说，一旦设置好 uniqueInstance 实例后，就不再需要同步这个方法了。之后每次调用这个方法，同步都是一种累赘。

2.3 饿汉式

如果应用程序总是创建并使用单件，或者在创建和运行时方面的负担不太繁重，你可能需要急切的创建此单件，如下：

/** * 饿汉式： */ public class Singleton03 { private static Singleton03 uniqueInstance = new Singleton03(); private Singleton03(){} public static synchronized Singleton03 getInstance(){ return uniqueInstance; } }

在静态初始化器中创建单件，依赖于 JVM 在加载这个类时马上创建此唯一的单件实例。由 JVM 保证线程安全。

缺点：类加载时就初始化，浪费内存。

2.4 双重检查加锁（DCL）——推荐

利用双重检查加锁（double-checked locking）,首先检查是否实例已经创建了，如果尚未创建，“才”进行同步。这样一来，只有第一次会同步，这才是我们想要的。

/** * 双重检查加锁 */ public class Singleton04 { // volatile 关键字确保：当 uniqueInstance 被初始化成 Singleton实例时，多个线程能正确的处理 uniqueInstance private volatile static Singleton04 uniqueInstance; private Singleton04() { } public static Singleton04 getInstance() { if (uniqueInstance == null) { synchronized (Singleton04.class) { if (uniqueInstance == null) { uniqueInstance = new Singleton04(); } } } return uniqueInstance; } }

2.5 枚举——推荐

这种方式是 Effective Java 作者 Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还自动支持序列化机制，防止反序列化重新创建新的对象，绝对防止多次实例化。

/** * 枚举 */ public enum Singleton05 { INSTANCE; }

2.6 关于单例模式的一些问题

享有特权的客户端可以借助 AccessibleObject.setAccessible方法，通过反射机制调用私有构造器。如果要抵御这种攻击，可以修改构造器，让他在被要求创建第二个实例的时候抛出异常。想要让单例类变成可序列化的，仅仅在声明中加入 implements Serializable 是不够的。为了维护和保证单例，必须声明所有实例域都是瞬时的（transient），并提供一个 readResolve 方法。否则，每次反序列化一个序列化的实例时，都会创建一个新的对象。 // readResolve method to preserve singleton property private Object readResolve(){ return INSTANCE; }

而，使用枚举实现的单例，天然的就避免了上述问题。