企业官网建设流程全解析

Tomcat 这玩意儿，做 Java Web 的基本绕不开。可现实里最常见的场景是：本地跑得好好的，一上服务器就报Address already in use；IDEA 里点启动，控制台刷出一屏红字，最后一行写着could not obtain connection to query metadata；项目部署上去访问是 404，日志里连个像样的提示都没有。多数人这时候的做法是百度关键词，找到一条差不多的答案，复制粘贴，重启，好了——但下次换个环境又炸，因为压根不知道这个报错是从哪一层冒出来的。

我这篇文章想干两件事。第一件，把 Tomcat 常见的报错按"出问题的层次"重新梳理一遍，从启动脚本、端口、类加载、连接池一路到 SSL 配置，讲清楚每种报错背后到底发生了什么，为什么这么解。第二件，也是我觉得更有意思的——手动写一个能跑起来的迷你 Tomcat，用ServerSocket加线程池，自己解析 HTTP 报文、自己映射 Servlet、自己加载WEB-INF下的类。写完之后你再回头看那些报错，会发现它们的位置感一下子就清晰了：ClassNotFoundException 是类加载层的事，404 是映射层的事，端口冲突是网络层的事，各归各位。

这篇内容适合谁看？正在被 Tomcat 报错折磨的运维和后端同学、想搞明白 Web 容器内部到底怎么回事的初中级开发者、以及准备给现有项目做容器替换或者调优的人。代码部分我会给完整可运行的版本，但更重要的是每一步为什么这么设计——这才是我自己踩坑之后真正记住的东西。

1. 先想清楚：Tomcat 到底替我们接管了哪些活

1.1 一个请求进来，经过了几道手

很多人对 Tomcat 的认知停留在"放 war 包的地方"。但你只要自己写过一次最原始的 Socket 服务，就会立刻明白它省掉了多少事。

一个 HTTP 请求从浏览器发出，到你的doGet方法被执行，中间至少经历了这些环节：内核把 TCP 连接交给监听端口的进程；Tomcat 的 Acceptor 线程接住这个连接，交给 Worker 线程；Worker 从 socket 上读字节流，按 HTTP 协议切分出请求行、请求头、请求体；根据请求行里的 URI，找到对应的 Host、Context（也就是你的应用）、Wrapper（也就是那个具体的 Servlet）；构造HttpServletRequest和HttpServletResponse两个包装对象；调用Servlet.service()；最后把响应对象里的状态行、响应头、响应体按协议格式写回 socket 并关闭连接。

这里面每一环都可能出错，而且报错信息分布在完全不同的地方。端口被占用是内核层直接就拒绝了；URI 找不到对应 Context 是映射层的问题；Servlet 类加载不出来是类加载器的问题。你把这条链路在脑子里画出来，排查速度至少快一倍。

1.2 为什么"手写一遍"是最快的理解方式

我在带新人的时候有个固定动作：让对方用ServerSocket写一个只返回 "hello" 的服务。写完之后再问一句"如果我要支持两个不同的路径返回不同内容呢"，他就自然开始想路由表；再问"如果我要让用户自己写类来处理请求呢"，他就自然想到接口和反射；再问"如果用户把类打包成 jar 放在某个目录下呢"，他就自然碰到类加载器。

这就是手写迷你 Tomcat 的价值——它把你平时当成黑盒的那一层，拆成了几个你能一手写完的小模块。而且这个过程不白费功夫，Tomcat 本身的架构也是这么分层的：Server→Service→Connector+Engine→Host→Context→Wrapper。你手写的版本就是它的一根简化骨架。

1.3 报错分类的底层逻辑

我把常见报错归成五大类，后面第 5 章会逐条展开：

这张表你贴在工位上，遇到红字先定位它在哪一行，比漫无目的地搜关键词高效得多。

2. 手动实现迷你 Tomcat 的整体设计

2.1 拆成三层：网络层、协议层、容器层

我在设计这个迷你容器的时候，刻意做了严格分层，因为分层本身就是为了让报错有归属。

