其實，大部分 Java 開發同學知道這兩種線程池的特性，只是抱有僥幸心理，覺得只是使用線程池做一些輕量級的任務，不可能造成隊列積壓或開啟大量線程。

但，現實往往是殘酷的。 我之前就遇到過這么一個事故：用戶注冊后，我們調用一個外部服務去發送短信，發送短信接口正常時可以在 100 毫秒內響應，TPS 100 的注冊量，CachedThreadPool 能穩定在占用 10 個左右線程的情況下滿足需求。 在某個時間點，外部短信服務不可用了，我們調用這個服務的超時又特別長，比如 1 分鐘，1 分鐘可能就進來了 6000 用戶，產生 6000 個發送短信的任務，需要 6000 個線程，沒多久就因為無法創建線程導致了 OOM，整個應用程序崩潰。

因此，我同樣不建議使用 Executors 提供的兩種快捷的線程池，原因如下：

我們需要根據自己的場景、并發情況來評估線程池的幾個核心參數，包括核心線程數、最大線程數、線程回收策略、工作隊列的類型，以及拒絕策略，確保線程池的工作行為符合需求，一般都需要設置有界的工作隊列和可控的線程數。

任何時候，都應該為自定義線程池指定有意義的名稱，以方便排查問題。 當出現線程數量暴增、線程死鎖、線程占用大量 CPU、線程執行出現異常等問題時，我們往往會抓取線程棧。 此時，有意義的線程名稱，就可以方便我們定位問題。

除了建議手動聲明線程池以外，我還建議用一些監控手段來觀察線程池的狀態。 線程池這個組件往往會表現得任勞任怨、默默無聞，除非是出現了拒絕策略，否則壓力再大都不會拋出一個異常。 如果我們能提前觀察到線程池隊列的積壓，或者線程數量的快速膨脹，往往可以提早發現并解決問題。

在之前的 Demo 中，我們用一個 printStats 方法實現了最簡陋的監控，每秒輸出一次線程池的基本內部信息，包括線程數、活躍線程數、完成了多少任務，以及隊列中還有多少積壓任務等信息：

接下來，我們就利用這個方法來觀察一下線程池的基本特性吧。

首先，自定義一個線程池。 這個線程池具有 2 個核心線程、5 個最大線程、使用容量為 10 的 ArrayBlockingQueue 阻塞隊列作為工作隊列，使用默認的 AbortPolicy 拒絕策略，也就是任務添加到線程池失敗會拋出 RejectedExecutionException。 此外，我們借助了 Jodd 類庫的 ThreadFactoryBuilder 方法來構造一個線程工廠，實現線程池線程的自定義命名。

60 秒后頁面輸出了 17，有 3 次提交失敗了

并且日志中也出現了 3 次類似的錯誤信息：

我們把 printStats 方法打印出的日志繪制成圖表，得出如下曲線：

至此，我們可以總結出線程池默認的工作行為：

不會初始化 corePoolSize 個線程，有任務來了才創建工作線程；

當核心線程滿了之后不會立即擴容線程池，而是把任務堆積到工作隊列中；

當工作隊列滿了后擴容線程池，一直到線程個數達到 maximumPoolSize 為止；

如果隊列已滿且達到了最大線程后還有任務進來，按照拒絕策略處理；

當線程數大于核心線程數時，線程等待 keepAliveTime 后還是沒有任務需要處理的話，收縮線程到核心線程數。

了解這個策略，有助于我們根據實際的容量規劃需求，為線程池設置合適的初始化參數。當然，我們也可以通過一些手段來改變這些默認工作行為，比如：

聲明線程池后立即調用 prestartAllCoreThreads 方法，來啟動所有核心線程；

傳入 true 給 allowCoreThreadTimeOut 方法，來讓線程池在空閑的時候同樣回收核心線程。

不知道你有沒有想過：Java 線程池是先用工作隊列來存放來不及處理的任務，滿了之后再擴容線程池。 當我們的工作隊列設置得很大時，最大線程數這個參數顯得沒有意義，因為隊列很難滿，或者到滿的時候再去擴容線程池已經于事無那么，我們有沒有辦法讓線程池更激進一點，優先開啟更多的線程，而把隊列當成一個后備方案呢？比如我們這個例子，任務執行得很慢，需要 10 秒，如果線程池可以優先擴容到 5 個最大線程，那么這些任務最終都可以完成，而不會因為線程池擴容過晚導致慢任務來不及處理。

這里我只給你一個大致思路：

由于線程池在工作隊列滿了無法入隊的情況下會擴容線程池，那么我們是否可以重寫隊列的 offer 方法，造成這個隊列已滿的假象呢？

