实际上是通过不使用阻塞的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 设置成非阻塞异步的，然后模拟串行操作，一条命令发过去然后马上返回，切到其它协程去，等到回复后协程再切回来再发下一条；B 方案：如果接收方支持异步的，可以封装一套异步接口，然后通过协程调度，当然这个工作量有点大，因为接收方可能很多。
最理想的情况。上面第三点已经说了一下，就是想办法把同步阻塞操作更换为异步阻塞，当然这中间需要事件驱动辅助，例如 epoll，将 fd 挂在上面，然后切换协程，等到 epoll_wait 回调结果又切回来，本质上是异步操作，除此之外多了个协程切换一下，使得用户避免了异步回调这种反人类操作。当然在这个框架下，利用多线程使用多核资源也没有什么不妥，反正本质上还是异步回调那一套。
然后vert.x 也不能阻塞，如果是纯计算，复杂度高的话，也要离开eventloop，交给worker thread，vert.x会利用虚拟线程来将原来阻塞的io操作变成非阻塞看viet说后续打算是用future.get，这个在线程上下文中是阻塞的api，但是在虚拟线程的上下文中，是非阻塞的api，也就是future.get会变成future.await，就相对简单
有没有很大差异，性能上差异不大，或者说vert.x理应表现更好，只是说在web那种场景下，用无脑的虚拟线程，开发会更简单，有些人学不会await那么复杂的操作，非阻塞他判断不来，所以我用vert.x的时候有一个小心得，就是招安卓的人来搞vert.x，往往安卓的开发对vert.x上手更快，对await更熟悉TG：li9047
热门跟贴