实际上是通过不使用阻塞的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 设置成非阻塞异步的,然后模拟串行操作,一条命令发过去然后马上返回,切到其它协程去,等到回复后