目录
这篇文章主要是总结自己对于网络编程中异步，同步，阻塞和非阻塞的理解，这个问题自从学习nio以来一直困扰着我，，其实想来很久就想写了，只不过当时理解不够，无从下手。最近在学习vertx框架，又去熟悉了下netty的代码，因为了对于多线程也有了更深的理解，所以才开始对于这些概念有了理解，用于理清思路，本文需要有良好的多线程和网络编程基础，不适合初学者。
关于这四个概念在io方面的理解我贴两个链接，他们已经有了很好的说明我就不再讲述：
以前在学习c++中muduo只是记得，但是网上很多人说reactor模型是一个异步阻塞的模型，在学习netty的时候官网是这么介绍的:
netty is an asynchronous event-driven network application framework
for rapid development of maintainable high performance protocol servers & clients.
netty是一个异步的高性能网络框架，那么到底是谁说错了？
其实大家都没有错误,只是角度不同。
先说说什么io是异步的？异步其实是针对数据从内核拷贝到用户进程空间这个操作是谁完成的，同步io非常好理解，当用户进程发起一个read操作的时候发生一次系统调用，然后内核检查有没有数据，如果有则复制数据到进程空间，用户进程继续执行。而异步io中复制数据到进程空间这个操作是内核帮你完成的，等完成之后再来通知你，执行你的逻辑。reactor模型中，eventloop线程在select到有可读数据之后，然后在自己去读取数据，所以从这个角度来讲reactor模型确实是同步的，在linux的五种io模型中只有异步io是异步的。
那么为什么netty说他是一个异步网络库呢，这其实是另一个角度的阐述，对于网络库的作者来说，他们面向的是linux提供的这些api，所以说多路复用的reactor是同步的没问题。那么对于netty的使用者来说，我们面向的是netty，netty进一步封装了io操作，在我们发起io操作的时候它返回了一个future，我们可以提供一个监听器来传入我们的回调，当io操作完成时会执行我们的逻辑，我们的这个操作相对于netty就是异步的。
所以reactor是同步非阻塞的，netty是异步非阻塞的。
java中的future是异步的吗？
对于这个问题，我想相信很多同学都会认为是异步的，这里我认为是同步的，下面谈谈我的理解。
先想想一个异步操作需要哪些元素，我认为需要发起者，执行者，执行逻辑，回调逻辑。流程： 发起者请求执行者去执行所需逻辑，然后在成功之后调用回调逻辑。future中缺了什么？没错，就是那个回调！
我们使用future的模式一般是：投递一个任务到线程池得有个future，然后去执行其他可以并行的操作，操作完之后去调用future的get方法获取结果或者isdone判断是否执行完毕。这里的future只是对于计算结果的一个建模，我们在后面需要使用的时候再去轮询（轮询也是同步非阻塞的一个标志）或者阻塞，他提供的了一个非常好的特性：非阻塞！所以我认为future是一个同步非阻塞的实现。也正是因为future没有实现异步的特性，在jdk1.8之后新增了completablefuture提供了异步的特性。
注意异步元素的发起者和执行者可以是同一个线程，最常见的例子就是nodejs的单线程模型。拿netty的线程来具体，你在eventloop中发起一个写请求后得到一个future，你可以设置回调，下次执行这个回调的还是eventloop线程
这里主要说说在使用异步编程的一点理解，因为平时还是用为主，我们作为框架的使用者有必要了解一些常见的使用范式。就我目前接触的最多还是completablefuture，netty和vertx，当时也写过一点js，js主要也是回调的用法。我知道的用法如下：
因为异步的高性能，很多时候我们自己也想把一个操作封装成异步的，就需要明白到底什么是异步，明白异步需要的元素，你会发现如果不借助以后的异步组件将一个操作封装成异步非常的困难，所以最简单的方案就是将你的回调最终传递到已有异步的组件中。
举2个简单的例子：
我要评论completablefuture.supplyasync(object::new).thenaccept(o -> system.out.println(o));这一行非常简单的代码实现了一个异步，object::new会被投递到线程池中，然后执行完成后执行打印语句。框架层面的理解有助于我们在写代码中不会用错。有没有想过一个异步操作框架给你做了什么？
当你发起一个操作的时候，框架会去执行你的逻辑，在执行完毕时(成功或异常)去修改状态并执行你的回调。修改状态并执行你的回调这个操作在jdk中放在了completablefuture中，在netty中则单独采用了promise接口，其实两者的实现是非常类似的（方法名都取的差不多）。以netty举例分为future和promise两个方法，作为用户我们更应该关心future的接口，promise是框架层面需要实现的，我们在自己去实现的时候值得我们去学习里面的思想。
不过我认为我们直接使用promise的这种接口的机会很少，netty和vertx场景下还是有机会用到，在用到promise接口的时候应该考虑下是否合理，检查下是不是在同一个线程中，是不是可以简单的接口代替。给一个简单的错误示例：
这里说下promise，我们知道js中也有一个promise，千万不要当成类似的东西，两者毫无干系，netty的promise是对完成操作的行为的建模，js的promise是为了组合各个异步的调用。
import io.vertx.core.future;
public class auctionhandler {
public future<void> handle() {
// 请求级别变量
context context = new context();
context.future.trycomplete();
return context.future;
}
public static class context {
future<void> future = future.future();
}
public static void main(string[] args) {
// 注意这里的handle方法返回的future是vertx的。
// 这里的方法都是在同一个线程中执行的，完全没有异步化，所以可以改成传递一个普通的接口即可
new auctionhandler().handle().sethandler(event1 -> system.out.println("handler exec!"));
}
}
虽然这个的代码错误看上去很低级，但是在开发vertx应用时需要时刻保持警惕。另外还有一点需要说明：当返回给你的future已经是完成状态时，如上面的代码示例，你再增加回调，这个回调还会被执行，netty和completablefuture在添加回调的时候都是检查状态是否完成，完成的话直接投递到相应线程执行。
为什么要使用异步，相信很多同学都知道是为了高性能，那么异步为什么高性能？
这里先谈谈nodejs和java，对于nodejs，很多人听说性能十分高，"秒杀"java。我当时一直无法理解，为什么js能超过java，
首先node是单线程的，虽然可以借助第三方库来实现多线程，另外jvm作为业界最优秀的虚拟机，那么node到底是靠了什么超过了java？这里的关键就在于node的io模型采用了reactor模型，可以处理大量的连接。java中的web开发是以servlet为主导，采用了同步阻塞模型，虽然用线程池实现n个连接用m和线程做优化，但是当有大量连接时，线程数量过多导致的线程调度成本会很高，另外在线程处理io的时候也是同步阻塞，如果对方返回很难会导致当前线程一直无法释放，所以tomcat这种不适合处理大量连接的场景。
我们知道jetty的底层实现就是reactor模型，tomcat在8之后默认也用了reactor是不是会大幅提高性能？不幸的是，虽然可以提高一些性能但是还是无法和node一较高低，他解决的是http连接那一块的阻塞问题，但是由于servlet的编程模型，大量的同步阻塞操作还是无法避免，比如你在一个请求中去访问了数据库，这个线程就会一直被占用，一定程度上你可以通过增加线程来缓解但是线程过多又会增加调度的成本，可能会导致虚拟机假死。所以如果你的处理中有这种耗时操作，那他就是你的瓶颈，你的qps的上限就很低。在高并发场景下，servlet的瓶颈会十分突出，只能通过大量的堆机器来水平扩展，但是没有很好的榨干服务器的性能。
所以我们需要的是编程模型的改变，像nodejs那样在同步阻塞的地方进行异步非阻塞或者异步阻塞化。spring5.0中的 webflux给了一个对应的解决方案，提供了响应式编程的模型用以取代servlet，他对常见同步阻塞的地方进行了重写，如redis和mysql等常见的io。很早之前vertx（早期名字node.x，java版的nodejs）框架也提供了这样的编程模型，对很多同步阻塞的地方进行了重写，这个框架十分轻量级，社区活跃度非常高，使用起来非常方便。这两个底层都是netty，不得不说netty实在是太强大了。也从另外一个角度说明设计的重要性，语言反而是其次。nodejs，webflux和vertx都采用了类似的reactor模型，高性能服务器领域这个模型几乎已经是最佳实践，理解这个模型就和多线程一样重要。我觉得拿servlet和nodejs来做性能的对比，是十分不公平的。nodejs在java领悟的对手应该是vertx这种框架，关于高性能web框架的对比，这个网站已经给出了详细的排名，排名前十的大部分是jvm语言，nodejs在五十名之后了，所以不要在拿servlet去和nodejs做对比了，servlet这种模型在高并发领悟一定会被逐渐取代。所以要深入理解响应式编程，拥抱响应式编程，现有的代码以及未来的开发都可以用响应式编程来做优化。
那么异步到底解决了什么问题？
上面举的例子只是简单说明了现有的异步非阻塞框架的性能优势。但是这个问题我也无法给出准确的解释，只是谈谈我自己的理解：
程序运行过程中始终是围绕着两个主题：io、cpu。cpu和io的速度差距十分大，异步和reactor模型都是为了平衡这个差距，让cpu能充分利用起来，不要因为io和其他同步操作导致线程hang住，始终处于可运行的状态，可以使用少量的线程充分利用cpu。
很多人可能会疑问就算了把这些弄的明明白白到底有什么用？其实如果你很好的掌握了reactor的编程模型，很多问题就能想明白了下面谈下自己理解的有用的地方：
最后还想说一句，netty这个框架实在是太强大了，线程模型设计十分优秀，vertx把很多异步操作委托给了底层的netty，因为netty实现中的eventloop具有天然的线程隔离（一个eventloop对应一个线程，只会被这个线程调用），很多地方免去了同步，vertx同样继承了这个优点，有机会一定好好看看netty的设计和源码。
阻塞和同步的四种组合，对于异步阻塞还是无法理解，这种模式真的存在吗？
如对本文有疑问， 点击进行留言回复！！
Springboot项目因为kackson版本问题启动报错解决方案
Java多线程下的其他组件之CyclicBarrier、Callable、Future和FutureTask详解
网友评论