ZH
FrançaisDeutschEspañol한국어Tiếng ViệtPortuguêsEnglish简体中文
首页 / 编程语言 / Golang

Goroutine泄漏：Golang中的隐形RAM消耗者

Cris The Dev · 2026/10/06 · 8 分钟阅读 · 106

1. 概述

Goroutine是使Go“酷”的东西——轻量级、易于创建、每个只需几KB。但正因为轻量级，你容易创建它们却忘记…清理。Goroutine泄漏是指goroutine被永久阻塞、永远不会结束的状态，并随时间累积直到RAM耗尽或系统崩溃。

读完这篇文章，你将了解：最常见的泄漏模式、如何使用pprof和运行时指标来检测、以及如何通过context、缓冲channel、带超时的select来修复。

2. 什么是Goroutine泄漏

不同于常规的内存泄漏（对象因仍有引用而不被GC），goroutine泄漏是一个goroutine被永久阻塞在某处——通常是等待一个永远不会发生的channel读/写。该goroutine不会死亡、不会被GC，它的栈（以及它持有的所有闭包变量）永久存在于heap中。

最危险的问题在于：程序不会立即崩溃。它照常运行，请求返回正确结果，但RSS（驻留内存）随每个请求逐渐增加。几小时或几天后，容器被OOMKilled。

3. 常见泄漏模式#1：发送到没有人接收的channel

func fetchWithTimeout(url string, timeout time.Duration) (string, error) {
	resultCh := make(chan string)

	go func() {
		result := slowHTTPCall(url) // 假设需要5秒
		resultCh <- result          // (1) 发送到无缓冲channel
	}()

	select {
	case res := <-resultCh:
		return res, nil
	case <-time.After(timeout):
		return "", fmt.Errorf("timeout after %v", timeout)
	}
}

如果timeout（比如1秒）小于slowHTTPCall的执行时间（5秒），fetchWithTimeout在case <-time.After处返回超时错误并立即退出。但第(1)行的goroutine仍在运行。当它在5秒后完成时，试图将result发送到resultCh——已经没有人读这个channel了因为父函数已经返回。由于resultCh无缓冲，发送到无人接收的channel会永远阻塞。这个goroutine永久泄漏。

如果每秒调用这个函数1000次且超时较短，你每秒会有1000个goroutine泄漏。

3.1. 修复：缓冲channel

func fetchWithTimeout(url string, timeout time.Duration) (string, error) {
	resultCh := make(chan string, 1) // (1) 缓冲大小为1

	go func() {
		result := slowHTTPCall(url)
		resultCh <- result // 因为有缓冲，永远不会阻塞
	}()

	select {
	case res := <-resultCh:
		return res, nil
	case <-time.After(timeout):
		return "", fmt.Errorf("timeout after %v", timeout)
	}
}

第(1)行为channel分配缓冲大小1。当goroutine发送result时，它写入缓冲后立即退出——无需任何人读取。Goroutine正常结束，不会泄漏。这是快速修复但不是彻底的：slowHTTPCall仍然运行完整的5秒，即使调用者已不关心结果，浪费CPU/网络。

4. 泄漏模式#2：当context被cancel时忘记结束goroutine

func worker(ch <-chan int) {
	go func() {
		for v := range ch { // (1) 如果ch不被关闭，永远等待
			process(v)
		}
	}()
}

如果没人close(ch)，第(1)行的goroutine永远等待读取channel。这个模式在worker在请求作用域内创建但channel源的生命周期不同时常见（比如全局队列永不关闭）。

4.1. 用context.Context修复

func worker(ctx context.Context, ch <-chan int) {
	go func() {
		for {
			select {
			case <-ctx.Done(): // (1) 接收取消信号
				return
			case v, ok := <-ch:
				if !ok { // (2) channel已关闭
					return
				}
				process(v)
			}
		}
	}()
}

第(1)行监听ctx.Done()——当调用者调用cancel()时，goroutine立即退出，不管ch是否有数据。第(2)行处理channel正常关闭的情况。这是标准模式：所有长时间运行的goroutine应该接收context.Context，并始终有通过ctx.Done()的退出路径。

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
worker(ctx, dataCh)

5. 泄漏模式#3：sync.WaitGroup中某些goroutine永不调用Done()

func processAll(items []Item) {
	var wg sync.WaitGroup
	for _, item := range items {
		wg.Add(1)
		go func(it Item) {
			defer wg.Done()
			if err := validate(it); err != nil {
				return // 在return前忘记调用Done()？不，defer仍会运行
			}
			save(it)
		}(item)
	}
	wg.Wait() // (1) 等待所有goroutine调用Done()
}

在这个例子中defer wg.Done()是安全的因为defer总是运行，即使提早return。但真正的泄漏发生在goroutine在return前被阻塞——比如save(it)调用一个无超时的API且永远挂起。那时wg.Wait()在第(1)行也被无限期阻塞，拖累调用processAll的goroutine也泄漏。

注意： defer wg.Done()只能救你脱离忘记调用Done()的错误。它救不了goroutine在body内被卡住。总是为所有I/O设置超时（HTTP客户端、数据库查询、gRPC调用）。

6. 泄漏模式#4：通过不调用Stop()的time.Ticker泄漏

func startMonitor() {
	ticker := time.NewTicker(5 * time.Second)
	go func() {
		for range ticker.C { // (1) 永远运行
			checkHealth()
		}
	}()
}

time.NewTicker在运行时内创建一个goroutine来将tick泵入ticker.C。如果从不调用ticker.Stop()，第(1)行的读取goroutine和ticker的内部goroutine都会永生——即使startMonitor被多次调用（比如每次重新加载配置），你累积多个并行运行的ticker。

