go语言实现设计模式—单例模式
go语言实现设计模式—单例模式
- 1 背景
- 2 什么是单例
- 3 为什么使用单例
-
- 3.1 资源访问冲突问题
- 3.2 解决方式
- 3.3 应用场景
- 3.4 设计思考
- 4 如何创建单例
-
- 4.1 饿汉式-线程安全
- 4.2 懒汉式-非线程安全
- 4.3 懒汉式-线程安全
- 4.4 双重检查
- 4.5 once写法：推荐采用
- 5 采用Once实现单例模式
- 6 其他
-
- 6.1 借鉴
- 6.2 思考
- 参考资料
1 背景
在研读业务代码时，我发现自定义类型会以“懒汉式-非线程安全”和“饿汉式”进行实例化，因此对单例模式产生兴趣，它是什么？原理是怎样的？解决了什么样的问题？应用场景如何？优缺点是什么？
2 什么是单例
单例设计模式（Singleton Design Pattern）： 一个类只允许创建一个对象（或者实例），那这个类就是一个单例类，这种设计模式就叫作单例设计模式，简称单例模式。
单例模式是最简单的设计模式之一，它提供了创建对象的最佳方式。
这种模式涉及到一个单一的结构体，该结构体负责创建自己的对象，同时确保只有单个对象被创建。即多次创建一个结构体的对象，得到的对象的存储地址永远与第一次创建对象的存储地址相同。
3 为什么使用单例
3.1 资源访问冲突问题
goroutine1:
{
file1 = new(File)
file1.write("abc")
}
goroutine2:
{
file2 = new(File)
file2.write("defh")
}
多协程对同一文件的实例进行写操作时，就有可能存在写入的数据互相覆盖的情况。
3.2 解决方式
- 1 加锁，同一个文件的所有实例共享一把锁
- 2 分布式锁，但实现安全可靠、无 bug、高性能较难
- 3 并发队列，多个线程同时往并发队列写数据，一个单独线程将并发队列中的数据写入文件
- 4 单例模式 ：
- 不用创建那么多实例，节省内存空间，
- 节省系统文件句柄（对于操作系统来说，文件句柄也是一种资源）
3.3 应用场景
从业务概念上，如果有些数据在系统中只应保存一份，那就比较适合设计为单例类。
1.需要频繁实例化然后销毁的对象。
2.创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
3.有状态的工具类对象。
4.频繁访问数据库或文件的对象。
- 配置信息类：在系统中，我们只有一个配置文件，当配置文件被加载到内存之后，以对象的形式存在，也理所应当只有一份。
- 日志应用：共享的日志文件一直处于打开状态，因为只能有一个实例去操作。
- 数据库连接池：用单例模式来维护频繁打开或者关闭数据库连接所引起的效率损耗
- 多线程的线程池：采用单例模式对池中的线程进行控制。
- 操作系统的文件系统：一个操作系统只能有一个文件系统，也是单例模式实现的例子
3.4 设计思考
- 考虑对象创建时的线程安全问题
- 考虑是否支持延迟加载
- 考虑 getInstance() 性能是否高（是否加锁）
4 如何创建单例
单例模式是最简单的设计模式之一，它提供了创建对象的最佳方式。
这种模式涉及到一个单一的结构体，该结构体负责创建自己的对象，同时确保只有单个对象被创建。即多次创建一个结构体的对象，得到的对象的存储地址永远与第一次创建对象的存储地址相同。
4.1 饿汉式-线程安全
直接创建对象，线程安全。
缺点
- 在导入包/init的同时会创建该对象，并持续占有在内存中。
- 这样的实现方式不支持延迟加载（在真正用到再创建实例）
package singleton
type School struct{}
var (
instance *School
)
func init(){
instance = new(School)
}
func GetInstance() *School {
return instance
}
4.2 懒汉式-非线程安全
优点是支持延迟加载
缺点是通过懒汉式-非线程安全方式创建单例，在并发下可能会多次创建
package singleton
type School struct{}
var (
instance *School
)
func GetInstance() *School {
if instance == nil {
instance = new(School)
}
return instance
}
4.3 懒汉式-线程安全
在非线程安全的基础上，利用Sync.Mutex进行加锁,保证线程安全，
但由于每次调用该方法都进行了加锁操作，在性能上相对不高效
package singleton
type School struct {}
var (
instance *School
lock *sync.Mutex = &sync.Mutex{}
)
func GetInstance() *School {
lock.Lock()
defer lock.Unlock()
if instance == nil {
instance = new(School)
}
return instance
}
4.4 双重检查
在懒汉式（线程安全）的基础上再进行忧化，通过判断来减少加锁的操作。保证线程安全同时不影响性能。这种实现方式解决了懒汉式并发度低的问题。
设计思路：第一次判断不加锁，第二次加锁保证线程安全，一旦对象建立后,获取对象就不用加锁了
package singleton
var (
instance *School
lock sync.Mutex
)
func GetInstance() *School {
if instance == nil {
lock.Lock() //第一次判断不加锁，第二次加锁保证线程安全，一旦对象建立后,获取对象就不用加锁了
if instance == nil {
instance = new(School)
}
lock.Unlock()
}
return instance
}
4.5 once写法：推荐采用
利用 sync.Once 方法Do，确保Do中的方法只被执行一次的特性，创建单个结构体实例。
使用Do方法也巧妙的保证了并发线程安全。
package singleton
var (
instance *School
once sync.Once
)
func GetInstance() *School {
once.Do(func() {
instance = new(School)
})
return instance
}
其中Once源码利用atomic操作实现f函数只执行一次
- 进行加锁，再做一次判断，如果没有执行，则进行标志已经执行并调用该方法
- 判断是否执行过该方法，如果执行过则不执行
func (o *Once) Do(f func()) {
if atomic.LoadUint32(&o.done) == 1 { 判断是否执行过该方法，如果执行过则不执行
return
}
// Slow-path.
o.m.Lock()
defer o.m.Unlock() 进行加锁，再做一次判断，如果没有执行，则进行标志已经执行并调用该方法
if o.done == 0 {
defer atomic.StoreUint32(&o.done, 1)
f()
}
}
5 采用Once实现单例模式
package main
import (
"fmt"
"strconv"
"sync"
)
type School struct {
name string
id int
}
var (
instance *School
once sync.Once
wg sync.WaitGroup
)
func GetInstance(name string, id int) *School {
once.Do(func() {
fmt.Println("------------init-----------")
instance = new(School)
})
instance.name = name
instance.id = id
return instance
}
func main() {
for i := 0; i < 10; i++ {
wg.Add(1)
go func(seq int) {
defer wg.Done()
instance = GetInstance("xiaobai"+strconv.Itoa(seq), 25)
fmt.Printf("gonum: %s, address: %p, name: %s, id: %d\n",
strconv.Itoa(seq), instance, instance.name, instance.id)
}(i)
}
wg.Wait()
fmt.Println("end!")
}
运行结果
6 其他
6.1 借鉴
本文go设计模式实现单例模式，借鉴于Java设计模式，存在未考虑完善的地方：
- Java中单例模式会存在指令重排序问题
- 懒汉式还是饿汉式更好需要看具体的场景。对于那些短生命周期的应用，如客户端应用来说，启动是频繁发生的，如果启动时导致了一堆饿汉初始化，会给用户带来不好的体验，如果把初始化往后延，将初始化分散在未来的各个时间点，即使某个懒汉初始化时间较长，用户也几乎无感知。而对于生命周期较长的应用，长痛不如短痛，启动时耗点时，保证后面的使用流畅也是可取的。
- 对于单例存在的其他问题，比如对 OOP 特性、扩展性、可测性不友好等问题，还是无法解决。所以，如果要完全解决这些问题，可能要从根上，寻找其他方式来实现全局唯一。实际上，实例的全局唯一性可以通过多种不同的方式来保证。我们既可以通过单例模式来强制保证，也可以通过工厂模式、IOC 容器（比如 Spring IOC 容器）来保证，还可以通过程序员自己来保证（自己在编写代码的时候自己保证不要创建两个类对象）。
- 如果单例类并没有后续扩展的需求，并且不依赖外部系统，那设计成单例类就没有太大问题。对于一些全局的类，与其在其他地方 new ，还要在类之间传来传去，不如直接做成单例类，使用起来简洁方便。
6.2 思考
- 如何理解单例模式中的唯一性？
- 如何实现线程唯一的单例？
- 如何实现集群环境下的单例？
- 如何实现一个多例模式？
参考资料
1 https://time.geekbang.org/column/article/194035
2 https://blog.csdn.net/TCatTime/article/details/106882600
3 https://blog.csdn.net/qq_37703616/article/details/81989889
4 https://github.com/tmrts/go-patterns/blob/master/creational/singleton.md