当需控制最多N个线程并发访问资源（如连接池限流）时用Semaphore；Lock仅适用于互斥场景。Semaphore(5)可配数据库连接池，设0会死锁，过大则失效；acquire(timeout)只限制排队超时，不保障整体操作时限；多进程须用multiprocessing.Semaphore或Manager；异步代码必须用asyncio.Semaphore并await，禁用threading版。
什么时候该用 threading.Semaphore 而不是 threading.Lock
当你要控制「同时最多 N 个线程」访问某资源，而不是「只允许 1 个」时，Semaphore 才有意义。比如连接池限流、API 调用配额、文件句柄复用——这些都不是“互斥”，而是“配额管理”。用 Lock 硬扛只会把并发压到 1，吞吐直接掉底。
- 常见错误：把数据库连接池的并发控制写成
Lock，结果所有请求排队等一个连接 - 典型场景：
Semaphore(5)配合数据库连接池，保证最多 5 个查询并行执行 - 注意初始化值：设成 0 就永远卡住；设得太大等于没限（比如设成 1000 但实际机器只有 2 核）
- 性能影响：
Semaphore内部也是基于条件变量实现的，争抢激烈时会有唤醒开销，但比自己手写计数 +Lock更可靠
acquire() 的 timeout 参数为什么经常失效
它只管等待阶段是否超时，不保证“拿到信号量后操作一定来得及完成”。很多人误以为设了 timeout=2 就能防住整个请求超时，其实只是防住了排队时间。
- 错误现象：
sem.acquire(timeout=2)返回False，但上游 HTTP 请求已耗时 5 秒——因为前面 3 秒在做参数校验、日志记录等非临界区操作 - 正确做法：把
timeout当作“排队许可”的截止时间，业务逻辑的总耗时需另外用signal.alarm或 asyncio.timeout 包裹 - 兼容性坑：Windows 下
signal.alarm不可用；Python 3.11+ 推荐用asyncio.wait_for配合asyncio.Semaphore - 别依赖
acquire(blocking=False)做快速失败——它可能因 GIL 切换瞬间错过释放，导致误判
多进程里用 multiprocessing.Semaphore 会出什么问题
它不能跨进程共享状态，除非显式传给子进程或通过 multiprocessing.Manager 包装。直接在父进程中创建、子进程中引用，每个进程都有一份独立副本。
- 错误现象：主进程
sem = Semaphore(3)，fork 出 4 个子进程，每个都能无阻塞调用acquire()—— 实际并发变成 12 - 解决路径：用
multiprocessing.Manager().Semaphore(3)，或者更轻量的multiprocessing.Semaphore配合ctx=mp.get_context('spawn')初始化 - 性能代价：Manager 方式走进程间通信，比纯内存快不了多少；spawn 模式启动慢，但语义清晰
- 替代思路：高并发服务优先考虑异步（
asyncio.Semaphore）或外部限流（Redis + Lua 计数），避免进程内复杂同步
和 asyncio.Semaphore 混用时最常踩的坑
绝对不要在一个 async 函数里调用 threading.Semaphore.acquire()。它会阻塞整个 event loop，让所有协程卡死。
立即学习“Python免费学习笔记（深入）”；
- 错误写法：
await asyncio.sleep(0); sem.acquire()——acquire()是同步阻塞调用，loop 进不去下一轮 - 正确对应：异步代码必须用
asyncio.Semaphore，且acquire()要用await；同步代码就老实用threading.Semaphore - 混合场景（比如 async 函数里要调用同步 SDK）：用
loop.run_in_executor包一层，但记得 executor 里的 semaphore 也得是threading版本 - 容易忽略：
asyncio.Semaphore不受 GIL 影响，但它的计数器是协程安全的——这点比手动if count > 0: count -= 1可靠得多