由于我們 Hack 了隊列，在達到了最大線程后勢必會觸發拒絕策略，那么能否實現一個自定義的拒絕策略處理程序，這個時候再把任務真正插入隊列呢？

接下來，就請你動手試試看如何實現這樣一個“彈性”線程池吧。 Tomcat 線程池也實現了類似的效果，可供你借鑒。

不久之前我遇到了這樣一個事故：某項目生產環境時不時有報警提示線程數過多，超過 2000 個，收到報警后查看監控發現，瞬時線程數比較多但過一會兒又會降下來，線程數抖動很厲害，而應用的訪問量變化不大。

為了定位問題，我們在線程數比較高的時候進行線程棧抓取，抓取后發現內存中有 1000 多個自定義線程池。 一般而言，線程池肯定是復用的，有 5 個以內的線程池都可以認為正常，而 1000 多個線程池肯定不正常。

在項目代碼里，我們沒有搜到聲明線程池的地方，搜索 execute 關鍵字后定位到，原來是業務代碼調用了一個類庫來獲得線程池，類似如下的業務代碼：調用 ThreadPoolHelper 的 getThreadPool 方法來獲得線程池，然后提交數個任務到線程池處理，看不出什么異常。

但是，來到 ThreadPoolHelper 的實現讓人大跌眼鏡，getThreadPool 方法居然是每次都使用 來創建一個線程池。

我們可以想到 newCachedThreadPool 會在需要時創建必要多的線程，業務代碼的一次業務操作會向線程池提交多個慢任務，這樣執行一次業務操作就會開啟多個線程。 如果業務操作并發量較大的話，的確有可能一下子開啟幾千個線程。

那，為什么我們能在監控中看到線程數量會下降，而不會撐爆內存呢？

回到 newCachedThreadPool 的定義就會發現，它的核心線程數是 0，而 keepAliveTime 是 60 秒，也就是在 60 秒之后所有的線程都是可以回收的。 好吧，就因為這個特性，我們的業務程序死得沒太難看。

要修復這個 Bug 也很簡單，使用一個靜態字段來存放線程池的引用，返回線程池的代碼直接返回這個靜態字段即可。 這里一定要記得我們的最佳實踐，手動創建線程池。 修復后的 ThreadPoolHelper 類如下：

線程池的意義在于復用，那這是不是意味著程序應該始終使用一個線程池呢？要根據任務的“輕重緩急”來指定線程池的核心參數，包括線程數、回收策略和任務隊列：對于執行比較慢、數量不大的 IO 任務，或許要考慮更多的線程數，而不需要太大的隊列。 而對于吞吐量較大的計算型任務，線程數量不宜過多，可以是 CPU 核數或核數2倍（理由是，線程一定調度到某個 CPU 進行執行，如果任務本身是 CPU 綁定的任務，那么過多的線程只會增加線程切換的開銷，并不能提升吞吐量），但可能需要較長的隊列來做緩沖。

業務代碼使用了線程池異步處理一些內存中的數據，但通過監控發現處理得非常慢，整個處理過程都是內存中的計算不涉及 IO 操作，也需要數秒的處理時間，應用程序 CPU 占用也不是特別高，有點不可思議。

經排查發現，業務代碼使用的線程池，還被一個后臺的文件批處理任務用到了?；蛟S是夠用就好的原則，這個線程池只有 2 個核心線程，最大線程也是 2，使用了容量為 100 的 ArrayBlockingQueue 作為工作隊列，使用了 CallerRunsPolicy 拒絕策略：

這里模擬一下文件批處理的代碼，在程序啟動后通過一個線程開啟死循環邏輯，不斷向線程池提交任務，任務的邏輯是向一個文件中寫入大量的數據：

可以想象到，這個線程池中的 2 個線程任務是相當重的。通過 printStats 方法打印出的日志，我們觀察下線程池的負擔：

可以看到，線程池的 2 個線程始終處于活躍狀態，隊列也基本處于打滿狀態。 因為開啟了 CallerRunsPolicy 拒絕處理策略，所以當線程滿載隊列也滿的情況下，任務會在提交任務的線程，或者說調用 execute 方法的線程執行，也就是說不能認為提交到線程池的任務就一定是異步處理的。 如果使用了 CallerRunsPolicy 策略，那么有可能異步任務變為同步執行。 從日志的第四行也可以看到這點。 這也是這個拒絕策略比較特別的原因。

不知道寫代碼的同學為什么設置這個策略，或許是測試時發現線程池因為任務處理不過來出現了異常，而又不希望線程池丟棄任務，所以最終選擇了這樣的拒絕策略。 不管怎樣，這些日志足以說明線程池是飽和狀態。

