Tomcat 高并發(fā)之道原理拆解與性能調優(yōu)

高并發(fā)拆解核心準備

這回，再次拆解，專注 Tomcat 高并發(fā)設計之道與性能調優(yōu)，讓大家對整個架構有更高層次的了解與感悟。其中設計的每個組件思路都是將 Java 面向對象、面向接口、如何封裝變與不變，如何根據實際需求抽象不同組件分工合作，如何設計類實現(xiàn)單一職責，怎么做到將相似功能高內聚低耦合，設計模式運用到極致的學習借鑒。

這次主要涉及到的是 I/O 模型，以及線程池的基礎內容。

一起來看 Tomcat 如何實現(xiàn)并發(fā)連接處理以及任務處理，性能的優(yōu)化是每一個組件都起到對應的作用，如何使用最少的內存，最快的速度執(zhí)行是我們的目標。

設計模式

?模板方法模式：抽象算法流程在抽象類中，封裝流程中的變化與不變點。將變化點延遲到子類實現(xiàn)，達到代碼復用，開閉原則。

?觀察者模式：針對事件不同組件有不同響應機制的需求場景，達到解耦靈活通知下游。

?責任鏈模式：將對象連接成一條鏈，將沿著這條鏈傳遞請求。在 Tomcat 中的 Valve 就是該設計模式的運用。

I/O 模型

Tomcat 實現(xiàn)高并發(fā)接收連接，必然涉及到 I/O 模型的運用，了解同步阻塞、異步阻塞、I/O 多路復用，異步非阻塞相關概念以及 Java NIO 包的運用很有必要。本文也會帶大家著重說明 I/O 是如何在 Tomcat 運用實現(xiàn)高并發(fā)連接。大家通過本文我相信對 I/O 模型也會有一個深刻認識。

Java 并發(fā)編程

實現(xiàn)高并發(fā)，除了整體每個組件的優(yōu)雅設計、設計模式的合理、I/O 的運用，還需要線程模型，如何高效的并發(fā)編程技巧。在高并發(fā)過程中，不可避免的會出現(xiàn)多個線程對共享變量的訪問，需要加鎖實現(xiàn)，如何高效的降低鎖沖突。因此作為程序員，要有意識的盡量避免鎖的使用，比如可以使用原子類 CAS 或者并發(fā)集合來代替。如果萬不得已需要用到鎖，也要盡量縮小鎖的范圍和鎖的強度。

對于并發(fā)相關的基礎知識，如果讀者感興趣后面也給大家安排上，目前也寫了部分并發(fā)專輯，大家可移步到歷史文章或者專輯翻閱，主要講解了并發(fā)實現(xiàn)的原理、什么是內存可見性，JMM 內存模模型、讀寫鎖等并發(fā)知識點。

Tomcat 總體架構

再次回顧下 Tomcat 整體架構設計，主要設計了?connector 連接器處理 TCP/IP 連接，container 容器作為 Servlet 容器，處理具體的業(yè)務請求。對外對內分別抽象兩個組件實現(xiàn)拓展。

• 一個 Tomcat 實例默認會有一個 Service，而一個 Service 可以包含多個連接器。連接器主要有 ProtocalHandler 和 Adapter 兩個組件共同完成連接器核心功能。
• ProtocolHandler?主要由?Acceptor?以及?SocketProcessor?構成，實現(xiàn)了 TCP/IP 層 的 Socket 讀取并轉換成?TomcatRequest?和?TomcatResponse，最后根據 http 或者 ajp 協(xié)議獲取合適的?Processor?解析為應用層協(xié)議，并通過 Adapter 將 TomcatRequest、TomcatResponse 轉化成 標準的 ServletRequest、ServletResponse。通過?getAdapter().service(request, response);將請求傳遞到 Container 容器。
• adapter.service()實現(xiàn)將請求轉發(fā)到容器?org.apache.catalina.connector.CoyoteAdapter

//?Calling?the?container
connector.getService().getContainer().getPipeline().getFirst().invoke(
????????????????????????request,?response);

這個調用會觸發(fā) getPipeline 構成的責任鏈模式將請求一步步走入容器內部，每個容器都有一條 Pipeline，通過 First 開始到 Basic 結束并進入容器內部持有的子類容器，最后到 Servlet，這里就是責任鏈模式的經典運用。具體的源碼組件是 Pipeline 構成一條請求鏈。如下圖所示，整個 Tomcat 的架構設計重要組件清晰可見，希望大家將這個全局架構圖深深印在腦海里，掌握全局思路才能更好地分析細節(jié)之美。

啟動流程：startup.sh 腳本到底發(fā)生了什么

• Tomcat 本生就是一個 Java 程序，所以 startup.sh 腳本就是啟動一個 JVM 來運行 Tomcat 的啟動類 Bootstrap。
• Bootstrap 主要就是實例化 Catalina 和初始化 Tomcat 自定義的類加載器。熱加載與熱部署就是靠他實現(xiàn)。
• Catalina: 解析 server.xml 創(chuàng)建 Server 組件，并且調用 Server.start() 方法。
• Server：管理 Service 組件，調用 Server 的 start() 方法。
• Service：主要職責就是管理連接器和頂層容器 Engine，分別調用?Connector?和?Engine?的?start?方法。

Engine 容器主要就是組合模式將各個容器根據父子關系關聯(lián)，并且 Container 容器繼承了 Lifecycle 實現(xiàn)各個容器的初始化與啟動。Lifecycle 定義了?init()、start()、stop()?控制整個容器組件的生命周期實現(xiàn)一鍵啟停。

這里就是一個面向接口、單一職責的設計思想?，Container 利用組合模式管理容器，LifecycleBase 抽象類繼承 Lifecycle 將各大容器生命周期統(tǒng)一管理這里便是，而實現(xiàn)初始化與啟動的過程又 LifecycleBase 運用了?模板方法設計模式抽象出組件變化與不變的點，將不同組件的初始化延遲到具體子類實現(xiàn)。并且利用觀察者模式發(fā)布啟動事件解耦。

具體的 init 與 start 流程如下泳道圖所示：這是我在閱讀源碼 debug 所做的筆記，讀者朋友們不要怕筆記花費時間長，自己跟著 debug 慢慢記錄，相信會有更深的感悟。

init 流程

start 流程

