工作窃取通过超时机制、统一锁序、主动熔断三大策略防死锁：窃取操作设0.05～0.2秒超时，多锁按ID升序获取，停滞队列自动熔断并探测恢复。

多线程分治计算中，工作窃取（work-stealing）本是提升负载均衡的利器，但一旦某个工作队列因锁竞争或资源依赖陷入死锁，它就不再“可窃取”，反而会拖住整个窃取链条——其他空闲线程反复尝试从该队列取任务，却在 acquire() 上无限阻塞，最终所有线程卡死。这不是局部故障，而是全局冰封。破解关键在于**不让死锁发生，更不让死锁扩散**。

用超时机制给每次窃取加“安全阀”

工作窃取的核心操作（如从双端队列 pop 或 tryDequeue）若内部涉及锁（比如队列本身加锁、或任务执行前需获取共享资源），必须避免无条件等待：

• 不用 with lock:，改用 if lock.acquire(timeout=0.1): ... lock.release()，超时即放弃本次窃取，转向下一个队列
• 对任务执行阶段也设防：若任务需持有多把锁，每把锁都带 timeout，任意一步失败就标记该任务为“临时不可执行”，推回队列尾部或转入重试池，不阻塞窃取线程
• 超时值不宜过长——0.05～0.2 秒足够覆盖正常队列访问延迟；过长仍可能引发级联等待

统一锁序 + 锁封装，从源头掐断循环等待

分治任务常需访问共享状态（如合并结果缓存、全局计数器、中间数据区），不同子任务若按随机顺序申请锁，极易形成 A→B→C→A 的环路：

• 为所有参与分治的共享资源预定义唯一编号（如按变量名哈希、或显式赋值 LOCK_ID = 101），任何线程申请多个锁时，强制按 ID 升序 acquire
• 封装一个安全加锁函数：acquire_all_sorted(*locks)，内部自动排序并逐个带超时获取，任一失败则释放已获锁并返回 False
• 避免在递归分治的每一层都新建锁对象——复用顶层定义的有限锁集，减少锁数量本身就能降低环路概率

主动探测与熔断，不让一个队列拖垮全局

当某队列长时间无法被窃取（例如连续 3 次超时或阻塞超 500ms），不能让它继续“假装健康”：

• 每个工作队列维护一个“最后成功窃取时间戳”，调度器定期扫描，对停滞超阈值的队列触发熔断：将其标记为 DISABLED，后续窃取请求直接跳过
• 熔断不是永久隔离——另起一个低优先级监控线程，每隔几秒尝试轻量探测（如仅检查队列非空且无锁争用），恢复后重新启用
• 配合日志：记录熔断原因（“lock_b timeout ×3”、“持有 lock_a 等待 lock_c 超时”），直指死锁苗头

用 RLock 替代 Lock？不，那是错觉

有人想用 threading.RLock 避免同一线程重复加锁崩溃，但它对工作窃取场景毫无帮助：

• RLock 解决的是单线程递归重入问题，而窃取是多线程跨队列协作，死锁永远发生在“线程A等线程B的锁，线程B等线程A的锁”之间
• 若错误地用同一把 RLock 保护多个逻辑资源，反而扩大了“占有并等待”范围，更容易卡死
• 真正需要的是细粒度锁 + 明确边界，而不是一把万能大锁