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() 就没机会执行，许可数永远少一个。