今天有个面试官和我讲 go 的协程比系统的线程更慢，这个我不能理解

我不知道他的回答和我的回答哪个是有依据的，麻烦有大佬知道的，指正我一下，仅是探讨技术对错问题，谢谢。

他一上来问我 go 的协程能否做到线程不能做到的事，而且至少重复问了我 3 次。我回：总的来说是可以加快程序的运行效率。他就讲出了他的理论和依据，既然 go 协程是要由线程去接管运行的，资源也是从线程分来的，那么何谈加快运行效率，你原本线程要做的事还是没变，而且还多了管理协程的开销。后来他又提了一些问题试图来让我相信他这个理论和依据，不知道其中某个问题的时候，我回的是：不耗费资源的操作时，协程要更快，在耗费资源较多时，还是线程更快。然后他还是在反复和我纠结这个问题。在我看来 go 的协程实现是分割原本线程的资源，做到更轻量化和更灵活的资源调度。调用完资源空闲了就可以及时 gc ，就可以用更少的资源去做更多的事。到最后，他才说，我的大前提是，要做的事是非常耗费资源的操作，就感觉很搞不懂。

虽然我面试问题回答的很差，但是我依旧想知道这个问题，不知道有没有大佬来和我指正一下，
另外他还有第二个问题，既然协程这套理论这么牛逼，那么 c++ 为什么没有呢？（在我印象里 c++只有线程）

如果只讨论协程和线程自身内部运行时的性能，那一定是线程更好 但线程的代价更高，占用的系统资源更多，创建线程的时间更长，线程间的资源交互更慢 所以在使用层面是需要通过应用场景来确定具体用哪个

太纠结技术细节，从对话能看出来，即使进入岗位，以后你的日子也不好过。

认同 15 楼说法。面试官的问题应该分场景的。 如果一个线程的任务就是能跑满一个时间片，而不会在自己的时间片中提前结束任务，那么协程完全不必要。但是如果一个线程所分配的任务，比如只需要 1/10 时间片，那么，引入协程改造，确实能把未引入协程时给其它 cpu 的任务，以协程调度方式继续在本线程运行。这就减少了线程切换，更大限度的利用了 cpu 。 但是别忘了，操作系统调度的是线程作业，程序尽早出让某个线程 CPU 也是一种协调。尽可能霸占未必主流大部分程序

搞好前提就方便回答了。如果是 CPU 密集型，直接线程数等于 CPU 核数行了；如果是 IO 密集型，就算是单线程跑协程也比多线程好，资源的分配都不是一个级别的，可以搞一百万个协程，你试下搞一百万个线程看炸不炸。

> 不耗费资源的操作时，协程要更快，在耗费资源较多时，还是线程更快。 有点笼统，资源的定义是啥没说清楚，不过 > 总的来说是可以加快程序的运行效率 这一点肯定不对，协程仅仅是增加了程序的并发度，效率不一定高。一般来说，协程和线程都是解决 IO 阻塞时 cpu 空闲问题，协程可以实现更高阻塞并发，线程虽然并发程度没有协程高，但是总体上一般认为效率比协程还是高的。这里的效率指的是，协程还需要额外的开销进行 cooperative 部分，比如把异步、回调包成类似同步的操作。 换一个说法，就对于非阻塞 IO 密集型任务，比如 CPU 上纯纯的 for-loop ，协程就毫无用处。 你回答给人感觉认识不够清晰，估计就 pass 了。或者是你跟他不匹配，觉得沟通费劲，至少你自己也觉得跟他沟通费劲，以后做同事也没意思。不如友好 byebye

其实前面不少回答已经很准确了，我就补充下面试官的想法。面试官无非是想看看你对程序运行时的理解是否足够深入。Go 算是 C 语言的加强版，像 GC 、map 、channel 这些，你用 C 写就得找库或者自己实现，但 Go 就给你包装好了。协程也是一样，你用着是协程，但底层还是在线程上跑的，只不过 Go 帮你把调度逻辑写了，一个线程上可以根据需要不断切换执行各个协程的逻辑。你自己也可以实现这个，但太麻烦，而且大多数人写不对。至于为什么必须有线程，那是因为操作系统就只支持到线程。所以面试官说的确实没问题，算是考察下操作系统吧。当然这个知识点我觉得也就是层窗户纸。

我总觉得这个面试官是喜欢在网上刷语言不重要，重要的是思想的那类人🤣

@DIO 这什么大厂主任😂确实挺次的吧

线程成本高： * 线程堆栈占用内存大 * 线程切换成本高，是需要内核才能切换 协程成本低： * go 的堆栈是动态的，最初只会使用很小的内存空间 * go 协程切换是用户态的，成本低 另外 go 适合 io 密集型的，原生线程适合计算密集型。