网络层只干一件事：绑定端口，accept()阻塞等待连接，把Socket丢给线程池。它完全不懂 HTTP，也不懂你的业务。协议层负责把InputStream里的字节翻译成结构化的请求对象，再把结构化的响应对象序列化回字节。容器层则负责路由、Servlet 生命周期、类加载。

为什么非要这么分？因为分完之后，你要换实现的时候成本极低。比如网络层从 BIO 换成 NIO，容器层一行都不用改；协议层要支持 HTTP/1.1 的chunked传输，也只需要改动解析和写出这两个方法。Tomcat 的Connector和Container分离就是这个道理，只不过它做得更极致。

2.2 网络模型为什么从 BIO 起步

有人会说都什么年代了还写 BIO。但对一个用来理解原理的迷你实现，BIO 加线程池是最优解，原因有三点。

第一，代码路径清晰。一个请求一个线程，你打断点的时候能完整看到从accept到service的调用栈，不会在 Selector 的事件循环里迷失。第二，它足够支撑中等规模场景。Tomcat 直到 8.5 才默认启用 NIO，此前长期使用的 APR 和 BIO 组合在生产环境跑了十几年，说明 BIO 加合理线程池并不是不能用。第三，也是关键的一点——它让你直观感受到maxThreads这个参数到底限制的是什么。当你看到线程池满了之后新连接全部堵在accept队列里，你就永远不会再随便把maxThreads调到 5000。

提示：迷你实现用 BIO 是为了理解，生产上 Tomcat 8.5 以后默认就是 NIO 模式，IO 多路复用在连接数上万时优势明显，这一点不要混淆。

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字样。这个约束看起来很教条，但你写下去就会发现，它逼着你在正确的层次上解决问题。比如 URL 解码（把%E4%B8%AD还原成中文），它天然属于协议层，就该放在HttpParser里，而不是散落在路由查找的代码中。

3. 核心细节拆解：报文解析、路由映射与类加载

3.1 HTTP 请求解析里最容易踩的三个坑

第一个坑，BufferedReader和请求体的冲突。新手最常见的写法是new BufferedReader(new InputStreamReader(socket.getInputStream()))，然后readLine()读第一行得到请求行。这在纯 GET 请求下没问题，因为 GET 没有请求体。但一旦是 POST，你再用同一个 reader 去读 body，就会读到空——因为BufferedReader内部做了缓冲，已经把一部分 body 吃进它自己的缓冲区了，而你从InputStream直接再读，读到的是缓冲区之后的内容。

正确做法是：解析完请求头和请求行之后，根据Content-Length头，从原始的InputStream上精确读取对应字节数。这也是为什么 Tomcat 内部对ServletInputStream有严格的状态机管理——一旦你调用了getReader()，再调getInputStream()就会抛IllegalStateException。它就是在防这种读串了的情况。

第二个坑，请求头的行结束符。HTTP 协议规定是\r\n，但有些客户端或者手写的测试工具会只发\n。readLine()恰好能容忍这两种，所以手工解析时用它反而安全。但如果你自己用read()逐字节找\r\n，就得考虑兼容。

第三个坑，URI 的编码。请求行里的 URI 是经过百分号编码的，中文参数、空格、特殊符号都会变成%XX形式。加上+号在表单提交里代表空格，这两套规则混在一起，很容易解析错。我的处理顺序是：先按?切出 path 和 query，再对 query 按&切分、按=切分，最后对 key 和 value 分别做URLDecoder.decode(value, "UTF-8")。注意URLDecoder会把+也解成空格，这在 query 场景下是符合规范的。

3.2 响应格式与状态码的封装

响应写出去的时候，最容易忽略的是头部顺序和Content-Length。HTTP 响应格式是：

HTTP/1.1 200 OK\r\n Content-Type: text/html;charset=UTF-8\r\n Content-Length: 128\r\n \r\n <body>

我见过有人把Content-Length算错，结果是浏览器一直转圈等数据，直到超时。原因通常是用了Writer写字符，但在计算长度的时候算的是字符数而实际发出的是字节数。中文一个字符 UTF-8 下占三个字节，这个差值会让Content-Length偏小，浏览器收到少于声明长度的数据就会一直等。

