Go多协程并发环境下的错误处理

开发 后端
在Go语言中,我们通常会用到panic和recover来抛出错误和捕获错误,这一对操作在单协程环境下我们正常用就好了,并不会踩到什么坑。但是在多协程并发环境下,我们常常会碰到以下两个问题。

[[426205]]

引言

在Go语言中,我们通常会用到panic和recover来抛出错误和捕获错误,这一对操作在单协程环境下我们正常用就好了,并不会踩到什么坑。但是在多协程并发环境下,我们常常会碰到以下两个问题。假设我们现在有2个协程,我们叫它们协程A和B好了:

  • 如果协程A发生了panic,协程B是否会因为协程A的panic而挂掉?
  • 如果协程A发生了panic,协程B是否能用recover捕获到协程A的panic?

答案分别是:会、不能。

那么下面我们来一一验证,并给出在具体的业务场景下的最佳实践。

问题一

  • 如果协程A发生了panic,协程B是否会因为协程A的panic而挂掉?

为了验证这个问题,我们写一段程序:

  1. package main 
  2.  
  3. import ( 
  4.     "fmt" 
  5.     "time" 
  6.  
  7. func main() { 
  8.  
  9.     // 协程A 
  10.     go func() { 
  11.         for { 
  12.             fmt.Println("goroutine1_print"
  13.         } 
  14.     }() 
  15.  
  16.     // 协程B 
  17.     go func() { 
  18.         time.Sleep(1 * time.Second
  19.         panic("goroutine2_panic"
  20.     }() 
  21.  
  22.     time.Sleep(2 * time.Second

首先主协程开启两个子协程A和B,A协程不停的循环打印goroutine1_print字符串;B协程在睡眠1s后,就会抛出panic(睡眠这一步为了确保在A跑起来开始打印了之后,B才会panic),主协程睡眠2s,等待A、B子协程全部执行完毕,主协程退出。最终打印结果如下:

  1. ... 
  2. goroutine1_print 
  3. goroutine1_print 
  4. goroutine1_print 
  5. goroutine1_print 
  6. goroutine1_print 
  7. goroutine1_print 
  8. goroutine1_print 
  9. goroutine1_print 
  10. goroutine1_print 
  11. goroutine1_print 
  12. goroutine1_print 
  13. goroutine1_print 
  14. panic: goroutine2_panicgoroutine1_print 
  15.  
  16.  
  17. goroutine1_print 
  18. goroutine goroutine1_print 
  19. 19goroutine1_print 
  20. goroutine1_print 
  21. goroutine1_print 
  22. goroutine1_print 
  23.  [runninggoroutine1_print 
  24. ]: 
  25. goroutine1_print 
  26. goroutine1_print 
  27. goroutine1_print 
  28. main.main.func2() 
  29.         /Users/jiangbaiyan/go/src/awesomeProject/main.go:18 +0x46 
  30. created by main.main 
  31.         /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?

还是类似上面那段代码,我们还可以再精简一下:

  1. package main 
  2.  
  3. import ( 
  4.    "fmt" 
  5.    "time" 
  6.  
  7. func main() { 
  8.  
  9.    defer func() { 
  10.        if e := recover(); e != nil { 
  11.            fmt.Println("recover_panic"
  12.        } 
  13.    }() 
  14.  
  15.    go func() { 
  16.        panic("goroutine2_panic"
  17.    }() 
  18.  
  19.    time.Sleep(2 * time.Second

我们这次只开启一个协程,并在主协程中加入了recover,希望它能够捕获到子协程中的panic,但是结果未能如愿:

  1. panic: goroutine2_panic 
  2.  
  3. goroutine 6 [running]: 
  4. main.main.func2() 
  5.        /Users/jiangbaiyan/go/src/awesomeProject/main.go:17 +0x39 
  6. created by main.main 
  7.        /Users/jiangbaiyan/go/src/awesomeProject/main.go:16 +0x57 
  8.  
  9. Process finished with exit code 2 

我们看到,recover并没有生效。所以,哪个协程发生了panic,我们就需要在哪个协程recover,我们改成这样:

  1. package main 
  2.  
  3. import ( 
  4.    "fmt" 
  5.    "time" 
  6.  
  7. func main() { 
  8.  
  9.    go func() { 
  10.        defer func() { 
  11.            if e := recover(); e != nil { 
  12.                fmt.Println("recover_panic"
  13.            } 
  14.        }() 
  15.        panic("goroutine2_panic"
  16.    }() 
  17.  
  18.    time.Sleep(2 * time.Second

结果成功打印recover_panic字符串:

  1. recover_panic 
  2.  
  3. Process finished with exit code 0 

所以我们的答案也得到了验证:协程A发生panic,协程B无法recover到协程A的panic,只有协程自己内部的recover才能捕获自己抛出的panic。

最佳实践

我们先假设有这样一个场景,我们要开发一个客户端,这个客户端需要调用2个服务,这2个服务没有任何先后顺序的依赖,所以我们可以开启2个goroutine,通过并发调用这两个服务来获得性能提升。那么这个时候我们刚才所谈到的问题一就成了问题。

通常来讲,我们不希望其中一个服务调用失败,另一个服务调用也跟着失败,而是要继续执行完其他几个服务调用逻辑,这个时候我们该怎么办呢?

聪明的你一定会想到,我在每个协程内部编写一个recover语句,让他接住每个协程自己可能会发生的panic,就能够解决一个协程panic而导致所有协程挂掉的问题了。我们编写如下代码,这就是在业务开发中,结合问题二解决问题一的最佳实践:

  1. // 并发调用服务,每个handler都会传入一个调用逻辑函数 
  2. func GoroutineNotPanic(handlers ...func() error) (err error) { 
  3.  
  4.     var wg sync.WaitGroup 
  5.     // 假设我们要调用handlers这么多个服务 
  6.     for _, f := range handlers { 
  7.  
  8.         wg.Add(1) 
  9.         // 每个函数启动一个协程 
  10.         go func(handler func() error) { 
  11.  
  12.             defer func() { 
  13.                 // 每个协程内部使用recover捕获可能在调用逻辑中发生的panic 
  14.                 if e := recover(); e != nil { 
  15.                     // 某个服务调用协程报错,可以在这里打印一些错误日志 
  16.                 } 
  17.                 wg.Done() 
  18.             }() 
  19.  
  20.             // 取第一个报错的handler调用逻辑,并最终向外返回 
  21.             e := handler() 
  22.             if err == nil && e != nil { 
  23.                 err = e 
  24.             } 
  25.         }(f) 
  26.     } 
  27.  
  28.     wg.Wait() 
  29.  
  30.     return 

以上方法调用示例:

  1. // 调用示例 
  2. func main() { 
  3.  
  4.     // 调用逻辑1 
  5.     aRpc := func() error { 
  6.         panic("rpc logic A panic"
  7.         return nil 
  8.     } 
  9.      
  10.     // 调用逻辑2 
  11.     bRpc := func() error { 
  12.         fmt.Println("rpc logic B"
  13.         return nil 
  14.     } 
  15.  
  16.     err := GoroutineNotPanic(aRpc, bRpc) 
  17.     if err != nil { 
  18.         fmt.Println(err) 
  19.     } 

这样我们就实现了一个通用的并发处理逻辑,每次调用我们只需要把业务逻辑的函数传入即可,不用每次自己单独编写一套并发控制逻辑;同时调用逻辑2就不会因为调用逻辑1的panic而挂掉了,容错率更高。在业务开发中我们可以参考这种实现方式~

本文转载自微信公众号「NoSay」,可以通过以下二维码关注。转载本文请联系NoSay公众号。

 

 

责任编辑:武晓燕 来源: NoSay
相关推荐

2016-10-28 17:39:47

phpgolangcoroutine

2021-04-29 09:02:44

语言Go 处理

2014-11-17 10:05:12

Go语言

2023-12-26 22:05:53

并发代码goroutines

2021-05-21 08:21:57

Go语言基础技术

2022-09-05 08:55:15

Go2提案语法

2021-09-13 07:53:31

Go错误处理

2021-09-27 10:04:03

Go程序处理

2023-10-26 15:49:53

Go日志

2021-09-27 15:33:48

Go 开发技术

2020-12-17 06:25:05

Gopanic 模式

2023-11-24 11:15:21

协程编程

2023-03-10 08:48:29

2011-03-22 10:10:21

CentOSNagios安装

2021-04-14 07:08:14

Nodejs错误处理

2024-02-28 08:54:57

switchGo错误

2018-12-04 14:00:41

协程编程模式PHP

2021-04-25 09:36:20

Go协程线程

2024-03-27 08:18:02

Spring映射HTML

2023-10-12 09:46:00

并发模型线程
点赞
收藏

51CTO技术栈公众号