Go signal.Notify 怎样安全停止多个信号监听器

Go 里可以让多个通道同时注册同一组信号：每次收到信号时，各通道都会得到自己的通知副本。安全停止的关键不是关闭这些通道，而是对每个通道调用 signal.Stop，等它不再接收信号后，再退出对应的监听 goroutine。需要把一组后台工作统一取消时，则优先使用 signal.NotifyContext，并在收尾阶段调用它返回的 stop 函数。

官方资料：https://pkg.go.dev/os/signal

先分清 Notify、Stop 与 close 的职责

signal.Notify 建立的是“系统信号到 channel”的转发关系。对同一个信号注册多个不同通道时，包会分别向这些通道转发；它们不是从一个共享队列里抢同一条消息。signal.Stop 用来解除某个通道上的全部注册，返回后该通道不会再收到由 signal 包转发的新信号。

不要写 close(ch) 来代替 signal.Stop(ch)。通道的写入者是 os/signal 包，业务代码并不拥有它的发送端；直接关闭会把后续发送变成 panic 风险。可以由业务方关闭一个“监听器已退出”的完成通道，但不要关闭 Notify 的输入通道。

为多个监听器准备独立缓冲通道

如果一个服务里有主流程、指标收集和审计收尾三个监听器，可以分别准备容量为 1 的通道。官方文档指出，对于只关心某一种信号的通道，容量为 1 通常足够；信号到达频率和处理策略更复杂时，应结合自己的丢弃或合并策略调整。

package main

import (
	"fmt"
	"os"
	"os/signal"
	"syscall"
)

func main() {
	// 每个监听器有自己的通道，避免多个消费者抢同一条通知。
	mainCh := make(chan os.Signal, 1)
	metricsCh := make(chan os.Signal, 1)
	auditCh := make(chan os.Signal, 1)

	// 三次 Notify 都会接收 SIGINT 和 SIGTERM 的独立通知。
	signal.Notify(mainCh, os.Interrupt, syscall.SIGTERM)
	signal.Notify(metricsCh, os.Interrupt, syscall.SIGTERM)
	signal.Notify(auditCh, os.Interrupt, syscall.SIGTERM)

	// 示例只读取主监听器；生产代码应让另外两个监听器拥有自己的收尾协程。
	sig := 

这里的三个 Stop 最好由同一个生命周期管理者负责。这样可以明确谁注册、谁解除注册，也不会让某个监听器在主流程已经退出后继续保留信号处理行为。

让每个监听器先停止转发，再退出 goroutine

监听器如果需要持续处理信号，可以把 signal.Stop 放在退出路径的第一步，再通过独立的完成信号通知上层。关键顺序是：先停止新的信号转发，再让消费者退出，最后执行共享资源的收尾。

type listener struct {
	name string
	ch   chan os.Signal
	done chan struct{}
}

func (l *listener) run() {
	defer close(l.done) // 只由监听器自己关闭完成通道。

	for sig := range l.ch {
		fmt.Println(l.name, "处理", sig)
		// 真实项目可在这里设置一次性退出标记或通知工作组。
		break
	}
}

func stopListener(l *listener) {
	// Stop 返回后不再向 l.ch 转发信号，随后监听器可以安全结束。
	signal.Stop(l.ch)
	select {
	case 

上例中的 time.After 只用于展示等待边界，完整程序还需要导入 time。如果监听器可能收到多次信号，不要把“收到一次”直接等同于“所有工作已退出”；应使用 sync.Once、取消函数或统一的工作组状态保证收尾只执行一次。

用 NotifyContext 统一取消多个后台工作

当多个后台任务都能响应 context 时，NotifyContext 比手工维护多个信号通道更简单。它会在指定信号到达、父 context 取消或显式调用 stop 时结束派生 context。注意：stop 不只是“取消函数”，还负责解除信号行为并释放相关资源，因此即使业务任务通过其它原因结束，也应调用它。

func runService(parent context.Context) error {
	// stop 会在服务正常结束时释放 signal.NotifyContext 的资源。
	ctx, stop := signal.NotifyContext(parent, os.Interrupt, syscall.SIGTERM)
	defer stop()

	workersDone := make(chan struct{})
	go func() {
		defer close(workersDone) // 由工作组拥有完成通道。
		for {
			select {
			case 

这个写法把“收到信号”和“工作已收尾”分成两个状态：ctx.Done() 只代表应该停止，workersDone 才代表后台工作已经退出。若还存在必须单独监听原始信号的模块，可以保留独立的 Notify 通道，但要让它和统一的取消流程有清晰的所有权边界。

重复信号、重复 Stop 与通道所有权

生产环境里最容易出错的是第二次 Ctrl+C 或多个退出路径同时执行。建议把收尾入口做成幂等操作：第一次调用负责取消 context、停止监听和等待工作；后续调用只复用第一次的结果，不再次关闭通道或重复释放资源。

type shutdown struct {
	once sync.Once
	done chan struct{}
}

func (s *shutdown) request(cancel context.CancelFunc) {
	s.once.Do(func() {
		// 只允许一个路径发起取消和后续收尾。
		cancel()
		close(s.done)
	})
}

如果使用 NotifyContext，通常把 stop 放入同一个生命周期函数的 defer；如果使用多个 Notify，则集中保存每个通道并逐一调用 signal.Stop。不要把一个通道交给多个模块后再让其中任意模块决定关闭它，这会让资源所有权不可追踪。

一张表记住正确的停止方式

常见问题

多个 channel 会不会各自收到同一个 SIGTERM？

会。对不同 channel 调用 signal.Notify 时，每个 channel 都会独立收到匹配信号；它们不是共享消费队列。

signal.Stop 会关闭 channel 吗？

不会。它只解除信号转发关系。通道是否关闭应由通道所有者决定，但 Notify 通道通常不应由业务代码主动关闭。

为什么调用 stop 后还要等待 worker？

停止信号接收只表示不再接收新的退出通知，不代表数据库连接、文件写入或后台 goroutine 已经完成。应单独等待工作完成，并设置合理超时。

什么时候选 NotifyContext？

当多个任务都能通过 context 取消，且不需要读取原始信号值时，NotifyContext 更适合做统一退出入口；需要区分信号或让多个独立监听器分别消费时，再使用 Notify 加多个通道。

总结

安全停止多个 Go 信号监听器可以归纳为四点：每个监听器使用自己的缓冲通道；用 signal.Stop 解除注册而不是关闭 Notify 通道；统一任务取消时调用 NotifyContext 返回的 stop；把“收到退出请求”和“后台工作完成”分开等待。这样即使退出路径被重复触发，也能保持清晰的通道所有权和可控的进程收尾顺序。