前言
本系列為本人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原始碼的一些事兒之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二三事