Tokio^[1]的 task (一個(gè) Future ) 里如果使用了阻塞調(diào)用，例如std::Mutex，會(huì)阻塞當(dāng)前的 tokio-worker 線程，這個(gè) worker 無(wú)法再執(zhí)行其他 task。所以代碼里如果不可避免的有(少量的)阻塞調(diào)用，就要為 runtime 啟動(dòng)更多的 worker 線程，保證存在沒(méi)被阻塞的 worker 來(lái)執(zhí)行待調(diào)度的 task，以避免整個(gè) tokio runtime 完全 hang 住(有 task 但沒(méi) worker 運(yùn)行它)。

但現(xiàn)實(shí)是，就算 worker 再多，tokio 也可能造成永久性的阻塞。

原因是 tokio 里的待執(zhí)行 task 不是簡(jiǎn)單的放到一個(gè) queue 里，除了 runtime 內(nèi)共享的，可被每個(gè) worker 消費(fèi)的run_queue^[2]，每個(gè) worker 還有一個(gè)自己的lifo_slot^[3]，只存儲(chǔ)一個(gè)最后被放入的 task (目的是減小調(diào)度延遲)。lifo_slot只由它所屬的 worker 使用，里面存儲(chǔ)的 task 不能被其他 worker 執(zhí)行。由于這個(gè)結(jié)構(gòu)，構(gòu)造 hang 住的方法是如圖所示：

• ?Future f1 被 runtime-1 執(zhí)行， 持有一個(gè) async 的鎖m后，返回了Pending，這時(shí)它被調(diào)度到 worker-1 本地的lifo_slot。

• ?Future f2 在 runtime-1 執(zhí)行后返回Pending，被放入共享隊(duì)列run_queue。

• ?Future f3 在 runtime-1 中執(zhí)行, 它將一個(gè)任務(wù)f4交給其他的 runtime 去完成(例如為了隔離網(wǎng)絡(luò)IO和本地磁盤(pán)IO)，使用block_on(f4)^[4]的方式，等待執(zhí)行結(jié)果返回。

• ? f4 中也需要鎖m，等待。

這時(shí)，f2 在共享隊(duì)列run_queue中，可以被執(zhí)行，但是 f1 在 worker-1 本地的lifo_slot里，只能由 worker-1 調(diào)度，但 worker-1 當(dāng)前阻塞在 f3。于是等待關(guān)系形成了一個(gè)環(huán):f4 → m(f1) → f3 → f4，hang 死任務(wù)達(dá)成。

審核編輯 ：李倩