创建型模式之单例模式
此篇博客主要谈谈创建型模式中的单例模式,包括单例模式的五种实现方式:饿汉式、懒汉式、双重检测锁、静态内部类以及枚举。
此篇博客主要参考以下文档:
https://design-patterns.readthedocs.io/zh_CN/latest/
模式动机
对于系统中的某些类来说,只有一个实例很重要,例如,一个系统中可以存在多个打印任务,但是只能有一个正在工作的任务;一个系统只能有一个窗口管理器或文件系统;一个系统只能有一个计时工具或ID(序号)生成器。
如何保证一个类只有一个实例并且这个实例易于被访问呢?定义一个全局变量可以确保对象随时都可以被访问,但不能防止我们实例化多个对象。
一个更好的解决办法是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建,并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。
模式定义
单例模式(Singleton Pattern):单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法。
单例模式的要点有三个:一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。
模式结构
单例模式包含如下角色:
- Singleton:单例
上图中实现了懒汉式单例模式,可以延时加载,一定程度上减少了资源的开销。
代码分析
饿汉式
1 | public class HungerSingleton { |
饿汉式单例模式在类加载时便创建了实例对象,客户端调用实例创建方法时直接返回实例即可,该方式是线程安全的。
懒汉式
1 | public class LazySingleton { |
与饿汉式单例模式不同,懒汉式单例模式直到客户端真正调用实例创建方法时才创建实例,起到了延时加载的作用。
为了保证线程安全,可以用synchronized修饰方法,另外还能用双重检测锁的方式保证线程安全。
双重检测锁
1 | public class DoubleCheckSingleton { |
值得一提的是,此处采用两次判断instance是否为null的原因,假设多个线程同时通过第一个条件,此时由于synchronized锁,只能有一个线程可以执行后面实例的创建过程,若是没有第二个instance的判断,则在第一个线程创建实例对象后,后续线程将会再次创建对象,因此此时还需要判断instance是否已经被创建。
静态内部类
1 | public class StaticSingleton { |
这里需要提一下为什么静态内部类是线程安全的,其原因在于:
- 只有在访问静态内部类的静态变量方法时,静态内部类才开始加载。
- 虚拟机会保证一个类的构造器
()方法在多线程环境下被正确地加载,同步,如果多个线程同时初始化一个类,只有一个线程会执行这个类的构造器 ()方法,其他线程都需要阻塞等待,直到活动线程执行 ()方法完毕。如果在一个类的 ()方法中有耗时很长的操作,就可能造成多个进程阻塞(需要注意的是,其他线程虽然会被阻塞,但如果执行 ()方法后,其他线程唤醒之后不会再次进入 ()方法。同一个加载器下,一个类型只会初始化一次。)
枚举
1 | public enum EnumSingleton { |
相比于其他方式来说,枚举式单例模式更加简洁。
方法对比
- 饿汉式(线程安全,调用效率高,不能够延时加载)
- 懒汉式(线程安全,调用效率不高,可以延时加载)
- 双重检测锁(由于JVM底层原因,偶尔会出问题)
- 静态内部类(线程安全,调用效率高,可以延时加载)
- 枚举(线程安全,调用效率高,不能延时加载,天然地防止反射和反序列化)
单例对象占用资源小,不需要延时加载:枚举好于饿汉单例。
对象占用资源大,需要延时加载:静态内部类好于懒汉。
模式分析
单例模式的目的是保证一个类仅有一个实例,并提供一个访问它的全局访问点。单例模式包含的角色只有一个,就是单例类——Singleton。单例类拥有一个私有构造函数,确保用户无法通过new关键字直接实例化它。除此之外,该模式中包含一个静态私有成员变量与静态公有的工厂方法,该工厂方法负责检验实例的存在性并实例化自己,然后存储在静态成员变量中,以确保只有一个实例被创建。
在单例模式的实现过程中,需要注意如下三点:
- 单例类的构造函数为私有;
- 提供一个自身的静态私有成员变量;
- 提供一个公有的静态工厂方法。
模式优点
- 提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例,所以它可以严格控制客户怎样以及何时访问它,并为设计及开发团队提供了共享的概念。
- 由于在系统内存中只存在一个对象,因此可以节约系统资源,对于一些需要频繁创建和销毁的对象,单例模式无疑可以提高系统的性能。
- 允许可变数目的实例。我们可以基于单例模式进行扩展,使用与单例控制相似的方法来获得指定个数的对象实例。
模式缺点
- 由于单例模式中没有抽象层,因此单例类的扩展有很大的困难。
- 单例类的职责过重,在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色,提供了工厂方法,同时又充当了产品角色,包含一些业务方法,将产品的创建和产品的本身的功能融合到一起。
- 滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术,因此,如果实例化的对象长时间不被利用,系统会认为它是垃圾,会自动销毁并回收资源,下次利用时又将重新实例化,这将导致对象状态的丢失。
适用环境
在以下情况下可以使用单例模式:
- 系统只需要一个实例对象,如系统要求提供一个唯一的序列号生成器,或者需要考虑资源消耗太大而只允许创建一个对象。
- 客户调用类的单个实例只允许使用一个公共访问点,除了该公共访问点,不能通过其他途径访问该实例。
- 在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来,如果一个类可以有几个实例共存,就需要对单例模式进行改进,使之成为多例模式
总结
- 单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法。单例模式的要点有三个:一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。
- 单例模式只包含一个单例角色:在单例类的内部实现只生成一个实例,同时它提供一个静态的工厂方法,让客户可以使用它的唯一实例;为了防止在外部对其实例化,将其构造函数设计为私有。
- 单例模式的目的是保证一个类仅有一个实例,并提供一个访问它的全局访问点。单例类拥有一个私有构造函数,确保用户无法通过new关键字直接实例化它。除此之外,该模式中包含一个静态私有成员变量与静态公有的工厂方法。该工厂方法负责检验实例的存在性并实例化自己,然后存储在静态成员变量中,以确保只有一个实例被创建。
- 单例模式的主要优点在于提供了对唯一实例的受控访问并可以节约系统资源;其主要缺点在于因为缺少抽象层而难以扩展,且单例类职责过重。
- 单例模式适用情况包括:系统只需要一个实例对象;客户调用类的单个实例只允许使用一个公共访问点。