Go 基础体系 · 第 24/113 篇。示例统一基于 Go 1.26.4；核心片段可能省略 package 与 import，完整程序可直接按文中结构运行。

Go goroutine 生命周期：泄漏、打断、错误传播与优雅关闭

本文所有代码与运行行为均以 Go 1.26.4 为基准。goroutine 很轻，但不是无主资源。每次 go f() 都创建了一项并发任务：它可能持有栈、堆引用、锁、连接、文件和下游请求。可靠程序必须在启动时同时定义四件事：任务为何结束、谁发出停止信号、谁等待它真正结束、错误交给谁处理。

本文讨论任务生命周期，不重复 G-M-P 调度器、channel 基础或 worker pool 吞吐模式。调度器负责让可运行 goroutine 获得执行机会，却不知道某项业务工作是否已经失去价值；channel 和 context 提供机制，却不会自动组成正确的所有权协议。

1. 生命周期是一份所有权契约

启动 goroutine 的代码通常最了解它的依赖和退出条件，因此默认也应拥有停止与等待责任。若责任转移给长期运行组件，组件 API 应显式暴露 Close/Shutdown 和等待语义，而不是把后台循环藏在构造函数里。

type Worker struct {
	cancel context.CancelFunc
	done   chan struct{}
}

func (w *Worker) Close() {
	w.cancel()
	<-w.done
}

Close 在这里不仅发信号，还确认 goroutine 已退出。实际类型还需定义重复 Close、并发 Close 和启动失败的行为。若 API 只有 cancel 没有 wait，调用方无法确认资源何时释放；若只有 wait 没有 cancel，异常路径可能永久阻塞。

2. goroutine 泄漏究竟是什么

泄漏是任务已无业务价值，却仍不能结束。它不一定永远存在：一项请求超时后还运行十分钟，也是在这十分钟内泄漏资源。常见阻塞位置包括无人接收的 channel 发送、永不关闭的接收、锁、无 deadline 的网络 I/O、停止协议缺失的 ticker 循环，以及等待永远不会完成的子任务。

func firstResult() int {
	result := make(chan int)
	go func() { result <- expensive() }()
	return 0 // 发送方最终可能永久阻塞
}

把 channel 缓冲改为 1 只能修正“恰好一个结果、计算一定结束”的特定协议。它无法修复多次发送、无限生产、卡死 I/O 或持有其他资源。正确做法是先定义退出条件，再让每个阻塞点都能走到退出路径。

3. Context 发出取消，等待原语确认退出

取消是协作式的，Go 没有安全的通用 goroutine kill。Context 的 Done 适合广播“工作不再需要”，但 goroutine 必须在阻塞操作和长循环中观察它。创建者再用 WaitGroup 或 done channel 确认退出。

func produce(ctx context.Context, out chan<- int) {
	defer close(out)
	for n := 0; ; n++ {
		select {
		case out <- n:
		case <-ctx.Done():
			return
		}
	}
}

仅在循环开头检查一次 context 不够：随后向满 channel 发送仍可能永久阻塞。相反，在不可阻塞的短计算每条指令都检查会增加噪音与成本，可按批次检查。I/O 应优先调用原生接收 context 或 deadline 的 API；为一个无法取消的阻塞函数套 goroutine，只会把等待从调用方转移成后台泄漏。

4. Channel 的关闭责任与退出协议

关闭 channel 表示“不会再有值”，不是释放 channel 本身。通常由唯一发送方或协调所有发送方的 goroutine 关闭；接收方不能在生产者仍可能发送时擅自关闭，否则发送会 panic。多个生产者共享输出时，协调者等待所有生产者后关闭。

var wg sync.WaitGroup
for _, input := range inputs {
	wg.Add(1)
	go func() {
		defer wg.Done()
		produce(input, results)
	}()
}
go func() {
	wg.Wait()
	close(results)
}()

nil channel 永不就绪，可在 select 状态机中禁用 case，但意外 nil 会造成永久阻塞。接收循环若依赖 close 结束，所有错误路径都必须保证最终 close；否则还应能选择 context。不要为了“保险”在多处 recover 重复关闭，应该让所有权唯一。

5. 错误必须沿生命周期向拥有者传播

后台 goroutine 中的普通 return err 没有调用者接收；忽略错误会让上层误以为任务成功。一次性任务可发送一个带缓冲的结果，避免调用方取消后发送方卡住。多任务可用结果 channel 或任务组统一收集。

type result[T any] struct {
	value T
	err   error
}

func async[T any](ctx context.Context, fn func(context.Context) (T, error)) <-chan result[T] {
	out := make(chan result[T], 1)
	go func() {
		value, err := fn(ctx)
		out <- result[T]{value, err}
		close(out)
	}()
	return out
}

这里缓冲 1 是协议的一部分：fn 只产生一次结果，发送无需依赖调用方仍在等待。但 fn 本身仍必须响应 ctx。长期组件的异步错误应进入有界监控通道、触发组件关闭或交给 supervisor，不能无限堆积，也不能仅打印后继续处于损坏状态。

