Tomcat 7.0.103 Windows部署配置与高频排错指南

简介：apache-tomcat-7.0.103-windows-x64.zip 是适用于 Windows 64 位系统的 Tomcat 7 免安装发行版，面向 Java Web 开发者与运维人员，解决本地快速搭建 Servlet/JSP 运行环境、调试 Web 应用或部署测试项目的需求。压缩包解压后即可使用，无需额外配置环境变量，适合初学 Tomcat 与有快速上线需求的开发者。资源共 648 个文件，压缩后约 10.38MB，核心文件类型包括 100 余个 class 与 70 余个 java 源码文件，可对照学习请求处理流程；大量 html、jsp、jspx 等构成默认 Web 应用与示例页面；30 个 jar 包提供运行期依赖；xml、properties、dtd、xsd 负责容器与上下文配置；bat、sh 脚本用于 Windows/Linux 下的启动与关闭。目前已有 573 人学习下载。包内目录结构完整，bin、conf、lib、webapps 一应俱全，附带 release-notes 与 license 文档，便于查阅版本特性与授权信息。直接使用 startup.bat 即可启动服务，是部署 Java Web 项目、分析 Tomcat 内部机制或进行二次开发的实用基础资源。

1. Tomcat 7.0.103 的定位：Windows x64 上最后一个 7.x 安装包，别急着升版

看到 tomcat-7.0.103-windows-x64.zip 这个名字，熟悉 Java Web 的人都知道，7.x 分支到这里就收尾了。我手里有个老项目，虽然跑在 Servlet 3.0 规范上，但自定义标签库和 JSP 片段写法比较老，换到 8.5 之后页面渲染直接翻车，换回 Tomcat 7 才稳定。这个安装包能解决的事情很具体：给遗留应用一个不挑 JVM 参数的运行容器，给刚学 Servlet/JSP 的人一个免安装、解压就用的学习环境。需要提醒的是，它不是最新技术，但它是 7.x 的最终版本，很多生产环境选它就是看中“最后版”的稳定性和兼容性。

2. 解压与 JDK 配对：先用三步跑起来，再确认版本边界

2.1 为什么选 7.0.103：Servlet 3.0 是版本边界

Tomcat 7 对标的是 Servlet 3.0、JSP 2.2、EL 2.2。如果你的项目里大量使用 @WebServlet、@WebListener 这类注解配置，Tomcat 7 能完全支持。如果项目用了 JSTL 1.2 这类老标签库，放在 7.0.103 上没有任何兼容问题；但上了 8.5 以后，部分老标签库的 jar 包会跟新 Jasper 编译器的常量池逻辑发生微妙冲突，页面报 JasperException 的几率直接变大。这个现象不绝对，但我在两个项目里都撞上过。

从 JDK 支持角度讲，Tomcat 7.0.103 官方明确支持 Java 6 及以上，我实测最稳的是 JDK 7/8。JDK 8 的字符串常量收紧和 Tomcat 7 的 JSP 编译器配合良好。JDK 11 以及更高版本上，Tomcat 7 虽然偶尔能启动，但底层类加载模块访问权限完全变了，JSP 编译阶段经常抛 ClassNotFoundException，非要硬上的话要做好反复调试的准备。所以选型就这么定了：如果你不能升级到 Tomcat 8.5 且不想动代码，7.0.103 就是你最后的稳定基地。

这里说一句大实话：选 7.0.103 不是因为它的性能比 8.5 强，而是因为你要复现的旧环境可能就是这一套。性能瓶颈通常不在容器本身，而在数据库、连接池和不合理的业务代码。升级容器之前先问自己：代码经过压测验证没有，升级后的回归成本能不能接受。新版虽好，老项目不是非升不可。

在 Windows 上使用 Tomcat 7.0.103 还有一个额外优势：zip 包解压后没有任何注册表残留，想删就直接删文件夹，切换版本方便。我自己习惯把不同版本的 Tomcat 单独放在一个 env 目录，比如 D:\env\tomcat-7.0.103、D:\env\tomcat-8.5.xx，用哪个就把 CATALINA_HOME 指到哪个，这样最直观，也能随时回滚。

2.2 三步启动：JAVA_HOME、CATALINA_HOME 与 startup.bat

