1.单例模式（Singleton Pattern）

墨家先生

已于 2022-05-11 17:14:00 修改

阅读量497

点赞数 1

分类专栏：设计模式文章标签： java 单例模式

于 2022-05-05 16:16:48 首次发布

原文链接：https://blog.csdn.net/qq_41458550/article/details/109243456

版权

设计模式专栏收录该内容

8 篇文章 2 订阅

订阅专栏

1.概述

1.1.定义

单例模式确保某个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
在计算机系统中，线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例。
这些应用都或多或少具有资源管理器的功能。每台计算机可以有若干个打印机，但只能有一个Printer Spooler，以避免两个打印作业同时输出到打印机中。每台计算机可以有若干通信端口，系统应当集中管理这些通信端口，以避免一个通信端口同时被两个请求同时调用。
总之，选择单例模式就是为了避免不一致状态，避免政出多头。

1.2.特点

单例类只能有一个实例。
单例类必须自己创建自己的唯一实例。
单例类必须给所有其他对象提供这一实例。

单例模式保证了全局对象的唯一性，比如系统启动读取配置文件就需要单例保证配置的一致性。

1.3.线程安全问题

方面在获取单例的时候，要保证不能产生多个实例对象，后面会详细讲到五种实现方式；
在使用单例对象的时候，要注意单例对象内的实例变量是会被多线程共享的，推荐使用无状态的对象，不会因为多个线程的交替调度而破坏自身状态导致线程安全问题，比如我们常用的VO，DTO等（局部变量是在用户栈中的，而且用户栈本身就是线程私有的内存区域，所以不存在线程安全问题）。

2.八种实现方式

2.1.饿汉式（静态常量）【可用】

优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点：在类装载的时候就完成实例化，没有达到懒加载（Lazy Loading）的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。

public class Singleton1 {
    public static final Singleton1 INSTANCE = new Singleton1();

    private Singleton1() {
    }

    public static Singleton1 getInstance() {
        return INSTANCE;
    }
}

2.2.饿汉式（静态代码块）【可用】

这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。

public class Singleton2 {
    public static final Singleton2 INSTANCE;

    static {
        INSTANCE = new Singleton2();
    }

    private Singleton2() {
    }

    public static Singleton2 getInstance() {
        return INSTANCE;
    }
}

2.3.懒汉式（线程不安全）【不可用】

这种写法起到了Lazy Loading的效果，但是只能在单线程下使用。如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。

public class Singleton3 {
    public static Singleton3 instance;

    private Singleton3() {
    }

    public static Singleton3 getInstance() {
        if (instance == null) {
            instance = new Singleton3();
        }
        return instance;
    }
}

2.4.懒汉式（线程安全，同步方法）【不推荐用】

解决上面第三种实现方式的线程不安全问题，做个线程同步就可以了，于是就对getInstance()方法进行了线程同步。
缺点：效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接return就行了。方法进行同步效率太低要改进。

public class Singleton4 {
    public static Singleton4 instance;

    private Singleton4() {
    }

    public static synchronized Singleton4 getInstance() {
        if (instance == null) {
            instance = new Singleton4();
        }
        return instance;
    }
}

2.5.懒汉式（线程安全，同步代码块）【不可用】

由于第四种实现方式同步效率太低，所以摒弃同步方法，改为同步产生实例化的的代码块。但是这种同步并不能起到线程同步的作用。
跟第3种实现方式遇到的情形一致，当 instance 为 null 时，两个线程可以并发地进入 if 语句内部。然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个 Singleton 对象。注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。

public class Singleton5 {
    public static Singleton5 instance;

    private Singleton5() {
    }

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

2.6.双重检查【推荐使用】

Double-Check概念对于多线程开发者来说不会陌生，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象。
优点：线程安全；延迟加载；效率较高。

public class Singleton6 {
	// 此处增加了 volatile 规避多线程编程中的问题
    public volatile static Singleton6 instance;

