threading.Lock本质是操作系统级互斥量，封装pthread_mutex或CRITICAL_SECTION，能真正阻塞线程；GIL不保护用户数据，需显式加锁同步共享状态；推荐用with语句确保释放，注意锁粒度与死锁风险。
Python 的 threading.Lock 本质是操作系统级互斥量
CPython 解释器中，threading.Lock 并非纯 Python 实现，而是对底层 pthread_mutex（Linux/macOS）或 Windows CRITICAL_SECTION 的封装。这意味着它能真正阻塞线程、让出 CPU，而不是忙等——这点和 threading.Semaphore(1) 行为一致，但语义更明确。
关键点在于：GIL（全局解释器锁）不负责保护用户数据，只保护解释器内部状态。所以即使有 GIL，多个线程并发修改同一个字典或列表仍会出错，必须用 Lock 显式同步。
- 创建开销小，但每次
acquire()/release()涉及系统调用，频繁争抢会明显拖慢性能 - 不可重入：同一个线程重复
acquire()会死锁；需要可重入场景请改用threading.RLock - 不支持超时的
acquire()在 Python 3.2+ 才加入timeout参数，旧版本只能靠信号量或手动轮询
什么时候用锁，什么时候根本不用
不是所有共享变量都需要加锁。核心判断依据是「是否发生复合操作」——即读-改-写（read-modify-write）三步无法原子完成。
比如 counter += 1 看似一行，实际被拆成 LOAD、INCR、STORE 三步，中间可能被切换；而单纯赋值 flag = True 或读取 config['timeout'] 是安全的（前提是其他地方没在同时改这个 key）。
立即学习“Python免费学习笔记（深入）”；
- 安全场景：
logging.info()调用、只读访问不可变对象（str/tuple/NamedTuple）、单次赋值 - 危险场景：
list.append()、dict.update()、queue.get()（虽然queue内部已加锁，但自定义队列需自行处理） - 容易误判的：
+=对list是就地修改（需锁），对str是新建对象（无需锁，但通常也不该这么用）
with 语句是唯一推荐的锁使用方式
直接调用 acquire() 和 release() 极易漏掉释放，尤其遇到异常或提前 return。Python 的上下文管理器能保证无论什么路径退出代码块，锁都会被释放。
lock = threading.Lock()
# ✅ 推荐
with lock:
shared_data.append(item)
<h1>❌ 危险（异常时 lock 不会被释放）</h1><p>lock.acquire()
shared_data.append(item)
lock.release() # 这行可能永远执行不到
-
with lock:底层调用的是__enter__/__exit__，和手动acquire/release效果等价 - 若需超时获取锁：
with lock: # 不支持 timeout→ 改用if lock.acquire(timeout=0.1): ... lock.release() - 不要在
with块内做耗时操作（如网络请求、文件读写），否则会人为拉长临界区，成为性能瓶颈
锁粒度与嵌套死锁的真实代价
锁太粗（比如整个函数包一个锁）会严重限制并发；锁太细（每行都加锁）又增加管理成本和死锁风险。最隐蔽的问题是锁顺序不一致导致的死锁。
例如线程 A 先锁 lock_a 再锁 lock_b，线程 B 反过来先锁 lock_b 再锁 lock_a —— 两者卡住互相等待，程序彻底僵死，且 Python 不提供锁依赖检测。
- 固定锁顺序：按变量名、地址或预定义编号统一加锁顺序（如总是先
acquire(lock_x)再acquire(lock_y)） - 避免嵌套锁：一个函数尽量只持有一个锁；若必须多锁，确保所有调用路径遵循相同顺序
- 调试技巧：用
threading.settrace()或第三方库（如deadlock-detector）辅助定位，但生产环境慎用
真正难的从来不是“怎么加锁”，而是识别哪些状态变化必须原子、哪些锁可以合并、哪些操作其实该移到进程间通信里去——这些判断没法靠语法糖解决。