讀者朋友根據我的兩篇內容，抓住主線組件去 debug，然后跟著該泳道圖閱讀源碼，我相信都會有所收獲，并且事半功倍。在讀源碼的過程中，切勿進入某個細節(jié)，一定要先把各個組件抽象出來，了解每個組件的職責即可。最后在了解每個組件的職責與設計哲學之后再深入理解每個組件的實現(xiàn)細節(jié)，千萬不要一開始就想著深入理解具體一篇葉子。

每個核心類我在架構設計圖以及泳道圖都標識出來了，給大家分享下如何高效閱讀源碼，以及保持學習興趣的心得體會。

如何正確閱讀源碼

切勿陷入細節(jié)，不看全局：我還沒弄清楚森林長啥樣，就盯著葉子看?，看不到全貌和整體設計思路。所以閱讀源碼學習的時候不要一開始就進入細節(jié)，而是宏觀看待整體架構設計思想，模塊之間的關系。

1.閱讀源碼之前，需要有一定的技術儲備

比如常用的設計模式，這個必須掌握，尤其是：模板方法、策略模式、單例、工廠、觀察者、動態(tài)代理、適配器、責任鏈、裝飾器。大家可以看 關于設計模式的歷史文章，打造好的基礎。

2.必須會使用這個框架/類庫，精通各種變通用法

魔鬼都在細節(jié)中，如果有些用法根本不知道，可能你能看明白代碼是什么意思，但是不知道它為什么這些寫。

3.先去找書，找資料，了解這個軟件的整體設計。

從全局的視角去看待，上帝視角理出主要核心架構設計，先森林后樹葉。都有哪些模塊？模塊之間是怎么關聯(lián)的？怎么關聯(lián)的？

可能一下子理解不了，但是要建立一個整體的概念，就像一個地圖，防止你迷航。

在讀源碼的時候可以時不時看看自己在什么地方。就像「碼哥字節(jié)」給大家梳理好了 Tomcat 相關架構設計，然后自己再嘗試跟著 debug，這樣的效率如虎添翼。

4. 搭建系統(tǒng)，把源代碼跑起來！

Debug 是非常非常重要的手段， 你想通過只看而不運行就把系統(tǒng)搞清楚，那是根本不可能的！合理運用調用棧（觀察調用過程上下文）。

5.筆記

一個非常重要的工作就是記筆記（又是寫作！），畫出系統(tǒng)的類圖（不要依靠 IDE 給你生成的）， 記錄下主要的函數(shù)調用， 方便后續(xù)查看。

文檔工作極為重要，因為代碼太復雜，人的大腦容量也有限，記不住所有的細節(jié)。文檔可以幫助你記住關鍵點， 到時候可以回想起來，迅速地接著往下看。

要不然，你今天看的，可能到明天就忘個差不多了。所以朋友們記得收藏后多翻來看看，嘗試把源碼下載下來反復調試。

錯誤方式

• 陷入細節(jié)，不看全局：我還沒弄清楚森林長啥樣，就盯著葉子看?，看不到全貌和整體設計思路。所以閱讀源碼學習的時候不要一開始就進入細節(jié)，而是宏觀看待整體架構設計思想，模塊之間的關系。
• 還沒學會用就研究如何設計：首先基本上框架都運用了設計模式，我們最起碼也要了解常用的設計模式，即使是“背”，也得了然于胸。在學習一門技術，我推薦先看官方文檔，看看有哪些模塊、整體設計思想。然后下載示例跑一遍，最后才是看源碼。
• 看源碼深究細節(jié)：到了看具體某個模塊源碼的時候也要下意識的不要去深入細節(jié)，重要的是學習設計思路，而不是具體一個方法實現(xiàn)邏輯。除非自己要基于源碼做二次開發(fā)，而且二次開發(fā)也是基于在了解整個架構的情況下才能深入細節(jié)。

組件設計-落實單一職責、面向接口思想

當我們接到一個功能需求的時候，最重要的就是抽象設計，將功能拆解主要核心組件，然后找到需求的變化與不變點，將相似功能內聚，功能之間若耦合，同時對外支持可拓展，對內關閉修改。努力做到一個需求下來的時候我們需要合理的抽象能力抽象出不同組件，而不是一鍋端將所有功能糅合在一個類甚至一個方法之中，這樣的代碼牽一發(fā)而動全身，無法拓展，難以維護和閱讀。

帶著問題我們來分析 Tomcat 如何設計組件完成連接與容器管理。

看看 Tomcat 如何實現(xiàn)將 Tomcat 啟動，并且又是如何接受請求，將請求轉發(fā)到我們的 Servlet 中。

Catalina

主要任務就是創(chuàng)建 Server，并不是簡單創(chuàng)建，而是解析 server.xml 文件把文件配置的各個組件意義創(chuàng)建出來，接著調用 Server 的 init() 和 start() 方法，啟動之旅從這里開始…，同時還要兼顧異常，比如關閉 Tomcat 還需要做到優(yōu)雅關閉啟動過程創(chuàng)建的資源需要釋放，Tomcat 則是在 JVM 注冊一個「關閉鉤子」，源碼我都加了注釋，省略了部分無關代碼。同時通過?await()?監(jiān)聽停止指令關閉 Tomcat。

????/**
?????*?Start?a?new?server?instance.
?????*/
????public?void?start()?{
????//?若?server?為空，則解析?server.xml?創(chuàng)建
????????if?(getServer()?==?null)?{
????????????load();
????????}
????//?創(chuàng)建失敗則報錯并退出啟動
????????if?(getServer()?==?null)?{
????????????log.fatal("Cannot?start?server.?Server?instance?is?not?configured.");
????????????return;
????????}

????????//?開始啟動?server
????????try?{
????????????getServer().start();
????????}?catch?(LifecycleException?e)?{
????????????log.fatal(sm.getString("catalina.serverStartFail"),?e);
????????????try?{
????????????????//?異常則執(zhí)行?destroy?銷毀資源
????????????????getServer().destroy();
????????????}?catch?(LifecycleException?e1)?{
????????????????log.debug("destroy()?failed?for?failed?Server?",?e1);
????????????}
????????????return;
????????}

????????//?創(chuàng)建并注冊?JVM?關閉鉤子
????????if?(useShutdownHook)?{
????????????if?(shutdownHook?==?null)?{
????????????????shutdownHook?=?new?CatalinaShutdownHook();
????????????}
????????????Runtime.getRuntime().addShutdownHook(shutdownHook);
????????}
????//?通過?await?方法監(jiān)聽停止請求
????????if?(await)?{
????????????await();
????????????stop();
????????}
????}

