软件设计模式——单例模式详解
文章目录
- 单例模式
-
- 1. 简介
- 2. 单例模式实现
-
- 2.1 饿汉式（静态变量）
- 2.2 饿汉式（静态代码块）
- 2.3 懒汉式（线程不安全）
- 2.4 懒汉式（线程安全）
- 2.5 懒汉式（双重检查锁DCL）
- 2.6 懒汉式（静态内部类）
- 2.7 枚举方式
- 3. 存在问题及解决
-
- 3.1 序列化反序列化
-
- 问题演示
- 解决方案
- 3.2 反射
-
- 问题演示
- 解决方案
单例模式
1. 简介
单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
单例模式应用十分广泛。比如数据库连接类，实际上只需要创建一个对象或是直接使用静态方法就可以了，没必要去创建多个对象。
单例模式的主要有以下角色：
- 单例类。只能创建一个实例的类
- 访问类。使用单例类
注意：
- 为保证只能由自己创建对象，单例类必须 构造方法私有化。
- 单例类必须自己创建自己的唯一实例。
- 单例类必须给所有其他对象提供这一实例。
2. 单例模式实现
单例设计模式分为两种：
饿汉式： 类加载就会导致该单实例对象被创建
懒汉式： 类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建
2.1 饿汉式（静态变量）
/**
* 饿汉式
* 静态变量创建类的对象
*/
public class Singleton {
//私有构造方法
private Singleton() {}
//在成员位置创建该类的对象
private static Singleton instance = new Singleton();
//对外提供静态方法获取该对象
public static Singleton getInstance() {
return instance;
}
}
说明：
该方式在成员位置声明Singleton类型的静态变量，并创建Singleton类的对象instance。instance对象是随着类的加载而创建的，保证了线程的安全。但如果该对象足够大的话，而一直没有使用就会造成内存的浪费。这种方式由于不存在线程安全问题， 因此不用加锁，效率较高，以空间换时间。
2.2 饿汉式（静态代码块）
/**
* 恶汉式
* 在静态代码块中创建该类对象
*/
public class Singleton {
//私有构造方法
private Singleton() {}
//在成员位置创建该类的对象
private static Singleton instance;
static {
instance = new Singleton();
}
//对外提供静态方法获取该对象
public static Singleton getInstance() {
return instance;
}
}
说明：
该方式在成员位置声明Singleton类型的静态变量，而对象的创建是在静态代码块中，也是随着类的加载而创建。所以和方式1基本上一样，当然该方式也存在内存浪费问题。
2.3 懒汉式（线程不安全）
/**
* 懒汉式
* 线程不安全
*/
public class Singleton {
//私有构造方法
private Singleton() {}
//在成员位置创建该类的对象
private static Singleton instance;
//对外提供静态方法获取该对象
public static Singleton getInstance() {
if(instance == null) {
instance = new Singleton();
}
return instance;
}
}
说明：
从上面代码我们可以看出该方式在成员位置声明Singleton类型的静态变量，并没有进行对象的赋值操作，那么什么时候赋值的呢？当调用getInstance()方法获取Singleton类的对象的时候才创建Singleton类的对象，这样就实现了懒加载的效果。但是，如果是多线程环境，会出现线程安全问题。
2.4 懒汉式（线程安全）
/**
* 懒汉式
* 线程安全
*/
public class Singleton {
//私有构造方法
private Singleton() {}
//在成员位置创建该类的对象
private static Singleton instance;
//对外提供静态方法获取该对象，方法用synchronized修饰
public static synchronized Singleton getInstance() {
if(instance == null) {
instance = new Singleton();
}
return instance;
}
}
说明：
该方式也实现了懒加载效果，同时又解决了线程安全问题。但是在getInstance()方法上添加了synchronized关键字，导致该方法的执行效果特别低。从上面代码我们可以看出，其实就是在初始化instance的时候才会出现线程安全问题，一旦初始化完成就不存在了。
2.5 懒汉式（双重检查锁DCL）
再来讨论一下懒汉模式中加锁的问题，对于 getInstance() 方法来说，绝大部分的操作都是读操作，读操作是线程安全的，所以我们没必让每个线程必须持有锁才能调用该方法，我们需要调整加锁的时机。由此也产生了一种新的实现模式：双重检查锁模式（DCL， double-checked locking）
/**
* 懒汉式
* 双重检查锁方式
*/
public class Singleton {
//私有构造方法
private Singleton() {}
private static Singleton instance;
//对外提供静态方法获取该对象
public static Singleton getInstance() {
//第一次判断，如果instance不为null，不进入抢锁阶段，直接返回实例
if(instance == null) {
synchronized (Singleton.class) {
//抢到锁之后再次判断是否为null
if(instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
双重检查锁模式是一种非常好的单例实现模式，解决了性能、线程安全问题。上面的双重检测锁模式看上去完美无缺，其实是存在问题，在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。
要解决双重检查锁模式带来空指针异常的问题，只需要使用 volatile 关键字, volatile 关键字可以保证可见性和有序性。
/**
* 懒汉式
* 双重检查锁方式
*/
public class Singleton {
//私有构造方法
private Singleton() {}
private static volatile Singleton instance;
//对外提供静态方法获取该对象
public static Singleton getInstance() {
//第一次判断，如果instance不为null，不进入抢锁阶段，直接返回实例
if(instance == null) {
synchronized (Singleton.class) {
//抢到锁之后再次判断是否为空
if(instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
总结：
比较好的单例实现模式，能够保证在多线程的情况下线程安全也不会有性能问题。
2.6 懒汉式（静态内部类）
静态内部类实现依赖于 Java 在类加载时不会加载其内部类，只有实例化内部类时才会加载的特性。其他语言不具备这一特性，无法使用该方式实现，因此这种方式不具备通用性。
静态内部类单例模式中实例由内部类创建，由于 JVM 在加载外部类的过程中，是不会加载静态内部类的，只有内部类的属性/方法被调用时才会被加载，并初始化其静态属性。静态属性由于被 static 修饰，保证只被实例化一次，并且严格保证实例化顺序。
/**
* 懒汉式
* 静态内部类方式
*/
public class Singleton {
//私有构造方法
private Singleton() {}
//定义静态内部类
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
//对外提供静态方法获取该对象
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
说明：
第一次加载Singleton类时不会去初始化INSTANCE，只有第一次调用getInstance()，虚拟机才会加载SingletonHolder并初始化INSTANCE，这样不仅能确保线程安全，也能保证 Singleton 类的唯一性。
静态内部类单例模式是一种优秀的单例模式，是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费。
2.7 枚举方式
枚举类实现单例模式是极力推荐的单例实现模式，因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特性来实现单例模式，枚举的写法非常简单，而且 枚举类型是所用单例实现中唯一一种不会被破坏的单例实现模式。
枚举方式属于饿汉式。
/**
* 饿汉式
* 枚举方式
*/
public enum Singleton {
INSTANCE;
}
3. 存在问题及解决
单例模式是能够被破坏的：
如果要使上面定义的单例类（Singleton）可以创建多个对象，可以有两种方式：分别是序列化和反射。（枚举除外，因为枚举不会被破坏）
3.1 序列化反序列化
问题演示
Singleton类：
public class Singleton implements Serializable {
//私有构造方法
private Singleton() {}
//定义静态内部类
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
//对外提供静态方法获取该对象
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
Test类：
public class Test {
public static void main(String[] args) throws Exception {
//往文件中写对象
writeObject2File();
//从文件中读取对象
Singleton s1 = readObjectFromFile();
Singleton s2 = readObjectFromFile();
//判断两个反序列化后的对象是否是同一个对象
System.out.println(s1 == s2); //false
}
private static Singleton readObjectFromFile() throws Exception {
//创建对象输入流对象
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("E:\\a.txt"));
//第一个读取Singleton对象
Singleton instance = (Singleton) ois.readObject();
return instance;
}
public static void writeObject2File() throws Exception {
//获取Singleton类的对象
Singleton instance = Singleton.getInstance();
//创建对象输出流
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("E:\\a.txt"));
//将instance对象写出到文件中
oos.writeObject(instance);
}
}
上面代码运行结果是false，表明序列化和反序列化已经破坏了单例设计模式。
解决方案
序列化、反序列方式破坏单例模式的解决方法：
在Singleton类中添加readResolve()方法，在反序列化时被反射调用，如果定义了这个方法，就返回这个方法的值，如果没有定义，则返回新new出来的对象。
Singleton类：
public class Singleton implements Serializable {
//私有构造方法
private Singleton() {}
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
//对外提供静态方法获取该对象
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
//下面是为了解决序列化反序列化破解单例模式
private Object readResolve() {
return SingletonHolder.INSTANCE;
}
}
3.2 反射
问题演示
Singleton类：
/**
* 懒汉式
* 双重检查锁方式
*/
public class Singleton {
//私有构造方法
private Singleton() {}
private static Singleton instance;
//对外提供静态方法获取该对象
public static Singleton getInstance() {
//第一次判断，如果instance不为null，不进入抢锁阶段，直接返回实例
if(instance == null) {
synchronized (Singleton.class) {
//抢到锁之后再次判断是否为null
if(instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
Test类：
public class Test {
public static void main(String[] args) throws Exception {
Singleton s1 = Singleton.getInstance();
//获取Singleton类的字节码对象
Class clazz = Singleton.class;
//获取Singleton类的私有无参构造方法对象
Constructor constructor = clazz.getDeclaredConstructor();
//取消访问检查
constructor.setAccessible(true);
//使用反射创建Singleton类的对象s2
Singleton s2 = (Singleton) constructor.newInstance();
//判断通过反射创建的两个Singleton对象是否是同一个对象
System.out.println(s1 == s2); //false
}
}
上面代码运行结果是false，表明反射已经破坏了单例设计模式
解决方案
（1）在构造方法中加上对象的非空判断：
private Singleton() {
synchronized (Singleton.class) {
if (instance != null) {
throw new RuntimeException("不要试图用反射破坏单例");
}
}
}
但是这种写法还是有问题，前面是先正常的调用了 getInstance() 方法，创建了 Singleton 对象，然后第 2 次用反射创建对象，私有构造函数里面的判断起作用了，反射破坏单例模式失败。
但如果先用反射创建对象，判断就不生效了：
// 获取无参构造器
Constructor<Singleton> declaredConstructor = Singleton.class.getDeclaredConstructor(null);
// 取消无参构造器私有属性
declaredConstructor.setAccessible(true);
// 使用反射获取的无参构造器实例化对象
Singleton s1 = declaredConstructor.newInstance();
Singleton s2 = declaredConstructor.newInstance();
// 比较实例化的两个对象
System.out.println(s1 == s2);
输出结果为 false，同一个类实例化的两个对象不相等，单例又被破坏了！还有什么办法防止这种反射破坏呢？
（2）使用标志位来避免重复创建
private static boolean flag = false;
private Singleton() {
synchronized (Singleton.class) {
if (flag == false) {
// 第一次创建后，标志位设为 true
flag = true;
} else {
// 后续再使用构造方法创建则直接报错
throw new RuntimeException("不要试图用反射破坏单例模式");
}
}
}
这样看起来很完美了，但还是不能完全防止反射破坏单例，因为依然可以利用反射修改 flag 的值。
// 获取无参构造器
Constructor<Singleton> declaredConstructor = Singleton.class.getDeclaredConstructor(null);
// 取消无参构造器私有属性
declaredConstructor.setAccessible(true);
// 使用反射获取的无参构造器实例化对象
Singleton s1 = declaredConstructor.newInstance();
// 获取 flag 属性
Field field = Singleton.class.getDeclaredField("flag");
// 取消 flag 属性的私有属性
field.setAccessible(true);
// 通过反射，修改属性的值
field.set(s1, false);
// 使用反射获取的无参构造器实例化对象
Singleton s2 = declaredConstructor.newInstance();
// 比较实例化的两个对象
System.out.println(s1 == s2);
输出结果为 false，同一个类实例化的两个对象不相等，单例又又被破坏了！正所谓道高一尺魔高一丈，懒汉式单例不管怎么挣扎，在反射面前都无计可施。
那么，就没有办法完美的实现单例这么一个最简单的设计模式了吗？答案是有的，但不是外界，而是 Java 自己给出的解决方案。正所谓解铃还须系铃人，反射是 Java 的语言特性，Java 赋予了它如此强大的能力，只能由 Java 自身来对其进行限制。在 Java 1.5 中推出的枚举就可以完美解决这个问题。
（3）使用枚举避免单例被破坏
详见：https://www.kuangstudy.com/bbs/1545601837217284098