深入理解 goroutine 泄漏和避免泄漏的最佳实践

Go的奇妙之处在于,我们可以使用goroutines和channel轻松地执行并发任务。如果在生产环境中使用goroutines和channel,但是不了解它们的行为方式,会造成一些严重的影响。

36c9bf62f855631b4dab2c9e24bd1b6d.png

好吧,我们就面临着这样的影响,我们在goroutines中出现了泄漏,导致应用服务器随着时间的推移而膨胀,消耗了大量的CPU和频繁的GC,影响了多个服务的SLA。

从本文中可以看到什么

  • 理解什么是goroutine泄露。

  • 理解goroutine泄漏的多种方式。

  • 详细了解造成goroutine泄露的一个真实场景。

  • 我们是如何找到goroutine泄漏原因?

  • 阻止goroutine泄漏的最佳实践是什么?

2d53268d6c6256d4639697ac8be9d5a9.png

正如你在上面所附的指标中所看到的,goroutines开始随着时间的推移成倍地飙升。唯一的一次下降是当我们的一个正在运行的实例被AWS调度走,新的实例被启动,或者有一个新的版本,杀死了现有的容器并产生了新的容器。

如果你观察GC暂停的时间,它会随着活动的goroutine的数量不断增加。GC暂停的次数越多,CPU利用率就越高,响应时间也越来越长。

回到这个问题上,什么是goroutine泄漏?

goroutine泄漏是指客户端生成一个goroutine来做一些异步任务,并在任务完成后将一些数据写入一个channel,但是

  • 没有监听程序消耗该channel的数据写入。

func newgoroutine(dataChan chan <dataType>) {
     data := makeNetworkCall()
     dataChan <- data
     return
}
func main() {
     dataChan := make(chan <dataType>)
     go newgoroutine(dataChan)
     // Some application processing (but forgot to consume data from the channel (dataChan))
     return 
}

在上述情况下,代码成功地完成了执行,好像根本就没有问题。但这里发生的情况是,会有一个没有被管理的goroutine驻留在内存中,占用CPU和RAM。

为什么呢?

主要原因是第3行,我们正在向一个通道写入数据,但根据Go原则,一个未缓冲的通道会阻止向通道的写入,直到消费者从该channel取走信息。

所以在这种情况下,第4行的返回将永远不会被执行,并且newgoroutine函数在整个应用程序生命周期中都被卡住,因为这个channel没有消费者。

  • 在goroutine启动和channel监听器之间有一些条件逻辑。

func newgoroutine(dataChan chan <dataType>) {
     data := makeNetworkCall()
     dataChan <- data
     return
}
func main() {
     dataChan := make(chan <dataType>)
     go newgoroutine(dataChan)
     // Some application processing 
     if processingError != nil {
          return
     }
     data := <- dataChan
     // Do something with data
     return 
}

在这个案例中,有一个小小的改进。我们有一个消费者从dataChan中消费数据,但是从我们生成goroutine开始,到我们开始从通道中消费数据之前,有大量的应用程序代码驻留在那里,这些代码可以在一些处理错误|DB错误|无指针异常|panic的情况下退出主函数,由于这些原因,channel的数据可能从未被执行。

这就是一个goroutine看似正常,实际可能导致泄漏的情况。

我们不能在应用处理之前将channel中的值提前消费,因为消费者会阻止剩下业务逻辑的处理,直到它收到数据,从而消除了并发任务的执行。

  • 发送完成立刻返回

以上两种情况是当goroutine因为没有channle的消费者而被阻塞,或者消费者从channel中消费数据的代码块被跳过。

当我们把一个channel传递给goroutine去消费时,当发送者向通道发送数据时出现了问题,这是否也是同样的情况?

func newgoroutine(dataChan chan <dataType>) {
     // Consume data from dataChan 
     data := <- dataChan
     // Do some processing on the data
     return
}
func main() {
     dataChan := make(chan <dataType>)
     go newgoroutine(dataChan)
     data, err := makeNetworkCall()
     if err != nil {
         return 
     }
     dataChan <- data // This piece of code is never executed in error case of networkCall which makes newgoroutine dangling
     // Do something with data
     return 
}

好吧,95%的goroutine泄露都是因为这3种情况中的一种,在我们的案例中,是由于情景-2。我们在GoIbibo-Makemytrip的工作是折扣和便利费服务。

