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原始碼的一些事兒之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二三事