Tomcat 這玩意兒做 Java Web 的基本繞不開?？涩F實里最常見的場景是本地跑得好好的一上服務器就報Address already in useIDEA 里點啟動控制臺刷出一屏紅字最后一行寫著could not obtain connection to query metadata項目部署上去訪問是 404日志里連個像樣的提示都沒有。多數人這時候的做法是百度關鍵詞找到一條差不多的答案復制粘貼重啟好了——但下次換個環(huán)境又炸因為壓根不知道這個報錯是從哪一層冒出來的。我這篇文章想干兩件事。第一件把 Tomcat 常見的報錯按出問題的層次重新梳理一遍從啟動腳本、端口、類加載、連接池一路到 SSL 配置講清楚每種報錯背后到底發(fā)生了什么為什么這么解。第二件也是我覺得更有意思的——手動寫一個能跑起來的迷你 Tomcat用ServerSocket加線程池自己解析 HTTP 報文、自己映射 Servlet、自己加載WEB-INF下的類。寫完之后你再回頭看那些報錯會發(fā)現它們的位置感一下子就清晰了ClassNotFoundException 是類加載層的事404 是映射層的事端口沖突是網絡層的事各歸各位。這篇內容適合誰看正在被 Tomcat 報錯折磨的運維和后端同學、想搞明白 Web 容器內部到底怎么回事的初中級開發(fā)者、以及準備給現有項目做容器替換或者調優(yōu)的人。代碼部分我會給完整可運行的版本但更重要的是每一步為什么這么設計——這才是我自己踩坑之后真正記住的東西。1. 先想清楚Tomcat 到底替我們接管了哪些活1.1 一個請求進來經過了幾道手很多人對 Tomcat 的認知停留在放 war 包的地方。但你只要自己寫過一次最原始的 Socket 服務就會立刻明白它省掉了多少事。一個 HTTP 請求從瀏覽器發(fā)出到你的doGet方法被執(zhí)行中間至少經歷了這些環(huán)節(jié)內核把 TCP 連接交給監(jiān)聽端口的進程Tomcat 的 Acceptor 線程接住這個連接交給 Worker 線程Worker 從 socket 上讀字節(jié)流按 HTTP 協議切分出請求行、請求頭、請求體根據請求行里的 URI找到對應的 Host、Context也就是你的應用、Wrapper也就是那個具體的 Servlet構造HttpServletRequest和HttpServletResponse兩個包裝對象調用Servlet.service()最后把響應對象里的狀態(tài)行、響應頭、響應體按協議格式寫回 socket 并關閉連接。這里面每一環(huán)都可能出錯而且報錯信息分布在完全不同的地方。端口被占用是內核層直接就拒絕了URI 找不到對應 Context 是映射層的問題Servlet 類加載不出來是類加載器的問題。你把這條鏈路在腦子里畫出來排查速度至少快一倍。1.2 為什么手寫一遍是最快的理解方式我在帶新人的時候有個固定動作讓對方用ServerSocket寫一個只返回 hello 的服務。寫完之后再問一句如果我要支持兩個不同的路徑返回不同內容呢他就自然開始想路由表再問如果我要讓用戶自己寫類來處理請求呢他就自然想到接口和反射再問如果用戶把類打包成 jar 放在某個目錄下呢他就自然碰到類加載器。這就是手寫迷你 Tomcat 的價值——它把你平時當成黑盒的那一層拆成了幾個你能一手寫完的小模塊。而且這個過程不白費功夫Tomcat 本身的架構也是這么分層的Server→Service→ConnectorEngine→Host→Context→Wrapper。你手寫的版本就是它的一根簡化骨架。1.3 報錯分類的底層邏輯我把常見報錯歸成五大類后面第 5 章會逐條展開報錯層次典型現象排查入口啟動腳本 / 環(huán)境雙擊閃退、JAVA_HOME not foundcatalina.bat、setclasspath.bat輸出網絡 / 端口Address already in usenetstat、lsof、ps -ef部署 / 映射404、歡迎頁不對、應用未加載logs/catalina.out、conf/server.xml類加載 / 依賴ClassNotFoundException、NoClassDefFoundErrorWEB-INF/lib、WEB-INF/classes資源 / 配置連接池拿不到連接、SSL 握手失敗、亂碼數據源配置、keystore、Connector編碼這張表你貼在工位上遇到紅字先定位它在哪一行比漫無目的地搜關鍵詞高效得多。2. 手動實現迷你 Tomcat 的整體設計2.1 拆成三層網絡層、協議層、容器層我在設計這個迷你容器的時候刻意做了嚴格分層因為分層本身就是為了讓報錯有歸屬。網絡層只干一件事綁定端口accept()阻塞等待連接把Socket丟給線程池。它完全不懂 HTTP也不懂你的業(yè)務。協議層負責把InputStream里的字節(jié)翻譯成結構化的請求對象再把結構化的響應對象序列化回字節(jié)。容器層則負責路由、Servlet 生命周期、類加載。為什么非要這么分因為分完之后你要換實現的時候成本極低。比如網絡層從 BIO 換成 NIO容器層一行都不用改協議層要支持 HTTP/1.1 的chunked傳輸也只需要改動解析和寫出這兩個方法。Tomcat 的Connector和Container分離就是這個道理只不過它做得更極致。2.2 網絡模型為什么從 BIO 起步有人會說都什么年代了還寫 BIO。但對一個用來理解原理的迷你實現BIO 加線程池是最優(yōu)解原因有三點。第一代碼路徑清晰。一個請求一個線程你打斷點的時候能完整看到從accept到service的調用棧不會在 Selector 的事件循環(huán)里迷失。第二它足夠支撐中等規(guī)模場景。Tomcat 直到 8.5 才默認啟用 NIO此前長期使用的 APR 和 BIO 組合在生產環(huán)境跑了十幾年說明 BIO 加合理線程池并不是不能用。第三也是關鍵的一點——它讓你直觀感受到maxThreads這個參數到底限制的是什么。當你看到線程池滿了之后新連接全部堵在accept隊列里你就永遠不會再隨便把maxThreads調到 5000。提示迷你實現用 BIO 是為了理解生產上 Tomcat 8.5 以后默認就是 NIO 模式IO 多路復用在連接數上萬時優(yōu)勢明顯這一點不要混淆。2.3 目錄結構與職責劃分我最終落地的結構是這樣的mini-tomcat/ ├── src/main/java/com/example/mt/ │ ├── MiniTomcat.java // 啟動入口網絡層 │ ├── http/ │ │ ├── MiniRequest.java // 請求對象協議層 │ │ ├── MiniResponse.java // 響應對象協議層 │ │ └── HttpParser.java // 報文解析 │ ├── container/ │ │ ├── MiniServlet.java // Servlet 接口 │ │ ├── ServletMapping.java // 路由表 │ │ └── WebXmlParser.java // 配置解析 │ └── loader/ │ └── WebappClassLoader.java └── webapps/ └── demo/ ├── WEB-INF/web.xml ├── WEB-INF/classes/ └── index.html每個包的邊界和前面說的三層嚴格對應。MiniTomcat里的代碼不會出現Servlet字樣container包里的代碼不會出現Socket字樣。這個約束看起來很教條但你寫下去就會發(fā)現它逼著你在正確的層次上解決問題。比如 URL 解碼把%E4%B8%AD還原成中文它天然屬于協議層就該放在HttpParser里而不是散落在路由查找的代碼中。3. 核心細節(jié)拆解報文解析、路由映射與類加載3.1 HTTP 請求解析里最容易踩的三個坑第一個坑BufferedReader和請求體的沖突。新手最常見的寫法是new BufferedReader(new InputStreamReader(socket.getInputStream()))然后readLine()讀第一行得到請求行。這在純 GET 請求下沒問題因為 GET 沒有請求體。但一旦是 POST你再用同一個 reader 去讀 body就會讀到空——因為BufferedReader內部做了緩沖已經把一部分 body 吃進它自己的緩沖區(qū)了而你從InputStream直接再讀讀到的是緩沖區(qū)之后的內容。正確做法是解析完請求頭和請求行之后根據Content-Length頭從原始的InputStream上精確讀取對應字節(jié)數。這也是為什么 Tomcat 內部對ServletInputStream有嚴格的狀態(tài)機管理——一旦你調用了getReader()再調getInputStream()就會拋IllegalStateException。它就是在防這種讀串了的情況。第二個坑請求頭的行結束符。HTTP 協議規(guī)定是\r\n但有些客戶端或者手寫的測試工具會只發(fā)\n。readLine()恰好能容忍這兩種所以手工解析時用它反而安全。但如果你自己用read()逐字節(jié)找\r\n就得考慮兼容。第三個坑URI 的編碼。請求行里的 URI 是經過百分號編碼的中文參數、空格、特殊符號都會變成%XX形式。加上號在表單提交里代表空格這兩套規(guī)則混在一起很容易解析錯。我的處理順序是先按?切出 path 和 query再對 query 按切分、按切分最后對 key 和 value 分別做URLDecoder.decode(value, UTF-8)。注意URLDecoder會把也解成空格這在 query 場景下是符合規(guī)范的。3.2 響應格式與狀態(tài)碼的封裝響應寫出去的時候最容易忽略的是頭部順序和Content-Length。HTTP 響應格式是HTTP/1.1 200 OK\r\n Content-Type: text/html;charsetUTF-8\r\n Content-Length: 128\r\n \r\n body我見過有人把Content-Length算錯結果是瀏覽器一直轉圈等數據直到超時。原因通常是用了Writer寫字符但在計算長度的時候算的是字符數而實際發(fā)出的是字節(jié)數。中文一個字符 UTF-8 下占三個字節(jié)這個差值會讓Content-Length偏小瀏覽器收到少于聲明長度的數據就會一直等。所以在迷你實現里我統(tǒng)一用ByteArrayOutputStream先在內存里把響應體字節(jié)攢好拿到真實的字節(jié)長度之后再寫Content-Length最后一次性刷出去。這個先攢后發(fā)的思路和 Tomcat 里OutputBuffer的設計是一致的。3.3 路由映射從 URI 到 Servlet 實例路由的本質是一個查找表。我在實現時用了最簡單的方式MapString, MiniServletkey 是url-patternvalue 是單例的 Servlet 實例。這是為了簡化真實 Tomcat 里每個請求都會拿一個StandardWrapper它管理著 Servlet 實例的單例和生命周期。匹配規(guī)則上我先實現了精確匹配然后補了兩條匹配類型寫法例子精確匹配/user/list請求路徑完全相同才命中前綴匹配/user/*以/user/開頭都命中擴展名匹配*.do以.do結尾都命中默認匹配/兜底通常指向靜態(tài)資源處理優(yōu)先級是精確 前綴 擴展名 默認這一點必須和 Servlet 規(guī)范保持一致否則同一個項目從真正 Tomcat 遷移到你的迷你容器上行為就不一樣了。順便說一句這個優(yōu)先級順序是很多人配置DispatcherServlet時踩坑的來源——/*會覆蓋掉*.jsp的映射導致 JSP 直接變成下載文件。3.4 類加載器隔離Tomcat 最容易被誤解的一層WEB-INF/classes和WEB-INF/lib/*.jar是應用私有的父加載器看不到它們這就是所謂的類加載隔離。為什么要隔離因為同一個 Tomcat 上可能跑十個應用它們依賴的spring-core版本可能完全不同。如果不隔離第一個加載的版本就會覆蓋后面所有的應用。Tomcat 的類加載順序和標準雙親委派是反的它先嘗試用WebappClassLoader自己加載加載不到才交給父加載器。這個打破雙親委派的行為正是很多ClassNotFoundException和LinkageError的根源。我在迷你實現里用URLClassLoader簡化了這件事public class WebappClassLoader extends URLClassLoader { public WebappClassLoader(File webappDir, ClassLoader parent) throws Exception { super(buildUrls(webappDir), parent); } private static URL[] buildUrls(File webappDir) throws Exception { ListURL urls new ArrayList(); File classes new File(webappDir, WEB-INF/classes); if (classes.exists()) { urls.add(classes.toURI().toURL()); } File lib new File(webappDir, WEB-INF/lib); File[] jars lib.listFiles((d, n) - n.endsWith(.jar)); if (jars ! null) { for (File jar : jars) { urls.add(jar.toURI().toURL()); } } return urls.toArray(new URL[0]); } }有了它你在 Servlet 里寫Class.forName(com.example.MyService)就能找到應用私有的類而不會跑到系統(tǒng)的 classpath 里去找。理解了這幾十行代碼你再看 Tomcat 那些NoClassDefFoundError思路會清楚很多要么是 jar 沒進WEB-INF/lib要么是同一個類被兩個加載器加載了導致類型轉換失敗。4. 完整實操寫一個能跑靜態(tài)資源和 Servlet 的迷你容器4.1 環(huán)境準備與工程搭建我用的是 JDK 17 加 Maven 的極簡配置。為什么選 17 而不是 8因為URLClassLoader在 9 以后的模塊化環(huán)境下有一些限制但用于加載普通 jar 依然沒問題而且 17 的Socket和字符串處理 API 更順手。如果你所在的項目必須用 JDK 8代碼也能原樣跑只是readAllBytes這類方法要換成循環(huán)讀取。pom.xml里只有一個 JUnit其余全靠 JDK 自帶。這一點很重要——我刻意不引第三方 HTTP 庫就是為了讓你看清協議本身的處理過程。用 Netty 或者 Undertow 能更快跑起來但那就失去意義了。4.2 啟動類網絡層的核心二十行public class MiniTomcat { private final int port; private final ExecutorService pool Executors.newFixedThreadPool(50); private final ServletMapping mapping new ServletMapping(); public MiniTomcat(int port) { this.port port; } public void start() throws Exception { mapping.load(new File(webapps/demo)); try (ServerSocket server new ServerSocket(port)) { System.out.println(MiniTomcat started on port port); while (true) { Socket socket server.accept(); pool.execute(() - handle(socket)); } } } private void handle(Socket socket) { try (socket; InputStream in socket.getInputStream(); OutputStream out socket.getOutputStream()) { MiniRequest req HttpParser.parse(in); MiniResponse resp new MiniResponse(out); if (req null) { return; } if (!mapping.dispatch(req, resp)) { StaticResourceHandler.handle(req, resp); } resp.flush(); } catch (Exception e) { e.printStackTrace(); } } }這里有個細節(jié)值得說try (socket; in; out)這種寫法會在代碼塊結束時自動關閉所有資源。很多人手寫 HTTP 服務時忘了關 Socket跑壓測的時候幾百個連接瞬間把文件句柄耗盡報Too many open files。生產上的 Tomcat 有連接池和空閑回收手寫版本就必須靠try-with-resources兜底。線程池固定 50 個線程也是一種取舍。真實場景應該做成可配置并且要意識到accept到線程池之后如果池子滿了任務會進無界隊列連接會一直堆著不處理。生產上更穩(wěn)妥的做法是給隊列設個上限滿了就快速返回 503這也是 Tomcat 的acceptCount在干的事。4.3 請求與響應對象的實現要點public class MiniRequest { private String method; private String uri; private String path; private String protocol; private final MapString, String headers new HashMap(); private final MapString, String params new HashMap(); private byte[] body; public String getParameter(String name) { return params.get(name); } public String getHeader(String name) { return headers.get(name.toLowerCase()); } public String getMethod() { return method; } public String getPath() { return path; } // 省略 setter }MiniResponse我給了它三個核心方法setStatus、setHeader、write。write把字節(jié)寫進內存緩沖flush負責拼裝成完整報文寫出去。這里再強調一遍前面提過的順序問題一定要在flush里現算Content-Length不要提前寫死。public void flush() throws IOException { byte[] data buffer.toByteArray(); StringBuilder head new StringBuilder(); head.append(HTTP/1.1 ).append(status).append(\r\n); if (!headers.containsKey(content-type)) { headers.put(Content-Type, text/html;charsetUTF-8); } headers.put(Content-Length, String.valueOf(data.length)); headers.forEach((k, v) - head.append(k).append(: ).append(v).append(\r\n)); head.append(\r\n); out.write(head.toString().getBytes(StandardCharsets.ISO_8859_1)); out.write(data); out.flush(); }注意響應頭我用ISO_8859_1編碼寫出去。這不是筆誤HTTP 頭部按規(guī)范只允許 ASCII 字符用ISO_8859_1保證每個字節(jié)原樣傳輸。如果用 UTF-8 編碼頭部遇到非 ASCII 字符會變成多字節(jié)客戶端解析頭部就會錯位。4.4 靜態(tài)資源處理與 404 兜底靜態(tài)資源處理的價值在于它讓整個容器看起來像個真東西你可以在webapps/demo下丟一個index.html瀏覽器訪問就能看到頁面。public class StaticResourceHandler { public static void handle(MiniRequest req, MiniResponse resp) throws IOException { String path req.getPath(); if (/.equals(path)) { path /index.html; } File file new File(webapps/demo, path); if (!file.exists() || file.isDirectory()) { resp.setStatus(404); resp.write(h1404 Not Found/h1.getBytes(StandardCharsets.UTF_8)); return; } String name file.getName().toLowerCase(); resp.setHeader(Content-Type, MimeTypes.of(name)); resp.write(Files.readAllBytes(file.toPath())); } }有一個安全問題必須在手寫版本里就養(yǎng)成習慣路徑穿越。如果用戶請求/../../etc/passwd直接拼接路徑就會讀到系統(tǒng)文件。真實 Tomcat 通過canonicalPath校驗來解決。我在迷你版里加了一句規(guī)范化檢查這對理解 Tomcat 的安全加固很有幫助。順便說 JSP。我最初也想在迷你版里跑 JSP但真正的 JSP 需要先編譯成 Servlet 再加載執(zhí)行工作量翻倍。我選擇的做法是把 JSP 的編譯產物手動放到WEB-INF/classes下當成普通 Servlet 來跑。這也順帶解釋了熱詞里那個操作——web 項目配置 tomcat 后查看 jsp 編譯后的 java 類你在 Tomcat 的work/Catalina/localhost/應用名/org/apache/jsp/目錄下就能看到這些中間產物。項目莫名其妙報 JSP 相關錯誤的時候去那個目錄看生成的 Java 文件比盯著 JSP 源碼猜快得多。4.5 啟動驗證與目錄約定把MiniTomcat跑起來控制臺輸出MiniTomcat started on port 8080然后瀏覽器訪問localhost:8080/index.html看到頁面訪問localhost:8080/hello看到 Servlet 返回的內容整個鏈路就通了。驗證順序我建議這樣走先靜態(tài)資源再精確匹配的 Servlet再帶參數的 POST最后中文參數。每一步都通過再往下走出問題的時候定位范圍就很小。我當初第一次寫的時候POST 中文參數一路亂碼最后發(fā)現是Content-Length用的是字符數而不是解碼后的字節(jié)數導致 body 讀少了一半UTF-8 多字節(jié)字符被截斷。這類問題在真正的 Tomcat 里之所以不常見就是因為它的OutputBuffer和編碼器已經處理好了這些邊界。5. Tomcat 常見報錯逐條排查實錄5.1 啟動類報錯端口、環(huán)境變量與腳本問題java.net.BindException: Address already in use是出現頻率最高的一條。它的意思非常字面端口已經被別的進程占了。Linux 下排查用lsof -i:8080或者netstat -tunlp | grep 8080Windows 下用netstat -ano | findstr 8080拿到 PID再去任務管理器或者taskkill /PID xxx /F處理。有時候你確認沒有 Java 進程占著那就要考慮是不是之前的 Tomcat 沒殺干凈用ps -ef | grep tomcat過一遍再用kill -9清理。還有一種隱蔽情況TIME_WAIT狀態(tài)的連接還在占用端口這時候要么等一會兒要么在Connector上配SO_REUSEADDR。Neither the JAVA_HOME nor the JRE_HOME environment variable is defined這條出現在 Windows 下雙擊startup.bat閃退的場景。原因是setclasspath.bat在啟動時找不到 JDK 路徑。解決方式是設好JAVA_HOME環(huán)境變量指向 JDK 根目錄而不是bin目錄。如果你機器上有多個 JDK想讓 Tomcat 用指定的那個比如 JDK 17 而系統(tǒng)默認是 8可以在setclasspath.bat開頭顯式加一行set JAVA_HOMED:\jdk-17這樣只影響這個 Tomcat 實例不動全局環(huán)境變量多個 Tomcat 并存時特別有用。注意JAVA_HOME指的是 JDK 安裝目錄含bin/java的那一層不是 JRE 目錄也不是bin目錄本身。這一條看著簡單但我見過太多人在這里多寫一層或者少寫一層。5.2 部署與映射類報錯404 與歡迎頁404 的成因太多我一般按這個順序排查先看logs/catalina.out里有沒有應用的啟動日志如果連 Deployment of web application archive 這種字樣的日志都沒有說明 war 包根本沒被掃描到檢查webapps目錄權限和conf/server.xml里的appBase配置如果有啟動日志但訪問還是 404那大概率是 context path 對不上你在server.xml里配了Context path/myapp瀏覽器就得訪問/myapp/xxx少一段多一段都不行。歡迎頁配置也是個高頻坑。web.xml里的welcome-file-list決定了訪問目錄路徑時默認返回哪個文件。如果列表里配了index.html但目錄下只有index.jspTomcat 不會自動幫你找直接 404。而且歡迎頁的查找是順序匹配的列表越靠前的優(yōu)先級越高把index.html放在index.jsp前面會導致 JSP 永遠不生效——明明文件在就是不顯示。打包方式也影響結果。war 包放進去 Tomcat 會自動解壓但如果你同時保留了舊的解壓目錄Tomcat 可能用的是舊目錄里的內容。我踩過的坑是更新 war 包忘了刪對應的解壓目錄改了半天代碼發(fā)現沒生效最后發(fā)現跑的是老目錄。穩(wěn)妥做法是停掉服務、刪掉 war 包和解壓目錄、再放新包。5.3 類加載與依賴類報錯java.lang.ClassNotFoundException和NoClassDefFoundError看著像含義不同。前者是主動加載時沒找到通常是Class.forName或者容器掃描時拋的后者是編譯期存在、運行期找不到常常意味著類在加載過程中失敗了比如靜態(tài)代碼塊拋了異常或者類被兩個不同的加載器加載了。排查的第一個動作是確認 jar 的位置。項目依賴必須是WEB-INF/lib下的 jar或者WEB-INF/classes下的 class 文件放在 Tomcat 的lib目錄里雖然也能用但那是容器級別的類加載器多個應用會互相干擾強烈不建議。第二個動作是看有沒有版本沖突。兩個不同版本的同一個包同時出現在WEB-INF/lib里Tomcat 按文件名排序加載先加載的生效行為就變得不可預期。我整理過一個快速判斷表現象大概率原因處理方式啟動時立刻報 CNFEjar 缺失或路徑不對檢查WEB-INF/lib運行到某個功能才報反射加載的類名拼寫錯誤核對全限定類名報 NoClassDefFoundError 且?guī)?Cause靜態(tài)初始化失敗看異常鏈最底層類型轉換失敗 ClassCastException同類被雙加載器加載統(tǒng)一依賴來源5.4 資源與連接類報錯連接池拿不到連接熱詞里那條could not obtain connection to query metadata : cannot create我特別想展開講因為它太典型了。這個報錯通常出現在應用啟動階段連接池Druid、HikariCP、DBCP 都可能嘗試建立第一條物理連接時失敗了。報錯信息本身只說了拿不到連接真正的原因藏在異常鏈里往往是下面幾種之一。其一是 JDBC 驅動和數據庫版本不匹配。比如數據庫是較新的版本驅動還是老版本握手階段就會失敗現象是cannot create后面跟著一個具體的握手異常。解決方式很直接換成匹配版本的驅動并且確認驅動 jar 在WEB-INF/lib下而不是只在你本地 IDEA 的庫路徑里。其二是應用啟動時數據庫還沒準備好。容器編排場景下這很常見數據庫容器起來比應用慢幾秒。連接池初始化就失敗整個應用啟動中斷。我的做法是把initialSize設成 0 或者很小的值讓它懶加載同時配好connectionTimeout和失敗重試別讓啟動階段的一次失敗把應用整個拖死。其三是賬號權限或者網絡不通這類用telnet或者數據庫客戶端從 Tomcat 所在機器上連一次就能確認。配好之后建議加一條validationQuery讓連接池在借出連接前做一次探活。這一步帶來的開銷很小但能擋住大量連接已被服務端關閉的詭異報錯。# Druid 參考配置 initialSize0 minIdle1 maxActive20 validationQuerySELECT 1 testWhileIdletrue connectionTimeout3000提示maxActive不要拍腦袋設大。數據庫端有最大連接數限制應用側配得再大超過數據庫限制照樣連不上而且會掩蓋真正的慢 SQL 問題。5.5 編碼、SSL 與安全加固相關報錯中文亂碼分三種位置處理方式完全不同。請求參數亂碼看Connector上的URIEncodingTomcat 8 以后默認就是 UTF-8如果被顯式改成了ISO-8859-1中文參數就會亂同時確認conf/server.xml里 Connector 的useBodyEncodingForURI設置它決定 POST body 的編碼是否也應用到 URI 上。響應亂碼看Content-Type里的charset或者response.setCharacterEncoding?？刂婆_和日志亂碼看 JVM 啟動參數里的-Dfile.encodingUTF-8以及conf/logging.properties的編碼設置。三處都對上中文才不會到處出問題。SSL 相關的報錯集中在握手階段。java.io.IOException: keystore password was incorrect是最直白的——密碼錯了。更隱蔽的是unable to find valid certification path to requested target這出現在雙向認證場景服務端要求客戶端提供證書而客戶端沒有或者證書鏈不完整。雙向認證需要服務端配keystoreFile和keystorePass同時配truststoreFile和truststorePass來校驗客戶端證書還要把clientAuth設成true。少配任何一個握手都會失敗而且不同配置錯誤對應的報錯信息差別很大建議一項一項對照著配。如果項目對加密算法有特定合規(guī)要求通常需要引入對應的加密套件實現并調整 Connector 的協議配置這部分建議照著中間件廠商的官方文檔逐項核對不要憑經驗猜。關于安全加固有三件事值得每年做一次把 Tomcat 升到當前維護的最新穩(wěn)定版刪掉webapps下所有用不到的默認應用尤其是管理端把管理端口的訪問來源限制在可信網段。這些動作成本極低但能擋掉絕大多數自動化掃描。6. 調優(yōu)要點與容器替換的取舍6.1 Connector 與 JVM 的關鍵參數Connector上真正需要關注的參數不多我列幾個最常動的參數作用參考值maxThreads處理請求的最大線程數200 起步按壓測調acceptCount隊列滿后的等待隊列長度100maxConnections允許的最大連接數10000connectionTimeout連接超時毫秒20000compression是否壓縮響應on僅對小文本有效調maxThreads的正確方式是壓測不是抄別人的數字。線程數加大的收益是有上限的因為下游的數據庫連接池、外部接口都有承載極限。我見過把maxThreads調到 2000 結果數據庫連接池只有 50最后瓶口全卡在數據庫上線程全在等連接內存反而被線程棧撐爆。JVM 層面堆大小建議-Xms和-Xmx設成一樣避免運行期擴容帶來的停頓。元空間設個上限-XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m防止動態(tài)生成類太多把內存吃光。垃圾回收器在 JDK 8 上可以用 G1JDK 17 上直接用默認的就行沒必要折騰。部署時在setenv.shLinux或者setenv.batWindows里配置這些參數這樣升級 Tomcat 的時候參數不會丟。6.2 內嵌容器的替換思路現在越來越多項目用 Spring Boot 內嵌容器不再單獨部署 war。內嵌場景下換容器比傳統(tǒng)部署簡單得多本質上就是換一個 starter 依賴。比如要換成 Undertow先在 web starter 里排掉 Tomcat再引 Undertowdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency換 Jetty 也是同樣的套路把 artifactId 換成spring-boot-starter-jetty即可。需要注意的坑有兩個一是有些代碼直接依賴了 Tomcat 特有的類比如org.apache.catalina.*下的工具類換容器后編譯不過得先清理掉二是配置屬性的前綴會變從server.tomcat.*變成server.undertow.*參數名也不一樣遷移時要逐項對應。如果項目有使用其他中間件產品的需求替換思路類似——多數商業(yè)中間件都會提供適配 Spring Boot 的 starter 或者遷移文檔關鍵是先確認它對 Servlet 規(guī)范的兼容程度以及是否有用到的 Tomcat 私有 API。這類替換我建議先在測試環(huán)境完整跑一遍回歸不要上來就改生產因為容器差異往往體現在一些邊緣行為上比如 Cookie 的默認屬性、URL 編碼的處理細節(jié)、靜態(tài)資源的緩存頭這些平時不顯眼的地方最容易出事。6.3 我踩過的幾個坑第一個是 IDEA 里配置 Tomcat 運行配置。不同版本的菜單路徑會變但核心永遠是三件事指定 JDK、指定服務器安裝目錄、在 Deployment 里添加 Artifact。如果啟動后報 404八成是 Artifact 的上下文路徑配的是/還是/項目名沒對上去看運行配置里的 Application context 那一欄。另外新版 IDEA 里有些配置項挪到了Settings的Build Tools下找不到的時候直接在設置里搜 Tomcat 比翻菜單快。第二個是熱部署的錯覺。改了 Java 代碼點重新部署有時候改動沒生效原因是 classes 沒有重新編譯或者輸出目錄指向了舊的路徑。最穩(wěn)的做法是 Build 之后再 Run不要依賴 IDE 的自動編譯。第三個是日志級別。排查問題時把conf/logging.properties里的級別從INFO調到FINE能看到大量內部狀態(tài)信息比如類加載過程、URL 匹配過程。問題解決后記得調回來否則日志文件會迅速膨脹磁盤被寫滿又是另一個故障。我個人在實際操作中的體會是Tomcat 的問題十有八九不是 Tomcat 本身的問題而是環(huán)境、依賴、配置這三者之間的錯位。所以排查時別急著改配置先把報錯鏈條完整讀一遍找到它落在哪一層再動手。手寫一遍迷你容器之后我對這條鏈路的感知明顯變強了——現在看到報錯第一反應不再是搜關鍵詞而是先問自己這是網絡層、協議層還是容器層的事