去年我用兩個周末從零手寫了一個能跑靜態(tài)頁面、能部署Servlet的迷你Tomcat。做完那一刻再回頭看那些“IDEA配置Tomcat”“VSCode配置Tomcat”的教程才終于明白一個道理大多數(shù)配置教程只是在教你怎么當一個操作員而手寫一遍Tomcat才能讓你真正擁有回答“Tomcat干嘛的”的底氣。這個項目最大的收獲不是代碼量而是把Tomcat這層“中間件黑盒”徹底拆開了。你日常部署war包、改端口、配web.xml時遇到的每一個詭異問題追到根上基本都逃不出這幾件事HTTP協(xié)議報文怎么解析、Servlet類從哪里加載、請求映射到哪個方法、連接怎么復用。如果你正在學Java Web底層、準備面試被問Servlet容器原理或者每次配Tomcat總遇到似懂非懂的報錯我強烈建議跟我一樣動手寫一個簡化版。1. 網(wǎng)上一堆Tomcat配置教程我為什么反而選擇手寫一遍1.1 在回答“Tomcat干嘛的”之前先別急著搜配置教程先給結論Tomcat不只是一個“能跑Java Web應用的軟件”它本質上是兩個東西疊在一起——一個HTTP服務器一個Servlet容器。HTTP服務器這層負責監(jiān)聽Tomcat端口默認8080把瀏覽器發(fā)過來的TCP字節(jié)流解析成符合HTTP協(xié)議的請求把服務器返回的數(shù)據(jù)封裝成HTTP響應寫回Socket。Servlet容器這層負責加載你寫的Servlet類、解析web.xml里的映射配置、按請求路徑找到對應的類并調用它的service/doGet/doPost方法然后把結果交回HTTP服務器層。很多開發(fā)干了幾年每天在用Tomcat卻說不出這兩個層次。你問“Tomcat干嘛的”他們只能回答“部署war包的”。這不是他們的鍋因為日常開發(fā)里Tomcat被IDE藏得太好了點一下啟動按鈕日志一刷應用就起來了中間發(fā)生了什么完全不可見。手寫一遍就是強制自己把這層包裝撕掉去看真正的報文、真正的類加載、真正的Socket讀寫。我給自己定的目標是寫一個MiniTomcat能做到——啟動后監(jiān)聽指定端口訪問靜態(tài)HTML和圖片能正確返回能解析web.xml能加載并調用Servlet能模擬Tomcat的類加載器隔離機制。難度不大但每一步都要親手造輪子這比讀十遍源碼都有用。1.2 一個人手寫Tomcat需要先劃清三大邊界寫之前最容易犯的錯誤是“什么都要做”。Session、Filter、WebSocket、HTTPS、NIO、War熱部署……如果第一版就把這些全塞進去你會陷入無窮無盡的細節(jié)最后什么都寫不完。我劃分的邊界是第一版只做“通信與協(xié)議層”也就是Socket監(jiān)聽、HTTP請求解析、HTTP響應封裝第二層做“容器與路由層”也就是Servlet映射、反射調用、靜態(tài)資源分發(fā)第三層做“類加載與部署層”也就是WebAppClassLoader、web.xml加載、熱部署的簡化實現(xiàn)。這三層恰好對應Tomcat源碼里的Connector和Container兩大核心組件也對應JVM類加載體系。先跑通這三層MiniTomcat已經(jīng)能回答“Tomcat啟動后發(fā)生了什么”這個問題。Session、Filter這些后面想要都是在Servlet調用鏈上加攔截器或上下文對象不是第一版的核心矛盾。2. 動手前的關鍵決策把功能拆成Connector、Container和Loader三塊2.1 功能模塊拆解誰來監(jiān)聽端口誰來處理請求誰來加載類我設計的第一版類結構非常簡單總共分四組互相之間的依賴關系也清晰模塊職責核心類啟動入口初始化配置、綁定端口、開啟事件循環(huán)BootstrapConnector層把Socket字節(jié)流轉成HttpRequest對象把處理結果寫回SocketHttpRequest、HttpResponse、RequestParserContainer層判斷請求是靜態(tài)資源還是Servlet分別處理StaticResourceProcessor、ServletProcessorLoader層解析web.xml、加載Servlet類、實現(xiàn)類加載隔離WebConfig、WebAppClassLoader這個分組其實就是Tomcat源碼結構的縮小版。Tomcat里Connector負責協(xié)議解析和網(wǎng)絡通信Container負責調用鏈處理WebappClassLoader負責應用隔離。我不需要引入Spring那套容器概念一個請求從Socket進來落到對應的Processor上就已經(jīng)能解釋Tomcat八成的運行邏輯了。2.2 工程骨架哪些類放在哪里我建議工程結構長這樣mini-tomcat/ ├── src/main/java/com/example/minitomcat/ │ ├── Bootstrap.java │ ├── connector/ │ │ ├── HttpRequest.java │ │ ├── HttpResponse.java │ │ └── RequestParser.java │ ├── container/ │ │ ├── StaticResourceProcessor.java │ │ └── ServletProcessor.java │ └── loader/ │ ├── WebAppClassLoader.java │ └── WebConfig.java └── webroot/ ├── conf/web.xml ├── classes/ └── static/Bootstrap是入口類似于Tomcat的catalina.sh腳本加上Server組件。webroot是應用根目錄里面三個子目錄分別放web.xml、Servlet編譯后的class文件、靜態(tài)資源。這里有一個容易被忽略的設計點webroot一定要做成可以外部配置的參數(shù)而不是在代碼里寫死“D:/webroot”。Tomcat之所以有CATALINA_HOME和webapps的區(qū)分就是因為容器安裝目錄和部署目錄要解耦手寫版哪怕只有兩個參數(shù)也要把這個習慣保留下來。2.3 為什么第一版不做Session和Filter我在設計時故意把Session、Filter、Listener從第一版里砍掉了只保留了Servlet調用鏈。原因很實際濾器的核心是在Servlet前后插入一段代碼Session的核心是在請求里維護一個客戶端標識它們在Tomcat架構里屬于Context組件上的附屬設施而不是地基。真正的地基是“Socket變成請求對象請求路徑變成類調用”這條主線。如果第一版就糾纏Session的過期策略、Cookie寫到哪個域你會煩躁到懷疑人生。先把地基夯好Filter和Session都是往調用鏈上掛一段邏輯而已。3. 請求解析拿Socket流還原出真實的HTTP請求3.1 HttpRequest解析請求行、請求頭、請求體Tomcat處理請求的第一件事就是把Socket輸入流里的字節(jié)還原成一個結構化對象。HTTP請求文本的格式非常固定依次是請求行、多個請求頭、空行、請求體。比如瀏覽器訪問http://localhost:8080/hello時發(fā)出的原始請求長這樣GET /hello HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 Accept: text/html最后那個空行是HTTP協(xié)議里請求頭和請求體的分隔標志解析任何HTTP報文都要靠它切分階段。我寫了RequestParser做這件事核心解析函數(shù)如下public void parse() throws IOException { parseRequestLine(); parseHeaders(); parseBody(); } private void parseRequestLine() throws IOException { String line readLine(); if (line null || line.isEmpty()) { throw new IOException(empty request line); } String[] parts line.split( ); this.method parts[0]; String fullPath parts[1]; int idx fullPath.indexOf(?); if (idx 0) { this.uri fullPath.substring(0, idx); this.queryString fullPath.substring(idx 1); } else { this.uri fullPath; } } private void parseHeaders() throws IOException { String line; while ((line readLine()) ! null !line.isEmpty()) { int colon line.indexOf(:); if (colon 0) { headers.put(line.substring(0, colon).trim().toLowerCase(), line.substring(colon 1).trim()); } } } private void parseBody() throws IOException { String len headers.get(content-length); if (len ! null) { int length Integer.parseInt(len); body new byte[length]; int read 0; while (read length) { int n input.read(body, read, length - read); if (n -1) break; read n; } } }這里有一個拿捏細節(jié)注釋中的Host頭在許多HTTP/1.1請求里是必需的Tomcat處理虛擬主機時要靠它區(qū)分站點。手寫版即使不實現(xiàn)虛擬主機也應當在解析請求頭時統(tǒng)一把小寫化的Header名存進Map否則后面想加功能還得回頭改。3.2 為什么手寫解析時要避開BufferedReader這是我自己踩過的一個大坑。剛開始我用BufferedReader.readLine()逐行讀請求頭和請求行看著很省事但一旦請求里有POST請求體就會出現(xiàn)數(shù)據(jù)丟失或阻塞。原因很簡單BufferedReader內部維護了一個8KB緩沖區(qū)讀第一行時它可能已經(jīng)把后面的請求頭甚至請求體全部讀進了緩沖區(qū)。你再去從Socket的InputStream里讀body時數(shù)據(jù)已經(jīng)被BufferedReader截走了讀到的是null或者殘缺數(shù)據(jù)。Tomcat底層的Connector之所以寫得很復雜一個重要原因就是在字節(jié)層面精確控制“哪些字節(jié)屬于請求頭哪些字節(jié)屬于請求體”絕對不能依賴帶緩沖的Reader越界讀字節(jié)。所以我后來改成了逐字節(jié)手動讀取private String readLine() throws IOException { ByteArrayOutputStream bos new ByteArrayOutputStream(); int ch; while ((ch input.read()) ! -1) { if (ch \r) { int next input.read(); if (next \n || next -1) { break; } bos.write(ch); bos.write(next); } else if (ch \n) { break; } else { bos.write(ch); } } return bos.toString(StandardCharsets.ISO_8859_1); }注意這里用了ISO_8859_1而不是UTF-8。請求行和請求頭里的ASCII字符用Latin-1解碼是最安全的因為后續(xù)URL解碼和請求體解碼可以按具體字符集處理。一旦這里用了UTF-8遇到某些特殊字節(jié)會產(chǎn)生奇奇怪怪的亂碼。3.3 HttpResponse把狀態(tài)行、Content-Length和響應體寫對請求解析完就得設計響應對象。最基礎的HTTP響應用幾行就能說明白HTTP/1.1 200 OK Content-Type: text/html; charsetUTF-8 Content-Length: 55 htmlbodyh1Welcome/h1/body/html第一行是狀態(tài)行包含協(xié)議版本、狀態(tài)碼、原因短語。請求頭里最關鍵的是Content-Length它告訴瀏覽器響應體有多少字節(jié)。很多人手寫HTTP響應的時候會漏掉它結果瀏覽器一直轉圈因為不知道響應體在哪里結束。我的HttpResponse封裝了下面的核心能力public void sendError(int status, String reason) throws IOException { setBody(htmlbodyh1 status reason /h1/body/html); } public void setBody(String content) throws IOException { byte[] data content.getBytes(StandardCharsets.UTF_8); OutputStream out socket.getOutputStream(); out.write((HTTP/1.1 status reason \r\n).getBytes(StandardCharsets.ISO_8859_1)); out.write((Content-Type: contentType ; charsetUTF-8\r\n).getBytes(StandardCharsets.ISO_8859_1)); out.write((Content-Length: data.length \r\n).getBytes(StandardCharsets.ISO_8859_1)); out.write(\r\n.getBytes(StandardCharsets.ISO_8859_1)); out.write(data); out.flush(); }注意兩個細節(jié)一是\r\n絕不能只寫\nHTTP協(xié)議規(guī)定行分隔符是CRLF很多客戶端和網(wǎng)關對裸換行非常敏感二是所有文本統(tǒng)一先轉字節(jié)再寫OutputStream不要用Writer去寫否則字符編碼會截斷字節(jié)。3.4 靜態(tài)資源解析與路徑穿越攔截靜態(tài)資源是最容易先跑通的部分。StaticResourceProcessor做的事很簡單把URI映射到webroot/static目錄下的文件存在的文件返回內容不存在的返回404。但這里必須加一個安全檢查——過濾..路徑穿越。如果不攔截用戶請求/../conf/web.xml就能直接讀到你的配置文件這在真實Tomcat里同樣是禁忌。我寫了一個最小檢查public void process(HttpRequest request, HttpResponse response) throws IOException { String path request.getUri(); if (path.contains(..)) { response.sendError(403, Forbidden); return; } File file new File(WebConfig.getWebRoot(), static path); if (!file.exists()) { response.sendError(404, Not Found: path); return; } response.setContentType(Files.probeContentType(file.toPath())); response.writeFile(file); }另外靜態(tài)資源的Content-Type在真實環(huán)境里要求很嚴格text/html、application/javascript、image/png必須正確設置否則瀏覽器會亂碼或拒絕執(zhí)行腳本。Java的Files.probeContentType可能返回null手寫版建議維護一個簡單的擴展名映射表兜底。4. Servlet映射與調用反射拿到類執(zhí)行完整的Servlet生命周期4.1 用web.xml描述路由容器按圖找類真實Tomcat通過web.xml把URL路徑和Servlet類綁定起來。手寫版我直接用JDK內置的DOM解析不需要引入第三方庫。最簡web.xml長這樣?xml version1.0 encodingUTF-8? web-app servlet servlet-namehello/servlet-name servlet-classcom.demo.HelloServlet/servlet-class /servlet servlet-mapping servlet-namehello/servlet-name url-pattern/hello/url-pattern /servlet-mapping /web-appWebConfig解析該文件時先建立servlet-name到servlet-class的映射再建立url-pattern到servlet-name的映射最終得到一個MapString, String路徑到類名。這里我要特別提一下路徑匹配的優(yōu)先級。真實Tomcat的url-pattern匹配規(guī)則很復雜支持精確匹配、前綴匹配/hello/*、擴展名匹配*.do精確匹配優(yōu)先級最高。手寫版第一版只支持精確匹配是合理的但設計Map數(shù)據(jù)結構時就要把“路徑可能帶通配符”考慮進去不要等第二版重構結構。4.2 ServletProcessor反射實例化與service調用我現(xiàn)在定義一個極簡Servlet接口避免引入完整Servlet API的依賴public interface MiniServlet { void service(HttpRequest request, HttpResponse response) throws IOException; }ServletProcessor拿到路徑后從WebConfig找Servlet類名再加載、實例化、調用service。關鍵點在于加載這一步必須用WebAppClassLoader而不是默認的應用類加載器這是整個手寫項目里最貼近Tomcat靈魂的地方public class ServletProcessor { public void process(HttpRequest request, HttpResponse response) throws Exception { String path request.getUri(); String className WebConfig.findServletClass(path); if (className null) { response.sendError(404, No servlet mapped for: path); return; } MiniServlet servlet WebConfig.getServletInstance(className); servlet.service(request, response); } }WebConfig內部維護一個MapString, MiniServlet實例緩存同一個Servlet類只加載一次、只實例化一次。這和Tomcat的行為一致Servlet默認是單實例多線程模型所有請求共享同一個Servlet對象。而線程安全問題自然降臨到Servlet開發(fā)者身上容器不負責加鎖。反射創(chuàng)建實例的代碼比較簡單public static MiniServlet loadServlet(String className) throws Exception { WebAppClassLoader loader new WebAppClassLoader(WebConfig.getWebRoot(), Thread.currentThread().getContextClassLoader()); Class? clazz loader.loadClass(className); Object instance clazz.getDeclaredConstructor().newInstance(); if (!(instance instanceof MiniServlet)) { throw new IllegalArgumentException(className is not a MiniServlet); } return (MiniServlet) instance; }這個getDeclaredConstructor().newInstance()看似不起眼實際上對應Tomcat里ClassLoader加載完成后、容器調用無參構造器創(chuàng)建Servlet實例的過程。如果類構造函數(shù)拋異?；蛘哳悰]有無參構造器這里的異常鏈會非常長排查時要從根因看Caused by而不是盯著最外層。4.3 生命周期、異常與500響應Tomcat里Servlet有完整生命周期init初始化、service處理請求、destroy銷毀。手寫版我在加載實例后立刻調用一次init()雖然接口里沒體現(xiàn)但在實現(xiàn)類里可以約定如果需要初始化資源就重寫init()。還有一個非常容易忽略的異常處理分支Servlet的service方法可能拋異常尤其是數(shù)據(jù)庫連接超時、空指針這類。此時容器不能把異常原樣吞掉也不應該把堆棧打到控制臺就完事而要給客戶端一個明確的500響應。我加了一個簡單的兜底try { servlet.service(request, response); } catch (Exception e) { response.sendError(500, Internal Server Error: e.getMessage()); }這段代碼雖然少但代表了Tomcat里StandardWrapperValve處理異常的思路容器負責捕獲異常并轉換為標準錯誤響應Servlet開發(fā)者不需要在業(yè)務代碼里到處處理HTTP狀態(tài)碼。5. 類加載器手寫版也要把雙親委派機制拆了重裝5.1 雙親委派機制JVM為什么要父優(yōu)先這是整個手寫Tomcat里面試最愛考的點也是很多人看源碼時最難理解的一環(huán)。先說JVM默認的雙親委派機制當應用類加載器AppClassLoader需要加載一個類時它不先自己找而是先委托給父加載器——擴展類加載器JDK 9之后叫PlatformClassLoader擴展類加載器再委托給啟動類加載器Bootstrap ClassLoader。父加載器加載不了才輪到子加載器自己找。這個機制的安全意義在于確保核心類庫永遠是同一個版本。比如java.lang.String只能由啟動類加載器加載即使你在自己的classpath里塞一個同名同包名的偽造類雙親委派也會阻止它進入JVM從而防止核心API被篡改。5.2 Tomcat為什么反著來先看本地類再找父加載器Tomcat的WebappClassLoader卻把默認邏輯倒過來了加載一個類時先在自己負責的類路徑里找也就是應用目錄下的WEB-INF/classes和WEB-INF/lib本地找不到才委托給父加載器。為什么要這么做因為一個JVM里可能同時跑多個Web應用每個應用可以依賴不同版本的Spring、MyBatis。如果用默認的雙親委派Spring的類一旦被父加載器加載所有應用就共享同一個版本沒法做應用隔離。更麻煩的是類一但被加載后很難卸載熱部署時舊版類會一直杵在JVM里。手寫MiniTomcat的WebAppClassLoader核心代碼其實很短public class WebAppClassLoader extends ClassLoader { private final Path webAppRoot; public WebAppClassLoader(String webAppRoot, ClassLoader parent) { super(parent); this.webAppRoot Paths.get(webAppRoot); } Override protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { Class? loaded findLoadedClass(name); if (loaded ! null) { return loaded; } if (name.startsWith(java.) || name.startsWith(javax.)) { return super.loadClass(name, resolve); } try { Path classFile webAppRoot.resolve(classes) .resolve(name.replace(., /) .class); byte[] data Files.readAllBytes(classFile); loaded defineClass(name, data, 0, data.length); if (resolve) { resolveClass(loaded); } return loaded; } catch (IOException e) { return super.loadClass(name, resolve); } } } }注意這里的兩個關鍵動作java.*和javax.*開頭的類必須強制交給父加載器絕對不能本地優(yōu)先否則你自己寫的javax.servlet.Servlet可能破壞整個體系本地找不到類時最后調super.loadClass走默認雙親委派保證容器自身的類比如MiniServlet接口還是由系統(tǒng)類加載器加載。5.3 熱部署原理換一個ClassLoader的生命周期熱部署為什么一定要和類加載器綁在一起因為JVM不允許在運行時替換一個已被加載的類但允許你新建一個ClassLoader用新的ClassLoader重新加載同名類。舊的ClassLoader和它加載的類對象只要沒有外部引用就會被GC回收。Tomcat的reloadabletrue就是這樣一個循環(huán)過程監(jiān)控WEB-INF/classes和WEB-INF/lib里的文件時間戳發(fā)現(xiàn)有變化就把當前Web應用上下文整個停掉創(chuàng)建新的WebappClassLoader重新加載所有類。手寫版的簡化實現(xiàn)可以做得很直接if (classFile.lastModified() loadedTime) { WebAppClassLoader newLoader new WebAppClassLoader(webRoot, parentClassLoader); WebConfig.clearServletCache(); WebConfig.setClassLoader(newLoader); }這里踩過的坑是熱部署時如果舊的Servlet實例還被全局Map引用新Loader和舊Loader的類就同時存在于JVM里容易造成ClassCastException。所以換Loader的同時必須清空實例緩存Tomcat重啟Context也是同樣的道理——不是JVM重啟而是應用級的狀態(tài)全部清空重建。6. 啟動與排查手寫容器第一次跑起來哪些坑必須先知道6.1 Bootstrap的啟動流程端口、根目錄、事件循環(huán)Bootstrap的main方法其實相當樸素public class Bootstrap { public static void main(String[] args) throws Exception { int port args.length 0 ? Integer.parseInt(args[0]) : 8080; WebConfig.init(Paths.get(webroot)); ExecutorService pool Executors.newFixedThreadPool(16); try (ServerSocket serverSocket new ServerSocket(port)) { while (!Thread.currentThread().isInterrupted()) { Socket socket serverSocket.accept(); pool.submit(() - handle(socket)); } } } private static void handle(Socket socket) { try (socket) { HttpRequest request new HttpRequest(socket.getInputStream()); request.parse(); HttpResponse response new HttpResponse(socket); if (request.getUri().startsWith(/servlet/)) { new ServletProcessor().process(request, response); } else { new StaticResourceProcessor().process(request, response); } } catch (IOException e) { // 客戶端斷開等場景忽略并關閉連接即可 } } }這段代碼已經(jīng)能體現(xiàn)Tomcat啟動的核心流程解析配置、綁定端口、循環(huán)接收連接、將連接交給處理器。你在IDEA里配置Tomcat時填的port、deployment路徑本質上就是告訴這個啟動類端口是多少webroot在哪。手寫版跑通之后再回去看那些配置界面你會覺得每個選項都極其熟悉。6.2 啟動階段三類報錯及排查鏈路我實際運行mini-tomcat時第一天就撞了三堵墻每一堵都很有代表性第一類是端口沖突。啟動時報BindException: Address already in use通常就是8080被其他進程占了。排查命令建議直接背下來Windows用netstat -ano | findstr :8080Linux用ss -lntp | grep 8080macOS用lsof -i :8080。找到PID后要么殺掉占用進程要么換一個端口啟動。第二類是靜態(tài)資源404。這個問題幾乎都是webroot路徑不對導致的。我一開始把靜態(tài)資源放在了工程根目錄下的static但Bootstrap啟動時的工作目錄如果是另一個模塊Paths.get(webroot)就找不到。解決方法是把webroot作為啟動參數(shù)傳進來并且用絕對路徑驗證Path root Paths.get(webroot).toAbsolutePath(); if (!Files.isDirectory(root)) { throw new IllegalStateException(webroot not found: root); }第三類是ClassNotFoundException。這鍋甩給JDK之前先檢查兩件事web.xml里的servlet-class類名是不是全限定名以及class文件是否真的存在于webroot/classes對應的包路徑下。注意用自定義WebAppClassLoader時類文件的位置不是看classpath而是看Loader里定義的webAppRoot/classes這兩個概念一開始非常容易混淆。6.3 高版本JDK的隱藏坑最近幾個JDK大版本包括我寫的JDK 17、21以及更往后的版本在模塊化上做得越來越嚴格Socket和ServerSocket這套API倒是沒變但反射訪問私有成員的限制觸發(fā)了很多舊中間件的問題。以前很多框架靠setAccessible(true)強行突破封裝高版本JDK會輸出類似“Illegal reflective access operation”的警告甚至直接拋異常。手寫Tomcat時我建議從現(xiàn)在開始就養(yǎng)成一個習慣ServletRequest、Servlet響應這類對象里不需要用反射去拿私有字段盡量走公開接口。如果實在要反射啟動時準備好--add-opens java.base/java.langALL-UNNAMED這類參數(shù)但能避開就避開。這不是讓你抵制新版本而是舊習慣在JDK高版本下已經(jīng)不值錢了。7. 并發(fā)接入與后臺安全從單線程到線程池再到上傳war被限制IP7.1 從單線程到線程池別讓一個慢請求堵死全局第一版我偷懶用單線程for循環(huán)處理每個Socket結果發(fā)現(xiàn)一個明顯問題如果一個請求處理耗時很久比如Servlet里去訪問了一個慢數(shù)據(jù)庫后面的請求全部排隊整個服務相當于卡死。后來改成每連接一線程問題又來了線程數(shù)量沒有上限幾百個并發(fā)就把內存打爆。最終采用固定大小線程池也就是你在Bootstrap里看到的Executors.newFixedThreadPool(16)。Tomcat真正生產(chǎn)環(huán)境的線程池參數(shù)更復雜要配核心線程數(shù)、最大線程數(shù)、隊列容量、拒絕策略。手寫版用固定線程池雖然粗糙但足夠說明“連接接入和業(yè)務處理要解耦”這個核心思想。這里有個值得注意的小知識線程池不是越大越好。每個線程要占約1MB左右的棧空間如果TCP連接都是長連接線程池會被根本不發(fā)請求的空閑連接長期占滿。這也是Tomcat后來轉向NIO的重要原因——用更少的線程處理更多的并發(fā)連接。7.2 HTTP/1.1與keep-alive線程復用的兩面HTTP/1.1默認開啟keep-alive意思是同一個TCP連接可以連續(xù)發(fā)多個HTTP請求不用每次請求都重新建立連接。手寫版為了簡單直接處理完一個請求就關閉Socket也能跑但如果你想往上靠就得在循環(huán)里連續(xù)解析請求boolean keepAlive true; while (keepAlive !socket.isClosed()) { HttpRequest request new HttpRequest(socket.getInputStream()); request.parse(); HttpResponse response new HttpResponse(socket); process(request, response); response.flush(); keepAlive keep-alive.equalsIgnoreCase(request.getHeader(connection)); }這個循環(huán)看起來簡單它埋了一個隱患如果客戶端連接?；畹t遲不發(fā)下一個請求服務端線程會阻塞在readLine()上大量keep-alive空閑連接會白白占住線程資源。Tomcat 8之后默認用NIO核心就是解決“線程阻塞在空連接上”的問題。手寫版你能把這個矛盾親手復現(xiàn)一遍再去看NIO和Reactor模型理解會完全不同。7.3 上傳war被限制IP后臺管理權限的最小實現(xiàn)順便聊聊網(wǎng)上經(jīng)常搜到的問題“tomcat后臺頁面上傳war被限制ip”。這個現(xiàn)象根因是Tomcat默認的manager應用出于安全考慮只允許本機訪問。它通過Context里的Valve做IP過濾配置文件里常看到RemoteAddrValve或者RemoteHostValve只放行127\.0\.0\.1或者內網(wǎng)IP段。所以你在本地訪問manager通常正常從遠程一上傳war就403。這個安全策略背后的道理值得細想上傳war包等于允許執(zhí)行任意代碼。如果你只靠一個用戶名密碼來保護上傳接口密碼一旦泄露或者口令爆破成功攻擊者直接傳一個webshell是整臺服務器的權限。所以Tomcat用最底層、最不容易被繞過的網(wǎng)絡層IP限制來兜底而不是把安全全押在認證上。手寫版要模擬這個行為可以在Bootstrap的accept邏輯后加一段判斷如果是部署或管理接口的請求先校驗來源IP不是白名單就直接返回403InetAddress remote socket.getInetAddress(); if (!isAllowedManagerIp(remote)) { HttpResponse response new HttpResponse(socket); response.sendError(403, manager access forbidden from remote.getHostAddress()); socket.close(); return; }生產(chǎn)環(huán)境更嚴格的方案是管理端口和業(yè)務端口徹底分開管理端口只綁定在127.0.0.1或內網(wǎng)網(wǎng)卡上不暴露到外網(wǎng)。Tomcat的做法也是類似的思路——manager接口和業(yè)務接口同居一個端口但用Valve做第一層攔截。理解了這個你就知道“限制IP”不是Tomcat在給用戶添麻煩而是在做正確的事。如果你也想照著這個思路手寫一遍我的建議是從靜態(tài)文件開始不要一上來就寫類加載器。先用最簡單的Socket解析一個GET請求把靜態(tài)頁面返回成功再逐步加Servlet映射、web.xml、ClassLoader最后再碰并發(fā)和部署管理。調試時多用curl -v、telnet 8080手工發(fā)HTTP報文看原始流量能幫你肉眼確認每一行響應頭是否正確。先跑通再說別的——這句話放在幾乎所有中間件學習上都成立。