:::tips 本质上, 单例模式就是整个系统下只能有一个实例

:::

为什么要使用单例?

单例设计模式(Singleton Design Pattern), 一个类只允许创建一个对象(或者实例), 这种设计模式就叫做单例模式

饿汉式

创建时,就进行初始化

type singleton struct{}
var ins *singleton = &singleton{}
func GetIns() *singleton{
    return ins
}

这种方法是 线程安全 的,因为一开始就只会创建一份
缺点是不能支持延迟加载, 启动时间加长 ,可能会持续占用部分内存

懒汉式

被调用时,如果没有初始化才进行初始化

type singleton struct{}
var ins *singleton
func GetIns() *singleton{
    if ins == nil {
    　　ins = &singleton{}
    }
    return ins
}

这种方法 线程不安全 写的时候一定要注意并发问题
支持延迟加载, 但是也不见得好, 如果处理时间很长, 中途卡顿体验更差

golang中的单例并发问题

隐藏的梦魇 - 并发下的单例错误

由于golang 的并发很容易实现, 所以很容易产生一些并发不安全的代码, 比如

package singleton
type singleton struct {}
var instance *singleton
func GetInstance() *singleton {
    if instance == nil {
        instance = &singleton{}   // 不是并发安全的
    }
    return instance
}

这里看似进行了检查, 但是在并发下, instance 是有可能被多次创建, 导致覆盖的
如果有代码保留了 instance 的不同实例, 会产生潜在的不同代码行为,很容易产生难以调试的bug, 而且debug的时候打上断点,反而调试不出问题, 绝对会抓狂

猪突猛进 - 加锁下的性能问题

应对并发问题, 我们最容易想到的就是 加锁 然鹅加锁会带来严重的性能问题

var mu Sync.Mutex
func GetInstance() *singleton {
    mu.Lock()                    // 如果实例存在没有必要加锁
    defer mu.Unlock()
    if instance == nil {
        instance = &singleton{}
    }
    return instance
}

我们引入了 Sync.Mutex 来保证 instance 只有一个实例, 虽然这完成了我们的目的, 然而这样做却给高并发下埋下了不小的性能隐患
加锁本身没有问题, 问题在于每一个 goroutine 来获取 instance 时都会有一次锁操作, 并且一次只能有一个 goroutine 获取得到 instance ,这是一个非常大的性能隐患, 在高并发的场景下必然会产生性能问题

双重保险 - Check-Lock-Check模式

在C++和其他语言中, 确保最少的锁定并且仍然是并发安全的最佳和最安全的方法是在获取锁定时利用 Check-Lock-Check

if check(){
    lock(){
        if check(){
            // 执行加锁的安全代码
        }
    }
}

首先进行检查,在执行锁操作, 这样在实例化之后, 就不会产生重复加锁的问题, if 语句的消耗远小于 加锁
但是加锁前也有可能其他人也拿到锁, 所以还需要在内部再检查一次, 避免覆盖问题

func GetInstance() *singleton {
    if instance == nil {     // 不太完美 因为这里不是完全原子的, 并发上来依然会出问题
        mu.Lock()
        defer mu.Unlock()
        if instance == nil {
            instance = &singleton{}
        }
    }
    return instance
}

通过 sync/atomic 的进行原子操作

import "sync"
import "sync/atomic"
var initialized uint32
... // 此处省略
func GetInstance() *singleton {
    if atomic.LoadUInt32(&initialized) == 1 {  // 原子操作 
            return instance
      }
    mu.Lock()
    defer mu.Unlock()
    if initialized == 0 {
         instance = &singleton{}
         atomic.StoreUint32(&initialized, 1)
    }
    return instance
}

但是,这样还是有点繁琐了, 每次都这样写还是很烦

不行我就是要偷懒 - 官方实现

这种常用的功能怎么能不封装, 官方在 sync 中已经做了封装, 看下源码吧(部分注释有删改)

// Once is an object that will perform exactly one action.
type Once struct {
    // done indicates whether the action has been performed.
    // It is first in the struct because it is used in the hot path.
    // The hot path is inlined at every call site.
    // Placing done first allows more compact instructions on some architectures (amd64/x86),
    // and fewer instructions (to calculate offset) on other architectures.
    done uint32
    m    Mutex
}
func (o *Once) Do(f func()) {
    if atomic.LoadUint32(&o.done) == 0 { // check
        // Outlined slow-path to allow inlining of the fast-path.
        o.doSlow(f)
    }
}
func (o *Once) doSlow(f func()) {
    o.m.Lock()                          // lock
    defer o.m.Unlock()
    if o.done == 0 {                    // check
        defer atomic.StoreUint32(&o.done, 1)
        f()
    }
}