通過「關閉鉤子」，就是當 JVM 關閉的時候做一些清理工作，比如說釋放線程池，清理一些零時文件，刷新內存數(shù)據到磁盤中…...

「關閉鉤子」本質就是一個線程，JVM 在停止之前會嘗試執(zhí)行這個線程。我們來看下 CatalinaShutdownHook 這個鉤子到底做了什么。

????/**
?????*?Shutdown?hook?which?will?perform?a?clean?shutdown?of?Catalina?if?needed.
?????*/
????protected?class?CatalinaShutdownHook?extends?Thread?{

????????@Override
????????public?void?run()?{
????????????try?{
????????????????if?(getServer()?!=?null)?{
????????????????????Catalina.this.stop();
????????????????}
????????????}?catch?(Throwable?ex)?{
???????????????...
????????}
????}

????/**
?????*?關閉已經創(chuàng)建的?Server?實例
?????*/
????public?void?stop()?{

????????try?{
????????????//?Remove?the?ShutdownHook?first?so?that?server.stop()
????????????//?doesn't?get?invoked?twice
????????????if?(useShutdownHook)?{
????????????????Runtime.getRuntime().removeShutdownHook(shutdownHook);
????????????}
????????}?catch?(Throwable?t)?{
????????????......
????????}

????????//?關閉?Server
????????try?{
????????????Server?s?=?getServer();
????????????LifecycleState?state?=?s.getState();
???????????//?判斷是否已經關閉，若是在關閉中，則不執(zhí)行任何操作
????????????if?(LifecycleState.STOPPING_PREP.compareTo(state)?<=?0
????????????????????&&?LifecycleState.DESTROYED.compareTo(state)?>=?0)?{
????????????????//?Nothing?to?do.?stop()?was?already?called
????????????}?else?{
????????????????s.stop();
????????????????s.destroy();
????????????}
????????}?catch?(LifecycleException?e)?{
????????????log.error("Catalina.stop",?e);
????????}

????}

實際上就是執(zhí)行了 Server 的 stop 方法，Server 的 stop 方法會釋放和清理所有的資源。

Server 組件

來體會下面向接口設計美，看 Tomcat 如何設計組件與接口，抽象 Server 組件，Server 組件需要生命周期管理，所以繼承 Lifecycle 實現(xiàn)一鍵啟停。

它的具體實現(xiàn)類是 StandardServer，如下圖所示，我們知道 Lifecycle 主要的方法是組件的 初始化、啟動、停止、銷毀，和 監(jiān)聽器的管理維護，其實就是觀察者模式的設計，當觸發(fā)不同事件的時候發(fā)布事件給監(jiān)聽器執(zhí)行不同業(yè)務處理，這里就是如何解耦的設計哲學體現(xiàn)。

而 Server 自生則是負責管理 Service 組件。

接著，我們再看 Server 組件的具體實現(xiàn)類是 StandardServer 有哪些功能，又跟哪些類關聯(lián)？

在閱讀源碼的過程中，我們一定要多關注接口與抽象類，接口是組件全局設計的抽象；而抽象類基本上是模板方法模式的運用，主要目的就是抽象整個算法流程，將變化點交給子類，將不變點實現(xiàn)代碼復用。

StandardServer 繼承了 LifeCycleBase，它的生命周期被統(tǒng)一管理，并且它的子組件是 Service，因此它還需要管理 Service 的生命周期，也就是說在啟動時調用 Service 組件的啟動方法，在停止時調用它們的停止方法。Server 在內部維護了若干 Service 組件，它是以數(shù)組來保存的，那 Server 是如何添加一個 Service 到數(shù)組中的呢？

????/**
?????*?添加?Service?到定義的數(shù)組中
?????*
?????*?@param?service?The?Service?to?be?added
?????*/
????@Override
????public?void?addService(Service?service)?{

????????service.setServer(this);

????????synchronized?(servicesLock)?{
???????????//?創(chuàng)建一個?services.length?+?1?長度的?results?數(shù)組
????????????Service?results[]?=?new?Service[services.length?+?1];
???????????//?將老的數(shù)據復制到?results?數(shù)組
????????????System.arraycopy(services,?0,?results,?0,?services.length);
????????????results[services.length]?=?service;
????????????services?=?results;
??????//?啟動?Service?組件
????????????if?(getState().isAvailable())?{
????????????????try?{
????????????????????service.start();
????????????????}?catch?(LifecycleException?e)?{
????????????????????//?Ignore
????????????????}
????????????}

????????????//?觀察者模式運用，觸發(fā)監(jiān)聽事件
????????????support.firePropertyChange("service",?null,?service);
????????}

????}

從上面的代碼可以知道，并不是一開始就分配一個很長的數(shù)組，而是在新增過程中動態(tài)拓展長度，這里就是為了節(jié)省空間，對于我們平時開發(fā)是不是也要主要空間復雜度帶來的內存損耗，追求的就是極致的美。

除此之外，還有一個重要功能，上面 Caralina 的啟動方法的最后一行代碼就是調用了 Server 的 await 方法。

這個方法主要就是監(jiān)聽停止端口，在?await?方法里會創(chuàng)建一個 Socket 監(jiān)聽 8005 端口，并在一個死循環(huán)里接收 Socket 上的連接請求，如果有新的連接到來就建立連接，然后從 Socket 中讀取數(shù)據；如果讀到的數(shù)據是停止命令“SHUTDOWN”，就退出循環(huán)，進入 stop 流程。

Service

同樣是面向接口設計，Service 組件的具體實現(xiàn)類是 StandardService，Service 組件依然是繼承 Lifecycle 管理生命周期，這里不再累贅展示圖片關系圖。我們先來看看 Service 接口主要定義的方法以及成員變量。通過接口我們才能知道核心功能，在閱讀源碼的時候一定要多關注每個接口之間的關系，不要急著進入實現(xiàn)類。

public?interface?Service?extends?Lifecycle?{

??//?----------主要成員變量

????//Service?組件包含的頂層容器?Engine
????public?Engine?getContainer();

????//?設置?Service?的?Engine?容器
????public?void?setContainer(Engine?engine);

????//?該?Service?所屬的?Server?組件
????public?Server?getServer();

????//?---------------------------------------------------------?Public?Methods

???//?添加?Service?關聯(lián)的連接器
????public?void?addConnector(Connector?connector);

????public?Connector[]?findConnectors();

???//?自定義線程池
????public?void?addExecutor(Executor?ex);

???//?主要作用就是根據?url?定位到?Service，Mapper?的主要作用就是用于定位一個請求所在的組件處理
????Mapper?getMapper();
}

接著再來細看 Service 的實現(xiàn)類：

public?class?StandardService?extends?LifecycleBase?implements?Service?{
????//?名字
????private?String?name?=?null;

????//Server?實例
????private?Server?server?=?null;

????//?連接器數(shù)組
????protected?Connector?connectors[]?=?new?Connector[0];
????private?final?Object?connectorsLock?=?new?Object();

????//?對應的?Engine?容器
????private?Engine?engine?=?null;

????//?映射器及其監(jiān)聽器，又是觀察者模式的運用
????protected?final?Mapper?mapper?=?new?Mapper();
????protected?final?MapperListener?mapperListener?=?new?MapperListener(this);
}

StandardService 繼承了 LifecycleBase 抽象類，抽象類定義了 三個 final 模板方法定義生命周期，每個方法將變化點定義抽象方法讓不同組件實現(xiàn)自己的流程。這里也是我們學習的地方，利用模板方法抽象變與不變。

此外 StandardService 中還有一些我們熟悉的組件，比如 Server、Connector、Engine 和 Mapper。

那為什么還有一個 MapperListener？這是因為 Tomcat 支持熱部署，當 Web 應用的部署發(fā)生變化時，Mapper 中的映射信息也要跟著變化，MapperListener 就是一個監(jiān)聽器，它監(jiān)聽容器的變化，并把信息更新到 Mapper 中，這是典型的觀察者模式。下游服務根據多上游服務的動作做出不同處理，這就是?觀察者模式的運用場景，實現(xiàn)一個事件多個監(jiān)聽器觸發(fā)，事件發(fā)布者不用調用所有下游，而是通過觀察者模式觸發(fā)達到解耦。

Service 管理了 連接器以及 Engine 頂層容器，所以繼續(xù)進入它的 startInternal 方法，其實就是 LifecycleBase 模板定義的 抽象方法。看看他是怎么啟動每個組件順序。

protected?void?startInternal()?throws?LifecycleException?{

????//1.?觸發(fā)啟動監(jiān)聽器
????setState(LifecycleState.STARTING);

????//2. 先啟動 Engine，Engine 會啟動它子容器，因為運用了組合模式，所以每一層容器在會先啟動自己的子容器。
????if?(engine?!=?null)?{
????????synchronized?(engine)?{
????????????engine.start();
????????}
????}

????//3.?再啟動?Mapper?監(jiān)聽器
????mapperListener.start();

????//4.?最后啟動連接器，連接器會啟動它子組件，比如?Endpoint
????synchronized?(connectorsLock)?{
????????for?(Connector?connector:?connectors)?{
????????????if?(connector.getState()?!=?LifecycleState.FAILED)?{
????????????????connector.start();
????????????}
????????}
????}
}

Service 先啟動了 Engine 組件，再啟動 Mapper 監(jiān)聽器，最后才是啟動連接器。這很好理解，因為內層組件啟動好了才能對外提供服務，才能啟動外層的連接器組件。而 Mapper 也依賴容器組件，容器組件啟動好了才能監(jiān)聽它們的變化，因此 Mapper 和 MapperListener 在容器組件之后啟動。組件停止的順序跟啟動順序正好相反的，也是基于它們的依賴關系。

Engine

作為 Container 的頂層組件，所以 Engine 本質就是一個容器，繼承了 ContainerBase ，看到抽象類再次運用了模板方法設計模式。ContainerBase 使用一個?HashMap children = new HashMap<>();?成員變量保存每個組件的子容器。同時使用?protected final Pipeline pipeline = new StandardPipeline(this);?Pipeline 組成一個管道用于處理連接器傳過來的請求，責任鏈模式構建管道。

?public?class?StandardEngine?extends?ContainerBase?implements?Engine?{
?}

Engine 的子容器是 Host，所以 children 保存的就是 Host。

我們來看看 ContainerBase 做了什么...

• initInternal 定義了容器初始化，同時創(chuàng)建了專門用于啟動停止容器的線程池。
• startInternal：容器啟動默認實現(xiàn)，通過組合模式構建容器父子關系，首先獲取自己的子容器，使用 startStopExecutor 啟動子容器。

public?abstract?class?ContainerBase?extends?LifecycleMBeanBase
????????implements?Container?{

???//?提供了默認初始化邏輯
????@Override
????protected?void?initInternal()?throws?LifecycleException?{
????????BlockingQueue?startStopQueue?=?new?LinkedBlockingQueue<>();
???????//?創(chuàng)建線程池用于啟動或者停止容器
????????startStopExecutor?=?new?ThreadPoolExecutor(
????????????????getStartStopThreadsInternal(),
????????????????getStartStopThreadsInternal(),?10,?TimeUnit.SECONDS,
????????????????startStopQueue,
????????????????new?StartStopThreadFactory(getName()?+?"-startStop-"));
????????startStopExecutor.allowCoreThreadTimeOut(true);
????????super.initInternal();
????}

??//?容器啟動
????@Override
????protected?synchronized?void?startInternal()?throws?LifecycleException?{

????????//?獲取子容器并提交到線程池啟動
????????Container?children[]?=?findChildren();
????????List>?results?=?new?ArrayList<>();
????????for?(Container?child?:?children)?{
????????????results.add(startStopExecutor.submit(new?StartChild(child)));
????????}
????????MultiThrowable?multiThrowable?=?null;
????????//?獲取啟動結果
????????for?(Future?result?:?results)?{
????????????try?{
????????????????result.get();
????????????}?catch?(Throwable?e)?{
????????????????log.error(sm.getString("containerBase.threadedStartFailed"),?e);
????????????????if?(multiThrowable?==?null)?{
????????????????????multiThrowable?=?new?MultiThrowable();
????????????????}
????????????????multiThrowable.add(e);
????????????}

????????}
???????......

????????//?啟動?pipeline?管道，用于處理連接器傳遞過來的請求
????????if?(pipeline?instanceof?Lifecycle)?{
????????????((Lifecycle)?pipeline).start();
????????}
?????//?發(fā)布啟動事件
????????setState(LifecycleState.STARTING);
????????//?Start?our?thread
????????threadStart();
????}


}

繼承了 LifecycleMBeanBase 也就是還實現(xiàn)了生命周期的管理，提供了子容器默認的啟動方式，同時提供了對子容器的 CRUD 功能。

Engine 在啟動 Host 容器就是 使用了 ContainerBase 的 startInternal 方法。Engine 自己還做了什么呢？

我們看下 構造方法，pipeline 設置了 setBasic，創(chuàng)建了 StandardEngineValve。

/**
?????*?Create?a?new?StandardEngine?component?with?the?default?basic?Valve.
?????*/
????public?StandardEngine()?{

????????super();
????????pipeline.setBasic(new?StandardEngineValve());
????????.....

????}

容器主要的功能就是處理請求，把請求轉發(fā)給某一個 Host 子容器來處理，具體是通過 Valve 來實現(xiàn)的。每個容器組件都有一個 Pipeline 用于組成一個責任鏈傳遞請求。而 Pipeline 中有一個基礎閥（Basic Valve），而 Engine 容器的基礎閥定義如下：

final?class?StandardEngineValve?extends?ValveBase?{
????@Override
????public?final?void?invoke(Request?request,?Response?response)
????????throws?IOException,?ServletException?{

????????//?選擇一個合適的?Host?處理請求，通過?Mapper?組件獲取到合適的?Host
????????Host?host?=?request.getHost();
????????if?(host?==?null)?{
????????????response.sendError
????????????????(HttpServletResponse.SC_BAD_REQUEST,
?????????????????sm.getString("standardEngine.noHost",
??????????????????????????????request.getServerName()));
????????????return;
????????}
????????if?(request.isAsyncSupported())?{
????????????request.setAsyncSupported(host.getPipeline().isAsyncSupported());
????????}

????????//?獲取?Host?容器的?Pipeline?first?Valve?,將請求轉發(fā)到?Host
????????host.getPipeline().getFirst().invoke(request,?response);
}

這個基礎閥實現(xiàn)非常簡單，就是把請求轉發(fā)到 Host 容器。處理請求的 Host 容器對象是從請求中拿到的，請求對象中怎么會有 Host 容器呢？這是因為請求到達 Engine 容器中之前，Mapper 組件已經對請求進行了路由處理，Mapper 組件通過請求的 URL 定位了相應的容器，并且把容器對象保存到了請求對象中。

組件設計總結

大家有沒有發(fā)現(xiàn)，Tomcat 的設計幾乎都是面向接口設計，也就是通過接口隔離功能設計其實就是單一職責的體現(xiàn)，每個接口抽象對象不同的組件，通過抽象類定義組件的共同執(zhí)行流程。單一職責四個字的含義其實就是在這里體現(xiàn)出來了。在分析過程中，我們看到了觀察者模式、模板方法模式、組合模式、責任鏈模式以及如何抽象組件面向接口設計的設計哲學。

連接器之 I/O 模型與線程池設計

連接器主要功能就是接受 TCP/IP 連接，限制連接數(shù)然后讀取數(shù)據，最后將請求轉發(fā)到?Container?容器。所以這里必然涉及到 I/O 編程，今天帶大家一起分析 Tomcat 如何運用 I/O 模型實現(xiàn)高并發(fā)的，一起進入 I/O 的世界。

I/O 模型主要有 5 種：同步阻塞、同步非阻塞、I/O 多路復用、信號驅動、異步 I/O。是不是很熟悉但是又傻傻分不清他們有何區(qū)別？

所謂的I/O 就是計算機內存與外部設備之間拷貝數(shù)據的過程。

CPU 是先把外部設備的數(shù)據讀到內存里，然后再進行處理。請考慮一下這個場景，當程序通過 CPU 向外部設備發(fā)出一個讀指令時，數(shù)據從外部設備拷貝到內存往往需要一段時間，這個時候 CPU 沒事干了，程序是主動把 CPU 讓給別人？還是讓 CPU 不停地查：數(shù)據到了嗎，數(shù)據到了嗎……

這就是 I/O 模型要解決的問題。今天我會先說說各種 I/O 模型的區(qū)別，然后重點分析 Tomcat 的 NioEndpoint 組件是如何實現(xiàn)非阻塞 I/O 模型的。

I/O 模型

一個網絡 I/O 通信過程，比如網絡數(shù)據讀取，會涉及到兩個對象，分別是調用這個 I/O 操作的用戶線程和操作系統(tǒng)內核。一個進程的地址空間分為用戶空間和內核空間，用戶線程不能直接訪問內核空間。

網絡讀取主要有兩個步驟：

• 用戶線程等待內核將數(shù)據從網卡復制到內核空間。
• 內核將數(shù)據從內核空間復制到用戶空間。

同理，將數(shù)據發(fā)送到網絡也是一樣的流程，將數(shù)據從用戶線程復制到內核空間，內核空間將數(shù)據復制到網卡發(fā)送。

不同 I/O 模型的區(qū)別：實現(xiàn)這兩個步驟的方式不一樣。

• 對于同步，則指的應用程序調用一個方法是否立馬返回，而不需要等待。
• 對于阻塞與非阻塞：主要就是數(shù)據從內核復制到用戶空間的讀寫操作是否是阻塞等待的。

同步阻塞 I/O

用戶線程發(fā)起read調用的時候，線程就阻塞了，只能讓出 CPU，而內核則等待網卡數(shù)據到來，并把數(shù)據從網卡拷貝到內核空間，當內核把數(shù)據拷貝到用戶空間，再把剛剛阻塞的讀取用戶線程喚醒，兩個步驟的線程都是阻塞的。

同步非阻塞

用戶線程一直不停的調用read方法，如果數(shù)據還沒有復制到內核空間則返回失敗，直到數(shù)據到達內核空間。用戶線程在等待數(shù)據從內核空間復制到用戶空間的時間里一直是阻塞的，等數(shù)據到達用戶空間才被喚醒。循環(huán)調用read方法的時候不阻塞。

I/O 多路復用

用戶線程的讀取操作被劃分為兩步：

1. 用戶線程先發(fā)起?select?調用，主要就是詢問內核數(shù)據準備好了沒？當內核把數(shù)據準備好了就執(zhí)行第二步。
2. 用戶線程再發(fā)起?read?調用，在等待內核把數(shù)據從內核空間復制到用戶空間的時間里，發(fā)起 read 線程是阻塞的。

為何叫 I/O 多路復用，核心主要就是：一次?select?調用可以向內核查詢多個**數(shù)據通道(Channel)**的狀態(tài)，因此叫多路復用。

異步 I/O

用戶線程執(zhí)行 read 調用的時候會注冊一個回調函數(shù)， read 調用立即返回，不會阻塞線程，在等待內核將數(shù)據準備好以后，再調用剛剛注冊的回調函數(shù)處理數(shù)據，在整個過程中用戶線程一直沒有阻塞。

Tomcat NioEndpoint

Tomcat 的 NioEndpoit 組件實際上就是實現(xiàn)了 I/O 多路復用模型，正是因為這個并發(fā)能力才足夠優(yōu)秀。讓我們一起窺探下 Tomcat NioEndpoint 的設計原理。

對于 Java 的多路復用器的使用，無非是兩步：

1. 創(chuàng)建一個 Seletor，在它身上注冊各種感興趣的事件，然后調用 select 方法，等待感興趣的事情發(fā)生。

2. 感興趣的事情發(fā)生了，比如可以讀了，這時便創(chuàng)建一個新的線程從 Channel 中讀數(shù)據。

Tomcat 的 NioEndpoint 組件雖然實現(xiàn)比較復雜，但基本原理就是上面兩步。我們先來看看它有哪些組件，它一共包含 LimitLatch、Acceptor、Poller、SocketProcessor 和 Executor 共 5 個組件，它們的工作過程如下圖所示：

正是由于使用了 I/O 多路復用，Poller 內部本質就是持有 Java Selector 檢測 channel 的 I/O 時間，當數(shù)據可讀寫的時候創(chuàng)建 SocketProcessor 任務丟到線程池執(zhí)行，也就是少量線程監(jiān)聽讀寫事件，接著專屬的線程池執(zhí)行讀寫，提高性能。

自定義線程池模型

為了提高處理能力和并發(fā)度， Web 容器通常會把處理請求的工作放在線程池來處理， Tomcat 拓展了 Java 原生的線程池來提升并發(fā)需求，在進入 Tomcat 線程池原理之前，我們先回顧下 Java 線程池原理。

Java 線程池

簡單的說，Java 線程池里內部維護一個線程數(shù)組和一個任務隊列，當任務處理不過來的時，就把任務放到隊列里慢慢處理。

ThreadPoolExecutor

來窺探線程池核心類的構造函數(shù)，我們需要理解每一個參數(shù)的作用，才能理解線程池的工作原理。

????public?ThreadPoolExecutor(int?corePoolSize,
??????????????????????????????int?maximumPoolSize,
??????????????????????????????long?keepAliveTime,
??????????????????????????????TimeUnit?unit,
??????????????????????????????BlockingQueue?workQueue,
??????????????????????????????ThreadFactory?threadFactory,
??????????????????????????????RejectedExecutionHandler?handler)?{
????????......
????}

• corePoolSize：保留在池中的線程數(shù)，即使它們空閑，除非設置了 allowCoreThreadTimeOut，不然不會關閉。
• maximumPoolSize：隊列滿后池中允許的最大線程數(shù)。
• keepAliveTime、TimeUnit：如果線程數(shù)大于核心數(shù)，多余的空閑線程的保持的最長時間會被銷毀。unit 是 keepAliveTime 參數(shù)的時間單位。當設置?allowCoreThreadTimeOut(true)?時，線程池中 corePoolSize 范圍內的線程空閑時間達到 keepAliveTime 也將回收。
• workQueue：當線程數(shù)達到?corePoolSize?后，新增的任務就放到工作隊列?workQueue?里，而線程池中的線程則努力地從?workQueue?里拉活來干，也就是調用 poll 方法來獲取任務。
• ThreadFactory：創(chuàng)建線程的工廠，比如設置是否是后臺線程、線程名等。
• RejectedExecutionHandler：拒絕策略，處理程序因為達到了線程界限和隊列容量執(zhí)行拒絕策略。也可以自定義拒絕策略，只要實現(xiàn)?RejectedExecutionHandler?即可。默認的拒絕策略：AbortPolicy?拒絕任務并拋出?RejectedExecutionException?異常；CallerRunsPolicy?提交該任務的線程執(zhí)行；``

來分析下每個參數(shù)之間的關系：

提交新任務的時候，如果線程池數(shù) < corePoolSize，則創(chuàng)建新的線程池執(zhí)行任務，當線程數(shù) = corePoolSize 時，新的任務就會被放到工作隊列 workQueue 中，線程池中的線程盡量從隊列里取任務來執(zhí)行。

如果任務很多，workQueue 滿了，且 當前線程數(shù) < maximumPoolSize 時則臨時創(chuàng)建線程執(zhí)行任務，如果總線程數(shù)量超過 maximumPoolSize，則不再創(chuàng)建線程，而是執(zhí)行拒絕策略。DiscardPolicy?什么都不做直接丟棄任務；DiscardOldestPolicy?丟棄最舊的未處理程序;

具體執(zhí)行流程如下圖所示：

Tomcat 線程池

定制版的 ThreadPoolExecutor，繼承了 java.util.concurrent.ThreadPoolExecutor。對于線程池有兩個很關鍵的參數(shù)：

• 線程個數(shù)。
• 隊列長度。

Tomcat 必然需要限定想著兩個參數(shù)不然在高并發(fā)場景下可能導致 CPU 和內存有資源耗盡的風險。繼承了 與 java.util.concurrent.ThreadPoolExecutor 相同，但實現(xiàn)的效率更高。

其構造方法如下，跟 Java 官方的如出一轍

public?ThreadPoolExecutor(int?corePoolSize,?int?maximumPoolSize,?long?keepAliveTime,?TimeUnit?unit,?BlockingQueue?workQueue,?RejectedExecutionHandler?handler)?{
????????super(corePoolSize,?maximumPoolSize,?keepAliveTime,?unit,?workQueue,?handler);
????????prestartAllCoreThreads();
????}

在 Tomcat 中控制線程池的組件是?StandardThreadExecutor?, 也是實現(xiàn)了生命周期接口，下面是啟動線程池的代碼

????@Override
????protected?void?startInternal()?throws?LifecycleException?{
????????//?自定義任務隊列
????????taskqueue?=?new?TaskQueue(maxQueueSize);
????????//?自定義線程工廠
????????TaskThreadFactory?tf?=?new?TaskThreadFactory(namePrefix,daemon,getThreadPriority());
???????//?創(chuàng)建定制版線程池
????????executor?=?new?ThreadPoolExecutor(getMinSpareThreads(),?getMaxThreads(),?maxIdleTime,?TimeUnit.MILLISECONDS,taskqueue,?tf);
????????executor.setThreadRenewalDelay(threadRenewalDelay);
????????if?(prestartminSpareThreads)?{
????????????executor.prestartAllCoreThreads();
????????}
????????taskqueue.setParent(executor);
????????//?觀察者模式，發(fā)布啟動事件
????????setState(LifecycleState.STARTING);
????}

其中的關鍵點在于：

1. Tomcat 有自己的定制版任務隊列和線程工廠，并且可以限制任務隊列的長度，它的最大長度是 maxQueueSize。
2. Tomcat 對線程數(shù)也有限制，設置了核心線程數(shù)（minSpareThreads）和最大線程池數(shù)（maxThreads）。

除此之外， Tomcat 在官方原有基礎上重新定義了自己的線程池處理流程，原生的處理流程上文已經說過。

• 前 corePoolSize 個任務時，來一個任務就創(chuàng)建一個新線程。
• 還有任務提交，直接放到隊列，隊列滿了，但是沒有達到最大線程池數(shù)則創(chuàng)建臨時線程救火。
• 線程總線數(shù)達到 maximumPoolSize ，直接執(zhí)行拒絕策略。

Tomcat 線程池擴展了原生的 ThreadPoolExecutor，通過重寫 execute 方法實現(xiàn)了自己的任務處理邏輯：

• 前 corePoolSize 個任務時，來一個任務就創(chuàng)建一個新線程。
• 還有任務提交，直接放到隊列，隊列滿了，但是沒有達到最大線程池數(shù)則創(chuàng)建臨時線程救火。
• 線程總線數(shù)達到 maximumPoolSize ，繼續(xù)嘗試把任務放到隊列中。如果隊列也滿了，插入任務失敗，才執(zhí)行拒絕策略。

最大的差別在于 Tomcat 在線程總數(shù)達到最大數(shù)時，不是立即執(zhí)行拒絕策略，而是再嘗試向任務隊列添加任務，添加失敗后再執(zhí)行拒絕策略。

代碼如下所示:

????public?void?execute(Runnable?command,?long?timeout,?TimeUnit?unit)?{
???????//?記錄提交任務數(shù)?+1
????????submittedCount.incrementAndGet();
????????try?{
????????????//?調用?java?原生線程池來執(zhí)行任務，當原生拋出拒絕策略
????????????super.execute(command);
????????}?catch?(RejectedExecutionException?rx)?{
??????????//總線程數(shù)達到?maximumPoolSize，Java?原生會執(zhí)行拒絕策略
????????????if?(super.getQueue()?instanceof?TaskQueue)?{
????????????????final?TaskQueue?queue?=?(TaskQueue)super.getQueue();
????????????????try?{
????????????????????//?嘗試把任務放入隊列中
????????????????????if?(!queue.force(command,?timeout,?unit))?{
????????????????????????submittedCount.decrementAndGet();
??????????????????????//?隊列還是滿的，插入失敗則執(zhí)行拒絕策略
????????????????????????throw?new?RejectedExecutionException("Queue?capacity?is?full.");
????????????????????}
????????????????}?catch?(InterruptedException?x)?{
????????????????????submittedCount.decrementAndGet();
????????????????????throw?new?RejectedExecutionException(x);
????????????????}
????????????}?else?{
??????????????//?提交任務書?-1
????????????????submittedCount.decrementAndGet();
????????????????throw?rx;
????????????}

????????}
????}

Tomcat 線程池是用 submittedCount 來維護已經提交到了線程池，這跟 Tomcat 的定制版的任務隊列有關。Tomcat 的任務隊列 TaskQueue 擴展了 Java 中的 LinkedBlockingQueue，我們知道 LinkedBlockingQueue 默認情況下長度是沒有限制的，除非給它一個 capacity。因此 Tomcat 給了它一個 capacity，TaskQueue 的構造函數(shù)中有個整型的參數(shù) capacity，TaskQueue 將 capacity 傳給父類 LinkedBlockingQueue 的構造函數(shù)，防止無限添加任務導致內存溢出。而且默認是無限制，就會導致當前線程數(shù)達到核心線程數(shù)之后，再來任務的話線程池會把任務添加到任務隊列，并且總是會成功，這樣永遠不會有機會創(chuàng)建新線程了。

為了解決這個問題，TaskQueue 重寫了 LinkedBlockingQueue 的 offer 方法，在合適的時機返回 false，返回 false 表示任務添加失敗，這時線程池會創(chuàng)建新的線程。

public?class?TaskQueue?extends?LinkedBlockingQueue<Runnable>?{

??...
???@Override
??//?線程池調用任務隊列的方法時，當前線程數(shù)肯定已經大于核心線程數(shù)了
??public?boolean?offer(Runnable?o)?{

??????//?如果線程數(shù)已經到了最大值，不能創(chuàng)建新線程了，只能把任務添加到任務隊列。
??????if?(parent.getPoolSize()?==?parent.getMaximumPoolSize())
??????????return?super.offer(o);

??????//?執(zhí)行到這里，表明當前線程數(shù)大于核心線程數(shù)，并且小于最大線程數(shù)。
??????//?表明是可以創(chuàng)建新線程的，那到底要不要創(chuàng)建呢？分兩種情況：

??????//1.?如果已提交的任務數(shù)小于當前線程數(shù)，表示還有空閑線程，無需創(chuàng)建新線程
??????if?(parent.getSubmittedCount()<=(parent.getPoolSize()))
??????????return?super.offer(o);

??????//2.?如果已提交的任務數(shù)大于當前線程數(shù)，線程不夠用了，返回?false?去創(chuàng)建新線程
??????if?(parent.getPoolSize()??????????return?false;

??????//?默認情況下總是把任務添加到任務隊列
??????return?super.offer(o);
??}

}

只有當前線程數(shù)大于核心線程數(shù)、小于最大線程數(shù)，并且已提交的任務個數(shù)大于當前線程數(shù)時，也就是說線程不夠用了，但是線程數(shù)又沒達到極限，才會去創(chuàng)建新的線程。這就是為什么 Tomcat 需要維護已提交任務數(shù)這個變量，它的目的就是在任務隊列的長度無限制的情況下，讓線程池有機會創(chuàng)建新的線程。可以通過設置 maxQueueSize 參數(shù)來限制任務隊列的長度。

性能優(yōu)化

線程池調優(yōu)

跟 I/O 模型緊密相關的是線程池，線程池的調優(yōu)就是設置合理的線程池參數(shù)。我們先來看看 Tomcat 線程池中有哪些關鍵參數(shù)：

這里面最核心的就是如何確定 maxThreads 的值，如果這個參數(shù)設置小了，Tomcat 會發(fā)生線程饑餓，并且請求的處理會在隊列中排隊等待，導致響應時間變長；如果 maxThreads 參數(shù)值過大，同樣也會有問題，因為服務器的 CPU 的核數(shù)有限，線程數(shù)太多會導致線程在 CPU 上來回切換，耗費大量的切換開銷。

線程 I/O 時間與 CPU 時間

至此我們又得到一個線程池個數(shù)的計算公式，假設服務器是單核的：

線程池大小 = （線程 I/O 阻塞時間 + 線程 CPU 時間 ）/ 線程 CPU 時間

其中：線程 I/O 阻塞時間 + 線程 CPU 時間 = 平均請求處理時間。

Tomcat 內存溢出的原因分析及調優(yōu)

JVM 在拋出 java.lang.OutOfMemoryError 時，除了會打印出一行描述信息，還會打印堆棧跟蹤，因此我們可以通過這些信息來找到導致異常的原因。在尋找原因前，我們先來看看有哪些因素會導致 OutOfMemoryError，其中內存泄漏是導致 OutOfMemoryError 的一個比較常見的原因。

其實調優(yōu)很多時候都是在找系統(tǒng)瓶頸，假如有個狀況：系統(tǒng)響應比較慢，但 CPU 的用率不高，內存有所增加，通過分析 Heap Dump 發(fā)現(xiàn)大量請求堆積在線程池的隊列中，請問這種情況下應該怎么辦呢？可能是請求處理時間太長，去排查是不是訪問數(shù)據庫或者外部應用遇到了延遲。

java.lang.OutOfMemoryError: Java heap space

當 JVM 無法在堆中分配對象的會拋出此異常，一般有以下原因：

1. 內存泄漏：本該回收的對象唄程序一直持有引用導致對象無法被回收，比如在線程池中使用 ThreadLocal、對象池、內存池。為了找到內存泄漏點，我們通過 jmap 工具生成 Heap Dump，再利用 MAT 分析找到內存泄漏點。jmap -dump:live,format=b,file=filename.bin pid

2. 內存不足：我們設置的堆大小對于應用程序來說不夠，修改 JVM 參數(shù)調整堆大小，比如 -Xms256m -Xmx2048m。

3. finalize 方法的過度使用。如果我們想在 Java 類實例被 GC 之前執(zhí)行一些邏輯，比如清理對象持有的資源，可以在 Java 類中定義 finalize 方法，這樣 JVM GC 不會立即回收這些對象實例，而是將對象實例添加到一個叫“java.lang.ref.Finalizer.ReferenceQueue”的隊列中，執(zhí)行對象的 finalize 方法，之后才會回收這些對象。Finalizer 線程會和主線程競爭 CPU 資源，但由于優(yōu)先級低，所以處理速度跟不上主線程創(chuàng)建對象的速度，因此 ReferenceQueue 隊列中的對象就越來越多，最終會拋出 OutOfMemoryError。解決辦法是盡量不要給 Java 類定義 finalize 方法。

java.lang.OutOfMemoryError: GC overhead limit exceeded

垃圾收集器持續(xù)運行，但是效率很低幾乎沒有回收內存。比如 Java 進程花費超過 96％的 CPU 時間來進行一次 GC，但是回收的內存少于 3％的 JVM 堆，并且連續(xù) 5 次 GC 都是這種情況，就會拋出 OutOfMemoryError。

這個問題 IDE 解決方法就是查看 GC 日志或者生成 Heap Dump，先確認是否是內存溢出，不是的話可以嘗試增加堆大小。可以通過如下 JVM 啟動參數(shù)打印 GC 日志:

-verbose:gc?//在控制臺輸出GC情況
-XX:+PrintGCDetails??//在控制臺輸出詳細的GC情況
-Xloggc:?filepath??//將GC日志輸出到指定文件中

比如 可以使用?java -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -jar xxx.jar?記錄 GC 日志，通過 GCViewer 工具查看 GC 日志，用 GCViewer 打開產生的 gc.log 分析垃圾回收情況。

java.lang.OutOfMemoryError: Requested array size exceeds VM limit

拋出這種異常的原因是“請求的數(shù)組大小超過 JVM 限制”，應用程序嘗試分配一個超大的數(shù)組。比如程序嘗試分配 128M 的數(shù)組，但是堆最大 100M，一般這個也是配置問題，有可能 JVM 堆設置太小，也有可能是程序的 bug，是不是創(chuàng)建了超大數(shù)組。

java.lang.OutOfMemoryError: MetaSpace

JVM 元空間的內存在本地內存中分配，但是它的大小受參數(shù) MaxMetaSpaceSize 的限制。當元空間大小超過 MaxMetaSpaceSize 時，JVM 將拋出帶有 MetaSpace 字樣的 OutOfMemoryError。解決辦法是加大 MaxMetaSpaceSize 參數(shù)的值。

java.lang.OutOfMemoryError: Request size bytes for reason. Out of swap space

當本地堆內存分配失敗或者本地內存快要耗盡時，Java HotSpot VM 代碼會拋出這個異常，VM 會觸發(fā)“致命錯誤處理機制”，它會生成“致命錯誤”日志文件，其中包含崩潰時線程、進程和操作系統(tǒng)的有用信息。如果碰到此類型的 OutOfMemoryError，你需要根據 JVM 拋出的錯誤信息來進行診斷；或者使用操作系統(tǒng)提供的 DTrace 工具來跟蹤系統(tǒng)調用，看看是什么樣的程序代碼在不斷地分配本地內存。

java.lang.OutOfMemoryError: Unable to create native threads

1. Java 程序向 JVM 請求創(chuàng)建一個新的 Java 線程。
2. JVM 本地代碼（Native Code）代理該請求，通過調用操作系統(tǒng) API 去創(chuàng)建一個操作系統(tǒng)級別的線程 Native Thread。
3. 操作系統(tǒng)嘗試創(chuàng)建一個新的 Native Thread，需要同時分配一些內存給該線程，每一個 Native Thread 都有一個線程棧，線程棧的大小由 JVM 參數(shù)-Xss決定。
4. 由于各種原因，操作系統(tǒng)創(chuàng)建新的線程可能會失敗，下面會詳細談到。
5. JVM 拋出“java.lang.OutOfMemoryError: Unable to create new native thread”錯誤。

總結

回顧 Tomcat 總結架構設計，詳細拆解 Tomcat 如何處理高并發(fā)連接設計。并且分享了如何高效閱讀開源框架源碼思路，設計模式、并發(fā)編程基礎是重中之重.

點個在看支持我吧，轉發(fā)就更好了