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

 更新时间:2020-09-24 15:01:26   作者:佚名   我要评论(0)

引言


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

引言

在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而挂掉了,容错率更高。在业务开发中我们可以参考这种实现方式~

到此这篇关于详解Go多协程并发环境下的错误处理的文章就介绍到这了,更多相关Go多协程并发错误处理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家! 

您可能感兴趣的文章:
  • Django高并发负载均衡实现原理详解
  • golang并发编程的实现
  • 一百行Golang代码实现简单并发聊天室
  • 基于Django的乐观锁与悲观锁解决订单并发问题详解
  • django解决订单并发问题【推荐】
  • golang并发ping主机的方法
  • golang并发下载多个文件的方法
  • Go并发调用的超时处理的方法
  • 详解Go 并发

相关文章

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

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

    引言 在Go语言中,我们通常会用到panic和recover来抛出错误和捕获错误,这一对操作在单协程环境下我们正常用就好了,并不会踩到什么坑。但是在多协程并发环境下,
    2020-09-24
  • Go语言中如何通过方法为类型添加行为

    Go语言中如何通过方法为类型添加行为

    前言 数十年以来, 传统的面向对象语言总是说方法属于类, 但 Go 不是这样做的: 它提供了方法, 但是并没有提供类和对象。 乍一看, 这种做法似乎有些奇怪, 甚至可
    2020-09-24
  • Golang Http 验证码示例实现

    Golang Http 验证码示例实现

    验证码(CAPTCHA)是“Completely Automated Public Turing test to tell Computers and Humans Apart”(全自动区分 计算机 和人类的 图灵测试 )的缩写,是一种区
    2020-09-24
  • Go语言使用swagger生成接口文档的方法

    Go语言使用swagger生成接口文档的方法

    swagger介绍 Swagger本质上是一种用于描述使用JSON表示的RESTful API的接口描述语言。Swagger与一组开源软件工具一起使用,以设计、构建、记录和使用RESTful Web服务
    2020-09-24
  • 谈谈对Golang IO读写的困惑

    谈谈对Golang IO读写的困惑

    前言 Golang的IO读写提供了很多种方式,目前本人知道的有io库、os库、ioutil库、bufio库、bytes/strings库等。 虽然库多是一件好事,意味着选择性多,但让我困惑
    2020-09-24
  • Go 实现热重启的详细介绍

    Go 实现热重启的详细介绍

    最近在优化公司框架 trpc 时发现了一个热重启相关的问题,优化之余也总结沉淀下,对 go 如何实现热重启这方面的内容做一个简单的梳理。 1.什么是热重启? 热重启(H
    2020-09-24
  • 详解Go 结构体格式化输出

    详解Go 结构体格式化输出

    在软件系统中定位问题时日志不可或缺,但是当一个系统功能繁多,需要打印的日志也多如牛毛,此时为了提高我们浏览日志的效率,便于阅读的输出格式必不可少。 打印结
    2020-09-24
  • Linux shell实现压缩多个文件代码实例

    Linux shell实现压缩多个文件代码实例

    Linux环境下写一个脚本 从键盘让用户输入几个文件,脚本能够将此几个文件归档压缩成一个文件: 1.首先介绍一下case语句格式 2.脚本如下: DEST读取的是压缩后文件的
    2020-09-24
  • 详解Go 并发

    详解Go 并发

    golang 天生语言层面支持并发, 非常棒的语言, 有时我们业务开发时, 遇到复杂场景, 需要用于并发, 将多个请求使用协程组完成并发, 当遇到嵌套循环,还存在上下文关系需
    2020-09-24
  • Bash技巧:把变量赋值为换行符(判断文件是否以换行符结尾)

    Bash技巧:把变量赋值为换行符(判断文件是否以换行符结尾)

    变量赋值为换行符 在 bash 中,如果要把变量赋值为换行符,写为 '\n' 没有效果,需要写为 $'\n'。具体举例如下: $ newline='\n' $ echo $newline \n $ newline=$
    2020-09-24

最新评论