lock是基础互斥锁，仅允许一个线程持有，不支持同线程重入；rlock为可重入锁，支持同线程多次acquire/release，记录持有者线程id并要求成对调用。
Lock 是最基础的互斥锁
Lock 表示一个简单的互斥锁，同一时间只允许一个线程获取它。一旦被某个线程 acquire 成功，其他线程再调用 acquire 就会被阻塞，直到该锁被 release。它不记录持有者信息，也不支持同一线程重复加锁。
常见误用场景：如果在同一线程中连续两次调用 acquire() 而中间没有 release()，第二次会一直阻塞（死锁）。
适用情况：
- 保护共享资源，且加锁/解锁逻辑严格配对
- 不同线程之间协作，无需递归调用锁
- 性能敏感、逻辑简单时优先考虑
RLock 支持同一线程多次加锁
RLock（可重入锁，Reentrant Lock）允许同一线程多次调用 acquire()，每次调用都会增加内部计数器；只有对应次数的 release() 才会让锁真正释放。它会记录当前持有锁的线程 ID，确保只有持有者才能释放。
立即学习“Python免费学习笔记（深入）”；
典型使用场景：函数内部可能间接再次进入加锁区域（比如递归调用、封装了加锁逻辑的工具方法）。
注意点：
- 必须由同一线程完成所有 release，否则抛出 RuntimeError
- 开销略大于 Lock（需维护线程ID和计数）
- 不能用于线程间同步等待（如 condition 变量需搭配 Lock）
关键区别一目了然
核心差异不在“是否可重入”，而在于所有权和计数机制：
- Lock 没有拥有者概念：谁都能 release（哪怕不是加锁者），容易引发逻辑错误
- RLock 有明确拥有者：只有加锁线程能 release，且必须成对调用
- Lock 不可重入 → 同一线程重复 acquire 会阻塞；RLock 可重入 → 允许嵌套加锁
- 两者都保证线程安全，但 RLock 更适合复杂调用链中的锁管理
怎么选？看实际需求
多数简单场景用 Lock 就够了——轻量、直观、不易出错。当代码结构导致可能在已持锁状态下再次请求同一把锁（例如 A 函数加锁后调用了 B 函数，B 内部又尝试加同一把锁），就必须换成 RLock。
小提醒：
- 不要因为“怕出错”就默认用 RLock，过度使用会掩盖设计问题
- 调试时若发现线程卡在 acquire，先检查是不是 Lock 被同一线程重复请求了
- 涉及 Condition、Semaphore 等高级同步原语时，底层通常要求传入 Lock 而非 RLock
