Lock是非可重入互斥锁，同一线程重复acquire会死锁；RLock是可重入锁，支持同一线程多次acquire和对应次数的release，适用于递归或嵌套调用场景。
Lock 是最基础的线程互斥锁
lock 对象代表一个“非可重入”的互斥锁。它只有两种状态：锁定和未锁定。线程调用 acquire() 时，若锁已被其他线程持有，就会阻塞等待；一旦获得锁，必须由同一线程调用 release() 才能释放。关键点在于：同一个线程不能连续 acquire 两次，否则会死锁。
常见误用示例：
- 在已持有 Lock 的函数中，再次调用同一 Lock 的
acquire()→ 线程卡住 - 忘记调用
release()→ 其他线程永远无法获取该锁 - 在异常路径中未释放锁 → 建议用
try/finally或with语句确保释放
RLock 支持同一线程多次获取
RLock（Reentrant Lock）是可重入锁，允许同一线程多次调用 acquire()，内部维护一个获取计数器和持有线程标识。只有当该线程调用 release() 次数等于 acquire() 次数时，锁才真正释放，其他线程才能竞争。
适用场景包括：
- 递归调用中需保护共享资源（如递归遍历加锁的数据结构）
- 多个方法彼此调用，且各自内部都尝试加同一把锁
- 封装性要求高、不想严格区分“谁该负责加锁”的逻辑模块
性能与使用选择建议
RLock 内部开销略大于 Lock（需记录线程 ID 和计数），但差异微小，一般无需过度担忧。选择依据主要看语义需求：
立即学习“Python免费学习笔记（深入）”；
- 只用于简单临界区保护，且绝不会在已持锁状态下再次请求 → 用 Lock
- 涉及嵌套调用、递归、或多个函数共用一把锁且调用关系不固定 → 用 RLock
- 不确定是否重入、又不愿重构调用逻辑 → RLock 更安全，避免隐式死锁
一个直观对比小例子
假设有个类方法需要加锁，而该方法内部又调用了另一个也要加锁的私有方法：
- 用 Lock：第二次
acquire()会阻塞自己 → 死锁 - 用 RLock：计数变为 2，后续一次
release()只减计数，直到归零才真正释放 → 正常运行
所以不是“RLock 更高级”，而是“用途不同”——Lock 强调资源独占权的严格交接，RLock 强调同一线程内的执行流一致性。
