协程这么好,它能完全代替线程么?
共 893字,需浏览 2分钟
·
2022-12-17 11:40
好多问题呀,开始回答或者提问前,其实可以看看问题本身是不是有问题,像黄执中一样。
------
这个问题首先前提就有问题,谁说协程那么好的?任何技术肯定都有自己的适用场景,这种通用层面的技术则更是了。
协程本质上就是由用户代码主动在某个时间点出让 CPU,可以在任何一行出让,当然语言层或框架层的协程一般会在原本是阻塞函数的调用内部,让出 CPU 资源,不阻塞当前线程。
当然像 go 这种协程做的特别牛逼的,牛逼到它自己都不想承认自己是协程的语言,就另说了。
所以协程一般适用于 IO 密集型的高并发场景。
你要说就完全 CPU 密集型计算,那还不如开你 CPU 核数那么多线程呢,开了协程反而不能并行了,还多了协程间切换的损耗。
所以协程那么好,这句话就可以否了,同时也顺便拿出了一个场景,说明用协程替换线程是负优化的,自然协程也不能完全替换线程。
------
再有,刚刚是站在应用程序角度考虑,要分场景看是使用协程还是线程。再从操作系统层面考虑,协程就根本无法替代线程了。
你想,协程需要自己主动出让 CPU 资源,那要是操作系统使用协程来运行应用程序,那万一应用程序自己一直不出让 CPU,也不调用能产生阻塞操作进而间接出让 CPU 的代码,那不就坏事了。
再有,协程本身的优势在于切换成本小,本质是因为栈小,而且也不需要切换页表。
那要是操作系统真的拿协程来跑多应用程序,这些优势也就不复存在了,而且如果协程实现在了内核态,本身从用户态陷入内核态的切换也少不了。
所以本来协程有的优势,在这里全没了,还极大增加了不公平性。
------
最后,这俩事情本身就不好讨论替换这一说,因为他们本质都不一样。
协程说白了就是一段串行的指令流,只不过中间哪个地方往哪跳的逻辑,被封装在了 "协程" 这个概念里而已。
再者,协程本身也是要跑在线程中的,需要有载体,他们二者本身就是相辅相成的关系,何来替代呢,更别说完全替代了。
有时候,了解清楚一项技术的本质,就能更好看清这些问题的荒诞了。
今天阳了躺在床上实在无聊,就挑了个知乎上的问题回答了一下,看好多回答都没说在点子上,就码了这些字,感兴趣的同学可以点开阅读原文看看。