Java编程方法论-Spring WebFlux篇 01 为何须要Spring WebFlux 上

前言

本系列为本人Java编程方法论 响应式解读系列的Webflux部分，现分享出来，前置知识Rxjava2 ，Reactor的相关解读已经录制分享视频，并发布在b站，地址以下:

Rxjava源码解读与分享：www.bilibili.com/video/av345…

Reactor源码解读与分享：www.bilibili.com/video/av353…

NIO源码解读相关视频分享： www.bilibili.com/video/av432…

NIO源码解读视频相关配套文章:

BIO到NIO源码的一些事儿之BIO

BIO到NIO源码的一些事儿之NIO 上

BIO到NIO源码的一些事儿之NIO 中

BIO到NIO源码的一些事儿之NIO 下 之 Selector BIO到NIO源码的一些事儿之NIO 下 Buffer解读 上 BIO到NIO源码的一些事儿之NIO 下 Buffer解读 下

其中，Rxjava与Reactor做为本人书中内容将不对外开放，你们感兴趣能够花点时间来观看视频，本人对着两个库进行了全面完全细致的解读，包括其中的设计理念和相关的方法论，也但愿你们能够留言纠正我其中的错误。

为何须要Spring WebFlux

在咱们要面临愈来愈高的并发处理，传统的Spring Web MVC已经没法知足咱们的需求，即咱们须要一个无阻塞的且经过不多的硬件资源(体现就是经过不多数量的线程)的web框架来处理并发任务。Servlet 3.1确实为非阻塞I/O提供了相应API。可是，使用它时，Servlet 其他部分API的在执行时就是同步（好比Filter）或阻塞（getParameter，getPart）。 咱们知道，Tomcat这类服务器其有一个Servlet Worker线程池，而使用Spring Web MVC的话，对于请求的处理过程将会在DispatcherServlet中进行，而其内部默认并不会进行异步处理，因此，当有I/O或者耗时操做的时候，极可能会阻塞当前Servlet所在线程。(参考网上关于SpringMVC异步操做的相关博文)，关于其异步改造，本人也在RxJava2的相关分享视频的项目实例中进行有改造，你们可回顾。而咱们的目的就是将当前Servlet所在线程给让出来，这样能够接收更多的请求。 那二者的区别到底在什么地方，Spring WebFlux到底有何意义可供咱们迁移学习。相信你们在接触过Tomcat以后，都会去学习一下Tomcat的配置文件server.xml，从中咱们也知道Connector，其主要功能是:接收链接请求，建立Request和Response对象用于和请求端交换数据；而后分配线程让Servlet容器来处理这个请求，并把产生的Request和Response对象传给Servlet。当Servlet处理完请求后，也会经过Connector将响应返回给客户端。 因此咱们从Connector入手，讨论一些与Connector有关问题，包括NIO/BIO模式、线程池、链接数等。 根据协议的不一样，Connector能够分为HTTP Connector、AJP Connector等，此处只讨论HTTP Connector。

Tomcat下Connector中的协议

Connector在处理HTTP请求时，会使用不一样的protocol。不一样的Tomcat版本支持的protocol不一样，其中典型的protocol包括BIO、NIO和APR(Tomcat7中支持这3种，Tomcat8增长了对NIO2的支持，而在Tomcat8.5和Tomcat9.0，则去掉了对BIO的支持)。

Connector使用哪一种protocol，能够经过Tomcat配置文件server.xml中的<connector>元素中的protocol属性进行指定，也可使用默认值。若是没有指定protocol，则使用默认值HTTP/1.1，其含义以下:在Tomcat7中，自动选取使用BIO或APR(若是找到APR须要的本地库，则使用APR，不然使用BIO)；在Tomcat8中，自动选取使用NIO或APR(若是找到APR须要的本地库，则使用APR，不然使用NIO)。

不管是BIO，仍是NIO，Connector处理请求的大体流程是同样的:在accept队列中接收链接(当客户端向服务器发送请求时，若是客户端与服务端完成三次握手创建了链接，则服务端将该链接放入accept队列)；在链接中获取请求的数据，生成request；调用Servlet容器处理请求；返回response。

为了便于你们的理解，这里先明确一下链接与请求的关系:

• 链接是TCP层面的(传输层)，对应socket。
• 请求是HTTP层面的(应用层)，必须依赖于TCP的链接实现。
• 一个TCP链接中可能传输多个HTTP请求。

BIO是Blocking IO，顾名思义是阻塞的IO；NIO是Non-blocking IO，则是非阻塞的IO。而APR是Apache Portable Runtime，是Apache可移植运行库，利用本地库能够实现高可扩展性、高性能；Apr是在Tomcat上运行高并发应用的首选模式，可是须要安装apr、apr-utils、tomcat-native等包。

在BIO实现的Connector中，请求主要是由JioEndpoint对象来处理。JioEndpoint维护了Acceptor和Worker，经过Acceptor接收socket，而后从Worker线程池中找出空闲的线程处理socket，若是worker线程池没有空闲线程，则Acceptor将阻塞。其中Worker是Tomcat自带的线程池，若是经过<Executor>配置了其余线程池，原理与Worker相似。

在NIO实现的Connector中，处理请求的主要实体是NIOEndpoint对象。NIOEndpoint中除了包含Acceptor和Worker外，仍是用了Poller，处理流程以下图所示:

图中Acceptor及Worker分别是以线程池形式存在，Poller是一个单线程(此处是其与Netty最大的区别)。注意，与BIO的实现同样，这里，须要说起的是，在server.xml中没有配置<Executor>，则以Worker线程池运行，若是配置了<Executor>，则以基于java.util.concurrent.ThreadPoolExecutor线程池运行。

由图可知，Acceptor接收socket后(这里虽然是基于NIO的connector，可是在接收socket方面仍是传统的serverSocket.accept()方式，得到SocketChannel对象，而后封装在一个tomcat的org.apache.tomcat.util.net.NIOChannel实现类对象，并将之包装为一个PollerEvent对象)，并非直接使用Worker中的线程处理请求，而是先将PollerEvent对象发送给了Poller，而Poller是实现NIO的关键。Acceptor向Poller发送包装后的请求经过添加队列的操做实现，这里使用了典型的生产者-消费者模式。同时，在Poller中，维护了一个Selector对象；当Poller从队列中取出socket后，注册到该Selector中；而后经过遍历Selector，找出其中可读的socket，并使用Worker中的线程处理相应请求。与BIO相似，Worker也能够被自定义的线程池代替。

经过上述过程能够看出，在NIOEndpoint处理请求的过程当中，不管是Acceptor接收socket，仍是线程处理请求(添加到Poller队列是同步的)，使用的仍然是阻塞方式；但在读取socket并交给Worker中的线程的这个过程当中，使用非阻塞的NIO实现，这是NIO模式与BIO模式的最主要区别(其余区别对性能影响较小)。而也是因为这个区别，在并发量较大的情形下能够给Tomcat效率带来显著提高。

目前大多数HTTP请求使用的是长链接(HTTP/1.1默认keep-alive为true)，而长链接意味着，一个TCP的socket在当前请求结束后，若是没有新的请求到来，socket不会立马释放，而是等timeout后再释放。若是使用BIO，读取socket并交给Worker中的线程这个过程是阻塞的，也就意味着在socket等待下一个请求或等待释放的过程当中，处理这个socket的工做线程会一直被占用，没法释放；所以Tomcat能够同时处理的socket数目不能超过最大线程数，性能受到了极大限制。而使用NIO，读取socket并交给Worker中的线程这个过程是非阻塞的(是由Poller所在线程维护的)，并不会占用工做线程，所以Tomcat能够同时处理的socket数目不受最大线程数约束，并发性能也就大大提升，但Poller同时也是其性能瓶颈。

所以，随着NIO所实现Connector的引入，客户端到服务器的通讯是非阻塞的，可是服务器到servlet的链接仍然是阻塞的，也就意味着每一个请求都会阻塞一个线程，也就致使咱们会看到一个线程处理一个请求的模型。 所以，随着Servlet容器的发展，Servlet API也就须要非阻塞支持，也就是Servlet 3.1+。

关于Tomcat下Connector的更多深刻解读，有感兴趣的能够参考本人的另外一篇博文tomcat从启动到接轨Servlet二三事