好多問題呀，開始回答或者提問前，其實(shí)可以看看問題本身是不是有問題，像黃執(zhí)中一樣。

------

(相關(guān)資料圖)

這個(gè)問題首先前提就有問題，誰說協(xié)程那么好的？任何技術(shù)肯定都有自己的適用場景，這種通用層面的技術(shù)則更是了。

協(xié)程本質(zhì)上就是由用戶代碼主動(dòng)在某個(gè)時(shí)間點(diǎn)出讓 CPU，可以在任何一行出讓，當(dāng)然語言層或框架層的協(xié)程一般會(huì)在原本是阻塞函數(shù)的調(diào)用內(nèi)部，讓出 CPU 資源，不阻塞當(dāng)前線程。

當(dāng)然像 go 這種協(xié)程做的特別牛逼的，牛逼到它自己都不想承認(rèn)自己是協(xié)程的語言，就另說了。

所以協(xié)程一般適用于 IO 密集型的高并發(fā)場景。

你要說就完全 CPU 密集型計(jì)算，那還不如開你 CPU 核數(shù)那么多線程呢，開了協(xié)程反而不能并行了，還多了協(xié)程間切換的損耗。

所以協(xié)程那么好，這句話就可以否了，同時(shí)也順便拿出了一個(gè)場景，說明用協(xié)程替換線程是負(fù)優(yōu)化的，自然協(xié)程也不能完全替換線程。

------

再有，剛剛是站在應(yīng)用程序角度考慮，要分場景看是使用協(xié)程還是線程。再從操作系統(tǒng)層面考慮，協(xié)程就根本無法替代線程了。

你想，協(xié)程需要自己主動(dòng)出讓 CPU 資源，那要是操作系統(tǒng)使用協(xié)程來運(yùn)行應(yīng)用程序，那萬一應(yīng)用程序自己一直不出讓 CPU，也不調(diào)用能產(chǎn)生阻塞操作進(jìn)而間接出讓 CPU 的代碼，那不就壞事了。

再有，協(xié)程本身的優(yōu)勢在于切換成本小，本質(zhì)是因?yàn)闂Ｐ?，而且也不需要切換頁表。

那要是操作系統(tǒng)真的拿協(xié)程來跑多應(yīng)用程序，這些優(yōu)勢也就不復(fù)存在了，而且如果協(xié)程實(shí)現(xiàn)在了內(nèi)核態(tài)，本身從用戶態(tài)陷入內(nèi)核態(tài)的切換也少不了。

所以本來協(xié)程有的優(yōu)勢，在這里全沒了，還極大增加了不公平性。

------

最后，這倆事情本身就不好討論替換這一說，因?yàn)樗麄儽举|(zhì)都不一樣。

協(xié)程說白了就是一段串行的指令流，只不過中間哪個(gè)地方往哪跳的邏輯，被封裝在了 "協(xié)程" 這個(gè)概念里而已。

再者，協(xié)程本身也是要跑在線程中的，需要有載體，他們二者本身就是相輔相成的關(guān)系，何來替代呢，更別說完全替代了。

有時(shí)候，了解清楚一項(xiàng)技術(shù)的本質(zhì)，就能更好看清這些問題的荒誕了。

今天陽了躺在床上實(shí)在無聊，就挑了個(gè)知乎上的問題回答了一下，看好多回答都沒說在點(diǎn)子上，就碼了這些字，感興趣的同學(xué)可以點(diǎn)開閱讀原文看看。

關(guān)鍵詞： 應(yīng)用程序 操作系統(tǒng) 相輔相成的