rlock允许同一线程多次acquire，lock不行；rlock内部维护线程id和计数器，支持递归调用，但不可用于跨线程等待，也不能与lock混用acquire/release。
RLock 允许同一线程多次 acquire，Lock 不行
这是最直接的差异点：如果一个线程已经持有了 Lock，再次调用 acquire() 会阻塞自己；而 RLock（可重入锁）允许同一线程反复调用 acquire()，只要 release() 次数匹配就行。
典型场景是递归函数或嵌套调用中需要加锁——比如某个方法内部调用了另一个也需加锁的方法。用 Lock 就会卡死，RLock 才能正常工作。
- 错误现象：
Lock.acquire()在同一线程里第二次调用时永久阻塞，CPU 占用不升，程序“假死” -
RLock内部维护了持有线程 ID 和计数器，只有同一线程且计数归零才真正释放 - 性能上
RLock略重（多一次线程 ID 判断和计数操作），但绝大多数场景差异可忽略
不能混用 RLock 和 Lock 的 acquire/release
RLock 必须用它自己的 acquire()/release() 配对，不能拿 Lock 的实例去 release 一个 RLock，反之亦然。这不是类型检查问题，而是语义错配。
常见误用是在类初始化时定义了一个 Lock，后来改成 RLock，但忘了检查所有 release() 调用点是否仍兼容——尤其当锁对象被传进其他模块或作为参数传递时。
立即学习“Python免费学习笔记（深入）”；
- 错误现象：
RuntimeError: release unlocked lock或cannot release un-acquired lock - 注意：即使你只在一个地方改了锁类型，也可能影响多个调用路径
- 调试建议：在关键路径加日志，打印
threading.current_thread().ident和锁对象 id，确认 acquire/release 成对且来自同一上下文
RLock 无法用于跨线程同步等待
RLock 的设计目标不是解决线程间协作，而是解决单线程内重入问题。它不支持 wait()/notify()，也不能替代 Condition。
有人试图用 RLock + 循环 sleep 来实现“等待某条件成立”，结果发现既低效又容易漏信号——因为 RLock 没有唤醒机制。
- 使用场景错配：需要等待外部事件（如数据就绪、任务完成）时，该用
threading.Condition或threading.Event -
RLock和Lock都只是互斥工具，不带状态通知能力 - 若强行用
RLock做条件等待，大概率出现忙等或死锁，且难以复现
with 语句下 RLock 和 Lock 表现一致但语义不同
两者都支持 with lock: 语法，自动处理 acquire/release，看起来没区别。但一旦发生异常或提前 return，RLock 的计数逻辑仍会正确回退，而 Lock 因为不允许重入，反而更“刚性”——出错时更容易暴露未配对的调用。
也就是说，with 并不能掩盖底层差异，只是让基础用法更安全。
- 示例：
with rlock:进入后又调用另一个也用rlock的函数，没问题；换成lock就会在第二层with卡住 - 别以为写了
with就高枕无忧——嵌套调用链里的锁对象是否统一，才是关键 - 真实项目中，建议在模块顶层明确声明用的是
RLock还是Lock，并在文档里写清理由，避免后续维护者误判
重入性不是免费的，它是以额外状态跟踪为代价换来的便利。很多看似“应该能重入”的地方，其实只需要把锁粒度调细、或者重构调用关系，就能避开对 RLock 的依赖。真要用，就得从一开始就把它当作契约的一部分，而不是临时救急的补丁。