6.1. 修复：将生命周期绑定到context

func startMonitor(ctx context.Context) {
	ticker := time.NewTicker(5 * time.Second)
	go func() {
		defer ticker.Stop() // (1) 总是清理ticker
		for {
			select {
			case <-ctx.Done():
				return
			case <-ticker.C:
				checkHealth()
			}
		}
	}()
}

第(1)行确保ticker.Stop()在goroutine退出时被调用，不管通过哪条路。ctx.Done()允许调用者在不需要时主动停止monitor。

7. 用pprof检测goroutine泄漏

检测泄漏的最好方法不是用眼睛读代码，而是直接测量。

import (
	"net/http"
	_ "net/http/pprof" // (1) 自动注册调试路由
)

func main() {
	go func() {
		http.ListenAndServe("localhost:6060", nil)
	}()
	// ... app的其余部分
}

第(1)行用空名导入net/http/pprof——仅为了side-effect注册路由/debug/pprof/*，不需要从package调用任何函数。

运行app后调用：

curl http://localhost:6060/debug/pprof/goroutine?debug=1
goroutine profile: total 15234
14998 @ 0x43f1 0x454a 0x4a2b ...
#	0x4a2b	main.fetchWithTimeout.func1+0x5b	/app/main.go:12

236 @ 0x43f1 0x454c ...

首行的14998是明显的信号：近15000个goroutine卡在代码中的同一点（main.go:12）。这正是goroutine泄漏——一个重复的模式，不是正常流量。

7.1. 随时间跟踪goroutine数量

func logGoroutineCount() {
	ticker := time.NewTicker(10 * time.Second)
	for range ticker.C {
		log.Printf("goroutines: %d", runtime.NumGoroutine())
	}
}

runtime.NumGoroutine()返回当前活着的goroutine数。如果这个数字不断增加但在稳定流量下从不减少，这是非常可信的泄漏指标。应该通过Prometheus导出这个指标（go_goroutines——实际上Prometheus的Go客户端已经有了这个指标）。

8. 编写测试尽早捕获泄漏

库go.uber.org/goleak帮助编写自动检测泄漏的测试，而不是等到生产环境发现。

<!-- 用go.mod替代Maven -->
go get go.uber.org/goleak
package fetcher_test

import (
	"testing"
	"time"

	"go.uber.org/goleak"
)

func TestFetchWithTimeout_NoLeak(t *testing.T) {
	defer goleak.VerifyNone(t) // (1) 测试完成后检查

	_, err := fetchWithTimeout("http://slow-endpoint.local", 100*time.Millisecond)

	if err == nil {
		t.Fatal("expected timeout error")
	}

	time.Sleep(200 * time.Millisecond) // (2) 给goroutine机会完成
}

第(1)行注册在测试结束时运行的检查：goleak比较当前活着的goroutine列表与基线，如果有“奇怪”的goroutine（不是来自运行时/测试框架），测试失败并输出该goroutine的栈追踪。第(2)行给goroutine足够时间在检查前完成——如果没有这行，测试可能有假阳性。

如果使用没有缓冲channel的fetchWithTimeout版本（见第3节），这个测试会失败，输出类似：

--- FAIL: TestFetchWithTimeout_NoLeak (0.30s)
    goleak.go:39: found unexpected goroutines:
    [Goroutine 18 in state chan send, with fetcher.fetchWithTimeout.func1 on top of the stack:
    goroutine 18 [chan send]:
    fetcher.fetchWithTimeout.func1()
        /app/fetcher.go:9 +0x65
    ]

栈追踪指向泄漏的确切位置——调试时很有用。

9. 避免goroutine泄漏的检查清单

  • 所有运行长I/O的goroutine应接收context.Context并有<-ctx.Done()分支。
  • 用于发送结果回调用者的无缓冲channel有被放弃的风险——考虑缓冲大小1或使用context。
  • time.Ticker、time.Timer在不再使用时必须调用Stop()。
  • sync.WaitGroup.Wait()仅在所有子goroutine有确定的退出路径时安全（对内部I/O的超时）。
  • 为创建goroutine的函数编写带goleak.VerifyNone(t)的测试，特别是有超时/cancel逻辑的函数。
  • 在生产环境的仪表板上监控runtime.NumGoroutine()或go_goroutines指标。

注意： 长时间运行的goroutine不一定是泄漏。运行整个应用生命周期的worker池是有效设计。问题只在goroutine数量随流量无限增长但不相应减少时出现。

10. 结论

Goroutine泄漏很危险因为它不会立即引起错误——应用仍返回正确结果，同时RAM在幕后不断增长。根本原因几乎总是：发送到无人接收的channel，或goroutine在调用者放弃时（超时、取消）缺乏退出路径。防止方法很简单：总是为长时间运行的goroutine传递context.Context、缓冲结果channel、并用goleak编写测试在代码审查阶段即捕获问题，而不是等生产环境OOMKilled。

golanggoroutineconcurrencymemory-leakperformance
作者的应用HoanTien.proCashback on Shopee, TikTok Shop and Lazada (Vietnam)iOS · Android · Web

同主题文章

Golang · 2026/10/24 · 9 分钟阅读 · 46

Go HTTP 服务器的优雅关闭

使用 signal.NotifyContext 和 http.Server.Shutdown 安全关闭 Go HTTP 服务器，处理超时、WebSocket、辅助资源和 Kubernetes。

Golang · 2026/10/21 · 9 分钟阅读 · 81

Go 中用 Struct Embedding 代替继承

Go 没有继承。本文讲解 struct embedding 的工作方式、方法如何被"提升"、方法覆盖的陷阱以及如何将 embedding 与 interface 结合。