所以在迷你实现里，我统一用ByteArrayOutputStream先在内存里把响应体字节攒好，拿到真实的字节长度之后再写Content-Length，最后一次性刷出去。这个"先攒后发"的思路和 Tomcat 里OutputBuffer的设计是一致的。

3.3 路由映射：从 URI 到 Servlet 实例

路由的本质是一个查找表。我在实现时用了最简单的方式：Map<String, MiniServlet>，key 是url-pattern，value 是单例的 Servlet 实例。这是为了简化，真实 Tomcat 里每个请求都会拿一个StandardWrapper，它管理着 Servlet 实例的单例和生命周期。

匹配规则上我先实现了精确匹配，然后补了两条：

优先级是精确 > 前缀 > 扩展名 > 默认，这一点必须和 Servlet 规范保持一致，否则同一个项目从真正 Tomcat 迁移到你的迷你容器上行为就不一样了。顺便说一句，这个优先级顺序是很多人配置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 { List<URL> 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")就能找到应用私有的类，而不会跑到系统的 classpath 里去找。理解了这几十行代码，你再看 Tomcat 那些NoClassDefFoundError，思路会清楚很多：要么是 jar 没进WEB-INF/lib，要么是同一个类被两个加载器加载了，导致类型转换失败。

4. 完整实操：写一个能跑静态资源和 Servlet 的迷你容器

4.1 环境准备与工程搭建

我用的是 JDK 17 加 Maven 的极简配置。为什么选 17 而不是 8？因为URLClassLoader在 9 以后的模块化环境下有一些限制，但用于加载普通 jar 依然没问题，而且 17 的Socket和字符串处理 API 更顺手。如果你所在的项目必须用 JDK 8，代码也能原样跑，只是readAllBytes这类方法要换成循环读取。

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(); } } }

这里有个细节值得说：try (socket; in; out)这种写法会在代码块结束时自动关闭所有资源。很多人手写 HTTP 服务时忘了关 Socket，跑压测的时候几百个连接瞬间把文件句柄耗尽，报Too many open files。生产上的 Tomcat 有连接池和空闲回收，手写版本就必须靠try-with-resources兜底。

线程池固定 50 个线程也是一种取舍。真实场景应该做成可配置，并且要意识到：accept到线程池之后，如果池子满了，任务会进无界队列，连接会一直堆着不处理。生产上更稳妥的做法是给队列设个上限，满了就快速返回 503，这也是 Tomcat 的acceptCount在干的事。

4.3 请求与响应对象的实现要点

