作为一个写了八年 Java 的开发者我见过太多人把 Tomcat 当黑匣子用——把 war 包往里一扔启动脚本一跑应用起来了就完事。直到有一天线上出现一个诡异的连接问题排查到最后才发现是对 Tomcat 的线程模型理解有偏差那一次我下定决心自己动手写一个够用的迷你版 Tomcat把 Servlet 容器的底层逻辑彻底吃透。这个项目的核心目标很明确不追求功能完备只求把 Servlet 容器的三条主线打通——HTTP 协议处理、Servlet 生命周期管理、请求到 Servlet 的映射机制。代码量控制在几百行以内但每一行都要能说明白“为什么这么写”。这篇文章就把我实现这个简易 Tomcat 的完整思路、代码细节和踩坑记录分享出来适合那些已经能写 Servlet 但不太清楚容器内部发生了什么的人也适合想系统理解 Web 服务器工作原理的初学者。1. 动手之前先弄明白 Servlet 容器到底干了三件什么事1.1 容器的本质一个把 HTTP 报文变成 Java 方法调用的翻译官很多人对 Servlet 容器有误解觉得它很神秘。其实剥开外壳看本质Servlet 容器做的工作和你日常点的外卖订单流程非常像外卖平台接收你的电话或者 App 订单把它转成一张标准格式的订单小票后厨根据小票做菜做好后平台再打包送回到你手里。对应到技术上就清晰了接收外卖订单 监听端口接受 TCP 连接读取 HTTP 请求报文转成标准订单小票 把原始的 HTTP 报文解析成HttpServletRequest对象包含 URL、请求参数、请求头、请求体后厨做菜 找到对应的 Servlet调用它的service()方法让业务代码处理请求打包送回 把业务代码产生的响应数据封装成HttpServletResponse按照 HTTP 协议格式写回客户端换句话说Servlet 容器就是一个协议翻译层让 Java 开发者不用关心 TCP Socket、不用关心 HTTP 报文怎么拼接和解析只需要面对一个“请求对象”和一个“响应对象”写业务逻辑就行。弄明白这层关系之后手写一个简易 Tomcat 的思路就很自然了我只需要实现上述四个环节别的不需要。不用做 JSP 解析不用做 Session 管理后面我会说为什么不用做类热加载这些在理解了核心流程之后再去扩展也来得及。1.2 手写版必须保留的三条主线面对 Tomcat 这种级别的开源项目最容易犯的错误就是贪大求全。Tomcat 的源码是几十万行的级别如果一头扎进去读源码大概率会迷失在类加载体系、管道阀门机制、JMX 管理等细节里出不来。我给自己的项目划定了一条清晰的边界只保留三样东西第一HTTP 协议处理器。能解析 HTTP/1.1 的 GET 和 POST 请求能解析请求头能读取请求体能根据 Content-Length 正确读取 body。响应端至少能输出状态行、响应头和内容。这个部分是整个容器的基础设施理解 TCP 字节流和 HTTP 协议文本之间的转换关系是最有价值的。第二Servlet 生命周期管理。init()、service()、destroy()三个方法必须在正确的时机被调用。容器启动时加载 Servlet 并调用init()请求到达时调用service()容器关闭时调用destroy()。这个生命周期管理逻辑是整个 Servlet 规范的核心骨架如果能把生命周期时间线彻底搞明白以后看 Spring MVC 的 DispatcherServlet 为什么那样设计就有基础了。第三URL 到 Servlet 的映射。你配置的servlet-mapping那段 XML 到底是怎么生效的URL 是怎么匹配到对应的 Servlet 的通配符/*和/有什么区别。这些都是 Web 开发里最常见但最容易含糊的概念亲手实现一遍映射逻辑后很多疑惑都会解开。1.3 明确不做的事也是项目的一部分说完了要做的还得说清楚不做什么这些边界的划定本身就是对架构能力的锻炼。Session 管理不做。不是因为 Session 不重要而是 Session 本质上是在“请求 - 响应循环”之上的一层状态封装它的实现依赖 Cookie 和服务器端存储。如果我把 Session 也加进来就涉及并发访问的线程安全、过期策略、序列化存储等一大堆问题会严重分散对核心流程的注意力。类热加载不做。Tomcat 的 WebappClassLoader 体系设计得极其精巧但那是为了保证多个应用在同一个 JVM 里类隔离。我写的简易版在同一个 JVM 里只跑自己的 ClassLoader是不需要类隔离的。JSP 不做。JSP 在 Tomcat 里的本质是先被翻译成 Servlet 源码再编译需要引入大量编译器相关的代码。现在前后端分离的架构下 JSP 用得越来越少这个功能留着等以后需要时再研究。项目的边界划定好之后动手编码就有了明确的路径。接下来我先把整体架构铺开说说我是怎么划分代码模块的。2. 整体架构一个最简单但五脏俱全的容器骨架2.1 需要一个连接器和一个容器各司其职我参考 Tomcat 经典的 Coyote连接器和 Catalina容器双层架构把我的简易版也分成两层。连接器这一层英文叫 Connector负责处理所有和网络协议相关的脏活累活。它做的事情是创建一个ServerSocket监听端口接受客户端的 Socket 连接读取字节流并解析成 HTTP 请求对象同时把响应对象写回客户端。连接器完全不知道业务逻辑它就像一个前台接待员只管把客人带进来带到哪个包间去是谁安排的它不管。容器这一层就是真正处理业务的地方。它需要维护一个注册表保存 URL 路径和 Servlet 实例的对应关系。当连接器把解析好的请求对象传过来时容器根据请求 URL 找到对应的 Servlet调用它的service()方法然后把处理结果交给连接器返回。在我的实现里为了不过度设计我把连接器抽象成一个HttpServer类容器抽象成一个ServletContainer类两个类通过一个Request对象和一个Response对象完成交互。模块划分清楚了下面就是更具体的类设计了。为了让代码结构清晰且贴近 Tomcat 的形象我尝试用几个核心类模拟 Tomcat 的关键角色。2.2 核心类设计用五个类撑起整个容器整个项目我刻意控制在五个核心类每个类对应 Tomcat 的某个核心角色这样读代码的人能迅速建立起“这个类对应 Tomcat 的哪个组件”的认知。第一个类是HttpServer对应 Tomcat 里的 Connector。它负责创建 ServerSocket、循环接受连接、为每个连接分配线程、解析请求、调用容器处理、返回响应。第二个类是Request对应 Tomcat 里的HttpServletRequest。它封装了请求行、请求头、请求体提供getMethod()、getUri()、getParameter()等方法。第三个类是Response对应 Tomcat 里的HttpServletResponse。它输出 HTTP 响应头和各种内容类型。第四个类是ServletContainer对应 Tomcat 里的 Container 体系。它维护一个 Map键是 URL 映射路径值是 Servlet 实例负责把请求转发给正确的 Servlet。第五个类是HttpServlet抽象类对应 Tomcat 里的javax.servlet.http.HttpServlet。它定义了doGet()和doPost()方法在service()里根据请求方法分派到具体的 do 方法。这五个类配合起来就形成了一个最小可运行的 Web 容器。当用户配置好一个业务 Servlet 后访问http://localhost:8080/hello就能看到效果。类结构搭好了接下来就得逐个击破核心细节了。这么多模块里HTTP 请求解析是最关键的第一步如果这一步解析有误后面所有逻辑都会跟着出错。3. 核心细节拆解一步步啃下硬骨头3.1 HTTP 请求解析从字节流到结构化对象TCP 连接建立之后客户端会发送一串符合 HTTP 协议格式的文本数据。这串文本长这样POST /login?namezhangsan HTTP/1.1 Host: localhost:8080 Content-Type: application/x-www-form-urlencoded Content-Length: 11 usernameadminpassword123456第一行是请求行包含三个部分请求方法、URI包含查询字符串、协议版本。中间若干行是请求头每一行都是键: 值的格式头部结束的标志是一个空行。空行之后是请求体请求体的大小由Content-Length头指定。解析代码最核心的思路是把输入流按行读取第一行特殊处理解析出 method、uri、protocol然后继续逐行读取遇到空行说明头部结束之后根据 Content-Length 继续读取 body。这里第一个容易踩坑的地方是按行读取不能用读文本的方式。HTTP 协议本质上是字节流虽然内容是 ASCII 文本但请求体部分可能是任意二进制数据。如果我用BufferedReader.readLine()来读请求体遇到内容里包含换行符的情况就会提前截断导致请求体读不完整。所以我的做法是请求行和请求头部分用BufferedReader.readLine()这部分本来就是文本行但到了请求体部分就必须根据Content-Length的值直接用输入流的read()方法来读取指定数量的字节。// 读取请求体的关键代码示意 int contentLength Integer.parseInt(headers.getOrDefault(Content-Length, 0)); byte[] bodyBytes new byte[contentLength]; int readCount 0; while (readCount contentLength) { int result inputStream.read(bodyBytes, readCount, contentLength - readCount); if (result -1) { break; } readCount result; }这段代码里我用了一个循环读取的方式是因为inputStream.read()并不保证一次能读到所有字节在网络传输场景下必须循环确认。这是一个非常经典的网络编程坑很多人写死inputStream.read(bodyBytes)在小请求下不会出问题一旦传输的字节数稍多就会遇到数据读取不完整的情况。3.2 URL 映射决定请求去哪里的路由表请求解析成对象之后容器要做的事情就是根据请求的 URI 找到对应处理的 Servlet。这个过程和快递分拣中心很像包裹上的地址决定了它被分配到哪个片区的快递员手里。在我的实现里URL 映射用一个HashMapString, Servlet来维护。key 是映射路径value 是 Servlet 实例。映射规则的确定遵循一个非常简单的约定精确匹配优先于通配符匹配。Tomcat 官方的映射规则要复杂得多包含着精确匹配、最长路径前缀匹配、扩展名匹配、默认匹配四个层级。如果我在简易版里完全照搬代码量会膨胀不少。但是我认为“精确匹配 通配符/* 默认 Servlet”这三个规则已经足够说明原理所以我就这样实现了。映射路径格式我设计成两种一种是/hello这种精确路径另一种是/test/*这种通配符路径。当一个请求的 URI 是/test/page时它就能匹配到/test/*这个映射。实现的核心算法是先看 Map 里有没有完全相等的 key有就直接返回没有的话把 URI 逐级截断看看/test/这种前缀能不能匹配上通配符的 key。public Servlet findServlet(String uri) { // 精确匹配优先 if (servletMapping.containsKey(uri)) { return servletMapping.get(uri); } // 通配符匹配/test/* 这种模式 for (Map.EntryString, Servlet entry : servletMapping.entrySet()) { String mappingPath entry.getKey(); if (mappingPath.endsWith(/*) uri.startsWith(mappingPath.substring(0, mappingPath.length() - 2))) { return entry.getValue(); } } // 默认 Servlet对应 Tomcat 的 DefaultServlet return servletMapping.getOrDefault(/ , null); }这段映射代码最大的价值在于让我彻底理解了两个问题。第一为什么要优先精确匹配因为业务系统里往往有这样的场景既配置了/test/*的统配规则又单独配置了/test/special的精确规则此时访问/test/special必须落到精确规则。第二默认 Servlet 扮演的角色是什么Tomcat 的 DefaultServlet 负责处理所有没有匹配规则的静态资源请求相当于兜底方案。3.3 Servlet 生命周期容器如何管好一个对象的生老病死Servlet 的生命周期管理是我认为整个项目最值得仔细研究的地方因为它体现出容器这类框架型代码的核心设计哲学——回调。框架代码定义一个流程骨架在特定时机调用开发者写的代码。开发者不用管流程怎么走只需要在正确的地方填入自己的实现。Servlet 的生命周期有明确的四个阶段加载与实例化容器启动或首次请求时创建 Servlet 实例初始化调用init()方法完成资源初始化服务调用service()方法处理具体请求销毁容器关闭时调用destroy()方法释放资源我的ServletContainer类里采用了懒加载策略不在容器启动时就实例化所有 Servlet而是等第一个请求到达时才加载。这个策略和 Tomcat 的load-on-startup配置形成对比——Tomcat 允许你配置 Servlet 启动时就加载但如果没配置默认也是懒加载的。public void process(Request request, Response response) { String uri request.getUri(); Servlet servlet findServlet(uri); if (servlet null) { response.sendError(404, Not Found); return; } // 懒加载第一次访问该 Servlet 时才实例化 if (servlet.getInstance() null) { servlet.init(); // 调用 init() 初始化 } servlet.service(request, response); }这里有一个很关键的细节init()方法在整个生命周期里只会被调用一次。所以我在调用init()之前必须加一个判断避免每次请求都重复初始化。这个判断在单线程模型下没有问题但是如果放到了多线程环境就会产生竞态条件——两个请求同时到达都发现 servlet 实例是 null都去执行init()。为了解决这个问题我对 init 块加了同步机制确保即使并发访问初始化也只执行一次。这个问题在后面讲线程安全时我会再展开。3.4 请求响应对象封装不直接操作 Socket 输出流在封装 Response 时我一开始偷懒直接在 Servlet 的doGet()方法里往输出流写 HTML 内容。后来发现这样设计的坏处是所有 Servlet 代码都耦合了 Socket 的细节如果换了通信层比如从 Socket 换成 NIO所有业务 Servlet 都要改。正确的做法是把输出逻辑封装在Response类里面业务 Servlet 只需要调用response.write()方法内部怎么拼 HTTP 响应头、怎么往 Socket 里写业务代码一概不用关心。public class Response { private OutputStream outputStream; public void write(String content) throws IOException { StringBuilder responseBuilder new StringBuilder(); responseBuilder.append(HTTP/1.1 200 OK\r\n); responseBuilder.append(Content-Type: text/html; charsetUTF-8\r\n); responseBuilder.append(Content-Length: ).append(content.getBytes().length).append(\r\n); responseBuilder.append(\r\n); responseBuilder.append(content); outputStream.write(responseBuilder.toString().getBytes()); outputStream.flush(); } }封装 Response 时最容易犯的一个错误是Content-Length计算错误。使用content.length()拿到的是字符个数但是响应体中实际写出去的是 UTF-8 编码后的字节数。如果内容是纯英文两者恰好一致一旦包含中文字符数和字节数就不同了会出现响应截断或者内容显示不完整的问题。正确写法必须用content.getBytes(UTF-8).length。4. 实操过程从零开始搭建项目代码4.1 配置工程环境与运行入口设计在开始写代码之前先说明一下环境和工程结构。我的实现按照 Maven 的标准目录结构来组织但为了保持简约没有引入任何第三方依赖。只需要 JDK 8 以上版本和一台安装了集成开发环境的电脑就够了。工程结构如下minitomcat/ ├── pom.xml └── src/main/java └── com/minitomcat ├── HttpServer.java ├── Request.java ├── Response.java ├── ServletContainer.java └── HttpServlet.java入口设计延续“配置文件管一切”的思路。我没有引入web.xml这种复杂的配置文件而是在一个简单的启动类里手动注册 Servlet 映射。这样做的理由是让配置和代码放在一起初学者能一眼看出“某个 URL 对应某个 Servlet”这个关系。public class Bootstrap { public static void main(String[] args) throws Exception { // 创建 Servlet 容器 ServletContainer container new ServletContainer(); // 注册 Servlet 映射 container.addServlet(/hello, new HelloServlet()); container.addServlet(/test/*, new TestServlet()); container.addServlet(/, new StaticResourceServlet()); // 启动 HTTP 服务 HttpServer server new HttpServer(8080, container); server.start(); } }Bootstrap类的职责很简单组装盛器、注册路由、启动服务。我把 Servlet 的实例化挪到了容器启动阶段这样写的好处是路由表提前固定请求来了直接查表就好省去了在process()里每次都做路由判断的额外开销。HttpServer类的核心逻辑如下public void start() throws IOException { ServerSocket serverSocket new ServerSocket(port); System.out.println(MiniTomcat started on port port); while (true) { Socket socket serverSocket.accept(); // 每个连接交给线程池处理 executorService.submit(() - handleRequest(socket)); } } private void handleRequest(Socket socket) { try { // 解析请求 Request request new Request(socket.getInputStream()); request.parse(); // 创建一个响应对象 Response response new Response(socket.getOutputStream()); // 交给容器处理 container.process(request, response); socket.close(); } catch (Exception e) { e.printStackTrace(); } }这段代码里有几处地方我特别想说明。socket.close()必须放在 finally 块里或者用 try-with-resources否则异常情况下连接不会释放时间长了会把文件描述符耗尽。线程池里的任务采用 Runnable 接口不能使用 Callable因为请求处理不需要返回值。4.2 请求解析的实现细节Request类是整个项目里最容易写错的地方也是我调试时间最长的地方。它的核心是把一个 InputStream 里的字节解析成多个成员变量。public class Request { private InputStream inputStream; private String method; private String uri; private String protocol; private MapString, String headers new HashMap(); private MapString, String parameters new HashMap(); private String body; public Request(InputStream inputStream) { this.inputStream inputStream; } public void parse() throws IOException { BufferedReader reader new BufferedReader(new InputStreamReader(inputStream)); // 解析请求行 String requestLine reader.readLine(); if (requestLine null || requestLine.isEmpty()) { return; } String[] parts requestLine.split( ); this.method parts[0]; this.protocol parts[2]; // 处理 URI 和查询参数 String fullUri parts[1]; if (fullUri.contains(?)) { String[] uriParts fullUri.split(\\?); this.uri uriParts[0]; parseParameters(uriParts[1]); } else { this.uri fullUri; } // 解析请求头 String line; while ((line reader.readLine()) ! null !line.isEmpty()) { int colonIndex line.indexOf(:); if (colonIndex 0) { String key line.substring(0, colonIndex).trim(); String value line.substring(colonIndex 1).trim(); headers.put(key, value); } } // 解析请求体POST 等场景 int contentLength Integer.parseInt(headers.getOrDefault(Content-Length, 0)); if (contentLength 0) { char[] bodyChars new char[contentLength]; reader.read(bodyChars, 0, contentLength); this.body new String(bodyChars); // 如果 Content-Type 是表单类型解析参数 parseParameters(this.body); } } }这段代码里最微妙的点是请求行解析时的空格切割。HTTP 协议要求请求行每个部分之间用一个空格分隔但是 URI 本身不能包含空格空格在 URI 里要编码成%20所以用空格切割是安全的。这个前提也解释了为什么你给 HTTP 请求传中文参数时需要对中文做 URL 编码。另一个容易忽视的细节是parseParameters()需要处理号。表单提交时空格会编码成号所以解析参数时要先把替换成空格再做 URLDecoder 解码。private void parseParameters(String queryString) { if (queryString null || queryString.isEmpty()) { return; } String[] pairs queryString.split(); for (String pair : pairs) { String[] kv pair.split(, 2); String key URLDecoder.decode(kv[0], UTF-8); String value kv.length 1 ? URLDecoder.decode(kv[1], UTF-8) : ; parameters.put(key, value); } }注意split(, 2)里的第二个参数2。如果没有这个参数当参数值里包含符号时比如密码是ab就会被错误地拆成多个部分。加上2之后表示最多拆分成两段第一个分隔符之后的所有内容都保留给 value。4.3 Thread 处理与常量池参数的选定到这步一个单线程的简易 Tomcat 已经能跑起来了。但是单线程模型的缺陷非常明显如果一个请求处理得很慢所有后续请求都会被阻塞就像只有一个窗口的银行网点前面一个人办理时间长后面所有人都在干等。我升级成了线程池模型但是线程池的参数选择也踩过一些坑。这个选择过程值得说一下因为参数配得不好即使引入线程池照样会出现各种问题。最初我配置了固定核心线程数 10最大线程数 100。测试后发现一个问题核心线程数和最大线程数之间的那部分线程在没有请求的时候也会被创建出来取决于线程池的工作队列策略导致启动后进程占了大量内存。后来改成这样的配置ExecutorService executorService new ThreadPoolExecutor( 4, // 核心线程数 16, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue(100), // 工作队列 new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(); Override public Thread newThread(Runnable r) { Thread thread new Thread(r); thread.setName(minitomcat-thread- counter.incrementAndGet()); thread.setDaemon(true); return thread; } }, new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );这几个参数分别需要考虑核心线程数 4我参考的是 CPU 核心数加一的原则。在大多数开发机上这是合理的初始值如果请求量大再调大。最大线程数 16需要权衡性能和内存占用。线程数量并不是越大越好因为每条线程都要占用内存作为线程栈而且线程切换本身也有开销。工作队列容量 100这是系统缓冲区的容量。队列满了之后新的任务会尝试创建新线程直到达到最大线程数如果最大线程数也满了就会触发拒绝策略。线程池拒绝策略选CallerRunsPolicy()这是很重要的一个决策。当系统过载时新任务不会被丢弃而是交给提交任务的线程自己执行。这样做虽然会在极端情况下阻塞业务线程但至少保证了请求不会静默丢失。线程池引入之后我注意到 Servlet 的线程安全问题也浮出水面了。ServletContainer.addServlet()方法需要在启动时被调用一次之后不能再调用。如果把addServlet()设计成运行时可调用就必须考虑并发写的竞争条件所以我刻意把路由表设计成在启动时构建完成的不可变 Map。4.4 静态资源处理让浏览器能加载图片和 CSS处理完动态请求之后我发现自己需要一个静态资源处理器不然浏览器访问 HTML 页面里的图片或者 CSS 样式表都会 404。这个需求在真实项目里太常用了Tomcat 默认就带一个 DefaultServlet 来处理。StaticResourceServlet的逻辑非常简单根据请求 URI 找到项目里的对应文件把文件内容读出来写到响应里。public class StaticResourceServlet extends HttpServlet { Override public void doGet(Request request, Response response) throws IOException { String uri request.getUri(); // 防止路径穿越攻击 if (uri.contains(..)) { response.sendError(403, Forbidden); return; } // 默认首页 if (/.equals(uri)) { uri /index.html; } Path filePath Paths.get(webapp, uri); if (Files.exists(filePath)) { byte[] content Files.readAllBytes(filePath); response.writeBytes(content); } else { response.sendError(404, File Not Found); } } }这里的安全问题是必须考虑的。如果不检查..用户访问http://localhost:8080/../conf/server.xml就能读到服务器上的任意文件这属于路径遍历漏洞在真实项目中是非常严重的风险。虽然简易版用不上这么强的安全策略但养成这个习惯对后续实战有帮助。5. 线程安全与性能考量别让容器死在并发下5.1 Servlet 是单例还是多例这是个并发问题在写这个简易 Tomcat 之前我对 Servlet 的线程安全没有特别深刻的感知。直到我用多个线程同时访问同一个 Servlet 的共享成员变量时数据出现错乱才意识到 Servlet 的实例模型对整个应用设计影响有多大。Tomcat 中 Servlet 默认是单例的。也就是说同一时刻可能会有多个线程在调用同一个 Servlet 实例的service()方法。这就意味着 Servlet 里如果定义了非线程安全的成员变量在高并发下就会出现数据错乱。public class UnsafeServlet extends HttpServlet { private int count 0; // 这是不安全的写法 Override public void doGet(Request request, Response response) throws IOException { count; response.write(当前计数: count); } }在多线程环境下这个count并非原子操作它的执行过程包含读值、加一、写回三个步骤。两个线程同时读到一个值然后各自加一写回就会导致计数丢失。正确的做法是尽量不要在 Servlet 里写可变的实例变量。如果实在需要计数可以用AtomicInteger或者加synchronized关键字同步。本质原因在于 Servlet 被容器管理着生命周期它的作用范围是整个应用而不是单个请求。请求相关的数据应该放在Request对象或者方法参数里利用线程栈隔离的特性避免并发问题。5.2 为什么用线程池而不是每请求一线程有些初学者在接触线程池之前习惯用new Thread(() - handleRequest(socket)).start()这种方式处理连接。这种做法在小规模测试时看不出什么问题但一旦并发量上来就会暴露出两个致命问题。第一线程创建和销毁的开销非常大。创建一个线程涉及操作系统内核分配线程控制块、分配栈空间销毁时要回收这些资源。如果每个请求都创建新线程系统资源会迅速耗尽。第二线程数量不可控。假设同时有 1000 个请求进来就会创建 1000 个线程每个线程默认栈空间是 1MB光线程栈就占用了 1GB 内存。更严重的是线程上下文切换的 CPU 开销会让系统响应变得极其缓慢甚至触发 OOM。线程池通过复用线程来解决这两个问题。核心线程创建后常驻任务来时直接从池子里取空闲线程执行避免了反复创建销毁的开销线程数量由参数控制超出负载的任务进入队列排队系统响应会保持稳定。5.3 实测性能数据与调优方向我写这个简易 Tomcat 后跑了一轮简单的性能测试用 ApacheBench 模拟 100 个并发请求访问一个只做字符串拼接的简单 Servlet。测试结果在单核虚拟机上大约是每秒 2000 个请求左右这个数字远低于 Tomcat 默认配置下每秒数万请求的水平。差距主要来自这几个方面第一我在解析 HTTP 请求报文时用的是BufferedReader.readLine()每次只读一行涉及字符编码转换。NIO 的ByteBuffer批量读取方式效率更高。第二每个请求一个完整的新建和销毁Request和Response对象的过程在超高并发下产生了可观的 GC 压力。第三没有启用 HTTP 持久连接。我的实现里每个连接处理完一个请求就关闭了而 HTTP/1.1 默认支持keep-alive能在一个连接上处理多个请求。少了连接复用的能力建立和断开 TCP 连接的三次握手、四次挥手开销占比非常高。对性能的提升可以做的优化包括引入 NIO 非阻塞 I/O 模型这样可以用少量线程管理大量连接实现 HTTP 持久连接对象池复用Request和Response对象。不过这些优化对于“理解原理”这个目标来说已经超出了范围。性能和并发优化本身就是一个很大的课题只要知道瓶颈在哪里就达到了认知的目的。6. 常见问题与排查技巧实录6.1 启动即报端口被占用这个问题在开发过程中最常遇到。当我把port设成 8080 启动时系统提示java.net.BindException: Address already in use: JVM_Bind。排查思路很直接先用命令找到谁占用了端口。# Windows netstat -ano | findstr 8080 # Linux / macOS lsof -i :8080常见的原因有两个一是之前启动的迷你版 Tomcat 进程没有彻底关掉或者杀进程时只杀了 IDE 的进程后台的 Java 进程还活着二是本机确实有其他程序在用 8080 端口比如另一个开发项目或者管理后台。解决方法是换一个端口或者把占用端口的进程杀掉。我一般在开发阶段会用一个不常用的端口比如 18080减少和其他开发工具的冲突。6.2 中文乱码问题这个问题的现象是浏览器请求一个返回中文内容的 Servlet 时显示出来的是乱码。排查后发现原因很简单就是字符编码不一致。浏览器发送请求时的默认编码和服务器返回响应时的编码不一致就会出现乱码。Tomcat 的 HTTP 响应头里有Content-Type: text/html; charsetUTF-8如果这个值标注的编码和实际响应的字节编码不一致浏览器就会尝试用错误的方式解码。解决思路是统一所有环节的编码在 Response 的write()方法里面设置 Content-Type 时显式指定charsetUTF-8把content.getBytes(UTF-8)换成使用指定字符集源码文件保存为 UTF-8 格式这里有一个我踩过的坑如果使用 IDE 默认的 GBK 编码保存源码编译后的 class 文件里字符串常量是 GBK 编码运行时用 UTF-8 输出到浏览器就会乱码。更稳妥的办法是在 Maven 的pom.xml里设置project.build.sourceEncoding为 UTF-8。6.3 请求体读取不完整的问题这个问题的隐蔽性很高。我写了一个登录 Servlet用表单 POST 提交数据结果服务器端的日志显示收到的用户名被截断了只拿到了几个字节。排查了半天才发现原因我使用了BufferedReader.readLine()来读取 POST 请求体。在这种情况下如果请求体的二进制内容恰好包含换行符\nASCII 码 10readLine()就会提前返回导致读取的数据不完整而最开始时问题并不明显因为普通文本内容很少包含裸换行符但这种错误一旦在特定数据下触发就会表现为随机性的数据丢失。解决方案正如前面代码里展示的那样根据Content-Length头读取指定长度的字节并且在网络流上循环读取直到读完为止。这个教训告诉我们网络协议处理里的“想当然”是最可怕的隐患格式规范里说你该读多少字节你就得严格按照字节数来读。6.4 并发下路由表被意外修改在调试线程安全时我发现一个诡异的现象某些请求偶尔会 404但大部分请求都正常。反复测试后发现是因为我在收到请求后调用了container.addServlet()方法这个动作在运行期往路由表里添加映射。当并发请求同时触发动态添加时HashMap在扩容过程中出现数据不一致导致部分路由查询失败。解决方法是明确约定路由表建立后不可变更。我使用Collections.unmodifiableMap()把 Map 包了一层任何运行期的添加操作都会抛出UnsupportedOperationException尽早暴露问题。当然真实 Tomcat 可以在运行期重新加载应用并更新映射但那是建立在复杂的并发控制机制之上的。对于简易版来说用不可变 Map 保证线程安全是最合理的取舍。6.5 Socket 连接不关闭导致文件描述符耗尽这个问题发生在压力测试阶段。压测工具发了几万个请求后操作系统提示Too many open files应用再也无法建立新连接了。排查后发现是我的handleRequest()方法在异常场景下没有关闭 Socket。正常情况下处理完请求就会走到socket.close()但如果解析请求时抛出了异常代码直接跳出方法Socket 没有关闭连接就一直停留在操作系统层面。修正方案是用 try-with-resourcestry (Socket socket serverSocket.accept(); InputStream input socket.getInputStream(); OutputStream output socket.getOutputStream()) { executorService.submit(() - handleRequest(socket)); }注意try-with-resources适合在一个方法内完成的场景。由于我用了线程池Socket 需要在子线程里用到所以不能直接在accept()的 try-with-resources 里关闭否则主线程退出 try 块时连接就已经关闭了。我在子线程任务里用独立的 try 块来保证最终关闭。6.6 问题排查通用方法论下面这张速查表是我在调试简易 Tomcat 时沉淀下来的排查清单遇到任何现象都可以对照着找方向现象可能原因排查顺序连接被拒绝服务未启动 / 端口占用1. 看控制台日志 2. 用netstat查端口 3. 尝试其他端口响应 404URL 映射错误1. 检查注册路径 2. 检查访问路径 3. 检查默认 Servlet中文乱码编码不一致1. 统一源码编码 2. 检查响应头 charset 3. 用 curl 看原始字节请求体截断Content-Length 读取错误1. 检查请求体是否按字节读取 2. 确认循环读取逻辑随机 404运行期修改路由表1. 检查是否调用addServlet2. 改成启动时注册文件句柄耗尽Socket 未正确关闭1. 检查异常分支 2. 用lsof查看连接数这套排查思路不仅适用于这个项目在做真实项目时遇到 Web 服务异常也完全可以按这个顺序来排查。7. 从手写版到真实 Tomcat之间的差距还有多远项目完成之后我拿它和真实 Tomcat 做了一次对比核心想搞清楚玩具和工业级产品差距到底在哪。第一协议支持完整度。我写的解析器只支持 HTTP/1.1 的基础报文格式真实 Tomcat 完整支持 HTTP/1.1 的所有规范包括持久连接、分块传输编码、条件请求等。第二连接处理模型。真实 Tomcat 在 8.5 版本以后默认使用 NIO 连接器它用极少量的线程管理成千上万的连接通过Selector监听就绪事件。我的简易版一个连接占用一个线程池任务本质上是 BIO 模型连接多了以后线程池会饱和。第三类加载体系。Tomcat 的类加载机制解决了多个 Web 应用在同一个 JVM 里类库冲突的问题每个应用有独立的类加载器。这个设计在简易版里完全没有体现因为我的目标只是理解核心原理。第四生命周期管理与 JMX。Tomcat 的每个组件都有标准化的生命周期管理支持启动、暂停、停止等状态转换还通过 JMX 暴露管理接口可以通过 JMX 控制台查看运行状态。第五集群和 Session 同步。生产环境经常要部署集群Tomcat 支持 session 复制、集群间通讯这些能力这些只有在真实环境中才会用到。意识到差距的下一步就是思考职业进阶路线了。如果未来真要深入容器领域值得研究的方向包括NIO 和 Netty 的网络编程模型、JVM 类加载机制、JMX 规范与实现以及 Tomcat 源码中设计模式的具体应用场景。8. 写在最后的几点实践心得项目写完之后最大的收获不是代码能力而是“理解技术”这件事本身的认知升级。之前使用 Tomcat 时遇到问题只能靠经验猜URL 访问失败可能是映射出错了响应慢可能是线程不够。但亲手写过一遍容器核心逻辑之后再遇到问题时脑子里会形成一条完整的因果链——你知道请求从 Socket 进来之后每一步发生了什么所以排查问题时不再靠猜而是能直接定位到某个环节。另一点心得是“做减法”对学习极其重要。Tomcat 的源码规模摆在那里如果目标只是理解原理从一个只保留核心功能的迷你版本入手比直接啃源码要高效得多。先搞清楚主干逻辑是什么再去阅读真实源码里对应模块理解起来会顺畅很多。最后分享一个后来在实际工作中派上大用场的技巧排查线上 Tomcat 问题时如果现象诡异比如请求卡住、响应偶发失败先去看线程池的活跃线程数和工作队列积压量往往能直接暴露问题。这个思路的形成正是从手写线程池参数开始建立起来的。技术学习这条路动手造一次轮子比读十篇源码分析都管用。