当客户应用一个促销代码时,我们有一套规则要执行,以找出正确的折扣。我们有另一个微服务,我们称之为实时动态折扣器(DD),它试图根据一些算法(黑盒子)来计算折扣。

这个动态折扣是一个A/B实验,只有10%的用户会参与其中。只有当我们的静态规则中存在有效的折扣时,我们才会覆盖DD折扣。

一个关于我们的伪代码

func loadDDDiscount(ddChan chan <dataType>) {
   ddRequest := formDDRequest()
   response := callDDService(ddRequest)
   ddChan <- response
}

func ApplyPromo() (discount int, err error) {
   ddChan := make(chan <dataType>)
   if ddEnabledRequest {
      loadDDDiscount(ddChan)
   }
   discount, err = validateStaticRules()
   // Got to say there is hell lot of processing & multiple error handlings while processing 
   if err != nil {
      return 0, err
   }
   if ddEnabledRequest {
      ddDiscount <- ddChan
      discount = overrideDiscount()
   }
   return discount, nil
}

我们只有在处理完静态规则后才需要DD的响应。所以来自ddChan的消费将在最后进行。

如果静态规则的评估有问题|如果没有满足请求的有效规则|如果用户应用了一些假的促销活动,我们从ddChan中消耗数据的代码将无法到达,这导致loadDDDiscount函数成为一个无法控制的goroutine。

那么,有什么方法可以解决这个问题?

方法-1

  • 方法 -> 从我们启动goroutine开始,到我们从退出channel的消耗数据为止,我们识别每一个错误条件,并在每一个返回语句前放置一个接收者,以解除对生成的goroutine的封锁。

  • 陷阱 -> 我们必须手动找到所有的边缘情况,并且在将来,如果我们必须处理更多的错误情况,我们需要记住在返回之前我们需要消耗哪些channel的数据。

方法-2

  • 方法 -> 与其在每个错误的情况下放置一个接收者,为什么不设置一个可以从channel中接收数据的延迟函数。

  • 陷阱 -- 在成功的情况下,数据将在处理完静态规则后从通道中读取。因此,如果我们在defer函数中开始接收通道中的数据,那么在成功的情况下就会阻塞主goroutine。

方法-3

  • 没有完美的方法。在上述所有场景中,我们创建了一个无缓冲的通道,阻止发送者向该通道发送数据,直到接收者收到数据。这里的主要问题是我们不确定由于我们的应用处理,接收方是否会被执行。那么,简单的解决方案是创建一个上限为1的缓冲通道。有了这个,即使没有消费者,或者消费者代码没有达到,发送者也不会被阻止写一次数据。

0248c3c55d9b6a631b85dcc23dc8cf1c.png
  • 陷阱 -> 绝对是零。这与非缓冲通道的工作原理完全相同,但为我们提供了一个额外的能力,即发送者在发送数据时不会受到阻碍,而消费者可以在任何时候消费它,而且生成的goroutine也不会等待消费者的到来。

我们用第三种方法将变化带入生产环境,你可以看到显著的影响。

127e32211562f71f2c664ce05618baaf.png

以前是线性增长的goroutine数量,现在下降到150个,我们的GC暂停频率也是如此。

整个事情中最痛苦的部分是,如何找到代码中存在goroutine泄漏的部分?

好吧,有一些包,比如https://github.com/uber-go/goleak,可以帮助你找到goroutine的泄漏,我发现用这个包来调试泄漏是很困难的。

所以我的方法是这样的。

  • 当服务器启动时,使用debug.SetGCPercent(-1)禁用垃圾收集器。

  • 现在运行代码中每一个使用Go程序的流程(Dev Env)。

  • 在每个API的入口处,打印在开始和执行API之前和之后运行的goroutines的数量。

func ApplyPromo() {
   fmt.Println(runtime.NumGoroutine())
   defer fmt.Println(runtime.NumGoroutine()
   // Process your application logic
}

现在,如果一个服务在前后返回不同的Goroutines数量,那么这个逻辑就存在泄漏。

我们有近20个API和大约35-40个地方使用了goroutines以改善并发性。幸运的是,我能够在前3次迭代中找出泄漏问题,并发现了这个存在泄漏的逻辑。

希望这个经验能够帮助大家在编写一些并发代码的时候,不要出现goroutines泄露的情况。

cfef01a762ab0497c34ccf03cc9f2ad7.png

推荐

Golang - 顶层记录日志

轻松容器化golang应用程序


随手关注或者”在看“,诚挚感谢!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值