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二三事