6. 任务组：首错取消、收集全部错误还是继续运行

同组任务不总是同一种失败语义。并行查询中任何一个失败可能取消兄弟任务；批量导入则可能收集每项错误继续处理；服务器中的独立连接通常不应因单个请求失败而整体退出。启动前要明确策略。

标准库 WaitGroup 只等待，不传错误也不取消。可用 Go 1.25 加入的 WaitGroup.Go 启动不会 panic 的任务，它会自动计数；需要错误传播时使用项目已有的结构化任务组或自己写小型协调器。常见的 errgroup.WithContext 位于 golang.org/x/sync/errgroup：首个非 nil 错误取消派生 context，但子任务仍须主动响应，Wait 才能返回。

错误合并策略应保留首要原因并区分取消的次生错误。某任务失败导致其他任务返回 context.Canceled 时，不应让后者覆盖原始数据库或协议错误。

7. Panic 边界不能代替错误协议

未恢复的任意 goroutine panic 会使整个进程崩溃。通用库通常不应吞 panic；进程级任务执行器若选择 recover，必须在 goroutine 最外层恢复，记录堆栈，把任务标为失败，并继续执行正常的 defer 清理。

defer func() {
	if recovered := recover(); recovered != nil {
		err = fmt.Errorf("task panic: %v\n%s", recovered, debug.Stack())
	}
}()

Recover 只适合明确隔离边界，不能证明组件状态仍一致。若 panic 发生在持锁更新不变量中，继续复用对象可能更危险。HTTP 服务有连接级恢复机制仍应修复根因。不要用 panic 表达普通取消、输入错误或下游失败。

8. Timer、Ticker 与回调生命周期

time.Ticker 不会替你结束 goroutine。拥有 ticker 的任务应 defer ticker.Stop()，并同时监听停止信号。Ticker 可能丢弃节拍，不能当成需要补跑每次计划的持久调度器。

func refresh(ctx context.Context, interval time.Duration, fn func(context.Context) error) error {
	ticker := time.NewTicker(interval)
	defer ticker.Stop()
	for {
		select {
		case <-ticker.C:
			if err := fn(ctx); err != nil {
				return err
			}
		case <-ctx.Done():
			return ctx.Err()
		}
	}
}

回调注册也是生命周期关系。事件总线、watcher、context.AfterFunc 或定时器若持有闭包，会间接保留闭包捕获对象；不再需要时应注销或 stop。AfterFunc 的 stop 不等待已启动回调，因此资源关闭要幂等并另行同步。

9. 外部 I/O 与“无法打断”的边界

网络调用要同时传 context 和配置协议阶段超时。Context 取消通常使客户端停止等待，但远端副作用可能已经发生。文件、某些系统调用、DNS/cgo 或第三方库不一定及时响应取消；必须查 API 契约并用部署环境验证。

不要为每个慢调用启动 goroutine 后 select timeout，却放弃结果 channel：这会稳定地产生泄漏。可选方案是使用支持 deadline 的接口、关闭底层连接打断 I/O、把不可信阻塞操作放到数量有硬上限的 worker，或隔离到可终止进程。并发上限保护系统，但 worker 若永久卡住仍需健康检测与进程恢复策略。

锁等待不能被 context 中止。应避免持锁做网络 I/O 或未知回调，保持临界区短并固定锁顺序。另开 goroutine 代替当前 goroutine 等锁没有解决被锁资源的生命周期。

10. HTTP 服务的优雅关闭顺序

服务收到 SIGTERM 后，目标不是立刻取消所有工作，而是停止接收新工作，给在途工作有限时间完成，再终止后台组件。典型顺序如下：

signal.NotifyContext 建立进程停止信号，并确保调用 stop 恢复默认信号行为。
调用 http.Server.Shutdown 关闭 listener、空闲连接并等待活跃 handler。
先停止后台任务的生产者，再关闭队列或取消消费者。
等待已知 goroutine、刷新必要状态，所有等待受总关闭 deadline 约束。
超时后记录仍未退出组件，调用 Server.Close 等强制手段并返回非零状态。

Shutdown 不会等待通过 Hijack 接管的连接，也不会自动管理业务自行启动的后台 goroutine；可用 RegisterOnShutdown 发通知，但回调本身不被 Shutdown 等待，仍要有自己的任务组。Kubernetes 的 readiness、负载均衡摘流和 termination grace period 也要纳入预算。

11. 怎样定位 goroutine 泄漏

runtime.NumGoroutine 只能作为趋势信号。正常连接、GC worker 和运行时任务都会变化；真正证据是相同负载下数量不回落，以及 goroutine profile 中某类栈持续增长。

curl -s 'http://127.0.0.1:6060/debug/pprof/goroutine?debug=2' > /tmp/goroutines.txt
go tool pprof -http=:0 http://127.0.0.1:6060/debug/pprof/goroutine
go test -race -count=50 ./...

