本文详解 go 应用在 upstart 环境下无法捕获 sigterm 的根本原因，并提供线程安全、生产就绪的信号处理方案，确保优雅退出前能准确采集运行时指标（如 goroutine 数量、内存分配量）。
本文详解 go 应用在 upstart 环境下无法捕获 sigterm 的根本原因，并提供线程安全、生产就绪的信号处理方案，确保优雅退出前能准确采集运行时指标（如 goroutine 数量、内存分配量）。
在使用 Upstart 管理 Go 编写的长期运行服务（如 TCP 服务器）时，常遇到 init:
问题根源在于 Go 主 goroutine 的生命周期失控。原代码中：
func main() {
sigc := make(chan os.Signal, 1)
signal.Notify(sigc, syscall.SIGTERM)
go func() {
s := <-sigc // 阻塞等待信号
// ... 日志与退出逻辑
os.Exit(1)
}()
someInfiniteLoopFunction() // ⚠️ 此处直接执行，main goroutine 不等待子 goroutine！
}someInfiniteLoopFunction() 启动后，若其内部未显式阻塞（例如无 select{} 或 time.Sleep），main 函数将立即返回，整个进程终止 —— 此时信号监听 goroutine 尚未获得调度机会，sigc 通道甚至未被真正监听，SIGTERM 自然被内核直接终止进程，而非投递到 Go 运行时。
更隐蔽的是：Go 的 signal.Notify 仅在至少有一个 goroutine 正在阻塞等待该信号通道 时才生效；若监听 goroutine 未被“保留住”，信号机制形同虚设。
✅ 正确做法是 强制主 goroutine 持有控制权，直到信号处理完成。推荐使用同步 channel 协调生命周期：
func main() {
sigc := make(chan os.Signal, 1)
done := make(chan struct{}, 1) // 使用 struct{} 更符合语义，零内存开销
signal.Notify(sigc, syscall.SIGTERM, syscall.SIGINT) // 建议同时监听 SIGINT（如 Ctrl+C）
go func() {
s := <-sigc
log.Printf("Received signal: %v", s)
// 采集关键运行时指标
numGoroutines := runtime.NumGoroutine()
var memStats runtime.MemStats
runtime.ReadMemStats(&memStats)
log.Printf("Active goroutines: %d", numGoroutines)
log.Printf("Heap memory allocated: %v bytes", memStats.Alloc)
log.Printf("Total GC cycles: %d", memStats.NumGC)
// ✅ 关键：此处可插入自定义清理逻辑
// e.g., 关闭 listener、等待 HTTP server Shutdown、通知子协程退出等
close(done) // 通知 main goroutine 可以安全退出
os.Exit(0) // 使用 0 表示正常终止（Upstart 依赖此码判断服务状态）
}()
// main goroutine 必须阻塞在此，确保监听 goroutine 有执行机会
<-done
// 注意：以下代码在收到信号后不会执行
someInfiniteLoopFunction()
}? 关键注意事项：
- done channel 必须在 os.Exit() 之前 发送信号（或 close()），否则
- 不要使用 time.Sleep 替代 channel 同步——它不可靠且违背并发设计原则；
- signal.Notify 应在 goroutine 启动前调用，确保信号注册时机正确；
- 生产环境建议同时监听 SIGINT 和 SIGTERM，兼容手动调试与系统管理；
- 若 someInfiniteLoopFunction 本身需响应信号（如 graceful shutdown），应将其改造为接收 context.Context 并配合 done channel 实现协同退出。
总结：Go 中信号处理不是“注册即生效”，而是依赖于 goroutine 的存活与通道的阻塞行为。通过 channel 显式同步主协程与信号处理器，既能保证信号必达，又能确保退出前完成诊断与清理，这是构建高可靠性服务的基础实践。
