Python RLock、Semaphore 的适用场景_网络技术_宿州市腾雀网络科技有限公司

RLock适用于同一线程需多次获取同一锁的递归或重入场景，允许重复acquire并需对应次数release；Semaphore则用于控制并发数，允许多线程共享资源但限制总量，acquire与release可跨线程。

当一个线程需要多次获取同一把锁（比如在递归调用、重入方法中），用普通 Lock 会直接阻塞自己，导致死锁。而 RLock（可重入锁）允许同一线程重复调用 acquire()，只要对应次数的 release() 就能真正释放锁。

常见错误现象：threading.Lo

ck 在递归函数里卡住，CPU 占用低但程序不继续；报错信息里没有异常，只是静默挂起。

使用场景：

注意点：

RLock 比 Lock 开销略大，因为要维护持有线程 ID 和计数器
必须由同一个线程完成所有 acquire() 和 release()，跨线程调用 release() 会抛 RuntimeError: release unlocked lock
不解决“锁顺序不一致”导致的死锁，只解决“自己锁自己”的问题

Semaphore 的核心不是“互斥”，而是“限制同时访问的线程数量”。它内部维护一个计数器，acquire() 减一，release() 加一，计数器为 0 时阻塞。

典型使用场景：

和 Lock/RLock 的关键差异：

容易踩的坑：

有人看到 RLock 也能“控制进入”，就试图靠它限制并发线程数，这是错的。因为 RLock 的重入特性意味着：只要一个线程拿到锁，它就能无限次 acquire()，完全绕过限制。

示例问题代码：

lock = threading.RLock()
# 错误：下面这段对并发数毫无约束力
lock.acquire()
do_work()
lock.release()

这和用 Lock 效果一样，且更易引发隐藏 bug。真正要控并发，请明确用 Semaphore(value=3)。

另一个混淆点：BoundedSemaphore 是 Semaphore 的子类，会在 release() 超出初始值时抛异常，适合调试阶段捕获误释放。

决定用哪个，关键是回答两个问题：

性能上差异不大，但语义错位会导致极难复现的竞态。比如在连接池里误用 RLock，可能让单个线程占满所有连接却不释放，而其他线程干等。

最常被忽略的一点：Python 的 GIL 让纯计算密集型任务无法真正并行，所以这些同步原语主要保护的是 I/O、共享数据结构（如 dict、list）、或 C 扩展中释放 GIL 后的临界区——别在无共享的 CPU 绑定循环里白加锁。