Go 语言编写代码的最大优点之一是能够在轻量级线程，即 Goroutines 中并发运行你的代码。

然而，拥有强大的能力也伴随着巨大的责任。

尽管 Goroutines 非常方便，但如果不小心处理，它们很容易引入难以追踪的错误。

Goroutine 泄露就是其中之一。它在背景中悄悄增长，可能最终在你不知情的情况下使你的应用程序崩溃。

因此，本文主要介绍 Goroutine 泄露是什么，以及你如何防止泄露发生。

我们来看看吧！

什么是 Goroutine 泄露？

当创建一个新的 Goroutine 时，计算机在堆中分配内存，并在执行完成后释放它们。

Goroutine 泄露是一种内存泄露，当 Goroutine 没有终止并在应用程序的生命周期中被留在后台时就会发生。

让我们来看一个简单的例子。

func goroutineLeak(ch chan int) {
    data := <- ch
    fmt.Println(data)
}

func handler() {
    ch := make(chan int)
    
    go goroutineLeak(ch)
    return
}

随着处理器的返回，Goroutine 继续在后台活动，阻塞并等待数据通过通道发送 —— 这永远不会发生。

因此，产生了一个 Goroutine 泄露。

在本文中，我将引导你了解两种常见的模式，这些模式很容易导致 Goroutine 泄漏：

• 遗忘的发送者
• 被遗弃的接收者

让我们深入研究！

遗忘的发送者

遗忘的发送者发生在发送者被阻塞，因为没有接收者在通道的另一侧等待接收数据的情况。

func forgottenSender(ch chan int) {
    data := 3
  
    // This is blocked as no one is receiving the data
    ch <- data
}

func handler () {
    ch := make(chan int)
  
    go forgottenSender(ch)
    return
}

虽然它起初看起来很简单，但在以下两种情境中很容易被忽视。

不当使用 Context

func forgottenSender(ch chan int) {
    data := networkCall()
  
    ch <- data
}

func handler() error {
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Millisecond)
    defer cancel()
  
    ch := make(chan int)
    go forgottenSender(ch)
  
    select {
        case data := <- ch: {
            fmt.Printf("Received data! %s", data)
      
            return nil
        }
    
        case <- ctx.Done(): {
            return errors.New("Timeout! Process cancelled. Returning")
        }
    }
}

在上面的例子中，我们模拟了一个标准的网络服务处理程序。

我们定义了一个上下文，它在10ms后发出超时，随后是一个异步进行网络调用的Goroutine。

select语句等待多个通道操作。它会阻塞，直到其其中一个情况可以运行并执行该情况。

如果网络调用完成之前超时到达，case <- ctx.Done() 将会执行，处理程序将返回一个错误。

当处理程序返回时，不再有任何接收者等待接收数据。forgottenSender将被阻塞，等待有人接收数据，但这永远不会发生！

这就是Goroutine泄露的地方。

错误检查后的接收者位置

这是另一个典型的情况。

func forgottenSender(ch chan int) {
    data := networkCall()
  
    ch <- data
}

func handler() error {
    ch := make(chan int)
    go forgottenSender(ch)
  
    err := continueToValidateOtherData()
    if err != nil {
        return errors.New("Data is invalid! Returning.")
    }
  
    data := <- ch
  
    return nil
}

在上面的例子中，我们定义了一个处理程序并生成一个新的Goroutine来异步进行网络调用。

在等待调用返回的过程中，我们继续其他的验证逻辑。

如你所见，当continueToValidateOtherData返回一个错误导致处理程序返回时，泄露就发生了。

没有人等待接收数据，forgottenSender将永远被阻塞！

解决方案：忘记的发送者

使用一个缓冲通道。

如果你回想一下，忘记的发送者发生是因为另一端没有接收者。阻塞问题的罪魁祸首是一个无缓冲的通道！

一个无缓冲的通道是在消息发出时立即需要一个接收者的，否则发送者会被阻塞。它是在没有为通道分配容量的情况下声明的。

func forgottenSender(ch chan int) {
    data := 3
  
    // This will NOT block
    ch <- data
}

func handler() {
    // Declare a BUFFERED channel
    ch := make(chan int, 1)
  
    go forgottenSender(ch)
    return
}

通过为通道添加特定的容量，在这种情况下为1，我们可以减少所有提到的问题。

发送者可以在不需要接收者的情况下将数据注入通道。

被遗弃的接收者

正如其名字所暗示的，被遗弃的接收者是完全相反的情况。

当一个接收者被阻塞，因为另一边没有发送者发送数据时，它就会发生。

func abandonedReceiver(ch chan int) {
    // This will be blocked
    data := <- ch
  
    fmt.Println(data) 
}

func handler() {
    ch := make(chan int)
  
    go abandonedReceiver(ch)
  
    return
}

第3行一直被阻塞，因为没有发送者发送数据。

让我们再次了解两个常见的场景，这些场景经常被忽视。

发送者未关闭的通道

func abandonedWorker(ch chan string) {
    for data := range ch {
        processData(data)
    }
  
    fmt.Println("Worker is done, shutting down")
}

func handler(inputData []string) {
    ch := make(chan string, len(inputData))
  
    for _, data := range inputData {
        ch <- data
    }
  
    go abandonedWorker(ch)
    
    return
}

在上面的例子中，处理程序接收一个字符串切片，创建一个通道并将数据插入到通道中。

处理程序然后通过Goroutine启动一个工作程序。工作程序预计会处理数据，并且一旦处理完通道中的所有数据，就会终止。

然而，即使消耗并处理了所有的数据，工作程序也永远不会到达“第6行”！

尽管通道是空的，但它没有被关闭！工作程序继续认为未来可能会有传入的数据。因此，它坐下来并永远等待。

这是Goroutine再次泄漏的地方。

在错误检查之后放置发送者

这与我们之前的一些示例非常相似。

func abandonedWorker(ch chan []int) {
    data := <- ch

    fmt.Println(data)
}

func handler() error {
    ch := make(chan []int)
    go abandonedWorker(ch)

    records, err := getFromDB()
    if err != nil {
        return errors.New("Database error. Returning")
    }

    ch <- records

    return nil
}

在上面的例子中，处理程序首先启动一个Goroutine工作程序来处理和消费一些数据。

然后，处理程序从数据库中查询记录，然后将记录注入通道供工作程序使用。

如果数据库出现错误，处理程序将立即返回。通道将不再有任何发送者传入数据。

因此，工作程序被遗弃。

解决方案：被遗弃的接收者

在这两种情况下，接收者都被留下，因为他们“认为”通道将有传入的数据。因此，它们阻塞并永远等待。

解决方案是一个简单的单行代码。

defer close(ch)

当你启动一个新的通道时，最好的做法是推迟关闭通道。

这确保在数据发送完成或函数退出时关闭通道。

接收者可以判断一个通道是否已关闭，并相应地终止。

func abandonedReceiver(ch chan int) {
    // This will NOT be blocked FOREVER
    data := <- ch
  
    fmt.Println(data) 
}

func handler() {
    ch := make(chan int)
  
      // Defer the CLOSING of channel
    defer close(ch)
  
    go abandonedReceiver(ch)
    return
}

结论

关于 Goroutine 泄漏就是这么多了！

尽管它不像其他 Goroutine 错误那么强大，但这种泄漏仍然会大大耗尽应用程序的内存使用。

记住，拥有强大的力量也伴随着巨大的责任。

保护我们的应用程序免受错误的责任在于你我——开发人员！