Python的threading.Lock底层绑定操作系统原生互斥锁（如pthread_mutex_init或CreateMutex），acquire/release直接操作内核态对象，真正阻塞而非轮询；它不感知GIL，仅保护用户指定共享数据。
Python 的 threading.Lock 底层靠什么工作？
它不靠 Python 字节码或解释器魔法，而是直接绑定操作系统原生互斥锁（mutex）。CPython 解释器在创建 threading.Lock 实例时，会调用 pthread_mutex_init（Linux/macOS）或 CreateMutex（Windows），后续的 acquire() 和 release() 就是在操作这些系统级对象。
这意味着：只要线程被 OS 调度、且能进入内核态等待，Lock 就能真正阻塞——不是轮询，也不是 Python 层面的“假装等”。但这也带来一个关键约束：Lock 对 GIL 无感知，它保护的是你指定的共享数据，不是 Python 对象的内部状态。
为什么 with lock: 比手动 acquire()/release() 更安全？
因为异常会打断执行流，手动调用容易漏掉 release()，导致死锁。而 with 语句通过上下文管理器协议，保证无论是否发生异常，__exit__ 都会被调用，从而释放锁。
常见错误现象：acquire() 后抛出 KeyError 或 NetworkError，没走到 release()，后续所有线程卡在 acquire() 上。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 永远优先用
with lock:，除非你明确需要非阻塞获取（这时用lock.acquire(blocking=False)） - 不要在
with块里做耗时操作（比如 HTTP 请求、文件读写），否则锁持有时间过长，拖慢并发效率 - 如果必须提前退出，用
return或raise都没问题，with仍会释放锁
RLock 和普通 Lock 在递归调用时的区别
普通 Lock 不允许同一线程重复 acquire()，第二次就会永久阻塞；RLock（可重入锁）则记录持有线程和计数，同一线程可多次获取，但必须调用相同次数的 release() 才真正释放。
使用场景：类方法之间相互调用，且各自都试图加锁——比如 add_item() 调用了 validate()，而两者都尝试拿同一把锁。
- 误用
Lock会导致看似“无理由”的卡死，错误现象是线程停在某个acquire()上，threading.enumerate()显示它还在运行 -
RLock有额外开销（要存线程 ID、维护计数），性能略低于Lock，别为图省事默认全用RLock -
RLock不能被其他线程release()，只有持有者才能释放，这点和Lock一致
锁粒度太粗会掩盖真正的并发问题
比如整个函数体包在一个 with lock: 里，看起来线程安全了，实则把本可并行的操作串行化，吞吐量掉一半，还可能让你误以为“加了锁就万事大吉”，忽略对共享数据访问路径的梳理。
真正该锁的，只是读写同一块内存（如全局 dict、实例变量）的那几行代码，而不是“整个业务逻辑”。
- 检查所有共享变量：哪些被多个线程读？哪些被写？读写是否需要原子性？
- 避免锁住 I/O 操作（
requests.get()、open()）、数据库查询等——它们本身不共享内存，加锁反而降低并发度 - 如果发现多个不相关的共享变量共用一把锁，考虑拆成多把锁（如
item_lock和stats_lock），但要注意避免锁顺序不一致引发死锁
最常被忽略的一点：锁只解决竞态条件，不解决逻辑错误。比如两个线程都读到 count=5，各自加 1 再写回，结果还是 6——这种得靠原子操作（threading.local、队列、或更高层的同步原语）来破，不是多加几把锁就能绕过去的。