Tomcat 7 在 Windows 上不需要安装，但也不能直接双击 startup.bat 就万事大吉。第一步，装好 JDK；第二步，配置 JAVA_HOME；第三步，解压 Tomcat 后启动。如果机器上有多个 JDK，我一般不在系统环境变量里全局改，而是写一个 run.bat 放在 Tomcat 的 bin 目录旁边，每次双击它，避免影响其他项目。

set "JAVA_HOME=D:\env\jdk8" set "CATALINA_HOME=D:\env\tomcat-7.0.103" cd /d "%CATALINA_HOME%\bin" startup.bat

这段脚本的逻辑很简单：

• JAVA_HOME 必须指向 JDK 的根目录，不是 D:\env\jdk8\bin，也不是 jre 目录。startup.bat 会通过 setclasspath.bat 检查这个变量，找不到就报错退出。
• CATALINA_HOME 是 Tomcat 解压后的根目录，包含 bin、conf、lib、webapps 这些子目录。startup.bat 只有在 CATALINA_HOME/bin 目录下执行时才能稳定工作。
• cd /d 是为了把当前目录切换到 bin，避免在别的路径下启动时相对路径定位错误。

启动后不建议马上去浏览器，先在命令行窗口观察有没有异常。正常情况下最后会看到 Server startup in [xxx] milliseconds，这句话出现前窗口不要关。如果窗口一闪而过，说明启动脚本在某一步失败，按第 4 章的方法排即可。

参数方面需要注意一个细节：startup.bat 本身不负责设置 JVM 内存，它只是调用了 catalina.bat start。真正设置堆内存、编码的位置是 CATALINA_OPTS，这个参数我放在 5.3 节里详细讲，这里先知道有这一层关系就行。新手常见误区是把 JAVA_OPTS 写在系统环境变量里，结果 Tomcat 确实读到了，但 stop 脚本也会带着这些参数运行，偶尔会出现停止时加载类失败的现象。

2.3 启动成功后看什么：catalina 日志与 work 目录

判断 Tomcat 是否成功，最可靠的方式不是看欢迎页，而是看 logs 目录下的 catalina.日期.log。Windows 上默认日志路径：

type "%CATALINA_HOME%\logs\catalina.2025-01-01.log"

如果日志里出现 LifecycleException 或 Address already in use，说明端口被占用或 context 配置有问题。如果日志最后一行有 INFO: Server startup，说明容器已经完成初始化。注意：Tomcat 7 的日志文件按天滚动，服务运行中跨天的话要看新生成的日志文件，不要盯着旧的看。

logs 目录里还有 localhost.日期.log，这个文件专门记录 JSP 编译和 Web 应用的异常。页面访问报 500，但 catalina 日志里没有实质内容时，去翻 localhost 日志，那里往往藏着 Unable to compile class for JSP 的完整异常栈。这是我排错时第一个会开的地方，比在页面上猜高效得多。

work 目录同样值得关注。Tomcat 首次访问 JSP 时会把它编译成 .java 和 .class 文件，存放在 work/Catalina/localhost/应用名/org/apache/jsp 下面。如果你发现修改了 JSP 但页面没变化，检查 work 目录下对应的 .class 文件时间戳是否更新；如果没有更新，说明 Tomcat 根本没有重新编译，把 work/Catalina 整个删掉再重启即可。我习惯把 work 目录当作 Tomcat 的缓存目录，遇到页面不刷新，先清 work，再刷新，九成能解决。

关闭服务时，不要直接关掉 startup 弹出的黑窗口。黑窗口只是控制台，真正的进程是后台运行的 java 进程，直接叉掉容易留下半死状态的端口监听，下次启动报端口占用。正确关闭方式：

cd /d "%CATALINA_HOME%\bin" shutdown.bat

shutdown.bat 通过 TCP 8005 端口向 Tomcat 发送 SHUTDOWN 指令，前提是 server.xml 里 Server port 没有被改动。如果改过 Server port，这里的指令端口也要同步改，两边不一致时 shutdown.bat 会超时无响应。这个细节比较冷门，但出现了就很烦人。

2.4 bin 目录脚本分工与目录结构：哪些能删，哪些要留着

