写在前面
单例模式是一种常用的软件设计模式，它所创建的对象只有一个实例，且该实例易于被外界访问。单例对象由于只有一个实例，所以它可以方便地被系统中的其他对象共享，从而减少系统中的资源开销。
单例模式
单例模式的实现思路是：
- 构造函数需要被私有化，外部无法直接通过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容器进行单元测试。
- 扩展性较好，如果要切换不同的单例实现，只需要调整容器中的对象创建即可。
总结
单例模式作为一种设计模式，由于具有明确的目的、简单的结构和易于理解的特点，在软件开发中使用频率很高，在许多应用程序和框架中都有广泛应用。
- 单例模式的主要优点包括：提供对唯一实例的受控访问，由于全局只存在一个实例，因此可以节约系统资源;允许扩展为可变数量的实例，既节约资源又解决过度共享影响性能的问题。
- 单例模式的主要缺点包括：没有抽象层导致扩展性差；违反单一职责原则，将实例化和业务逻辑混合在一起；在支持垃圾回收的运行时环境下可能导致状态丢失。
- 使用单例模式的典型场景包括：系统只需要一个实例；客户只能通过一个公共访问点获取实例;需要节约资源的频繁创建销毁对象。
总之，单例模式是一种利用率较高的设计模式，其限制实例个数的特点可以带来节省资源的优势，但也可能导致扩展性较弱以及与语言环境不够匹配等问题。在软件设计中，开发者需要权衡考虑系统的需求和优缺点，适当使用单例模式。
