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

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

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

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

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

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

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

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