三言两语说透设计模式的艺术-单例模式

写在前面

单例模式是一种常用的软件设计模式，它所创建的对象只有一个实例，且该实例易于被外界访问。单例对象由于只有一个实例，所以它可以方便地被系统中的其他对象共享，从而减少系统中的资源开销。

单例模式

单例模式的实现思路是：

(资料图片仅供参考)

构造函数需要被私有化，外部无法直接通过new来创建对象实例。提供一个静态的公有访问点，用于获取单例对象的实例。通过判断实例是否已经存在来决定创建或直接返回现有实例。

单例模式的要点：

某个类只能有一个实例它必须自行创建实例它必须自行向整个系统提供整个实例

我们来看一下使用TypeScript实现单例模式的代码示例:

class Singleton {  // 私有静态属性，存储唯一实例  private static instance: Singleton;  // 私有构造函数，防止外部实例化  private constructor() {}  // 向外部提供能够共享访问的唯一实例  public static getInstance(): Singleton {    if (!Singleton.instance) {      Singleton.instance = new Singleton();    }    return Singleton.instance;  }  // 其他方法和属性}const s1 = Singleton.getInstance(); const s2 = Singleton.getInstance();console.log(s1 === s2); // true

上面代码中，Singleton类的构造函数被private修饰，使其无法在类的外部通过new来创建实例。

getInstance方法首先会判断实例是否存在，如果不存在才去新建实例，如果实例已存在则直接返回现有实例。这确保了整个程序中只会创建该类的一个实例。

测试代码中，s1和s2实际上是获取的是同一个实例对象。

图片

单例模式的优点:

对唯一实例的受控访问。由于单例对象存放在静态变量中，所以可以直接通过类名访问，简单方便。可以避免对资源的重复占用。

单例模式的缺点:

没有抽象层，扩展困难。单例类的职责过重，违反单一职责原则。没有接口，依赖具体实现，导致扩展性差。

Singleton单例：在单例类的内部实现只生成一个实例，同时提供一个静态方法getInstance()方法，让用户可以访问它的唯一实例；为了防止在外部对单例类实例化，它的构造函数可见性为private；在单例类内部定义了一个Singleton类型的静态属性instance，作为提供给外部共享访问的唯一实例。

饿汉式单例类

饿汉式单例类：当类被加载时，静态属性instance会被初始化，此时类的私有构造函数会被调用，单例类的唯一实例将会被创建。

普通单例模式和饿汉式单例模式的区别:

普通单例模式是在第一次调用getInstance方法时才创建实例对象。饿汉式是无论是否调用都会在类加载时就创建实例对象。

下面我们使用TypeScript代码实现一个饿汉式单例：

class Singleton {  private static instance = new Singleton();    private constructor() {}  public static getInstance() {    return Singleton.instance;  }}const s1 = Singleton.getInstance();const s2 = Singleton.getInstance(); console.log(s1 === s2); // true

饿汉式单例由于在类加载时就完成了初始化，所以理论上它是线程安全的，在多线程环境下也能保证单例。

但饿汉式也有可能造成不必要的实例化，如果这个单例的实例对象较大，而客户端又没调用getInstance方法，那就会浪费内存。

懒汉式单例模式

其实懒汉式单例模式，就是前面提到的普通单例模式。

懒汉式单例模式实现代码如下：

class Singleton {  private static instance: Singleton;  private constructor() {}  public static getInstance(): Singleton {    if (!Singleton.instance) {      Singleton.instance = new Singleton();    }    return Singleton.instance;   }}

但是，这种实现方式存在一个问题，就是在多线程环境下会存在安全隐患。

如果有两个线程A和B，它们同时调用getInstance方法，并且实例还没有被初始化，那么它们会同时执行Singleton.instance = new Singleton();这行代码。

这样就会导致实际创建了两个实例，违反了单例模式的初衷。

为了使懒汉式单例在多线程中也是安全的，我们可以对getInstance方法加锁:

class Singleton {  private static instance: Singleton;  private constructor() {}  public static getInstance(): Singleton {    if (!Singleton.instance) {      // 加锁      lock()        if (!Singleton.instance) {        Singleton.instance = new Singleton();      }      // 释放锁       unlock()    }    return Singleton.instance;  }}

这样当一个线程进入该方法时，其它线程就只能等待，直到锁被释放后才能进入方法。

这就确保了单例实例的唯一性。这里的锁机制可以使用互斥量mutex等各种锁的实现。

以上是关于懒汉式单例线程安全性问题的一个补充说明。让我们的单例模式实现更加健壮。

饿汉式单例与懒汉式单例类比较实例化时机不同懒汉式是在第一次调用getInstance时才实例化Singleton对象饿汉式是在类加载时就实例化了Singleton对象资源利用效率不同懒汉式更节约资源，按需实例化，如果一直没有调用getInstance也不会实例化饿汉式不管是否需要都会实例化，如果长时间没有使用就会浪费内存多线程安全性不同饿汉式天然是多线程安全的，因为实例在类加载时就已经创建好了懒汉式需要额外的同步机制来保证多线程安全使用场景不同懒汉式更适合实例化过程比较耗时或耗资源的情况饿汉式更适合实例化过程很快且确定会用到的情况

懒汉式相比饿汉式更加灵活，但需要处理多线程安全问题。饿汉式编写简单但不太高效。

在实际开发中，我们可以根据需求选择合适的实现方式，也可以采用双重校验锁等线程安全的懒汉式实现。

一种更好的单例实现方式

饿汉式单例类不能实现延迟加载，不管将来用不用，它始终占据内存；懒汉式单例类线程安全控制繁琐，而且性能收到影响。对此，无论是饿汉式单例还是懒汉式单例都在一些问题，使用IoDH（Initialization on Demand Holder）可以结合两者的优点，克服两者的缺点实现性能和实现更优的单例模式。

IoDH是一种技术方案，它利用了类的静态属性来实现延迟加载和线程安全。要实现IoDH，只需在但李磊中增加静态内部类即可，在该内部类中创建单例对象，再将该单例对象通过getInstance()方法返回给外部使用。

// 单例服务接口interface SingletonService {  doSomething(): void; }// 单例服务类class SingletonServiceImpl implements SingletonService {  doSomething() {    console.log("Doing something...");  }}// IoC容器类class IoCContainer {  private singleton: SingletonService;  constructor() {    this.singleton = new SingletonServiceImpl();  }  getSingleton(): SingletonService {    return this.singleton;  }}// 测试代码const container = new IoCContainer();const s1 = container.getSingleton();const s2 = container.getSingleton();console.log(s1 === s2); // true

详细解析一下使用IoC容器实现单例模式的代码:

定义了单例服务接口SingletonService，用于规范单例对象的操作。SingletonServiceImpl实现了该接口，作为单例对象的具体实现类。IoC容器类IoCContainer在内部持有SingletonService类型的成员变量singleton。IoC容器类的构造函数中会实例化这个singleton对象，确保全局只有这一个实例。getSingleton()方法用来返回这个singleton实例。在测试代码中，从IoC容器中获取了两次单例对象，并比较它们的引用是否相同。运行结果证明两次获取的确是同一个对象引用，即单例。

这样通过IoC容器管理单例的创建，可以实现:

把单例对象的创建和生命周期管理转移到IoC容器。外部代码不需要关心单例内部的具体实现，只需要从容器中获取实例即可。符合单一职责原则，程序逻辑更清晰。有利于代码的可测试性，可以通过mock容器进行单元测试。扩展性较好，如果要切换不同的单例实现，只需要调整容器中的对象创建即可。总结

单例模式作为一种设计模式，由于具有明确的目的、简单的结构和易于理解的特点，在软件开发中使用频率很高，在许多应用程序和框架中都有广泛应用。

单例模式的主要优点包括：提供对唯一实例的受控访问，由于全局只存在一个实例，因此可以节约系统资源;允许扩展为可变数量的实例，既节约资源又解决过度共享影响性能的问题。单例模式的主要缺点包括：没有抽象层导致扩展性差；违反单一职责原则，将实例化和业务逻辑混合在一起；在支持垃圾回收的运行时环境下可能导致状态丢失。使用单例模式的典型场景包括：系统只需要一个实例；客户只能通过一个公共访问点获取实例;需要节约资源的频繁创建销毁对象。

总之，单例模式是一种利用率较高的设计模式，其限制实例个数的特点可以带来节省资源的优势，但也可能导致扩展性较弱以及与语言环境不够匹配等问题。在软件设计中，开发者需要权衡考虑系统的需求和优缺点，适当使用单例模式。

关键词：