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

------

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

【資料圖】

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

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

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

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

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

------

再有，剛剛是站在應(yīng)用程序角度考慮，要分場(chǎng)景看是使用協(xié)程還是線程。再?gòu)牟僮飨到y(tǒng)層面考慮，協(xié)程就根本無(wú)法替代線程了。

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

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

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

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

------

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

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

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

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

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