Tokio 的 task (一个 Future ) 里如果使用了阻塞调用，例如 std::sync::Mutex，会阻塞当前的 tokio-worker 线程，这个 worker 无法再执行其他 task。所以代码里如果不可避免的有(少量的)阻塞调用，就要为 runtime 启动更多的 worker 线程，保证存在没被阻塞的 worker 来执行待调度的 task，以避免整个 tokio runtime 完全 hang 住(有 task 但没 worker 运行它)。
但现实是，就算 worker 再多，tokio 也可能造成永久性的阻塞。
原因是 tokio 里的待执行 task 不是简单的放到一个 queue 里，除了 runtime 内共享的，可被每个 worker 消费的 run_queue ，每个 worker 还有一个自己的 lifo_slot ，只存储一个最后被放入的 task (目的是减小调度延迟)。lifo_slot 只由它所属的 worker 使用，里面存储的 task 不能被其他 worker 执行。由于这个结构，构造 hang 住的方法是如图所示：
Future f1 被 runtime-1 执行， 持有一个 async 的锁 m 后，返回了 Pending ，这时它被调度到 worker-1 本地的 lifo_slot。
Future f2 在 runtime-1 执行后返回 Pending，被放入共享队列 run_queue。
Future f3 在 runtime-1 中执行, 它将一个任务 f4 交给其他的 runtime 去完成(例如为了隔离网络IO和本地磁盘IO)，使用 block_on(f4) 的方式，等待执行结果返回。
f4 中也需要锁 m，等待。
这时，f2 在共享队列 run_queue 中，可以被执行，但是 f1 在 worker-1 本地的 lifo_slot 里，只能由 worker-1 调度，但 worker-1 当前阻塞在 f3。于是等待关系形成了一个环: f4 → m(f1) → f3 → f4，hang 死任务达成。
![图片]()
张炎泼（XP） @ Databend
前白山云合伙人兼研发总裁
曾就职于新浪、美团云等。物理系背叛者，设计师眼中的美工，bug mafer，vim 死饭，研究分布式协议
关于 Databend
Databend 是一款开源、弹性、低成本，基于对象存储也可以做实时分析的新式数仓。期待您的关注，一起探索云原生数仓解决方案，打造新一代开源 Data Cloud。
