go 怎么等待所有的协程完成_Go协程这样用才安全

Go协程有一个不小的问题——你无法在父协程中捕获子协程的panic。比如下面的例子：

func main() {

// 希望捕获所有所有 panic defer func() {

r := recover()

fmt.Println(r)

}()

// 启动新协程 go func() {

panic(123)

}()

// 等待一下，不然协程可能来不及执行 time.Sleep(1 * time.Second)

fmt.Println("这条消息打印不出来")

}

自己执行一下就会发现，最后的fmt.Println没有执行，也就是说开始的recover()没有捕获协程中的panic，整个进程都退出了。

一般的Go框架都是针对每一个请求启一个新协程，并统一捕获所有的panic。

如果程序员在写业务代码的时候开了新协程而且忘记了在协程中捕获panic的话，服务的进程就会因为某个未捕获的panic而退出。所以，我在《Sniper一个轻量级Go业务框架的思考》一文中建议少用或者不用协程。

少用或不用协程对于大多数业务场景是没有问题。但有些少数场景还是要用协程的。

比如说我司有一个批量查询接口，一次最多支持查50条信息。但我们的业务要求一次要查100到1000条信息不等。如果不使用协程，需要依次执行2到10次查询，可能就超时了。

不用协程会超时，用协程可能会panic，怎么办呢？最好的办法就是引入框架方法，把Go的协程包装一下。

我们首先定义一个结构体

type PanicGroup struct {

panics chan Panic // 协程 panic 通知信道 dones chan int // 协程完成通知信道 jobN int32 // 协程并发数量}

因为Go的channel无法直接初始化，所以需要定义一个工厂方法

func NewPanicGroup() *PanicGroup {

return &PanicGroup{

panics: make(chan Panic, 8),

dones: make(chan int, 8),

}

}

针对PanicGroup我们定义Go和Wait两个方法。

Go方法用来启动新的协程，定义如下：

func (g *PanicGroup) Go(f func()) *PanicGroup {

atomic.AddInt32(&g.jobN, 1)

go func() {

defer func() {

if r := recover(); r != nil {

g.panics

return

}

g.dones

}()

f()

}()

return g // 方便链式调用}

这里的核心思想就是启动一个带有recover()的协程，捕获f()执行过程产生的panic并写到g.dones。每个协程启动的时候将计数器加一，方便Wait方法等待。

Wait方法用来等待所有协程结束或者panic，定义如下

func (g *PanicGroup) Wait(ctx context.Context) error {

for {

select {

case

if atomic.AddInt32(&g.jobN, -1) == 0 {

return nil

}

case p :=

panic(p)

case

return ctx.Err()

}

}

}

如果所有协程都结束，g.jobN就会等于零，Wait就会返回。如果有协程发生panic，Wait就会通过p :=

使用起来也是非常的方便

g := NewPanicGroup()

g.Go(f1)

g.Go(f2)

g.Wait(ctx)

// 也可以链式调用err := NewPanicGroup().Go(f1).Go(f2).Wait(ctx)

PanicGroup的本质就是各个子协程各自捕获自己的panic，并通过channel传给父协程(传递的时候带上调用栈信息)。父协程拿到panic信息后重新panic，看起来就像是在父协程拋出来一样。如此就绕过了Go不能在父协程捕获子协程panic的问题，也就避免了部分业务逻辑panic导致整个服务进程退出的问题。

另外一个需要主意的设计就是Go方法的入参。有人喜欢设计成func(context.Context) error，我想了一下，觉得这种设计不好。

f是由PanicGroup执行的，如果需要传入一个ctx，那势必需要在PanicGroup中保存当前ctx，就是不被推荐的。当然，有人会说你可以在调Go方法的时候先把f存下来，等到调Wait方法的时候再统一起协程。这样做确实可以不用保存ctx了，却要保存所有的f，我也是不推荐这种做法。

f返回了一个error，这看起来是通用设计，返回报错总是天经地义的。可是，f是由PanicGroup 执行的，如果要返回错误，PanicGroup就需要跟踪哪些协程有报错、哪些没有报错，不同的报错如何跟协程对应。这会让PanicGroup的设计变得非常复杂。

基于以上两点，我建议将f设计成func()，完全没有参数，PanicGroup只跟踪panic就好了，简单明了。那如何给协程传参并处理返回结果呢？使用闭包！

这是一个实际的传参示例：

func MCount(ctx context.Context, ids []int64) (total map[int64]int32) {

m := sync.Mutex{}

g := xsync.NewPanicGroup()

chunkSize := 50

for i := 0; i < len(ids); i += chunkSize {

begin := i

end := i + chunkSize

if end > len(ids) {

end = len(ids)

}

g.Go(func() {

ts, err := mCount(ctx, ids[begin:end])

if err != nil {

// log error return

}

m.Lock()

defer m.Unlock()

for k, v := range ts {

total[k] = v

}

})

}

err = g.Wait(ctx)

return

}