共计 2721 个字符，预计需要花费 7 分钟才能阅读完成。
前言
在咱们开发过程中常常会应用到单例模式这一经典的设计模式，单例模式能够帮忙开发者针对某个（些）变量或者对象或者函数（办法）进行在程序运行期间只有一次的初始化或者函数调用操作，比方在开发我的项目中针对某一类连接池的初始化（如数据库连接池等）。针对这种状况，咱们就须要应用单例模式进行操作。
单例模式🌰
本人搞得单例模式
要实现一个单例模式，咱们会很快就想到了在一个构造体中搁置一个 flag 字段用于标记以后的函数是否被执行过，举个🌰：
`type SingletonPattern struct {`
`done bool`
`}`
`func (receiver *SingletonPattern) Do(f func()) {`
`if !receiver.done {`
`f()`
`receiver.done=true`
`}`
`}`
看似很美妙，然而此时，如果传入的须要调用的函数 f() 会执行很长时间，比方数据库查问或者做一些连贯什么的，当别的 goroutine 运行到此处的时候因为还没有执行完 f()，就会发现done 标记依然是false，那么依然会调用一次f()，此时就违反了单例模式的初衷。
那么如何解决下面的并发的问题呢。此时就能够应用 go 规范库中所提供的并发原语 —sync.Once
规范库真香系列之sync.Once
话不多说先上sync.Once 构造体的源代码：
`type Once struct {`
`// 标记符号，用于标记是否执行过 `
`done uint32`
`// 互斥锁，用于爱护并发调用以及避免 copy`
`m Mutex`
`}`
构造体就这么简略，字段 done 用于标记是否执行过函数，至于为什么应用 uint32 类型，作者的了解是为了之后应用 atomic 操作做的斗争，m字段值用于爱护并发状况下的情景，并且因为继承了 Locker 接口能够通过 vet 校验到其是否被复制
接下来看一下用于执行函数调用的 Do() 函数的实现：
`func (o *Once) Do(f func()) {`
`// 原子获取以后 done 字段是否等于 0`
`// 如果以后字段等于 1`
`// 则代表曾经 执行过 `
`// 这是第一层校验 `
`if atomic.LoadUint32(&o.done) == 0 {`
`// 如果为 0 则代表没被调用过则调用 `
`// 此处写成一个函数的起因是为了 `
`// 进行函数内联晋升性能 `
`o.doSlow(f)`
`}`
`}`
`func (o *Once) doSlow(f func()) {`
`// 此处加锁用于避免其余 goroutine 同时拜访调用 `
`o.m.Lock()`
`defer o.m.Unlock()`
`// 二次校验 `
`// 为的是避免多个 goroutine 进入此函数的时候，可能产生的反复执行 f()`
`if o.done == 0 {`
`// 函数执行完结设置 done 字段为 1 代表曾经执行结束 `
`defer atomic.StoreUint32(&o.done, 1)`
`// 执行 `
`f()`
`}`
`}`
此时，sync.Once 的所有源代码曾经解析结束了（惊不惊喜，意不意外），其实sync.Once 的过程很简略，就是依据标记进行双重判断确定函数是否执行过，没执行就执行，执行了就跳过。
sync.Once 的应用问题
哪来的 deadlock？
sync.Once 确实很简略，应用也很简略，然而还是会有应用上可能呈现的一些问题比方下列代码：
`func main() {`
`var once sync.Once`
`once.Do(`
`func() {`
`fmt.Println("one once do")`
`once.Do(`
`func() {`
`fmt.Println("second once do")`
`})`
`})`
`}`
该代码会呈现什么问题？答案是：
fatal error: all goroutines are asleep – deadlock!
为什么会这样？因为内层个 Do 是被外层的同一个 once 对象所调用，因为此时曾经进入了第一个 Do 并且曾经调用了函数，那么此时sync.Once 中的互斥锁字段，曾经被加了锁，此时二次加锁就会产生死锁。因而应用sync.Once 最重要的一点就是：*
不要在执行函数中，嵌套以后的
sync.Once对象 不要在执行函数中，嵌套以后的sync.Once对象 不要在执行函数中，嵌套以后的sync.Once对象。（重要的话要说三遍）
哪来的 invalid memory address or nil pointer dereference？
看一下上面的代码：
`func main() {`
`var once sync.Once`
`var conn net.Conn`
`once.Do(`
`func() {`
`var err error`
`conn, err = net.Dial("tcp", "")`
`if err != nil {`
`return`
`}`
`})`
`conn.RemoteAddr()`
`}`
在运行时，会呈现：
panic: runtime error: invalid memory address or nil pointer dereference
为什么？因为 sync.Once 只保障执行一次，然而不保障执行是否出错 ，即 我只管调用，出错了跟我无关，上述代码中
`conn, err = net.Dial("tcp", "")`
必然呈现 err!=nil 的状况，此时如果不对 conn 变量进行判断为nil，就会呈现空指针异样，那么，如何来保障他执行胜利了呢，咱们须要对其进行革新
`type Once struct {`
`once sync.Once`
`}`
`func (receiver *Once) OnceDo(f func() error) error {`
`var err error`
`receiver.once.Do(`
`func() {`
`err = f()`
`})`
`return err`
`}`
`func main() {`
`var once Once`
`var conn net.Conn`
`err := once.OnceDo(`
`func() error {`
`var err error`
`conn, err = net.Dial("tcp", "")`
`if err != nil {`
`return err`
`}`
`return nil`
`})`
`if err != nil {`
`log.Fatal(err)`
`}`
`}`
通过封装，咱们就能够失去sync.Once 执行时是否出错，以适配各种错误处理。
此封装可能会有更好的解决方案，下面的计划也仅仅是一个🌰罢了。
总结
至此sync.Once 的用法以及源码解析就实现了，可能有些中央有些了解上的谬误，请各位体谅并且帮忙指出修改意见，如果这篇文章能帮到你，这是我的荣幸。