解压后你会看到 bin、conf、lib、logs、temp、webapps、work 这几个目录，它们各自承担不同职责。bin 下重点认识五个文件：startup.bat 负责启动，shutdown.bat 负责关闭，catalina.bat 是核心脚本，service.bat 用来注册 Windows 服务，tomcat7w.exe 是服务安装后的图形配置工具。很多人搞混 startup.bat 和 catalina.bat，其实前者只是后者的一个薄封装，手动调试时直接用 catalina.bat run 更方便，因为日志会直接打在当前窗口，不会有黑匣子一样的感觉。

conf 目录是 Tomcat 的配置文件集。server.xml 定义端口、Host、Connector；web.xml 是全局默认配置，应用内 WEB-INF/web.xml 会覆盖它；context.xml 是全局 Context 默认值；logging.properties 控制日志输出格式和编码。lib 目录存放 Tomcat 运行时的 jar 包，如果你需要给应用加 JDBC 驱动，常见做法是把数据库驱动 jar 放到 lib 下，而不是一股脑丢进应用的 WEB-INF/lib。logs 目录记录运行日志，temp 目录存放临时文件，work 目录保存 JSP 编译产物，这两个都可以清空，但 logs 目录建议保留，排错时还要翻。

3. server.xml 三个必改项：端口、URIEncoding、应用路径

3.1 端口占用：先查 PID，再改 Connector

Tomcat 默认 HTTP 端口是 8080，但 8080 经常被其他程序占用。启动失败时，日志会提示 Exception initializing connector 和 Address already in use: JVM_Bind，意思很明确。先在命令行确认谁占了端口：

netstat -ano | findstr :8080

输出中最后一位是进程 PID。可以打开任务管理器确认这个进程能不能停；如果不确定这是谁，最好不要乱杀。更安全的做法是把 Tomcat 的端口改掉。打开 conf\server.xml，定位到以下节点：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

将 port="8080" 改为 port="8081"，保存后重启。这里几个参数的作用分别是：

• protocol="HTTP/1.1"：指定 HTTP 协议处理器，Tomcat 7 默认用 BIO/NIO，性能要求不高时可以默认不动。
• connectionTimeout="20000"：建立连接后等待读取请求的毫秒数，是超时兜底参数，不是 20 秒后一定断。
• redirectPort="8443"：当请求是 HTTP 但资源要求 HTTPS 时，Tomcat 会把它重定向到 8443 端口，一般配合 SSL 配置使用。

改完端口后，程序里所有绝对 URL 都要跟着变。如果应用里写死了 http://localhost:8080，那么新端口下部分重定向请求会失效。这也是我把端口改动放在部署前做而不是部署后做的主要原因：先统一基础配置，再丢 WAR 包，后头不用反复排查。

3.2 URIEncoding：中文参数乱码的高发地带

用浏览器访问 index.jsp?name=%E5%BC%A0%E4%B8%89，Tomcat 7 默认按照 ISO-8859-1 解析 URL 中的参数。Windows 中文环境下，后端 request.getParameter("name") 返回的就是乱码，因为浏览器发送的 UTF-8 字节被错误地按单字节字符集解码了。这个问题只靠 JSP 页面设置编码解决不掉，必须改 Connector。

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" useBodyEncodingForURI="true" />

URIEncoding="UTF-8" 告诉 Tomcat 用 UTF-8 解码 URL 里的参数，覆盖默认的 ISO-8859-1。useBodyEncodingForURI="true" 让 URL 参数的编码跟随请求体编码，如果你在 JSP 里设了 contentType，POST 请求的 body 会按那个编码解码，加上这个选项后，GET 参数也采用同样编码，避免 GET 和 POST 行为不一致。

POST 表单乱码则是另一个源头。如果表单页面本身是 GBK 编码，但后端读取用 UTF-8，那不管 server.xml 怎么改都会出问题。我的习惯是页面文件统一用 UTF-8 保存，JSP 顶部加一行：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

这样 response 输出为 UTF-8，request 读取表单时也会参考 content type 中声明的字符集。Tomcat 7 里 POST 表单如果不显式设置，默认按 ISO-8859-1 读，所以这条 pageEncoding 往往不是装饰，而是必需项。如果你用 Filter 统一设置了 request.setCharacterEncoding("UTF-8")，也可以，但注意 filter 必须在第一个执行，且设置后不能再被其他 filter 覆盖。

3.3 应用部署：WAR 包、解压目录与 ROOT 路径