pprof 端点只应暴露在受保护诊断网络。按顶部函数和阻塞原因聚类，区分 channel send/receive、select、semacquire、IO wait，再追到创建点和业务 ID。抓取流量高峰与回落后的两份 profile 做比较，比单张快照更可靠。执行 trace 可分析调度与阻塞时间，但采集有开销且文件可能很大。

测试泄漏时先用 channel 等确定性同步确认任务启动，取消后给合理 deadline 等待退出，并在前后比较目标栈而非机械要求 goroutine 总数完全相等。第三方泄漏检测库也必须处理运行时后台任务白名单。

12. 常见错误模式与修复选择

Fire-and-forget 请求任务：handler 返回后任务仍使用请求对象。修复为同步完成、交给进程级有界任务管理器，或先落可靠队列；不要持有 ResponseWriter。

只 cancel 不 wait：测试偶尔污染下一用例，关闭时资源仍在用。修复为组件 Close 同时等待 done，或让上层任务组统一 Join。

只 wait 不设停止路径：一个子任务卡住使整体永远无法结束。为所有阻塞操作提供取消/deadline，并给总等待设置上限。

接收方提前退出，上游仍发送：pipeline 常见泄漏。让取消贯穿全链路，每次发送选择 Done；输出由生产协调者关闭。

无界重试：错误路径变成永久 goroutine。限制次数和总时间，退避等待也响应取消，只重试分类后的瞬时错误。

13. 工程审查与可观测性

代码评审可从每个 go 关键字反向检查：输入是否在任务运行期间保持有效；是否捕获复用缓冲区；退出条件能否真实发生；取消是否打断每个阻塞点；完成如何被等待；panic 与 error 去向；任务数量有无上限。

组件指标应包括 active goroutine/worker、启动和完成数、按原因取消数、执行时长、队列等待、关闭耗时和强制终止数。日志记录任务 ID、组件、开始/结束原因和错误分类，但不要每轮 ticker 都打高频日志。分布式 trace 的 span 结束不能证明 goroutine 退出，仍要结合进程 profile。

上线前用真实关闭顺序做集成测试：制造在途请求，发送信号，验证新请求被拒绝、在途请求按预算完成、后台任务停止、进程在 grace period 内退出。仅测试 happy path 无法覆盖最容易泄漏的取消和半失败路径。

14. 可运行综合示例：有界任务组与信号关停

下面程序启动固定数量 worker，生产者拥有 jobs 并关闭它；进程信号取消根 context，worker 的接收、模拟工作和结果发送均可取消。协调 goroutine 在所有 worker 退出后关闭 results，主函数同时拥有停止和等待路径。示例没有外部依赖，可直接 go run，也可等待其自然完成。

package main

import (
	"context"
	"fmt"
	"os"
	"os/signal"
	"sync"
	"syscall"
	"time"
)

type result struct {
	job int
	err error
}

func worker(ctx context.Context, jobs <-chan int, results chan<- result) {
	for {
		select {
		case <-ctx.Done():
			return
		case job, ok := <-jobs:
			if !ok {
				return
			}
			timer := time.NewTimer(20 * time.Millisecond)
			select {
			case <-timer.C:
			case <-ctx.Done():
				timer.Stop()
				return
			}
			select {
			case results <- result{job: job}:
			case <-ctx.Done():
				return
			}
		}
	}
}

func run(ctx context.Context) error {
	jobs := make(chan int)
	results := make(chan result)
	var workers sync.WaitGroup
	for range 3 {
		workers.Add(1)
		go func() {
			defer workers.Done()
			worker(ctx, jobs, results)
		}()
	}
	go func() {
		defer close(jobs)
		for job := 1; job <= 8; job++ {
			select {
			case jobs <- job:
			case <-ctx.Done():
				return
			}
		}
	}()
	go func() {
		workers.Wait()
		close(results)
	}()

	for item := range results {
		if item.err != nil {
			return item.err
		}
		fmt.Println("completed", item.job)
	}
	return ctx.Err()
}

func main() {
	ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
	defer stop()
	if err := run(ctx); err != nil && err != context.Canceled {
		panic(err)
	}
}

任何生命周期设计最终都应能画成有限状态：created、running、stopping、stopped，并为每条转换标明触发者与确认者。缺少 stopped 的可观测证据，就还没有完成关停协议。

系列导航与关联阅读

系列入口：Go 完整技术体系学习路线：从语法、并发到框架、中间件与 AI
上一篇：Go 内存模型与数据竞争：happens-before 才是并发正确性
下一篇：Go 内存分配与逃逸分析：栈、堆、指针和分配成本
延伸：Go goroutine 与调度器：从 go 语句到 G-M-P 模型
延伸：Go context 完整指南：取消、超时、Deadline 与 Value
延伸：Go 并发模式：Worker Pool、Pipeline、Fan-out 与背压
进阶：Go 并发任务中的取消、超时与协程泄漏治理

官方资料

本文依据 Go 官方规范、标准库文档和 Go 官方博客重新梳理；正文与示例由 WR BLOG 编写。