【Go实现】设计模式：01-创建型-单例模式

单例模式

模式定义

单例模式（Singleton Pattern）是一种创建型设计模式，它保证一个类只有一个实例，并提供一个全局访问点。单例模式常用于需要共享资源或控制资源访问的场景，例如线程池、全局缓存、对象池等，这种场景下就适合使用单例模式。

Ensure a class only has one instance, and provide a global point of access to it.

但是，并非所有全局唯一的场景都适合使用单例模式。比如，考虑需要统计一个API调用的情况，有两个指标，成功调用次数和失败调用次数。这两个指标都是全局唯一的，所以有人可能会将其建模成两个单例SuccessApiMetric和FailApiMetric。按照这个思路，随着指标数量的增多，你会发现代码里类的定义会越来越多，也越来越臃肿。这也是单例模式最常见的误用场景，更好的方法是将两个指标设计成一个对象ApiMetric下的两个实例ApiMetic success和ApiMetic fail。

如何判断一个对象是否应该被建模成单例？

通常，被建模成单例的对象都有“中心点”的含义，比如线程池就是管理所有线程的中心。所以，在判断一个对象是否适合单例模式时，先思考下，这个对象是一个中心点吗？

模式结构

@startuml

class Singleton {
    - instance: Singleton
    - Singleton()
    + getInstance(): Singleton
}


Singleton -->  Singleton : create

@enduml

代码实现

有一些错误是很常见的，比如不考虑并发安全的单例模式。就像下面的示例代码：

package singleton

type singleton struct {
   }

var instance *singleton

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

在上述情况下，多个goroutine可以执行第一个检查，并且它们都将创建该singleton类型的实例并相互覆盖。无法保证它将在此处返回哪个实例，并且对该实例的其他进一步操作可能与开发人员的期望不一致。

不好的原因是，如果有代码保留了对该单例实例的引用，则可能存在具有不同状态的该类型的多个实例，从而产生潜在的不同代码行为。这也成为调试过程中的一个噩梦，并且很难发现该错误，因为在调试时，由于运行时暂停而没有出现任何错误，这使非并发安全执行的可能性降到了最低，并且很容易隐藏开发人员的问题。

激进的加锁

也有很多对这种并发安全问题的糟糕解决方案。使用下面的代码确实能解决并发安全问题，但会带来其他潜在的严重问题，通过加锁把对该函数的并发调用变成了串行。

var mu Sync.Mutex

func GetInstance() *singleton {
   
    mu.Lock