public class MiniRequest { private String method; private String uri; private String path; private String protocol; private final Map<String, String> headers = new HashMap<>(); private final Map<String, 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把字节写进内存缓冲，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;charset=UTF-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 头部按规范只允许 ASCII 字符，用ISO_8859_1保证每个字节原样传输。如果用 UTF-8 编码头部，遇到非 ASCII 字符会变成多字节，客户端解析头部就会错位。

4.4 静态资源处理与 404 兜底

静态资源处理的价值在于：它让整个容器看起来像个真东西，你可以在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("<h1>404 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())); } }

有一个安全问题必须在手写版本里就养成习惯：路径穿越。如果用户请求/../../etc/passwd，直接拼接路径就会读到系统文件。真实 Tomcat 通过canonicalPath校验来解决。我在迷你版里加了一句规范化检查，这对理解 Tomcat 的安全加固很有帮助。

顺便说 JSP。我最初也想在迷你版里跑 JSP，但真正的 JSP 需要先编译成 Servlet 再加载执行，工作量翻倍。我选择的做法是：把 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 返回的内容，整个链路就通了。

验证顺序我建议这样走：先静态资源，再精确匹配的 Servlet，再带参数的 POST，最后中文参数。每一步都通过再往下走，出问题的时候定位范围就很小。我当初第一次写的时候，POST 中文参数一路乱码，最后发现是Content-Length用的是字符数而不是解码后的字节数，导致 body 读少了一半，UTF-8 多字节字符被截断。这类问题在真正的 Tomcat 里之所以不常见，就是因为它的OutputBuffer和编码器已经处理好了这些边界。

5. Tomcat 常见报错逐条排查实录

5.1 启动类报错：端口、环境变量与脚本问题

java.net.BindException: Address already in use是出现频率最高的一条。它的意思非常字面：端口已经被别的进程占了。Linux 下排查用lsof -i:8080或者netstat -tunlp | grep 8080，Windows 下用netstat -ano | findstr 8080拿到 PID，再去任务管理器或者taskkill /PID xxx /F处理。有时候你确认没有 Java 进程占着，那就要考虑是不是之前的 Tomcat 没杀干净，用ps -ef | grep tomcat过一遍再用kill -9清理。还有一种隐蔽情况：TIME_WAIT状态的连接还在占用端口，这时候要么等一会儿，要么在Connector上配SO_REUSEADDR。

Neither the JAVA_HOME nor the JRE_HOME environment variable is defined这条出现在 Windows 下双击startup.bat闪退的场景。原因是setclasspath.bat在启动时找不到 JDK 路径。解决方式是设好JAVA_HOME环境变量，指向 JDK 根目录而不是bin目录。如果你机器上有多个 JDK，想让 Tomcat 用指定的那个（比如 JDK 17 而系统默认是 8），可以在setclasspath.bat开头显式加一行set JAVA_HOME=D:\jdk-17，这样只影响这个 Tomcat 实例，不动全局环境变量，多个 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.jsp，Tomcat 不会自动帮你找，直接 404。而且欢迎页的查找是顺序匹配的，列表越靠前的优先级越高，把index.html放在index.jsp前面，会导致 JSP 永远不生效——明明文件在，就是不显示。

打包方式也影响结果。war 包放进去 Tomcat 会自动解压，但如果你同时保留了旧的解压目录，Tomcat 可能用的是旧目录里的内容。我踩过的坑是：更新 war 包忘了删对应的解压目录，改了半天代码发现没生效，最后发现跑的是老目录。稳妥做法是停掉服务、删掉 war 包和解压目录、再放新包。

5.3 类加载与依赖类报错

java.lang.ClassNotFoundException和NoClassDefFoundError看着像，含义不同。前者是主动加载时没找到，通常是Class.forName或者容器扫描时抛的；后者是编译期存在、运行期找不到，常常意味着类在加载过程中失败了，比如静态代码块抛了异常，或者类被两个不同的加载器加载了。

排查的第一个动作是确认 jar 的位置。项目依赖必须是WEB-INF/lib下的 jar，或者WEB-INF/classes下的 class 文件，放在 Tomcat 的lib目录里虽然也能用，但那是容器级别的类加载器，多个应用会互相干扰，强烈不建议。第二个动作是看有没有版本冲突。两个不同版本的同一个包同时出现在WEB-INF/lib里，Tomcat 按文件名排序加载，先加载的生效，行为就变得不可预期。

我整理过一个快速判断表：

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 参考配置 initialSize=0 minIdle=1 maxActive=20 validationQuery=SELECT 1 testWhileIdle=true connectionTimeout=3000

提示：maxActive不要拍脑袋设大。数据库端有最大连接数限制，应用侧配得再大，超过数据库限制照样连不上，而且会掩盖真正的慢 SQL 问题。

5.5 编码、SSL 与安全加固相关报错

中文乱码分三种位置，处理方式完全不同。请求参数乱码，看Connector上的URIEncoding，Tomcat 8 以后默认就是 UTF-8，如果被显式改成了ISO-8859-1，中文参数就会乱；同时确认conf/server.xml里 Connector 的useBodyEncodingForURI设置，它决定 POST body 的编码是否也应用到 URI 上。响应乱码看Content-Type里的charset，或者response.setCharacterEncoding。控制台和日志乱码看 JVM 启动参数里的-Dfile.encoding=UTF-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。少配任何一个，握手都会失败，而且不同配置错误对应的报错信息差别很大，建议一项一项对照着配。如果项目对加密算法有特定合规要求，通常需要引入对应的加密套件实现并调整 Connector 的协议配置，这部分建议照着中间件厂商的官方文档逐项核对，不要凭经验猜。

关于安全加固，有三件事值得每年做一次：把 Tomcat 升到当前维护的最新稳定版；删掉webapps下所有用不到的默认应用，尤其是管理端；把管理端口的访问来源限制在可信网段。这些动作成本极低，但能挡掉绝大多数自动化扫描。

6. 调优要点与容器替换的取舍

6.1 Connector 与 JVM 的关键参数

Connector上真正需要关注的参数不多，我列几个最常动的：

调maxThreads的正确方式是压测，不是抄别人的数字。线程数加大的收益是有上限的，因为下游的数据库连接池、外部接口都有承载极限。我见过把maxThreads调到 2000 结果数据库连接池只有 50，最后瓶口全卡在数据库上，线程全在等连接，内存反而被线程栈撑爆。

JVM 层面，堆大小建议-Xms和-Xmx设成一样，避免运行期扩容带来的停顿。元空间设个上限，-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，防止动态生成类太多把内存吃光。垃圾回收器在 JDK 8 上可以用 G1，JDK 17 上直接用默认的就行，没必要折腾。部署时在setenv.sh（Linux）或者setenv.bat（Windows）里配置这些参数，这样升级 Tomcat 的时候参数不会丢。

6.2 内嵌容器的替换思路

现在越来越多项目用 Spring Boot 内嵌容器，不再单独部署 war。内嵌场景下换容器比传统部署简单得多，本质上就是换一个 starter 依赖。比如要换成 Undertow，先在 web starter 里排掉 Tomcat，再引 Undertow：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-undertow</artifactId> </dependency>

换 Jetty 也是同样的套路，把 artifactId 换成spring-boot-starter-jetty即可。需要注意的坑有两个：一是有些代码直接依赖了 Tomcat 特有的类，比如org.apache.catalina.*下的工具类，换容器后编译不过，得先清理掉；二是配置属性的前缀会变，从server.tomcat.*变成server.undertow.*，参数名也不一样，迁移时要逐项对应。

如果项目有使用其他中间件产品的需求，替换思路类似——多数商业中间件都会提供适配 Spring Boot 的 starter 或者迁移文档，关键是先确认它对 Servlet 规范的兼容程度，以及是否有用到的 Tomcat 私有 API。这类替换我建议先在测试环境完整跑一遍回归，不要上来就改生产，因为容器差异往往体现在一些边缘行为上，比如 Cookie 的默认属性、URL 编码的处理细节、静态资源的缓存头，这些平时不显眼的地方最容易出事。

6.3 我踩过的几个坑

第一个是 IDEA 里配置 Tomcat 运行配置。不同版本的菜单路径会变，但核心永远是三件事：指定 JDK、指定服务器安装目录、在 Deployment 里添加 Artifact。如果启动后报 404，八成是 Artifact 的上下文路径配的是/还是/项目名没对上，去看运行配置里的 Application context 那一栏。另外新版 IDEA 里有些配置项挪到了Settings的Build Tools下，找不到的时候直接在设置里搜 "Tomcat" 比翻菜单快。

第二个是热部署的错觉。改了 Java 代码点重新部署，有时候改动没生效，原因是 classes 没有重新编译或者输出目录指向了旧的路径。最稳的做法是 Build 之后再 Run，不要依赖 IDE 的自动编译。

第三个是日志级别。排查问题时把conf/logging.properties里的级别从INFO调到FINE，能看到大量内部状态信息，比如类加载过程、URL 匹配过程。问题解决后记得调回来，否则日志文件会迅速膨胀，磁盘被写满又是另一个故障。

我个人在实际操作中的体会是，Tomcat 的问题十有八九不是 Tomcat 本身的问题，而是环境、依赖、配置这三者之间的错位。所以排查时别急着改配置，先把报错链条完整读一遍，找到它落在哪一层，再动手。手写一遍迷你容器之后，我对这条链路的感知明显变强了——现在看到报错，第一反应不再是搜关键词，而是先问自己：这是网络层、协议层，还是容器层的事？