把 WAR 包放进 webapps 目录，Tomcat 启动时会自动解压。以 myapp.war 为例，它会生成 webapps/myapp 目录，访问地址是 http://localhost:8080/myapp/。如果想通过根地址访问应用，把 WAR 文件名改成 ROOT.war，访问地址就是 http://localhost:8080/。Tomcat 7 默认把根应用映射到 ROOT 目录，这一点在 conf/web.xml 的 welcome-file 里也有体现。部署时一个实际存在的坑：更新 WAR 包前如果不删掉旧解压目录，Tomcat 可能继续读取旧目录里残留的 class。常见做法是写一个部署脚本：

@echo off set "CATALINA_HOME=D:\env\tomcat-7.0.103" call "%CATALINA_HOME%\bin\shutdown.bat" rmdir /s /q "%CATALINA_HOME%\webapps\myapp" copy /y myapp.war "%CATALINA_HOME%\webapps\" call "%CATALINA_HOME%\bin\startup.bat"

脚本逻辑不复杂，但三个动作都不容省略：

• shutdown.bat 先停服务，避免文件被占用导致复制失败。
• rmdir /s /q 删除旧解压目录和旧 class，防止热加载读到过期字节码。
• copy /y 把新 WAR 放进去，然后启动。

如果你只想临时验证一个 WAR 能不能解压，也可以不重启整个 Tomcat，直接把它丢进 webapps 目录，Tomcat 默认扫描到新 WAR 会触发自动部署。但这种部署方式不受控，生产环境我一般不依赖它。Context 的自动部署开关其实是 Host 元素上的 deployOnStartup 和 autoDeploy 两个属性，默认都是 true；要完全关闭就在 server.xml 里显式设置。

提示：改了 server.xml 或部署了 WAR 包之后，一定要去 localhost 日志里看有没有部署成功记录，而不是只看页面是否可访问。Tomcat 7 对目录结构敏感，一个错误顺序可能引发后续多个应用解析失败。

3.4 手工配置 Context 的另一种部署方式：docBase 指向外部目录

如果你的应用代码放在 Tomcat 之外，比如 D:\apps\myapp，不想复制进 webapps，可以使用 Context XML 描述符。路径是 conf\Catalina\localhost\myapp.xml，文件名就是访问路径。内容很简单：

<Context docBase="D:\apps\myapp" reloadable="false" />

这段配置的含义：docBase 指向应用实际所在目录，Tomcat 从外部目录加载应用，webapps 下不会出现解压副本。这个方式的优点是更新代码时可以直接替换外部目录里的 class，不用把整个 WAR 重新复制进去；缺点是目录权限和相对路径容易写错，一旦 docBase 指向的路径不存在，Tomcat 会静默跳过部署，在日志里留下一个无法访问的 Context。

当需要同时使用外部应用和默认 ROOT 应用时，要额外注意 Context 名与 WAR 名不能冲突。如果 conf\Catalina\localhost 下已经存在 myapp.xml，再往 webapps 放 myapp.war，部署不一定会按你想的方向走，一般建议只保留一种部署方式，不要混用。

4. 启动失败与乱码排查：五个高频问题、原因和处理参数

4.1 双击 startup.bat 窗口一闪而过

现象：双击 bin\startup.bat，黑色窗口闪一下就消失，Tomcat 没起来，也没有任何报错窗口。

原因：启动脚本执行期间发生异常，窗口被自动关闭。最常见的触发点是 JAVA_HOME 不存在、指向了 JRE、CATALINA_HOME 路径带空格且未加引号。Tomcat 7 的 setclasspath.bat 会检查 JAVA_HOME 或 JRE_HOME，两者都找不到时就打印错误并退出。双击方式会把错误信息直接吞掉，所以特别难排查。

解决：打开命令行，手动执行：

cd /d D:\env\tomcat-7.0.103\bin set "JAVA_HOME=D:\env\jdk8" set "CATALINA_HOME=D:\env\tomcat-7.0.103" startup.bat

这次错误会留在窗口里。看到 Neither the JAVA_HOME nor the JRE_HOME environment variable is defined，说明 JDK 配置不对；看到 The CATALINA_HOME environment variable is not defined correctly，检查目录名是否拼错。确认 JDK 安装路径时，可以直接看 D:\env\jdk8\bin\java.exe 是否存在。另有一种情况是 Java 版本过高导致 bootstrap 类加载失败，比如 JDK 17 下启动 Tomcat 7 会在日志里出现 java.lang.UnsupportedClassVersionError，此时不如直接换 JDK 8。

