協(xié)程這么好，它能完全代替線程么？

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

------

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

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

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

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

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

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

------

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

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

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

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

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

------

最后，這倆事情本身就不好討論替換這一說，因為他們本質(zhì)都不一樣。

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

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

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

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