实现就是上面 check-lock-check 加 atomic 的写法, 封装成了一个模块而已

于是我们可以这样来写

package singleton
import (
    "sync"
)
type singleton struct {}
var instance *singleton
var once sync.Once
func GetInstance() *singleton {
    once.Do(func() {
        instance = &singleton{}
    })
    return instance
}

C#中的单例并发问题

和golang相同, C#也会和golang一样遇到并发问题

涛声依旧 - 并发错误创建出多个实例

using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace DesignPattern {
  class DoMain{
    static void Main (string[] args) {
      try {
        TaskFactory taskFactory = new TaskFactory();
        List<Task> taskList = new List<Task>();
        for (int i = 0; i < 5; i++) {
          taskList.Add(taskFactory.StartNew(() => {
            Singleton singleton = Singleton.CreateInstance();
          }));
        }
      } finally {
      }
      Console.ReadKey();
    }
  }
  class Singleton {
    private static Singleton singleton;
    private Singleton () {}
    public static Singleton CreateInstance () {
      if (singleton == null) {
        Console.WriteLine("创建");
        singleton = new Singleton();
      }
      return singleton;
    }
  }
}

23种设计模式 -- 单例模式 - 图1

该有的问题还是有, 加锁也会产生效率上的问题
所以依然是采用 check-lock-check 是最佳实践

宝刀未老 - Check-Lock-Check模式

修改为 check-lock-check

...
    public static Singleton CreateInstance () {
      if (singleton == null) {
        lock (singleton_lock) {
          if (singleton == null) {
            Console.WriteLine("创建");
            singleton = new Singleton();
          }
        }
      }
      return singleton;
    }
...

23种设计模式 -- 单例模式 - 图2

我就是超级懒 - 官方实现

惰性初始化关键字 lazy 可以惰性初始化, 如果想直接初始化, 用静态变量即可

  public sealed class Singleton {
    private Singleton () {
    }
    ////private static readonly Singleton singleInstance = new Singleton();
    private static readonly Lazy<Singleton> Instancelock = new Lazy<Singleton>(() => new Singleton());
    public static Singleton GetSingleton {
      get {
        return Instancelock.Value;
      }
    }
  }

单例模式之殇 - 为什么不推荐使用单例模式

对OOP的各种特性支持不友好

违背了基于接口而不是实现的原则

public class Order {
  public void create(...) {
    //...
    long id = IdGenerator.getInstance().getId();
    //...
  }
}
public class User {
  public void create(...) {
    // ...
    long id = IdGenerator.getInstance().getId();
    //...
  }
}

这里依赖了实现, 如果有一天要 User和Order的id生成方法变了, 那么所有的地方都需要进行改动

:::info 另外, 单例对继承,多态支持也不友好, 虽然并非不能实现, 但是单例的继承,多态实现起来会非常奇怪, 导致代码可读性变差, 不明白设计意图的人, 很那看懂这样的设计

所以, 一旦选择了单例类, 也就意味着你放弃了继承和多态这两个强有力的OOP特性, 也就损失了应对未来需求变化的扩展性

:::

隐藏了类之间的依赖关系

代码的可读性非常重要, 阅读代码的时候, 我们希望一眼就能看出类与类之间的依赖关系, 搞清楚这个类依赖了哪些外部类

通过构造函数, 参数传递等方式声明类之间的依赖关系, 我们通过查看函数定义, 就能很容易识别. 但是单例类不需要显示创建, 不需要参数传递, 直接就可以调用. 如果代码比较复杂, 这种调用关系会非常隐蔽, 阅读代码的时候, 就必须查看每个函数的代码实现, 才能知道这个类到底依赖了哪些单例类

单例模式对扩展性不友好

单例类只能有一个对象实例, 如果有一天, 我们需要在代码中创建一个以上的实例, 那么代码就需要有比较大的改动

单例模式对代码的可测试行不友好

单例模式会影响代码的可测试性, 如果单例类依赖比较中的外部资源, 比如DB, 我们在写单元测试的时候, 希望通过mock的方式替换掉,而单例类这种硬编码的方式,导致无法实现mock替换

单例不支持有参数的构造函数

但这个缺点可以通过配置文件的方式克服