4.2 修改了 Java 代码，页面却始终是旧逻辑

现象：重新编译并替换了 WEB-INF\classes 下的 .class 文件，重启 Tomcat 后访问页面，行为仍是修改前的结果，或者在重启后报 NoClassDefFoundError。

原因：Tomcat 7 对 WEB-INF\classes 下类的热加载依赖 reloadable 配置，默认情况并不保证每次文件变更都重新加载；另一个更隐蔽的因素是 work\Catalina 下保留了 JSP 对应的编译 class，旧版本被反复复用。

解决：先停 Tomcat，清理 work 缓存，再启动：

rmdir /s /q "%CATALINA_HOME%\work\Catalina"

这个目录是 Tomcat 存放 JSP 编译产物的位置，删除后首次访问会重新编译。同时检查 conf\server.xml 里 Host 或 Context 的 reloadable 参数。开发环境可以设 reloadable="true"，这样 WEB-INF\classes 内容有变化时 Tomcat 会自动重新加载应用；生产环境保持默认 false，因为监视文件变化会引入额外 IO 开销，且自动重载过程中出现异常，应用可能处于不可用状态。我的一般策略是本地调试开 reloadable，测试环境不开，完全靠重启保证状态一致。

4.3 日志出现 OutOfMemoryError: PermGen space

现象：应用运行一段时间后，页面无响应，日志里出现 java.lang.OutOfMemoryError: PermGen space，重启后短暂恢复，过两天又复现。

原因：JDK 7 及更早版本把类的元数据放在 PermGen 区，JSP 数量多、反复编译、热部署频繁时，PermGen 占用持续增长，最终撑爆。Tomcat 7 常年在运行期动态生成类，所以这个错误在它身上特别常见。

解决：在 bin\setenv.bat 中设置 JVM 参数。setenv.bat 默认不存在，手动创建后，startup.bat 和 catalina.bat 会自动读取：

set "CATALINA_OPTS=-Xms256m -Xmx512m -XX:MaxPermSize=256m"

这里把参数写进 CATALINA_OPTS 而不是 JAVA_OPTS，原因是有部分启动/停止脚本也会读 JAVA_OPTS，而 CATALINA_OPTS 只作用于 Tomcat 主进程。如果你用的是 JDK 8，PermGen 已被 Metaspace 替代，参数需要换成：

set "CATALINA_OPTS=-Xms256m -Xmx512m -XX:MaxMetaspaceSize=256m"

注意 Metaspace 默认是系统可用内存，不设上限时遇到内存泄漏也不容易第一时间暴露。我通常会把 MaxMetaspaceSize 写出来，让问题尽早浮现，然后定位是哪个类重复加载导致泄漏，而不是等整台机器内存耗尽。

4.4 页面和后台中文全部变成问号

现象：JSP 页面显示中文正常，但表单提交到后台再输出中文时变成问号；或者直接访问带中文参数的 URL，后台取到的内容不是预期值。

原因：三处编码不一致。文件本身不是 UTF-8，web.xml 或 JSP 没有声明 pageEncoding，server.xml 里 Connector 没有配置 URIEncoding。Tomcat 7 默认按 ISO-8859-1 解码 URI，这是历史上 Windows 中文环境最容易踩的坑。

解决：统一三处设定。第一，JSP 文件用 UTF-8 保存，顶部写全 pageEncoding；第二，server.xml 里加 URIEncoding="UTF-8" 和 useBodyEncodingForURI="true"；第三，如果 Tomcat 输出到控制台的日志乱码，在 conf\logging.properties 中加一行：

java.util.logging.ConsoleHandler.encoding = UTF-8

控制台乱码很多时候不影响页面业务，但会干扰日志阅读，我把它也归进编码统一排查项。实际项目里如果还用了数据库连接，JDBC URL 上也建议追加 characterEncoding=utf8，否则数据库读出来的中文同样会乱。整条链路从浏览器到 Tomcat、再到数据库，任何一环断掉都会表现为同一个现象，所以排查顺序是从前往后逐层验证。

4.5 WAR 包放进 webapps 后没有自动解压，访问 404

