Python锁机制：RLock与Condition变量

理解RLock：可重入锁解决什么问题

普通 threading.Lock 是不可重入锁，同一线程若尝试第二次获取已被自身持有的锁，将直接陷入死锁。而 threading.RLock（可重入锁）内部维护了“所有者线程标识”与“递归计数器”。当同一线程重复调用 acquire() 时，计数器递增，不会阻塞；每次 release() 则递减，仅当计数器归零时锁才真正释放。这种特性在递归函数或嵌套加锁场景中至关重要。例如，在实现带缓存的递归计算时，若外层函数已加锁，内层调用再次尝试加锁，使用普通锁会导致程序永久挂起，而 RLock 允许安全嵌套。使用时必须严格保证 acquire 与 release 成对出现，推荐使用 with 上下文管理器自动管理计数器，避免因异常导致计数器泄漏。

掌握Condition：等待与通知如何协作

threading.Condition 本质是一把条件变量，它必须绑定一把底层锁（默认即为 RLock）。其核心语义在于协调线程间的状态依赖：线程在调用 wait()、notify() 或 notify_all() 前，必须先通过 acquire() 获取该条件锁。调用 wait() 时，当前线程会原子性地释放底层锁并进入阻塞队列，直到被其他线程唤醒；唤醒后，线程会尝试重新竞争并获取锁，随后继续执行。由于操作系统可能存在“虚假唤醒”（Spurious Wakeup），即线程未被显式通知却意外醒来，因此条件检查必须包裹在 while 循环中而非 if 语句。例如 while not data_ready: cond.wait() 能确保线程醒来后再次验证共享状态，避免在条件未满足时错误执行后续逻辑，这是编写健壮并发代码的基石。

组合RLock与Condition：实现线程协作

将 RLock 与 Condition 结合可构建高效的生产者-消费者模型。首先创建 lock = threading.RLock()，再实例化 cond = threading.Condition(lock)。生产者线程在 with cond: 块中向共享队列追加任务，随后调用 cond.notify() 唤醒一个等待的消费者；消费者线程同样在 with cond: 中执行 while not queue: cond.wait()，条件满足后安全取出任务并处理。该组合的优势在于 RLock 允许同一线程在复杂业务逻辑中多次进入临界区而不阻塞，而 Condition 提供了精准的线程调度能力。运行时可观察到：当队列为空时消费者自动挂起并释放锁，生产者写入后立即通知，消费者重新获取锁并消费，整个过程无忙等待，CPU 利用率稳定，且通过打印线程名与队列长度可清晰验证状态流转的正确性。

避坑与验证：死锁、误用和调试方法

实际开发中需警惕四大并发陷阱：其一，RLock 未成对释放会导致内部计数器无法归零，后续线程永久阻塞，可通过 faulthandler.dump_traceback() 或 threading.enumerate() 定位卡死线程；其二，修改共享状态时未持有 Condition 锁，会引发竞态条件，必须确保所有读写操作均在 with cond: 保护下；其三，用 if 替代 while 检查条件，遭遇虚假唤醒时将直接执行错误分支，务必坚持循环校验；其四，滥用 notify_all() 或在不改变状态时调用 notify()，会导致“惊群效应”或唤醒丢失，应精确匹配状态变更与通知时机。调试时建议为 wait() 设置合理 timeout 参数，配合结构化日志记录锁获取与释放时间戳，必要时使用 logging 模块输出线程调用栈，以快速还原死锁或饥饿现场。