共计 3335 个字符，预计需要花费 9 分钟才能阅读完成。
引言
在 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/awesomeProject/main.go:18 +0x46
created by main.main
/Users/jiangbaiyan/go/src/awesomeProject/main.go: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() {panic("goroutine2_panic")
}()
time.Sleep(2 * time.Second)
}咱们这次只开启一个协程，并在主协程中退出了 recover，心愿它可能捕捉到子协程中的 panic，然而后果未能如愿：
panic: goroutine2_panic
goroutine 6 [running]:
main.main.func2()
/Users/jiangbaiyan/go/src/awesomeProject/main.go:17 +0x39
created by main.main
/Users/jiangbaiyan/go/src/awesomeProject/main.go: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 而挂掉了，容错率更高。在业务开发中咱们能够参考这种实现形式~
