详解Go多协程并发环境下的错误处理
引⾔
在Go语⾔中，我们通常会⽤到panic和recover来抛出错误和捕获错误，这⼀对操作在单协程环境下我们正常⽤就好了，并不会踩到什么坑。但是在多协程并发环境下，我们常常会碰到以下两个问题。假设我们现在有2个协程，我们叫它们协程A和B好了：
如果协程A发⽣了panic，协程B是否会因为协程A的panic⽽挂掉？
如果协程A发⽣了panic，协程B是否能⽤recover捕获到协程A的panic？
答案分别是：会、不能。
那么下⾯我们来⼀⼀验证，并给出在具体的业务场景下的最佳实践。
问题⼀
如果协程A发⽣了panic，协程B是否会因为协程A的panic⽽挂掉？
为了验证这个问题，我们写⼀段程序：
package main
import (
"fmt"
"time"
)
func main() {
// 协程A
go func() {
for {
fmt.Println("goroutine1_print")
}
}()
// 协程B
go func() {
time.Sleep(1 * time.Second)
panic("goroutine2_panic")
}()
time.Sleep(2 * time.Second)
}
⾸先主协程开启两个⼦协程A和B，A协程不停的循环打印goroutine1_print字符串；B协程在睡眠1s后，就会抛出panic（睡眠这⼀步为了确保在A跑起来开始打印了之后，B才会panic），主协程睡眠2s，等待A、B⼦协程全部执⾏完毕，主协程退出。最终打印结果如下：
...
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
panic: goroutine2_panicgoroutine1_print
goroutine1_print
goroutine goroutine1_print
19goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
[runninggoroutine1_print
]:
goroutine1_print
goroutine1_print
goroutine1_print
main.main.func2()
/Users/jiangbaiyan/go/src/:18 +0x46
created by main.main
/Users/jiangbaiyan/go/src/:16 +0x4d
我们可以看到，在协程B发⽣panic之前，协程A⼀直在打印字符串；然后协程A和panic交替打印字符串，最后主协程与协程A、B全部退出。所以我们可以看到，⼀个协程panic之后，是会导致所有的协程全部挂掉的，程序会整体退出，到这⾥我们就验证了第⼀个问题的答案。
⾄于panic和协程A交替打印的原因，可能是因为panic也需要打印字符串。因为打印也是需要时间的，当我们执⾏panic这⼀⾏代码的时候，到panic真正触发所有协程挂掉，是需要⼀定的时间的（尽管这个时间很短暂），所以再这⼀⼩段时间内，我们会看到交替打印的现象。
问题⼆
如果协程A发⽣了panic，其他协程是否能⽤recover捕获到协程A的panic？
还是类似上⾯那段代码，我们还可以再精简⼀下：
package main
import (
"fmt"
"time"
)
func main() {
defer func() {
if e := recover(); e != nil {
fmt.Println("recover_panic")
}
}()
go func() {
go语言开发环境搭建panic("goroutine2_panic")
}()
time.Sleep(2 * time.Second)
}
我们这次只开启⼀个协程，并在主协程中加⼊了recover，希望它能够捕获到⼦协程中的panic，但是结果未能如愿：
panic: goroutine2_panic
goroutine 6 [running]:
main.main.func2()
/Users/jiangbaiyan/go/src/:17 +0x39
created by main.main
/Users/jiangbaiyan/go/src/:16 +0x57
Process finished with exit code 2
我们看到，recover并没有⽣效。所以，哪个协程发⽣了panic，我们就需要在哪个协程recover，我们改成这样：
package main
import (
"fmt"
"time"
)
func main() {
go func() {
defer func() {
if e := recover(); e != nil {
fmt.Println("recover_panic")
}
}()
panic("goroutine2_panic")
}()
time.Sleep(2 * time.Second)
}
结果成功打印recover_panic字符串：
recover_panic
Process finished with exit code 0
所以我们的答案也得到了验证：协程A发⽣panic，协程B⽆法recover到协程A的panic，只有协程⾃⼰内部的recover才能捕获⾃⼰抛出的panic。
最佳实践
我们先假设有这样⼀个场景，我们要开发⼀个客户端，这个客户端需要调⽤2个服务，这2个服务没有任何先后顺序的依赖，所以我们可以开启2个goroutine，通过并发调⽤这两个服务来获得性能提升。那么这个时候我们刚才所谈到的问题⼀就成了问题。
通常来讲，我们不希望其中⼀个服务调⽤失败，另⼀个服务调⽤也跟着失败，⽽是要继续执⾏完其他⼏个服务调⽤逻辑，这个时候我们该怎么办呢？
聪明的你⼀定会想到，我在每个协程内部编写⼀个recover语句，让他接住每个协程⾃⼰可能会发⽣的panic，就能够解决⼀个协程panic⽽导致所有协程挂掉的问题了。我们编写如下代码，这就是在业务开发中，结合问题⼆解决问题⼀的最佳实践：
// 并发调⽤服务，每个handler都会传⼊⼀个调⽤逻辑函数
func GoroutineNotPanic(handlers ...func() error) (err error) {
var wg sync.WaitGroup
// 假设我们要调⽤handlers这么多个服务
for _, f := range handlers {
wg.Add(1)
// 每个函数启动⼀个协程
go func(handler func() error) {
defer func() {
// 每个协程内部使⽤recover捕获可能在调⽤逻辑中发⽣的panic
if e := recover(); e != nil {
// 某个服务调⽤协程报错，可以在这⾥打印⼀些错误⽇志
}
wg.Done()
}()
// 取第⼀个报错的handler调⽤逻辑，并最终向外返回
e := handler()
if err == nil && e != nil {
err = e
}
}(f)
}
wg.Wait()
return
}
以上⽅法调⽤⽰例：
// 调⽤⽰例
func main() {
// 调⽤逻辑1
aRpc := func() error {
panic("rpc logic A panic")
return nil
}
// 调⽤逻辑2
bRpc := func() error {
fmt.Println("rpc logic B")
return nil
}
err := GoroutineNotPanic(aRpc, bRpc)
if err != nil {
fmt.Println(err)
}
}
这样我们就实现了⼀个通⽤的并发处理逻辑，每次调⽤我们只需要把业务逻辑的函数传⼊即可，不⽤每次⾃⼰单独编写⼀套并发控制逻辑；同时调⽤逻辑2就不会因为调⽤逻辑1的panic⽽挂掉了，容错率更⾼。在业务开发中我们可以参考这种实现⽅式~
到此这篇关于详解Go多协程并发环境下的错误处理的⽂章就介绍到这了，更多相关Go多协程并发错误处理内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。