semaphore管理共享资源的关键是：许可证数量需依资源实际承载力精准设定（如数据库连接池上限的70%～80%），acquire与release必须严格成对且置于finally块中，禁用公平模式以保障吞吐，python原生semaphore功能简陋应封装超时或改用asyncio.semaphore。
用Semaphore管理共享资源，关键不在“会不会调用acquire和release”，而在于三点：许可证数量设得准不准、获取与释放是否严格成对、异常路径有没有兜底。
许可证数量怎么定？看资源真实容量
设10个许可，不代表系统就能扛住10个并发——得结合资源实际承载力来算。比如数据库连接池最大支持20个连接，但业务平均每个请求耗时800ms，QPS峰值是50，那并发度理论值约40（50 × 0.8），但直接设40会挤占全部连接，应预留缓冲，通常取连接池上限的70%～80%，即设14～16个许可更稳妥。
常见误设：
- 凭感觉设5或10，没对照资源瓶颈（如文件句柄数、API配额、内存缓冲区大小）
- 初始化值大于资源实际可用数，导致多个线程抢到许可却在执行时失败（如连接超时、内存OOM）
- 运行中无法动态调整，遇到流量突增只能重启服务
acquire和release必须成对，且必须进finally
不进finally，一次异常就少一个许可，后续所有线程在acquire处永久阻塞。Java里标准写法是：
try {
semaphore.acquire();
// 执行可能抛异常的操作
doWork();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException(e);
} finally {
semaphore.release(); // 这一行不能少，也不能挪位置
}
Python同理，threading.Semaphore不支持中断，更得靠手动finally兜底；若用asyncio，需配合async with语义或显式await release()。
别乱开公平模式，吞吐会掉一截
Java中new Semaphore(n, true)启用公平队列，看似“先到先得”，实则让新来的线程哪怕遇到空闲许可也得排队等前面的人——这违背限流本意。非公平模式默认允许“插队”，只要许可空闲，立刻响应，高并发下吞吐提升明显。
公平模式只在极少数场景有用：
- 明确观测到某类长任务持续霸占许可，造成其他短任务严重延迟
- 调度偏差已影响SLA，且压测证实非公平模式引发不可接受的饥饿
日常限流、连接池、爬虫并发控制，一律用默认非公平模式。
Python用户特别注意：原生Semaphore功能很简陋
threading.Semaphore没有超时参数、不支持公平性、acquire(blocking=False)只返回bool，没法知道等了多久。一旦某个线程卡死没释放，整个信号量就冻结，只能靠监控+重启救急。
实用建议：
- 加超时逻辑：自己封装acquire_with_timeout，用time.time() + while循环轮询acquire(blocking=False)
- 用concurrent.futures.ThreadPoolExecutor配合max_workers间接控并发，比手管Semaphore更稳
- 关键服务优先迁移到asyncio.Semaphore，它支持await acquire()和timeout参数