    private Singleton6() {
    }

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

双重检查锁定背后的理论是完美的。不幸地是，现实完全不同。双重检查锁定的问题是：指令重排序优化会导致其他线程可能获取未初始化完成的对象。
双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。
所以，后来人们加上了volatile，为的就是防止指令重排。
volatile另一个作用是对singleton修改后会立即将singleton的值从其工作内存刷回到主内存以保证其它线程的可见性。

2.7.静态内部类【推荐使用】

这种方式跟饿汉式方式采用的机制类似，但又有不同。两者都是采用了类装载的机制来保证初始化实例时只有一个线程。不同的地方在饿汉式方式是只要Singleton类被装载就会实例化，没有Lazy-Loading的作用，而静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。
类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。
优点：线程安全，调用效率高，可以延时加载。

// 因为要进行反序列化攻击测试，这里实现 Serializable 接口
public class Singleton7 implements Serializable {
    private Singleton7() {
    }

    public static class SingletonHolder {
        public static final Singleton7 INSTANCE = new Singleton7();
    }

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

似乎静态内部类看起来已经是最完美的方法了，其实不是，可能还存在反射攻击和反序列化攻击。

2.8.1.反射攻击

	@Test
    public void testReflect() throws Exception {
        Singleton7 instance = Singleton7.getInstance();
        Constructor<Singleton7> constructor = Singleton7.class.getDeclaredConstructor();
        constructor.setAccessible(true);
        Singleton7 newInstance = constructor.newInstance();
        System.out.println(instance == newInstance);
    }

运行结果：false
通过结果看，这两个实例不是同一个，违背了单例模式的原则。

2.8.2.反序列化攻击

将实例序列化和反序列化并比较

	@Test
    public void testSerialize() {
        Singleton7 instance = Singleton7.getInstance();
        ByteArrayOutputStream bos = null;
        ObjectOutputStream oos = null;
        ByteArrayInputStream bis = null;
        ObjectInputStream ois = null;
        try {
        	// 序列化
            bos = new ByteArrayOutputStream();
            oos = new ObjectOutputStream(bos);
            oos.writeObject(instance);
            // 反序列化
            bis = new ByteArrayInputStream(bos.toByteArray());
            ois = new ObjectInputStream(bis);
            Singleton7 newInstance = (Singleton7) ois.readObject();
            System.out.println(instance == newInstance);
        } catch (IOException | ClassNotFoundException e) {
            throw new RuntimeException(e);
        } finally {
            try {
                assert bos != null;
                bos.close();
                assert oos != null;
                oos.close();
                assert bis != null;
                bis.close();
                assert ois != null;
                ois.close();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        }
    }

运行结果：false
通过结果看，这两个实例不是同一个，违背了单例模式的原则。

2.8.枚举【推荐使用】

借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。

public enum Singleton8 {
    INSTANCE;

    public void doSomething() {
        System.out.println("do sth.");
    }
}

综上，线程安全的几种单例模式比较来看：
枚举（无锁，调用效率高，可以防止反射和反序列化调用，不能延时加载）> 静态内部类（无锁，调用效率高，可以延时加载） > 双重同步锁（有锁，调用效率高于懒汉式，可以延时加载） > 懒汉式（有锁，调用效率不高，可以延时加载） ≈ 饿汉式（无锁，调用效率高，不能延时加载）
ps:只有枚举能防止反射和反序列化调用

3.应用场景

3.1.优缺点

优点：
系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能。
缺点：
当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用new，可能会给其他开发人员造成困扰，特别是看不到源码的时候。约定俗成的方法 getInstance()。

3.2.使用场景

需要频繁的进行创建和销毁的对象；
创建对象时耗时过多或耗费资源过多，但又经常用到的对象；
工具类对象；
频繁访问数据库或文件的对象。

4.源码分享

github源码地址

墨家先生

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
1.单例模式（Singleton Pattern）

1.概述1.1.定义单例模式确保某个类只有一个实例，而且自行实例化并向整个系统提供这个实例。在计算机系统中，线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例。这些应用都或多或少具有资源管理器的功能。每台计算机可以有若干个打印机，但只能有一个Printer Spooler，以避免两个打印作业同时输出到打印机中。每台计算机可以有若干通信端口，系统应当集中管理这些通信端口，以避免一个通信端口同时被两个请求同时调用。总之，选择单例模式就是为了避免不一致状态，避免政出多头。1.
复制链接

扫一扫