他一上来问我 go 的协程能否做到线程不能做到的事，而且至少重复问了我 3 次。我回：总的来说是可以加快程序的运行效率。他就讲出了他的理论和依据，既然 go 协程是要由线程去接管运行的，资源也是从线程分来的，那么何谈加快运行效率，你原本线程要做的事还是没变，而且还多了管理协程的开销。后来他又提了一些问题试图来让我相信他这个理论和依据，不知道其中某个问题的时候，我回的是：不耗费资源的操作时，协程要更快，在耗费资源较多时，还是线程更快。然后他还是在反复和我纠结这个问题。在我看来 go 的协程实现是分割原本线程的资源，做到更轻量化和更灵活的资源调度。调用完资源空闲了就可以及时 gc ，就可以用更少的资源去做更多的事。到最后，他才说，我的大前提是，要做的事是非常耗费资源的操作，就感觉很搞不懂。
虽然我面试问题回答的很差，但是我依旧想知道这个问题，不知道有没有大佬来和我指正一下， 另外他还有第二个问题，既然协程这套理论这么牛逼，那么 c++ 为什么没有呢？（在我印象里 c++只有线程）
其实前面不少回答已经很准确了，我就补充下面试官的想法。面试官无非是想看看你对程序运行时的理解是否足够深入。Go 算是 C 语言的加强版，像 GC 、map 、channel 这些，你用 C 写就得找库或者自己实现，但 Go 就给你包装好了。协程也是一样，你用着是协程，但底层还是在线程上跑的，只不过 Go 帮你把调度逻辑写了，一个线程上可以根据需要不断切换执行各个协程的逻辑。你自己也可以实现这个，但太麻烦，而且大多数人写不对。至于为什么必须有线程，那是因为操作系统就只支持到线程。所以面试官说的确实没问题，算是考察下操作系统吧。当然这个知识点我觉得也就是层窗户纸。
mayli
172 天前
> 不耗费资源的操作时，协程要更快，在耗费资源较多时，还是线程更快。
有点笼统，资源的定义是啥没说清楚，不过
> 总的来说是可以加快程序的运行效率
这一点肯定不对，协程仅仅是增加了程序的并发度，效率不一定高。一般来说，协程和线程都是解决 IO 阻塞时 cpu 空闲问题，协程可以实现更高阻塞并发，线程虽然并发程度没有协程高，但是总体上一般认为效率比协程还是高的。这里的效率指的是，协程还需要额外的开销进行 cooperative 部分，比如把异步、回调包成类似同步的操作。 换一个说法，就对于非阻塞 IO 密集型任务，比如 CPU 上纯纯的 for-loop ，协程就毫无用处。
搞好前提就方便回答了。如果是 CPU 密集型，直接线程数等于 CPU 核数行了；如果是 IO 密集型，就算是单线程跑协程也比多线程好，资源的分配都不是一个级别的，可以搞一百万个协程，你试下搞一百万个线程看炸不炸。
Cannly
172 天前
认同 15 楼说法。面试官的问题应该分场景的。 如果一个线程的任务就是能跑满一个时间片，而不会在自己的时间片中提前结束任务，那么协程完全不必要。但是如果一个线程所分配的任务，比如只需要 1/10 时间片，那么，引入协程改造，确实能把未引入协程时给其它 cpu 的任务，以协程调度方式继续在本线程运行。这就减少了线程切换，更大限度的利用了 cpu 。 但是别忘了，操作系统调度的是线程作业，程序尽早出让某个线程 CPU 也是一种协调。尽可能霸占未必主流大部分程序