在 Go 并发编程中，信号量用于控制同时访问共享资源的 goroutine 数量，常用于限制数据库连接、外部 API 调用或文件句柄的并发。实现方式主要有两种：基于带缓冲 channel 的自制信号量，和标准库扩展包 golang.org/x/sync/semaphore 的 Weighted 类型。选择哪种需要结合项目依赖和业务场景判断，下面给出可执行的处理路径和检查点。
先别急着改配置：确认你的信号量实现
很多团队在初期会直接用 channel 模拟信号量，但后来维护时容易混淆缓冲区长度和信号量计数的含义。如果你在 review 代码时看到类似 sem := make(chan struct{}, 3)，这就是一个容量为 3 的计数信号量。素材中有一段典型说明：
在Go中，信号量通常通过带缓冲的channel来实现，因为channel的send和receive操作天然具备阻塞和唤醒语义。初始化一个容量为N的channel即相当于创建了一个计数信号量，其中N表示最大并发访问数。例如，sem := make(chan struct{}, 3)表示最多允许3个goroutine同时访问受保护的资源。当channel满时，后续的send操作会阻塞，直到有goroutine执行receive操作释放一个槽位。
这种实现简单，但需要手动确保 acquire 和 release 配对。如果项目中已经引入了 golang.org/x/sync 包，建议优先考虑 semaphore.Weighted，因为它内置了 context 支持和更清晰的 API。素材中给出了具体用法：
标准库的golang.org/x/sync/semaphore包提供了Weighted类型，可以更灵活地控制资源访问。通过semaphore.NewWeighted(n)创建信号量，其中n为最大并发数。调用Acquire(ctx, 1)会阻塞直到获取到资源，Release(1)释放资源。需要注意的是，Acquire可以接受context.Context以支持超时和取消，这在避免死锁时非常有用。例如，使用context.WithTimeout设置超时时间，防止goroutine永久阻塞。
如果你在遗留代码中发现 channel 实现且没有超时控制，可以先评估是否需要迁移。迁移成本不大：替换声明、修改 acquire/release 调用，并引入 context。
信号量控制的典型模式：加上 defer 就对了
无论哪种实现，使用模式几乎一样。素材中提供了一个可靠的代码骨架：
在业务代码中，信号量常用于限制对数据库连接池、外部API或文件句柄的并发访问。典型模式是：初始化信号量，在访问资源前调用Acquire，完成后在defer中Release。例如：sem.Acquire(ctx, 1); defer sem.Release(1)。这样即使发生panic也能确保资源释放。注意，释放次数必须与获取次数匹配，否则会导致信号量计数错误，引发资源泄漏或意外阻塞。
这个模式的核心是 defer sem.Release(1) 紧跟在 Acquire 之后，不要提前声明 defer 或放在后面容易遗漏的地方。代码审查时可以重点关注：如果看到 sem.Release 不在 defer 中，或者有的分支没有 release，就标记为风险项。
避免死锁和资源泄漏的检查点
使用信号量最容易出的问题是忘记释放，或嵌套获取导致死锁。素材中提到：
另一个风险是嵌套获取信号量引发的死锁，例如goroutine获取了信号量A后又去获取信号量B，而其他goroutine以相反顺序获取。解决方法包括统一获取顺序、使用tryAcquire（非阻塞尝试）或设置超时。
排查时可以从以下几个点入手：
- 检查所有 acquire 路径是否都有对应的 release。 特别关注 if-else 分支、switch 分支和循环中的 break/continue。使用
defer可以简化，但如果 acquire 在循环内，defer 会在循环结束后才执行，可能导致并发数超过预期。此时应该在内层手动 release 或使用带超时的 acquire。 - 确认嵌套获取的顺序是否全局一致。 如果 A 持有信号量 S1 后去获取 S2，那么所有 goroutine 都必须按这个顺序。不一致时会死锁。可以在代码中抽取出独立的锁层级接口，或使用单一全局信号量代替多层。
- 给 acquire 加超时或 context 取消。 即使不嵌套，如果资源一直不释放（比如下游 API 卡住），acquire 会阻塞整个 goroutine。设置一个合理的超时，超时后记录日志并返回错误，避免 goroutine 泄漏。
调试信号量问题的实用步骤
当线上出现 goroutine 持续增长或接口超时，信号量问题是一个排查方向。素材中提供了基础手段：
对于channel实现的信号量，使用len(sem)获取当前等待数，cap(sem)获取最大容量。对于semaphore.Weighted，可通过反射或添加日志记录获取计数。常见排查方法：在Acquire和Release附近添加日志，打印goroutine ID和时间戳；或使用pprof的goroutine profile查看阻塞栈。如果信号量计数长时间不为0，说明有资源未释放。
实际操作中，可以按以下步骤来：
- 导出 pprof 的 goroutine 信息：
go tool pprof http://localhost:6060/debug/pprof/goroutine，观察是否有大量 goroutine 在chan send或semacquire处阻塞。阻塞栈会停在 acquire 调用处，排查对应代码。 - 如果使用 channel 实现，在监控接口暴露当前信号量状态：
len(sem)表示已占用槽数，cap(sem)-len(sem)表示剩余容量。持续记录变化，如果剩余容量长时间为 0 且没有波动，说明所有槽位被占用且没有释放。 - 对于
semaphore.Weighted，官方没有暴露计数方法，但可以通过封装一层，在 acquire 前计数加 1，release 后减 1，配合 prometheus 或日志观察。注意并发安全。 - 如果怀疑某个 acquire 后未 release，可以在 release 处添加日志并打印 goroutine ID，对比 acquire 和 release 的配对情况。也可以利用
runtime.Stack生成栈信息。
信号量与互斥锁的选择边界
新手常问何时用信号量何时用 sync.Mutex。素材中给出了原则：
信号量主要用于控制并发数量，允许多个goroutine同时访问资源，但限制总数；而互斥锁（sync.Mutex）保证同一时刻只有一个goroutine访问资源。选择依据是：若资源允许并发读或有限并发写（如连接池），用信号量；若需互斥访问（如修改共享内存），用互斥锁。注意，信号量也可以实现互斥（容量为1时），但语义上不如Mutex直观，且性能略有损耗。
如果只是保护一个共享变量的写入，不要用容量为 1 的信号量代替 mutex，既降低可读性又多一次 channel 操作的开销。信号量特别适合“最大并发数”场景，比如限制同时只允许 5 个 goroutine 调用第三方 API，即使 API 本身是幂等的。确认场景后，再决定实现。
最后，信号量控制不是银弹，如果并发数限制太小会导致吞吐量下降，太大则达不到保护效果。建议先根据资源瓶颈（如连接池大小、API 限频）设定初始值，上线后通过监控调整。不要在生产环境突然大幅改动，可以先在灰度环境验证 goroutine 行为和资源使用率。