C产品如何满足特定用户需求？

本文共计1092个文字，预计阅读时间需要5分钟。

直接说结论：

为什么不能用 lock 或 Monitor 替代 SemaphoreSlim

它们是同步原语，lock 会把线程池线程卡死在等待队列里，而你真正要控的是「同时发出去的请求数」或「同时执行的 I/O 操作数」，不是「谁先抢到 CPU 时间片」。比如发起 1000 个 HTTP 请求，用 lock 会导致线程池快速耗尽，响应延迟飙升；SemaphoreSlim 的 WaitAsync() 是异步挂起，不占线程，这才是匹配 async/await 的正确姿势。

• lock 和 Monitor 适合保护内存共享变量（如静态计数器），不适合控制资源访问节奏
• SemaphoreSlim 初始化时传入的数字是硬上限，比如 new SemaphoreSlim(4) 表示最多 4 个 WaitAsync() 能立刻返回，第 5 个必须等前面有人 Release()
• 它不依赖操作系统内核对象，比老式 Semaphore 开销低，尤其适合高吞吐 Web API

WaitAsync() 必须配 finally 中的 Release()

这是最常踩的坑：异常一抛，Release() 就没机会执行，许可数永远少一个。哪怕 WaitAsync() 成功了，后续操作（比如 HttpClient.SendAsync()）抛出 HttpRequestException，也得确保释放。

• 写法必须是：await semaphore.WaitAsync(); try { /* 实际操作 */ } finally { semaphore.Release(); }
• 不要用 using 包裹 SemaphoreSlim——它不是 IDisposable 资源型对象，Dispose() 只清理内部 Task 状态，不影响计数
• 别在 catch 块里 Release()：如果 WaitAsync() 自己超时抛出 OperationCanceledException，说明根本没拿到许可，此时调 Release() 会触发 ObjectDisposedException 或计数错乱

如何为不同资源设置独立的 SemaphoreSlim 实例

一个 SemaphoreSlim 实例只能管一类资源。混用会导致逻辑耦合、调试困难，比如用同一个实例既控数据库连接又控日志写入，某次日志慢了会拖垮整个订单处理流程。

• 按资源边界隔离：数据库操作用 _dbSemaphore = new SemaphoreSlim(10)，外部 API 调用用 _apiSemaphore = new SemaphoreSlim(5)
• 初始化 maxCount 要参考下游实际承载力：数据库连接池默认是 100，设成 15～20 较安全；API 限流常见是 3～10，避免被 429 拒绝
• 不要盲目设成 CPU 核心数：I/O 密集型场景（HTTP、DB）的并发瓶颈不在 CPU，而在网络带宽、连接池或远端服务响应能力

SemaphoreSlim 不保证执行顺序，也不防重入

它只管“有多少个能进”，不管“谁先进”。默认是非公平的，高并发下可能让后请求的线程先拿到许可。另外，同一线程可以连续调用多次 WaitAsync()（即支持重入），但每次都要对应一次 Release()，否则照样泄漏。

• 如果你需要严格 FIFO，得自己加队列 + TaskCompletionSource 手动排队，SemaphoreSlim 不提供该能力
• 重入场景真实存在：比如某个服务方法内部调用了另一个也受同一信号量保护的方法，这时要小心嵌套等待导致的死锁风险
• 性能上，SemaphoreSlim 在千级并发下依然高效，但若单次 WaitAsync() 平均等待时间超过 100ms，说明设定的并发数过小，该调大了

真正难的不是写对那几行代码，而是想清楚「这个信号量到底在保护什么资源」「它的上限是由哪一方决定的」——是数据库连接池？是第三方 API 的配额？还是你自己服务器的内存水位？定错边界，再严谨的 Release() 也救不了架构问题。