可以想象到，業務代碼復用這樣的線程池來做內存計算，命運一定是悲慘的。我們寫一段代碼測試下，向線程池提交一個簡單的任務，這個任務只是休眠 10 毫秒沒有其他邏輯：

我們使用 wrk 工具對這個接口進行一個簡單的壓測，可以看到 TPS 為 75，性能的確非常差。

細想一下，問題其實沒有這么簡單。 因為原來執行 IO 任務的線程池使用的是 CallerRunsPolicy 策略，所以直接使用這個線程池進行異步計算的話，當線程池飽和的時候，計算任務會在執行 Web 請求的 Tomcat 線程執行，這時就會進一步影響到其他同步處理的線程，甚至造成整個應用程序崩潰。

解決方案很簡單，使用獨立的線程池來做這樣的“計算任務”即可。計算任務打

Netty網絡編程框架的核心概念以及入門案例

本文詳細介紹了Netty網絡編程框架的核心概念以及入門案例。

基于事件驅動的JavaNIO網絡通信框架，可以快速簡單地開發網絡應用程序。

極大地簡化并優化了TCP和UDP套接字服務器等網絡編程，并且性能以及安全性等很多方面甚至都要更好。

支持多種通信協議如FTP，SMTP，HTTP以及各種二進制和基于文本的傳統協議，同樣支持自定義協議。

簡單的說，Netty有三個優點：

高并發：基于NIO開發（Reactor模型），并發性能相比BIO得到了很大提高。

傳輸快：傳輸依賴于零拷貝特性，盡量減少不必要的內存拷貝，使用高性能序列化協議protobuf，實現了高效傳輸。

封裝好：封裝了原始NIO編程的很多細節，提供了易于使用調用接口，使用更簡單。

借用官方的描述：Netty成功地找到了一種在不妥協可維護性和性能的情況下實現易于開發，性能，穩定性和靈活性的方法。

Netty的社區目前非?；钴S。 很多涉及到網絡調用的開源項目和框架底層都用到了Netty，比如我們常用的Dubbo、RocketMQ、Elasticsearch、gRPC、Spark、GateWay等等。

總之，涉及到網絡編程開發時，比如即時通訊系統、自定義RPC框架、自定義HTTP服務器、實時消息推送系統等場景下，用Netty，準沒錯。

通道，Netty網絡操作抽象類，包括基本的I/O操作，如bind、connect、read、write等，Netty的Channel接口所提供的API，大大地降低了直接使用Socket類的復雜性。

不同協議、不同的阻塞類型的連接都有不同的Channel類型與之對應，下面是一些常用的Channel類型：

NioSocketChannel，異步的客戶端TCPSocket連接。

NioServerSocketChannel，異步的服務器端TCPSocket連接。

NioDatagramChannel，異步的UDP連接。

NioSctpChannel，異步的客戶端Sctp連接。

NioSctpServerChannel，異步的Sctp服務器端連接這些通道涵蓋了UDP和TCP網絡IO以及文件IO。

EventLoop（事件循環）接口是Netty的核心接口，用于處理連接的生命周期中所發生的各種事件，實際上就是負責監聽網絡事件并調用事件處理器進行相關I/O操作的處理。

EventLoop內部持有NIO中的Selector，Channel將會注冊到EventLoop中，一個EventLoop可以監聽多個Channel，EventLoop是實現IO多路復用的核心，可以看作是Reactor模型中的mainReactor。

Channel為Netty網絡操作抽象類，EventLoop負責監聽注冊到其上的Channel的IO事件，兩者配合完成I/O操作。

在Netty中所有的IO操作都是異步的，不能立刻得知消息是否被正確處理。

Channel會注冊到EventLoop中后會立即返回一個ChannelFuture對象，可以通過ChannelFuture#addListener注冊GenericFutureListener監聽器，當操作執行成功或失敗時監聽會自動觸發注冊的監聽事件。

ChannelHandler是消息的具體處理器。 他負責處理各種任務，這個任務非常廣泛，可以是讀寫事件、連接、解碼編碼、數據轉換、業務邏輯等等，處理完畢之后將數據繼續轉發到ChannelPipeline中的下一個ChannelHandler。

通過定制ChannelHandler可對Netty進行擴展。ChannelHandler接口本身并沒有提供很多方法，因為這個接口有許多的方法需要實現，為了方便使用，可以繼承它的子類：

ChannelInboundHandler用于處理入站I/O事件

ChannelOutboundHandler用于處理出站I/O操作

或者使用以下適配器類，更加方便：