现象：把 test.war 复制到 webapps 目录，等待几分钟后 webapps 下没有 test 目录，访问 http://localhost:8080/test/ 返回 404。

原因：Host 的 autoDeploy 或 deployOnStartup 被改为 false；或者应用名与包名不一致时，Tomcat 因为 Context 路径冲突拒绝部署；也可能是 WAR 包本身不是标准 zip 格式，扩展名虽然是 .war，但压缩工具破坏了结构。Tomcat 7 扫描到损坏的 WAR 会在 localhost 日志中报 Cannot expand 或 Deployment error。

解决：先用解压工具检查 WAR 内容，确认 WEB-INF\web.xml 位于包根目录下；再看 logs\localhost.日期.log 里的部署记录。临时排查可以只做一件事：

jar tf test.war | findstr "WEB-INF\web.xml"

有输出说明包结构正常。如果包没问题，手动在管理界面或 Context 配置里指定路径，而不是只依赖自动扫描。Tomcat 里 Context 的部署方式有三种：把 WAR 放在 webapps 自动部署、在 conf\server.xml 的 Host 里配置 Context、在 conf\Catalina\localhost 下放 XML 描述文件。第三种优先级最高，也最灵活，但文件里 docBase 写错时，自动部署会失效。我最后都会回到最简单可靠的方式：停 Tomcat、删旧目录、放 WAR、启动，虽然多花几十秒，但能避免很多玄学问题。

5. 服务化与远程访问：把 Tomcat 注册成系统服务，并放通防火墙

5.1 安装为 Windows 服务：不再依赖开机后手动点脚本

如果 Tomcat 部署在 Windows 服务器上，重启机器后没人去点 startup.bat，就需要把它装成 Windows 服务。Tomcat 7 自带 service.bat，安装命令：

cd /d D:\env\tomcat-7.0.103\bin service.bat install MyTomcatService net start MyTomcatService

MyTomcatService 是服务显示名，可以随意定义，只要不与系统已有服务重名。安装完成后，打开服务管理器，把启动类型改为自动，机器重启后 Tomcat 就会自己起来。service.bat 本质是利用 Tomcat 自带的 procrun 包装器，把 java 进程作为服务运行。卸载服务时用：

service.bat remove MyTomcatService

注意：如果 JAVA_HOME 没配置，service.bat install 会报错或生成一个无法启动的服务。建议安装前先执行 java -version 确认命令可用。服务安装完成后，内存参数的修改方式跟手动启动不完全一样，我习惯在 tomcat7w.exe 里改，图形界面更直观。

5.2 防火墙与监听地址：本地能访问、外部连不上的原因

服务起来后，其他电脑访问 IP:8080 会超时。第一反应不是怀疑 Tomcat，而是先看监听地址：

netstat -ano | findstr :8080

如果结果里有 127.0.0.1:8080 或只监听了本机回环地址，说明 Connector 被配置成仅本机访问。检查 server.xml，确保 Connector 没有写死 address="127.0.0.1"，或者显式设置允许所有接口：

<Connector port="8080" protocol="HTTP/1.1" address="0.0.0.0" connectionTimeout="20000" redirectPort="8443" />

address="0.0.0.0" 表示监听所有网卡地址，外网可以通过服务器公网 IP 或内网 IP 访问。接下来是 Windows 防火墙，Tomcat 默认不自动添加入站规则，手动放行端口：

netsh advfirewall firewall add rule name="Tomcat8080" dir=in action=allow protocol=TCP localport=8080

这个命令把 TCP 8080 端口的入站流量放行。注意，如果你的环境使用云服务器，还需要在云平台的安全组里放行该端口，这个步骤与 Tomcat 无关，但经常是服务起好了外部仍访问不到的原因。我排查时会把整条链路拆成三层：本机 curl 测 Tomcat，局域网内另一台机器测防火墙，公网再测安全组。哪一层通了，就知道问题在哪一层。

5.3 服务模式下怎样配置 JVM 参数

服务模式下的内存参数不建议写在 catalina.bat 里，因为服务启动不经过命令行脚本。常见做法是使用 bin 目录下的 tomcat7w.exe：

tomcat7w.exe //ES//MyTomcatService

