秒懂：tomcat的maxConnections、maxThreads、acceptCount 圖解

後面附圖 | 秒懂

瘋狂創客圈 Java 高併發【 億級流量聊天室實戰】實戰系列 【博客園總入口 】

---

前言

瘋狂創客圈（筆者尼恩建立的高併發研習社羣）Springcloud 高併發系列文章，將爲你們介紹三個版本的 高併發秒殺：

1、版本1 ：springcloud + zookeeper 秒殺

2、版本2 ：springcloud + redis 分佈式鎖秒殺

3、版本3 ：springcloud + Nginx + Lua 高性能版本秒殺

以及有關Springcloud 幾篇核心、重要的文章：

1、Springcloud 配置， 史上最全 一文全懂

2、Springcloud 中 SpringBoot 配置全集 ， 收藏版

3、Feign Ribbon Hystrix 三者關係 ， 史上最全 深度解析

4、SpringCloud gateway 詳解 ， 史上最全

5、圖解：tomcat的maxConnections、maxThreads、acceptCount | 秒懂

本文，是《tomcat的maxConnections、maxThreads、acceptCount》篇，爲你們解讀tomcat的maxConnections、maxThreads、acceptCount，你們能夠藏好，必定有用的到時候。

怎麼配置tomcat，才能使得本身的服務效率更高呢？

首先，這和tomcat的使用的IO模式有關

關於Java IO模式、以及IO處理的線程模型等基礎的通訊框架的知識，是Java程序員的重要、必備的內功，具體請參見尼恩編著的《Netty、Zookeeper、Redis高併發實戰》一書，這裏不作過多的贅述。
其次，也和tomcat的配置參數有關

尤爲是如下三個配置項：maxConnections、maxThreads、acceptCount。

1.4.1 Tomcat的高效配置

Tomcat的maxConnections、maxThreads、acceptCount三大配置，分別表示最大鏈接數，最大線程數、最大的等待數，能夠經過application.yml配置文件來改變這個三個值，一個標準的示例以下：

server:
  tomcat:
    uri-encoding: UTF-8
    #最大工做線程數，默認200, 4核8g內存，線程數經驗值800
    #操做系統作線程之間的切換調度是有系統開銷的，因此不是越多越好。
    max-threads: 1000
    # 等待隊列長度，默認100
   accept-count: 1000
    max-connections: 20000
    # 最小工做空閒線程數，默認10, 適當增大一些，以便應對忽然增加的訪問量
   min-spare-threads: 100

1.4.2 詳解：maxConnections、maxThreads、acceptCount

tomcat中maxConnections、maxThreads、acceptCount的具體含義是什麼呢？參考官方文檔，對三者的含義說明以下：

1、accept-count：最大等待數

官方文檔的說明爲：當全部的請求處理線程都在使用時，所能接收的鏈接請求的隊列的最大長度。當隊列已滿時，任何的鏈接請求都將被拒絕。accept-count的默認值爲100。
詳細的來講：當調用HTTP請求數達到tomcat的最大線程數時，還有新的HTTP請求到來，這時tomcat會將該請求放在等待隊列中，這個acceptCount就是指可以接受的最大等待數，默認100。若是等待隊列也被放滿了，這個時候再來新的請求就會被tomcat拒絕（connection refused）。

2、maxThreads：最大線程數

每一次HTTP請求到達Web服務，tomcat都會建立一個線程來處理該請求，那麼最大線程數決定了Web服務容器能夠同時處理多少個請求。maxThreads默認200，確定建議增長。可是，增長線程是有成本的，更多的線程，不只僅會帶來更多的線程上下文切換成本，並且意味着帶來更多的內存消耗。JVM中默認狀況下在建立新線程時會分配大小爲1M的線程棧，因此，更多的線程異味着須要更多的內存。線程數的經驗值爲：1核2g內存爲200，線程數經驗值200；4核8g內存，線程數經驗值800。

3、maxConnections：最大鏈接數

官方文檔的說明爲：

這個參數是指在同一時間，tomcat可以接受的最大鏈接數。對於Java的阻塞式BIO，默認值是maxthreads的值；若是在BIO模式使用定製的Executor執行器，默認值將是執行器中maxthreads的值。對於Java 新的NIO模式，maxConnections 默認值是10000。
對於windows上APR/native IO模式，maxConnections默認值爲8192，這是出於性能緣由，若是配置的值不是1024的倍數，maxConnections 的實際值將減小到1024的最大倍數。
若是設置爲-1，則禁用maxconnections功能，表示不限制tomcat容器的鏈接數。
maxConnections和accept-count的關係爲：當鏈接數達到最大值maxConnections後，系統會繼續接收鏈接，但不會超過acceptCount的值。

1.4.3 圖解：maxConnections、maxThreads、acceptCount關係

用一個形象的比喻，通俗易懂的解釋一下tomcat的最大線程數（maxThreads）、最大等待數（acceptCount）和最大鏈接數（maxConnections）三者之間的關係。

咱們能夠把tomcat比作一個火鍋店，流程是取號、入座、叫服務員，能夠作一下三個形象的類比：
（1）acceptCount 最大等待數
能夠類比爲火鍋店的排號處可以容納排號的最大數量；排號的數量不是無限制的，火鍋店的排號到了必定數據量以後，服務每每會說：已經客滿。
（2）maxConnections 最大鏈接數
能夠類比爲火鍋店的大堂的餐桌數量，也就是能夠就餐的桌數。若是全部的桌子都已經坐滿，則表示餐廳已滿，已經達到了服務的數量上線，不能再有顧客進入餐廳了。
（3）maxThreads：最大線程數
能夠類比爲廚師的個數。每個廚師，在同一時刻，只能給一張餐桌炒菜，就像極了JVM中的一條線程。

整個就餐的流程，大體以下：

（1）取號：若是maxConnections鏈接數沒有滿，就不須要取號，由於還有空餘的餐桌，直接被大堂服務員領上餐桌，點菜就餐便可。若是 maxConnections 鏈接數滿了，可是取號人數沒有達到 acceptCount，則取號成功。若是取號人數已達到acceptCount，則拿號失敗，會獲得Tomcat的Connection refused connect 的回覆信息。
（2）上桌：若是有餐桌空出來了，表示maxConnections鏈接數沒有滿，排隊的人，能夠進入大堂上桌就餐。
（3）就餐：就餐須要廚師炒菜。廚師的數量，比顧客的數量，確定會少一些。一個廚師必定須要給多張餐桌炒菜，若是就餐的人越多，廚師也會忙不過來。這時候就能夠增長廚師，一增長到上限maxThreads的值，若是仍是不夠，只能是拖慢每一張餐桌的上菜速度，這種狀況，就是你們常見的「上一道菜吃光了，下一道菜尚未上」尷尬場景。

maxConnections、maxThreads、acceptCount關係圖以下

最後，介紹一下瘋狂創客圈：瘋狂創客圈，一個Java 高併發研習社羣 【博客園 總入口 】

瘋狂創客圈，傾力推出：面試必備 + 面試必備 + 面試必備 的基礎原理+實戰 書籍 《Netty Zookeeper Redis 高併發實戰》

---

瘋狂創客圈 Java 死磕系列

• Java (Netty) 聊天程序【 億級流量】實戰 開源項目實戰

• Netty 源碼、原理、JAVA NIO 原理
• Java 面試題 一網打盡

• 瘋狂創客圈 【 博客園 總入口 】