协程作为用户态线程是如何提高性能和并发量的？

实际上是通过不使用阻塞的api，而是通过使用与这个api等效的异步版本。举例来说，可能原来你要原地等待硬盘io。现在你可能发出请求后就换成另一个协程，等到读取完成后再继续。

原理上，非协程程序也可以这么写，但是往往会比较复杂。通过一些封装，每个协程内部大致上和一般的程序一样。我认为这是使用协程的主要优势。线程的存在，使得程序可以在多个CPU一起执行。和协程的使用并不冲突，所以go中实际上是m：n的协程设计。

   协程是一种轻量级，用户态的线程，它的上下文切换可以简单认为是执行了数次memcpy，不必进入内核态并调用syscall。熟悉OS的朋友应该知道，一次syscall的开销是比较大的，因此协程切换的开销远远比线程切换小，而且协程的总数量不再受制于OS内核态控制的线程数量，因此能做到百万数量级。

协程能轻松实现上万并发，这个要看具体场景。举个栗子：同步阻塞的 redis client 单连接上限几千并发，异步非阻塞的 redis client 单链接可能 10w + 以上并发，这都多少倍了^_^！这里可以通过协程解决异步回调的问题。

协程应用在纯运算场景应该不常见，解决阻塞 IO 场景还是比较常见的。协程切换主要两个接口：yield 和 resume。理论上说，用户爱咋用就咋用，不管它是什么场景： IO 阻塞或非阻塞，IO 密集型或 CPU 密集型。

遇到阻塞 API，很多人是通过多线程去解决问题，除此之外还有其它解决方案。
A 方案：hook 技术，将同步阻塞的 api 设置成非阻塞异步的，然后模拟串行操作，一条命令发过去然后马上返回，切到其它协程去，等到回复后