最有效防死锁方式是显式调用lock.acquire(timeout=)并检查返回值，配合固定锁获取顺序和try/finally确保释放；with lock不支持超时，RLock不解决循环等待死锁。
直接用 lock.acquire(timeout=)，别用 with lock:
超时机制最有效、最可控的写法就是显式调用 acquire() 并传入 timeout 参数。用 with lock: 语法糖看似简洁，但它不支持传超时值，等于主动放弃防死锁能力。
必须配合 try/finally 确保释放：一旦 acquire() 成功返回 True，后续代码出异常也不能漏掉 release()；否则锁被永久持有，其他线程全卡住。
-
timeout值不能设为0就算完事——它只是非阻塞尝试，失败后没重试逻辑或回退策略，问题照旧 - 推荐设秒级值：
timeout=0.5适合缓存更新类轻量操作，timeout=3更适合依赖外部服务（如数据库查询、HTTP 请求）的场景 - 一定要检查返回值：
if not lock.acquire(timeout=2): raise RuntimeError("lock timeout")，漏掉这步等于白加
多个锁必须固定获取顺序，否则超时只是“延缓”死锁
超时解决的是单次等待失控，但无法打破循环等待这个死锁根因。比如线程 A 先拿 lock_a 再等 lock_b，线程 B 反过来先拿 lock_b 再等 lock_a，哪怕每个 acquire() 都带 timeout，也只是让它们轮流超时、反复失败，资源竞争逻辑没变。
真正要做的，是给所有锁定义全局顺序（比如按变量名排序、按资源重要性分级），所有线程严格遵守同一顺序请求。
立即学习“Python免费学习笔记（深入）”；
- 错误示范：
with lock_x: with lock_y:和with lock_y: with lock_x:混用 - 正确做法：统一写成
with lock_a: with lock_b:，哪怕某次只用到lock_b，也先申请lock_a（空占，或用if lock_a.acquire(timeout=0.1)快速跳过） - 复杂场景建议封装一个
acquire_all_locks(locks, timeout=1)函数，内部按序尝试，任意一步失败就全部回退
threading.RLock 不防死锁，别误当“安全锁”用
threading.RLock 解决的是同一线程重复进入临界区崩溃的问题（比如递归调用），不是多线程交叉等待导致的死锁。它照样满足死锁四条件——占有并等待、不可抢占、循环等待一个不少。
常见误用：用 RLock 替代多个 Lock 图省事，结果两把 RLock 还是按不同顺序获取，照样死锁；或者在 with rlock: 里又去抢别的 Lock，反而制造更隐蔽的等待链。
- 判断是否该用
RLock：只看有没有“同一个线程多次进同一段临界区”的需求，跟多线程协作无关 - 涉及多个资源协调时，一律用普通
Lock+ 固定顺序 + 超时，别混搭 -
RLock的acquire(timeout=)行为和Lock一致，该检查返回值、该配try/finally一点不能少
超时值不是越大越好，得结合业务容忍度动态调
设 timeout=30 看似保险，实际可能掩盖设计缺陷：如果一个本该毫秒级完成的内存计数操作，频繁走到 30 秒超时，说明锁粒度太大、临界区太长，或者根本不该加锁。
超时是兜底手段，不是性能优化方案。真正该做的是缩小临界区、拆分锁、用队列代替共享状态。
- 网络 I/O 类操作：超时应略大于下游服务 P99 延迟（比如查 Redis 设
timeout=0.3，查 MySQL 设timeout=2） - CPU 密集型临界区：超时应远小于单次任务预期耗时（比如处理一条消息预计 50ms，锁超时设
timeout=0.1） - 日志或监控中记录超时发生频率和堆栈：
sys._current_frames()可快速定位哪个线程卡在哪行acquire()