ChannelInboundHandlerAdapter用于處理入站I/O事件

ChannelOutboundHandlerAdapter用于處理出站I/O操作

ChannelDuplexHandler用于處理入站和出站事件

ChannelPipeline是一個ChannelHandler的鏈表，即ChannelHandler組成的List，提供了一個沿著鏈傳播入站和出站事件流的API。

可以在ChannelPipeline上通過addLast()方法添加一個或者多個ChannelHandler，因為一個數據或者事件可能會被多個Handler處理。 當一個ChannelHandler處理完之后就將數據交給下一個ChannelHandler。

在執行時，入站事件會從鏈表head往后傳遞到最后一個入站的handler（ChannelInboundHandler類型），出站事件會從鏈表tail往前傳遞到最前一個出站的handler（ChannelOutboundHandler類型），兩種類型的handler在執行時互不干擾。 如果Handler同時屬于入站、出站Handler，則都會執行一次。

JBoss和Tomcat部署方式的區別

在Web2.0的浪潮中，各種頁面技術和框架不斷涌現，為服務器端的基礎架構提出了更高的穩定性和可擴展性的要求。 近年來，作為開源中間件的全球領導者，JBoss在J2EE應用服務器領域已成為發展最為迅速的應用服務器。 在市場占有率和服務滿意度上取得了巨大的成功，絲毫不遜色于其它的非開源競爭對手，如WebSphere、WebLogic、Application Server。 JBoss Web的諸多優越性能，正是其廣為流行的原因。 基于Tomcat內核，青勝于藍Tomcat 服務器是一個免費的開放源代碼的Web 應用服務器，技術先進、性能穩定，而且免費，因而深受Java 愛好者的喜愛并得到了部分軟件開發商的認可。 其運行時占用的系統資源小，擴展性好，且支持負載平衡與郵件服務等開發應用系統常用的功能。 作為一個小型的輕量級應用服務器，Tomcat在中小型系統和并發訪問用戶不是很多的場合下被普遍使用，成為目前比較流行的Web 應用服務器。 而JBoss Web采用業界最優的開源Java Web引擎， 將Java社區中下載量最大，用戶數最多，標準支持最完備的Tomcat內核作為其Servlet容器引擎，并加以審核和調優。 單純的Tomcat性能有限，在很多地方表現有欠缺，如活動連接支持、靜態內容、大文件和HTTPS等。 除了性能問題，Tomcat的另一大缺點是它是一個受限的集成平臺，僅能運行Java應用程序。 企業在使用時Tomcat，往往還需同時部署Apache Web Server以與之整合。 此配置較為繁瑣，且不能保證性能的優越性。 JBoss在Tomcat的基礎上，對其進行本地化，將Tomcat 以內嵌的方式集成到 JBoss 中。 JBoss Web通過使用APR和Tomcat本地技術的混合模型來解決Tomcat的諸多不足。 混合技術模型從最新的操作系統技術里提供了最好的線程和事件處理。 結果，JBoss Web達到了可擴展性，性能參數匹配甚至超越了本地Apache HTTP服務器或者IIS。 譬如JBoss Web能夠提供數據庫連接池服務，不僅支持 JSP 等 Java 技術，同時還支持其他 Web 技術的集成，譬如 PHP、 兩大陣營。 標準化是減小技術依賴風險，保護投資最好的方式。 JBoss Web率先支持全系列JEE Web標準，從根本上保證了應用“一次開發，到處運行”的特點，使應用成品能方便地在JBoss Web和其他Java Web服務器之間輕易遷移。 集多功能于一身，性能卓越作為Web 應用服務器中的明星產品，JBoss Web服務器集多種功能于一身。 其關鍵功能包括：完全支持Java EE、高度的擴展性、快速的靜態內容處理、群集、OpenSSL、URL重寫和綜合性。 JBoss Web服務器具有原生特性和強大的可擴展性，可支持多種并非基于Java的服務器內容處理技術，可同時運行JSP, Servlet, Microsoft , PHP 及 CGI，為其提供一個單一的、高性能的企業級部署平臺。 與Tomcat 相比，JBoss Web在靜態資源訪問方面性能優越。 JBoss Web支持兩種組件模式——純Java和Native I/O。 在Native組件的支持下，動態運行不會受到任何影響，而靜態資源的訪問利用了操作系統本身提供的0拷貝傳送，CPU消耗降低，響應時間縮短，吞吐率大大提高，混合的連接模式支持最大達到個并發客戶端的同時訪問，與Apache Web服務器相當。 部署于高性能的操作系統，可利用JBoss Web對純Java和Native I/O兩種模式的支持，使得應用在開發時可隨時跨平臺敏捷遷移，而部署于高性能的操作系統相關的Native環境。 由于JBoss Web較好地解決了靜態資源的訪問性能問題，可在解決方案中把它直接作為強大的LVS的分發對象，和RHEL負載均衡系統結合，形成理論上無限線性擴展的負載均衡場景。 OpenSSL是業界最為快速和安全的開源傳輸組件，可借助操作系統和硬件的特性實現高效的安全承載。 JBoss Web集成了OpenSSL，可提供高效的安全傳輸服務，使得安全機制更上臺階。 研究表明， JBoss Web中的SSL性能比單純的Tomcat快四倍。 URL重寫功能可縮短URL，隱藏實際路徑提高安全性，易于用戶記憶和鍵入，及被搜索引擎收錄。 Tomcat 不具備URL重寫功能，JBoss Web則可提供一個靈活的URL rewriting操作引擎，支持無限個規則數和規則條件。 URL可被重寫以支持遺留的URL錯誤處理，或應對服務器不時產生的其他問題。 JBoss Web既可單獨運行，也可無縫嵌入JBoss應用服務器，成為JBoss中間件平臺的一部分。 不僅后臺服務調用的性能將得以提升，也可利用以下JBoss平臺的特性提升Web應用功能：基于JGroups的多種集群方案的支持基于Arjuna技術的JTA和JTS的事務處理支持優化的線程池和連接池的支持基于JMX 控制臺的基本管理支持和JBoss On的高級管理維護支持基于JBoss AOP技術的面向方面架構的支持Hibernate服務組件的支持專業團隊支持業界大多數開源產品在技術方面富于創新性，但在可持續性，產品生命周期規劃，以及質量保證方面缺乏有效保障，為軟件集成商和最終用戶所詬病。 紅帽所力行的“專業化開源技術”則完美解決了這一問題。 來自開源社區的JBoss Web，在紅帽專業化開源的錘煉下，在性能、擴展性、穩定性、安全性等方面，已成為一個達到企業級，甚至電信級標準的優秀產品。 紅帽不僅有專職的技術團隊投入JBoss Web的開發，而且具備專門的QA團隊為產品作質量保證。 完善的集成測試和兼容性測試保證了JBoss Web自身的穩定性，并保證了它的后向兼容和其他JBoss產品協作良好的互操作性。 在服務體系保障方面，JBoss 開拓了以產品專家提供的專家級支持服務作為開源軟件強大后盾的軟件生態模式。 公司以及龐大的 JBoss 授權服務合作伙伴網絡可為包括JBoss Web在內的整個JEMS 產品套件提供全面的支持服務。 與Tomcat相比，JBoss Web 可提供遷移服務與現場專家服務，在遷移服務方面，專家指導應用可從Tomcat向JBoss Web遷移，省時省力。 獨特的服務訂閱模式，全力保障軟件生命周期，讓企業高枕無憂。

