协程不是为了提高任何效率, 而是为了将异步编程简化成同步化, 1:N 有栈协程好几十年了, unix 和 windows 都有专门的 api, 不是什么新概念, 无栈协程是最近些年编译器进步兴起的

@strobber16 别人直接就把我 pass 了，他是一面，他觉得我回答的技术不太行。

> 那么何谈加快运行效率，你原本线程要做的事还是没变，而且还多了管理协程的开销 > go 的协程比系统的线程更慢 老哥你是真分不清这两种表述吗… 一个 CPU 密集的任务，机器不切换协程要跑 100 秒，管理协程花 1 秒，因此 101 > 100 协程更慢

要搞清楚一个事，每一个问题，都是有其前提条件的。比如，面试官说线程比协程快，如果前提条件是并发数很低的情况（并发数比 CPU 核心数少），那么是对的。你认同的观点，同样也是有前提条件的。讨论一个问题前，要先划好场景，不然就是没完没了，毫无意义的扯皮。这家公司 pass 吧

C++的协程都已经出了好几年了 我上星期才发了个帖子，用协程写 Demo 程序： /t/1117106

协程运行在线程内，怎么可能比线程更快？越是 CPU 密集型场景，协程越无用。线程跟 CPU 核心 1:1 绑定，设定好亲和性，才是最快的，多 CPU 时还要考虑 NUMA 尽量访问本地内存。 协程搞到冒烟，也不可能比手搓的多线程实现更快，只不过多线程实现复杂度较高。

协程就是，一个线程里调度运行的函数。简单讲，当去做 io 读取操作，其实很多时候是内核在读取，用户态这时候没必要等着内核读取完，把这段时间给其他函数运行，等内核读取完后继续运行。 最常见场景，爬虫，每个请求中间大量是等待 io 读取网络时间，这时候用协程就好。 还有一个 ui 常见例子，点击读取 button ，去读一个大文件并显示当 list 里，以前为了不卡死 ui 要不异步去读，要开线程，都会回调满天飞。协程就好，ui 线程读取大文件，等待过程还继续处理 ui 事件，然后读取完，继续显示列表，甚至代码逻辑就在一起。 线程是要有一套自己资源，开一个线程是废资源，其实现在配置无所谓，只不过多线程代码很多问题。但是如果代码都非 io 操作那就只能多开线程，这时候协程就没用了。

1 、goroutine 初始栈 2KB （会动态增长的，并不是说一定省内存了），而操作系统线程的栈通常 1MB 2 、Go 运行时内置调度器，相比线程由操作系统调度，goroutines 的上下文切换成本更低，避免内核态的开销。 3 、配合通道减少了竞争的问题，使用简单 缺点也有： 1 、没法控制怎么分配到 cpu 核上，开几个协程可能都挂一个线程上，，利用不了多核资源 2 、GUI 生态多是线程绑定，go 对这块的兼容很不好，没什么生态 3 、协程一旦执行阻塞系统调用，会把整个线程阻塞，导致该线程无法执行其他 goroutines ，降低并发效率 4 、协程不适合 CPU 密集型任务，因为没什么 io ，上下文切换反而增加了开销，，调度器也有损耗，不如用多线程直接绑定到核心上

“耗费资源”这个概念在你们交谈里面变得很模糊，欠缺定义。 楼主经验少点，工作几年了哦？可以刷些 Go 实现、Linux 调度的文章，了解下进程这块相关的知识。 面试官应该到最后解释一下的。 Go 的协程就是用户(态)自己管理的代码片段嘛，那资源的分配上相比 OS 提供的线程，肯定是能够自己 DIY 啦 至于 CPP ，那 CPP 人家是写 OS 的语言，我拿 CPP 写个 Linux 再写个 Golang 编译器，你说我 CPP 有没有协程？ https://draven.co/golang/docs/part3-runtime/ch06-concurrency/golang-goroutine/ https://samwho.dev/memory-allocation/ https://www.luozhiyun.com/archives/518 https://draven.co/golang/docs/part2-foundation/ch04-basic/golang-function-call/

你 CPU 跑满那肯定是系统线程快啊，但是你 CPU 跑满的东西你用 go 写？