打开图形界面后，切到 Java 选项卡，能看到 Initial memory pool、Maximum memory pool 和 JVM 参数输入框。直接把 -Xms 和 -Xmx 填进去即可，不需要加双引号。Java 选项卡里每一项都有默认值，默认初始堆可能和命令行启动时表现不一致，这也是很多人来回切换启动方式后内存表现不同的原因。

如果服务器上不方便打开图形界面，就把参数写进 setenv.bat。这个文件位于 bin 目录，Tomcat 启动脚本执行时会自动加载它：

set "CATALINA_OPTS=-Xms512m -Xmx1024m -Dfile.encoding=UTF-8 -XX:MaxMetaspaceSize=256m"

这里几个参数的含义：

• -Xms512m：JVM 启动时分配的初始堆大小为 512MB。如果服务器内存充足，建议与 -Xmx 一致，减少堆大小自动伸缩带来的性能抖动。
• -Xmx1024m：最大堆大小 1GB。当应用内存峰值接近这个值时，先分析是否有泄漏，再继续加内存。
• -Dfile.encoding=UTF-8：设置默认文件编码，影响读取外部资源文件时的解码行为，对中文内容很关键。
• -XX:MaxMetaspaceSize=256m：限制元数据区大小，防止 JSP 类无限增长拖垮整机。

setenv.bat 与 tomcat7w.exe 同时存在时，图形界面里的参数优先级更高。我一般只选一个入口管理，避免两个配置互相覆盖。service.bat 安装的服务在启动时读取的是服务定义的 JVM 参数，跟手动启动用的 CATALINA_OPTS 不是同一条路径，这一点务必记住：服务方式全部以服务配置为准，脚本方式全部以 setenv.bat 为准。

5.4 访问日志与请求排查：确认请求到达 Tomcat，而不是本机网络问题

当外部访问失败且防火墙和安全组都放行后，剩下的问题是：请求到底有没有进 Tomcat？打开 conf\server.xml，在 Host 元素内部加一个 Valve：

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b" />

保存后重启，logs 目录下会生成 localhost_access_log.txt。每行日志记录一个请求，pattern 里这些占位符的含义是：%h 客户端地址，%l 逻辑用户名，%u 认证用户名，%t 请求时间，%r 请求行，%s HTTP 状态码，%b 响应字节数。如果外部访问不通，先看这个文件里有没有请求记录。没有记录，问题在网络层；有记录但返回 500，问题在应用层。

这个习惯帮我避免了很多无用功。之前遇到过应用页面渲染慢，查了半天数据库，最后发现是访问日志里根本没有请求记录，原来是另一台机器用错了端口。先确认请求是否到达容器，再往下排查，能少走很多弯路。

6. 上线前验证：JspC 预编译与一条命令检查健康状态

6.1 JspC 预编译：把几百个 JSP 的语法错误提前抛出来

预编译是最值得固化的验证手段之一。JSP 文件多的时候，靠浏览器一个个打开不现实，JspC 可以让 Tomcat 在不启动的情况下把所有 JSP 编译一遍，语法错误直接暴露。

cd /d D:\env\tomcat-7.0.103\bin set "CLASSPATH=%CATALINA_HOME%\lib\*;%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_HOME%\bin\tomcat-juli.jar" java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.jasper.JspC ^ -uriroot "D:\env\tomcat-7.0.103\webapps\myapp" ^ -d "D:\env\tomcat-7.0.103\work\jsp_precompile"

命令中 -uriroot 指向 Web 应用根目录，-d 指定编译输出目录。Classpath 里要有 lib* 和 bootstrap.jar，否则找不到 Jasper 类。如果报 JSP 编译错误，会显示具体文件和行号，修完再跑一次。

6.2 curl 校验：启动后马上知道健康状态

另一个习惯是启动后立即发一个 HTTP 请求检查响应码。Windows 10 自带 curl，可以直接：

curl -s -o nul -w "%{http_code}" http://localhost:8080/

返回 200 表示容器正常，404 就是路径不对，000 表示连接失败。这一步只看健康状态，不验证业务数据。

我从那次换 JDK 导致老页面中途抛异常以后，每次对 Tomcat 版本做调整或更新 WAR，都会强制走一遍“停 Tomcat、清 work/Catalina、JspC 预编译、启动、curl 验证”这五步。很机械，但确实救过我一次。如果你的项目也跑在 Tomcat 7 上，建议把这套动作固定下来。希望帮到你。

本文还有配套的精品资源，点击获取