業務常見error示例——并發工具類庫導致的線程安全問題

通常提到線程安全問題等就有可能聽到關線程安全和并發工具的一些片面的觀點和結論。 比如“把 HashMap 改為 ConcurrentHashMap，就可以解決并發問題了呀”“要不我們試試無鎖的 CopyOnWriteArrayList 吧，性能更好”。 的確，為了方便開發者進行多線程編程，現代編程語言會提供各種并發工具類。 但如果我們沒有充分了解它們的使用場景、解決的問題，以及最佳實踐的話，盲目使用就可能會導致一些坑，小則損失性能，大則無法確保多線程情況下業務邏輯正確性。

之前有業務同學和我反饋，在生產上遇到一個詭異的問題，有時獲取到的用戶信息是別人的。 查看代碼后，我發現他使用了ThreadLocal 來緩存獲取到的用戶信息。 我們知道，ThreadLocal 適用于變量在線程間隔離，而在方法或類間共享的場景。 如果用戶信息的獲取比較昂貴（比如從數據庫查詢用戶信息），那么在 ThreadLocal 中緩存數據是比較合適的做法。 但，這么做為什么會出現用戶信息錯亂的 Bug 呢？

使用 Spring Boot 創建一個 Web 應用程序，使用 ThreadLocal 存放一個 Integer 的值，來暫且代表需要在線程中保存的用戶信息，這個值初始是 null。 在業務邏輯中，我先從 ThreadLocal 獲取一次值，然后把外部傳入的參數設置到 ThreadLocal 中，來模擬從當前上下文獲取到用戶信息的邏輯，隨后再獲取一次值，最后輸出兩次獲得的值和線程名稱。