大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
之前在协调多个goroutine的时候,使用了通道。基本都是按下面这样来使用的:
我们提供的服务有:成都做网站、网站设计、微信公众号开发、网站优化、网站认证、浦口ssl等。为数千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务,是有科学管理、有技术的浦口网站制作公司
package main
import "fmt"
func main() {
done := make(chan struct{})
count := 5
for i := 0; i < count; i++ {
go func(i int) {
defer func() {
done <- struct{}{}
}()
fmt.Println(i)
}(i)
}
for j := 0; j < count; j++ {
<- done
}
fmt.Println("Over")
}
这里有一个问题,要保证主goroutine最后从通道接收元素的的次数需要与之前其他goroutine发送元素的次数相同。
其实,在这种应用场景下,可以选用另外一个同步工具,就是这里要讲的sync包的WaitGroup类型。
sync.WaitGroup类型,它比通道更加适合实现这种一对多的goroutine协作流程。WaitGroup是开箱即用的,也是并发安全的。同时,与之前提到的同步工具一样,它一旦被真正的使用就不能被复制了。
WaitGroup拥有三个指针方法,可以想象该类型中有一个计数器,默认值是0,下面的方法就是操作或判断计数器:
Add(-1)
,可以在defer语句中调用它现在就用WaitGroup来改造开篇的程序:
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup // 开箱即用,所以直接声明就好了,没必要用短变量声明
// wg := sync.WaitGroup{} // 短变量声明可以这么写
count := 5
for i := 0; i < count; i++ {
wg.Add(1)
go func(i int) {
defer wg.Done()
fmt.Println(i)
}(i)
}
wg.Wait()
fmt.Println("Over")
}
改造后,在主goroutine最后等待退出的部分现在看着要美观多了。这个就是WaitGroup典型的应用场景了。
计数器不能小于0
在sync.WaitGroup类型值中计数器的值是不可以小于0的。一旦小于0会引发panic,不适当的调用Done方法和Add方法就有可能使它小于0而引发panic。
尽早增加计数器的值
如果在对它的Add方法的首次调用,与对它的Wait方法的调用是同时发起的。比如,在同时启动的两个goroutine中,分别调用这两个方法,那就就有可能会让这里的Add方法抛出一个panic。并且这种情况不太容易,应该予以重视。所以虽然WaitGroup值本身并不需要初始化,但是尽早的增加其计数器的值是非要必要的。
复用的情况
WaitGroup的值是可以被复用的,但需要保证其计数周期的完整性。这里的计数周期指的是这样一个过程:该值中的计数器值由0变为了某个正整数,而后又经过一系列的变化,最终由某个正整数又变回了0。这个过程可以被视为一个计数周期。在一个此类的生命周期中,它可以经历任意多个计数周期。但是,只有在它走完当前的计数周期后,才能够开始下一个计数周期。
也就是说,如果一个此类值的Wait方法在它的某个计数周期中被调用,那么就会立即阻塞当前的goroutine,直至这个计数周期完成。在这种情况下,该值的下一个计数周期必须要等到这个Wait方法执行结束之后,才能够开始。
Wait方法是有一个执行的过程的,如果在这个方法执行期间,跨越了两个计数周期,就会引发一个panic。比如,当前的goroutine调用了Wait方法而阻塞了。另一个goroutine调用了Done方法使计数器变成了0。此时会唤醒之前阻塞的goroutine,并且去执行Wait方法中其余的代码(这里还在这行Wait方法,执行的是源码sync.Wait方法里的代码,不是我们自己写的程序的Wait之后的代码)。在这个时候,又有一个goroutine调用了Add方法,使计数器的值又从0变为了某个正整数。此时正在执行的Wait方法就会立即抛出一个panic。
上面给了3种会引发panic的情况。关于后两种情况,建议如下:
不要把增加计数器值的操作和调用Wait方法的代码,放在不同的goroutine中执行。
就是要杜绝对同一个WatiGroup值的两种操作的并发执行。
后面提到的两种情况,不是每次都会发生,通常需要反复的实验才能够引发panic的情况。虽然不是每次都发生,但是在长期运行的过程中,这种情况是必然会出现的,应该予以重视并且避免。
如果对复现这些异常情况感兴趣,可以看一下sync代码包中的waitgroup_test.go文件。其中的名称以TestWaitGroupMisuse为前缀的测试函数,很好的展示了这些异常情况发生的条件。
与sync.WaitGroup类型一样,Sync.Once类型也属于结构体类型,同样也是开箱即用和并发安全的。由于这个类型中包含了一个sync.Mutex类型的字段,所以复制改类型的值也会导致功能失效。
Do方法
Once类型的Do方法只接收一个参数,参数的类型必须是func(),即无参数无返回的函数。该方法的功能并不是对每一种参数函数都只执行一次,而是只执行首次被调用时传入的那个函数,并且之后不会再执行任何参数函数。所以,如果有多个需要执行一次的函数,应该为它们每一个都分配一个sync.Once类型的值。
基本用法如下:
package main
import (
"fmt"
"sync"
"sync/atomic"
)
func main() {
var counter uint32
var once sync.Once
once.Do(func() {
atomic.AddUint32(&counter, 1)
})
fmt.Println("counter:", counter)
// 这次调用不会被执行
once.Do(func() {
atomic.AddUint32(&counter, 2)
})
fmt.Println("counter:", counter)
}
done字段
Once类型中还要一个名为done的uint32类型的字段。它的作用是记录所属值的Do方法被调用的次数。不过改字段的值只可能是0或1.一旦Do方法的首次调用完成,它的值就会从0变为1。
关于done的类型,其实用布尔类型就够了,这里只所以用uint32类型的原因是它的操作必须是原子操作,只能使用原子操作支持的数据类型。
Do方法的实现方式
Do方法在一开始就会通过atomic.LoadUint32来获取done字段的值,并且如果发现值为1就直接返回。这步只是初步保证了Do方法只会执行首次调用是传入的函数。
不过单凭上面的判断是不够的。如果两个goroutine都调用了同一个新的Once值的Do方法,并且几乎同时执行到了其中的这个条件判断代码,那么它们就都会因判断结果为false而继续执行Do方法中剩余的代码。
基于上面的可能,在初步保证的判断之后,Do方法会立即锁定其所属值中的那个sync.Mutex类型的m字段。然后,它会在临界区中再次检查done字段的值。此时done的值应该仍然是0,并且已经加锁。此时才认为是条件满足,才会去调用参数函数。并且用原子操作把done的值变为1。
单例模式
如果熟悉设计模式中的单例模式的话,这个Do方法的实现方式,与单例模式有很多相似之处。都会先在临界区之外判断一次关键条件,若条件不满足则立即返回。这通常被称为快路径,或者叫做快速失败路径。
如果条件满足,那么到了临界区中还要再对关键条件进行一次判断,这主要是为了更加严谨。这两次条件判断常被统称为(跨临界区的)双重检查。由于进入临界区前要加锁,显然会降低代码的执行速度,所以其中的第二次条件判断,以及后续的操作就被称为慢路径或者常规路径。
Do方法中的代码不多,但它却应用了一个很经典的编程范式。
一、由于Do方法只会在参数函数执行结束之后把done字段的值变为1,因此,如果参数函数的执行需要很长的时间或者根本就不会结束,那么就有可能会导致相关goroutine的同时阻塞。
比如,有多个goroutine并发的调用了同一个Once值的Do方法,并且传入的函数都会一直执行而不结束。那么,这些goroutine就都会因调用了这个Do方法而阻塞。此时,那个抢先执行了参数函数的goroutine之外,其他的goroutine都会被阻塞在该Once值的互斥锁m的那行代码上。
效果演示的示例代码:
package main
import (
"fmt"
"sync"
"time"
)
func main() {
once := sync.Once{} // 这里换短变量声明
wg := sync.WaitGroup{}
wg.Add(1)
go func() {
defer wg.Done()
// 这个函数会被执行
once.Do(func() {
for i := 0; i < 10; i++ {
fmt.Printf("\r任务[1-%d]执行中...", i)
time.Sleep(time.Millisecond * 400)
}
})
fmt.Printf("\n任务[1]执行完毕\n")
}()
wg.Add(1)
go func() {
defer wg.Done()
time.Sleep(time.Millisecond * 300)
// 这句Do方法的调用会一直阻塞,知道上面的函数执行完毕
// 然后Do方法里的函数不会执行
once.Do(func() {
fmt.Println("任务[2]执行中...")
})
// 上面Do方法阻塞结束后,直接会执行下面的代码
fmt.Println("任务[2]执行完毕")
}()
wg.Add(1)
go func() {
defer wg.Done()
time.Sleep(time.Millisecond * 300)
once.Do(func() {
fmt.Println("任务[3]执行中...")
})
fmt.Println("任务[3]执行完毕")
}()
wg.Wait()
fmt.Println("Over")
}
二、Do方法在参数函数执行结束后,对done字段的赋值用的是原子操作,并且这一操作是被挂载defer语句中的。因此,不论参数函数的执行会以怎样的方式结束,done字段的值都会变为1。
这样就是说即时参数函数没有执行成功,比如引发了panic。也是无法使用同一个Once值重新执行别的函数了。所以,如果需要为参数函数的执行设定重试机制,就要考虑在适当的时候替换Once值。
参考下面的示例:
package main
import (
"fmt"
"sync"
"time"
)
func main() {
once := sync.Once{}
wg := sync.WaitGroup{}
wg.Add(1)
go func() {
defer wg.Done()
defer func() {
if p := recover(); p != nil {
fmt.Printf("PANIC: %v\n", p)
// 下面的语句会给once变量替换一个新的Once值,这样下面的第二个任务还能被执行
// once = sync.Once{}
}
}()
once.Do(func() {
fmt.Println("开始执行参数函数,紧接着会引发panic")
panic(fmt.Errorf("主动引发了一个panic")) // panic之后就去调用defer了
fmt.Println("参数函数执行完毕") // 这行不会执行,后面的都不会执行
})
fmt.Println("Do方法调用完毕") // 这行也不会执行
}()
wg.Add(1)
go func() {
defer wg.Done()
time.Sleep(time.Millisecond * 500)
once.Do(func() {
fmt.Println("第二个任务执行中...")
time.Sleep(time.Millisecond * 800)
fmt.Println("第二个任务执行结束")
})
fmt.Println("第二个任务结束")
}()
wg.Wait()
fmt.Println("Over")
}
延迟一个昂贵的初始化步骤到有实际需求的时刻是一个很好的实践。这也是sync.Once的一个使用场景。
下面是从书上改的示例代码:
package main
import (
"fmt"
"sync"
)
var once sync.Once
var testmap map[string] int32
// 对testmap进行初始化的函数
func loadTestmap() {
testmap = map[string] int32{
"k1": 1,
"k2": 2,
"k3": 3,
}
}
// 获取testmap对应key的值,如果没有初始化,会先执行初始化
// 书上说这个函数是并发安全的,这里的map初始化之后,内容不会再变
func getKey(key string) int32 {
once.Do(loadTestmap)
// 最后的return这句可能不是并发安全的,不过线程安全的map不是这里的重点
// 假定这里的map在初始化之后只会被多个goroutine读取,其内容不会再改变
return testmap[key]
}
func main() {
fmt.Println(getKey("k1"))
}
这里不考虑map线程安全的问题,而且书上的例子这里的map只用来存放数据,初始化之后不会对其内容进行修改。
这里主要是保证在变量初始化过程中的并发安全。以这种方式来使用sync.Once,可以避免变量在正确构造之前就被其它goroutine分享。否则,在别的goroutine中可能会获取到一个内容不完整的变量。
sync代码包的WaitGroup类型和Once类型都是非常易用的同步工具。它们都是开箱即用和并发安全的。
Once类型使用互斥锁和原子操作实现了功能,而WatiGroup类型中只用到了原子操作。所以可以说,它们都是更高层次的同步工具。它们都基于基本的同步工具,实现了某种特定的功能。sync包中的其他高级同步工具,其实也都是这样的。