Tomcat 7.0.108 Windows x64 部署配置与排错指南-育师

简介：这份压缩包提供Apache Tomcat 7.0.108的Windows 64位发行版，面向需在本地部署和测试Java Web应用的开发者与学习者，可用于Servlet 3.0、JSP 2.2项目的运行验证。包内共640个文件、约10.1MB，以html说明、class与java源码、jsp页面、jar依赖及xml、properties配置为主，并含bat/sh脚本和少量图片。已有227人学习下载。解压后可从conf、webapps、logs、work等目录理解配置、部署、日志与编译产物，结合管理控制台、server.xml调整和WAR自动部署，搭建便于排错的Java Web测试环境。

1. apache-tomcat-7.0.108-windows-x64 到底是什么：谁还在用它、能解决什么问题

把 apache-tomcat-7.0.108-windows-x64 这个名字拆开看，它是三件事叠在一起：Tomcat 7 这个 Servlet 容器、7.0.108 这个小版本号，以及 windows-x64 这个面向 64 位 Windows 的免安装压缩包。解压就能跑、不写注册表也能用、需要的时候一条命令注册成系统服务，这是它至今仍被大量内网系统选中的原因。它解决的是“一个十几年前立项的 Java Web 应用，还要在一台新买的 Windows 服务器上继续跑三年”这种很现实的问题：老代码依赖 Servlet 3.0 规范，新版本容器改了默认行为，迁移成本比换台机器还高。

这篇写给两类人：手上有一套只能跑在 Tomcat 7 上的存量系统、需要在 Windows 上把它稳稳当当地立起来的人；以及第一次拿到这个压缩包、双击 startup.bat 发现窗口一闪就没了的初学者。下面按“解压能跑 → 参数配对 → 部署验证 → 踩坑排查 → 上线体检”的顺序走一遍，每一步都给出可复制的配置和判断依据。

2. 从解压到能访问：Windows x64 上的最小可运行环境

拿到压缩包后第一件事不是急着双击，而是把目录放对位置。放在C:\Program Files下是最常见的错误起点：路径里的空格会让一批批处理脚本解析参数时出错，路径里的中文还会让日志和临时目录在某些编码下变成乱码。我一般直接放在C:\app\tomcat7这种无空格、纯英文、层级浅的位置，后面所有配置都基于这个路径展开。

2.1 JDK 选型：为什么 7.0.108 建议配 JDK 8 而不是更高版本

Tomcat 7 实现的是 Servlet 3.0、JSP 2.2、EL 2.2 这套规范，最低要求 JDK 1.6，实际部署里最省心的搭配是 JDK 8。原因不是 JDK 8 更快，而是 JDK 9 之后的一系列改动会把 Tomcat 7 的老启动参数打成“部分失效”：类加载器结构变了、一些内置模块被移出、启动参数里的部分目录约定不再被识别，容器能起来，但你在排查问题时会被一堆无关警告干扰。用 JDK 8，等于让容器的行为和当年写这套代码时的环境保持一致。

第二个容易忽略的点是位数。文件名里的 windows-x64 指的是压缩包里那个tomcat7.exe服务宿主程序是 64 位的，它启动时要加载 64 位的 JVM，而你机器上装的是 32 位还是 64 位 JDK 由 JAVA_HOME 决定。这两者必须配对：64 位的 exe 配 32 位 JDK，注册服务时会直接失败；反过来 32 位 exe 配 64 位 JDK 也一样。还有一个隐蔽后果，哪怕服务注册成功，32 位 JVM 的堆上限也就 1.5G 左右，你把-Xmx4096m写进去，它起不来而且报错信息很不直观。

验证方式很土但有效：命令行执行java -version，输出里带 64-Bit 字样才算配对成功。别嫌这一步多余，我见过不止一次“服务装上了、就是起不来”，最后查出来是机器上同时装了三个 JDK，PATH 里那个是 32 位的。

2.2 目录结构与 CATALINA_HOME / CATALINA_BASE 的分工

解压后的七个目录各管一摊，动手前先认清，后面改配置才知道该改哪个文件：

目录	作用	什么时候需要动
`bin`	启动脚本、服务注册工具、bootstrap 类	改内存参数、注册服务
`conf`	server.xml、context.xml、tomcat-users.xml、web.xml	改端口、编码、权限
`lib`	容器级公共 jar	放数据库驱动、公共依赖
`webapps`	默认应用部署目录	放 WAR 包
`logs`	运行日志	排查启动失败
`temp`	临时文件	上传功能异常时看
`work`	JSP 编译产物	清缓存、排查 JSP 报错

真正值得说清的是 CATALINA_HOME 和 CATALINA_BASE 这对概念。HOME 指的是二进制和公共库所在的位置，BASE 指的是配置、日志、应用、工作目录所在的位置，不设 BASE 时它默认等于 HOME。单机单应用时两者相同，你完全不用管；但如果你要在一台机器上跑同一个版本的三个应用、共用一份二进制，就可以把 HOME 指向安装目录、给每个实例各配一个 BASE，各自有独立的 conf、logs、webapps。这是这套压缩包相比安装包最值钱的地方，做多实例部署时省下的磁盘和升级成本很可观。

2.3 三种启动方式：startup.bat、catalina.bat run、注册为 Windows 服务

启动这件事有三种做法，适用场景完全不同，混用是新手翻车的重灾区。

第一种是双击bin\startup.bat，它会新开一个窗口调catalina.bat start，窗口关掉服务还在，日志只能去 logs 目录看。这个方式只适合“我先试试能不能起来”，不适合排错，因为起不来时窗口一闪就消失，什么信息都留不下。

第二种是命令行进到 bin 目录执行catalina.bat run，它把容器跑在当前控制台里，启动异常、端口占用、类找不到全都直接打在屏幕上。排错阶段我基本只用这一种，它是这套东西唯一的黑匣子。

第三种是注册成 Windows 服务，开机自启、后台运行、能用服务管理器管，这是正式环境的做法。注意服务方式和前两种读取参数的路径不一样：前两种读bin\setenv.bat，服务方式读的是注册表里记录的 JVM 参数，你在 setenv.bat 里写的东西对它无效。这个差异坑过很多人，改完参数发现没生效，其实改错了地方。

:: bin\setenv.bat —— 文件默认不存在，自己新建；被 catalina.bat 启动时自动加载 set "JAVA_HOME=C:\app\jdk8" set "JAVA_OPTS=-Xms1024m -Xmx1024m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=384m -Dfile.encoding=UTF-8 -Duser.timezone=GMT+08:00"

这段的作用是给容器进程固定堆大小和字符集。-Xms和-Xmx设成一样大，避免运行期反复扩堆带来的停顿；MetaspaceSize是 JDK 8 的元空间初始阈值，老应用类多，给到 128m 起步比较安全；-Dfile.encoding=UTF-8决定 JVM 默认字符集，Windows 中文版默认是 GBK，不显式指定，日志和读文件的编码行为会随环境漂移。时区用GMT+08:00而不是城市名，是为了避免容器在不同语言环境下解析时区标识失败。

:: 以管理员身份运行，注册服务并启动；Tomcat7App 是自定义服务名 cd /d C:\app\tomcat7\bin service.bat install Tomcat7App net start Tomcat7App

service.bat install会把当前 JAVA_HOME 和 exe 路径写进服务配置，所以先确认java -version是 64 位再执行。装完之后要改内存或加参数，用同目录的tomcat7w.exe //ES//Tomcat7App打开图形界面，在 Java 选项卡的 Java Options 里一行一个参数地填，填完重启服务。这两步分工要记牢：绿色启动看 setenv.bat，服务启动看 tomcat7w。

3. server.xml 与 setenv.bat：把端口、编码、内存这三件事一次配对

conf 目录里四个文件，日常只需要动三个：server.xml管端口和连接器，tomcat-users.xml管管理后台的账号，context.xml管全局的会话与资源。这一章把 server.xml 里真正影响线上表现的部分挑出来讲，其余默认值不要动，动得越多，未来升级越难受。

3.1 Connector 的四个必调参数：port、URIEncoding、maxThreads、connectionTimeout

<!-- conf\server.xml：HTTP 连接器，改完必须重启容器，热加载不生效 --> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" maxThreads="200" minSpareThreads="20" acceptCount="100" URIEncoding="UTF-8" enableLookups="false" compression="on" compressionMinSize="2048" compressableMimeType="text/html,text/css,application/json,application/javascript" redirectPort="8443" />

逐项说清楚每个参数在解决什么问题。port是监听端口，改它的时候别只改这一处，同一个文件里还有 shutdown 端口（默认 8005）、AJP 端口（默认 8009）和redirectPort指向的 8443，四处一起看，否则你会遇到“端口改了但还是起不来”或者“改了 8080 结果 8005 被别的程序占了”。

URIEncoding="UTF-8"是这个版本里最该改的一个默认值。Tomcat 7 的 HTTP 连接器对 URL 查询串的默认解码字符集不是 UTF-8，不显式指定的话，GET 请求带中文参数到后端就是乱码。这个坑的特征是 POST 表单里的中文正常、URL 上的中文全是问号或乱码，因为两者走的是不同的解码路径。

maxThreads是并发处理线程上限，默认 200 对绝大多数内网系统够用；minSpareThreads是常驻空闲线程，调大能减少突发请求时的建线程开销；acceptCount是等待队列长度，队列满了之后新连接直接被拒。这三个值要一起看：线程数给得再大，队列太短一样会在峰值时丢掉请求。判断该不该调，看日志里有没有出现连接被拒的记录，没有就别动。

enableLookups="false"关掉反向域名解析，这个默认值在很多老配置里是 true，每个请求都去做一次解析，在高频接口上会带来非常不划算的延迟。compression打开对文本类响应做压缩，JSON 接口收益明显，但别把图片、压缩包这类已经是二进制的类型加进 compressableMimeType，压了反而更大。

AJP 连接器要单独提一句，因为 7.0.108 这个版本对它有硬性要求：

<!-- 不用 AJP 就整段注释掉；要用则必须配置 secret，否则连接器启动即失败 --> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" secret="换成一串你自己的随机串" />

这个版本所属的 7.0.x 后期分支收紧了 AJP 的默认安全策略，不带 secret 的连接器会被拒绝启动。绝大多数纯 HTTP 场景根本不需要 AJP，最省事的做法是把整段注释掉，少一个对外开放的端口，也少一处需要维护的密钥。

3.2 setenv.bat 里的 JVM 参数：堆、元空间与字符集的配比

上一节给了 setenv.bat 的模板，这里说清楚每个数字怎么定。堆大小取决于两件事：单机内存和应用的常驻对象量。经验做法是先给-Xmx一个保守值（比如 1024m），跑一轮接近真实的压力，观察日志和系统监控里的内存曲线，再决定加还是减。一上来就给机器一半内存，遇上真的内存泄漏，问题会从“每天挂一次”变成“每周挂一次”，反而更难定位。

元空间的坑更隐蔽。JDK 8 之后永久代被移到本地内存，-XX:MaxMetaspaceSize不设就是不限，一旦应用在做动态类生成或者反复热部署，它会一路吃物理内存，直到系统层面出问题，而容器自己的日志里一条异常都没有。设一个上限，让它在该报错的时候报错，比让它在深夜把整台机器拖垮要好。

字符集那两个参数要一起配：-Dfile.encoding=UTF-8影响 JVM 默认字符集，日志输出、读配置文件、new String(bytes)都受它影响；-Duser.timezone=GMT+08:00影响日期处理。这两个不配对，最常见的症状是日志中文正常但时间差八小时，或者反过来。

还有一个只在 Windows 上出现的注意点：

提示：setenv.bat 里的路径值如果包含空格，必须整体加双引号写成set "JAVA_HOME=C:\..."的形式，只给值加引号而不包住整个赋值语句，批处理解析时会把引号当成值的一部分传下去，表现为“明明路径是对的，就是找不到 Java”。

3.3 Host 与 Context：虚拟目录映射和 reloadable 的取舍

部署一个不在 webapps 下的应用，标准做法是在 Host 里加 Context：

<!-- conf\server.xml：把 D:\data\report-web 映射到 /report，docBase 与访问路径解耦 --> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Context path="/report" docBase="D:\data\report-web" reloadable="false" /> </Host>

docBase是应用的真实目录，path是浏览器访问的路径前缀，两者不需要同名，这一点在“应用必须放在 D 盘数据盘、但访问地址要保持 /report”的场景里特别有用。reloadable我只在开发机上设 true，它会监控 classes 和 lib 目录的变化并自动重载上下文，代价是每次重载都会留下一批无法回收的类，跑一天下来元空间就吃满了。生产环境一律 false，改完代码老老实实重启。

多个应用共享会话或共享数据源时，别在各自的 context.xml 里各写一遍，放到conf/context.xml的全局配置里，用crossContext控制应用间是否可互相访问上下文。这个开关默认关闭是对的，打开它意味着任何一个应用出问题都可能影响其他应用。

4. 部署一个 WAR：从放包到验证的完整链路

配好参数之后，真正的日常动作是把应用包部署上去。这个过程看着简单，实际边界不少：包放哪里、依赖放哪里、什么时候会自动重载、管理后台为什么打不开，四个问题挨着来。

4.1 WAR 与解压目录的优先级，以及 autoDeploy 的行为

最直接的部署方式是把app.war丢进webapps目录。容器有一个后台线程按固定间隔扫描部署目录（默认大约十秒一次），发现新包就解压、加载、挂载上下文，访问路径就是包名去掉 .war 后缀。命名为ROOT.war的包会映射到根路径/，这是很多“访问根路径 404”问题的答案。

优先级的规则要记牢：同一个应用同时存在app.war和app/解压目录时，容器会判断时间戳，较新的那个生效，并且可能反过来覆盖另一个。这个机制在排错时是灾难：你手动改了解压目录里的配置文件，重启后发现改动全没了，因为 war 包比目录新，容器重新解压覆盖了一遍。正规做法是改源码重新打包，而不是在解压目录里打补丁。

unpackWARs="true"让容器解压后运行，好处是 JSP 编译产物和静态资源读取路径更直观，坏处是每次重新部署都会在work目录留下上一版的编译缓存。遇到“代码明明是新的，页面还是老的”，第一件事就是停容器、删work下对应应用的目录、再启动。这是我最常用的后悔药，十次里有八次能解决问题。

4.2 依赖放哪里：WEB-INF/lib 与容器 lib 的边界

依赖放错位置是类冲突最常见的原因。判断标准只有一条：这个 jar 是不是这个应用独有的。业务框架、JSON 库、工具类，全部进WEB-INF/lib，跟着 WAR 走，一个应用一个版本，互不干扰。数据库驱动、公共的日志实现这种多个应用共用的东西，放$CATALINA_HOME/lib，随容器加载，省内存也省得每个包都塞一份。

有一条绝对不能破的规矩：Servlet API 相关的 jar 不能出现在WEB-INF/lib里。Tomcat 自己提供了这套接口的实现，你在应用里再塞一份，容器启动时会报类转换异常或者接口方法找不到，报错信息指向的是容器内部类，看起来跟你的代码毫无关系，非常迷惑。打包时把这类依赖设成 provided 作用域，是最省心的做法。

驱动版本冲突也值得说一句。同一个容器下两个应用分别依赖不同版本的数据库驱动，如果都放在容器 lib 里，后加载的会覆盖前一个，表现是“A 应用一直好好的，B 应用上线后 A 开始报方法不存在”。这种问题排查成本极高，处理办法就是驱动跟着应用走，放各自的 WEB-INF/lib。

4.3 用 manager 应用做远程部署：角色配置与上传命令

服务器不能随时登录桌面的时候，用管理后台做远程部署比自己传文件快得多。前提是在conf/tomcat-users.xml里配好角色：

<!-- conf\tomcat-users.xml：manager-script 是给命令行脚本用的，manager-gui 是给浏览器用的 --> <role rolename="manager-script"/> <role rolename="manager-gui"/> <user username="deployer" password="换成一串足够长的口令" roles="manager-script,manager-gui"/>

manager-script和manager-gui是两个不同的角色，前者允许通过 HTTP 接口执行部署、卸载、重载，后者只能打开网页界面。只给 gui 角色然后抱怨命令行 401，是极常见的配置失误。

配好之后可以用一条命令完成上传部署：

# 把本地 war 推到服务器并挂载到 /report，-u 后面是上面配的账号 curl -v -u deployer:口令 \ -T report.war \ "http://10.0.0.10:8080/manager/deploy?path=/report&update=true"

-T是上传文件，path是挂载路径，update=true表示已有同名上下文时覆盖它。执行成功会返回一段文本，包含部署状态和上下文列表；失败时也会返回文本，通常在开头就能看到原因，比如包结构不合法、上下文已经存在但没加 update、权限不足。这条链路我一般只在受控内网里用，管理后台本身在上线前是要关掉的，第 6 章会说怎么关。

5. 避坑与排查：五个把我拖到半夜的问题

下面这五条都是真实发生过、并且在多台机器上重复出现的。每一条按“现象 → 原因 → 解决”写，遇到时可以直接对号入座。

5.1 启动窗口一闪就没：JAVA_HOME、路径与 JRE 的三重陷阱

现象：双击startup.bat，命令行窗口闪一下立刻关闭，浏览器访问不了，logs 目录里也没有新的日志文件。

原因有四种，按出现频率排序：一是 JAVA_HOME 没设或者指向了一个不存在的目录，catalina.bat在做环境校验时直接退出；二是 JAVA_HOME 指向的是 JRE 而不是 JDK，缺少编译 JSP 需要的工具，容器启动到一半失败；三是路径里带空格或中文，批处理在拼 classpath 时被截断；四是端口被占用，容器还没来得及初始化日志框架就抛异常退出了。

解决：先用命令行执行catalina.bat run把错误打到屏幕上，而不是双击。看输出里的第一行报错，是环境变量问题就修环境变量，是端口问题就去改端口。如果连一行输出都没有，说明是脚本层面的问题，把 Tomcat 挪到无空格无中文的短路径下再试。这一步做完，九成的“闪退”都能定位。

5.2 GET 请求中文全乱码：URIEncoding 的默认值坑

现象：表单提交的中文正常显示，但页面上拼在 URL 里的查询参数到后端变成乱码，日志里输出来是一串问号或者奇怪字符。

原因：POST 请求体的解码由应用层request.setCharacterEncoding或过滤器决定，而 URL 查询串的解码由连接器的URIEncoding决定。这个版本的 HTTP 连接器不显式配置时，查询串走的是容器内部的旧默认字符集，和页面用的 UTF-8 对不上。

解决：在 Connector 上加URIEncoding="UTF-8"，重启容器。别在代码里用new String(param.getBytes("ISO-8859-1"),"UTF-8")这种转码大法去绕，那只是把乱码暂时糊住，一旦换个部署环境又会翻回来。应用层的 POST 编码统一交给一个编码过滤器在入口处设置，两边各管一段，边界清楚。顺带说一句，这个版本的连接器没有后来那些放宽 URL 特殊字符的参数，遇到方括号、竖线这类字符只能靠前端编码或者改走 POST。

5.3 Unsupported major.minor version：编译与运行环境的错位

现象：应用部署上去，访问报 500，日志里一行java.lang.UnsupportedMajorMinorVersion或者Unsupported major.minor version 52.0。

原因：class 文件的版本号高于运行它的 JVM 版本。52.0 对应 JDK 8，如果容器跑在 JDK 7 上就会报这个错。反过来的情况也存在：编译时用了更高的 JDK，本地跑得好好的，一上服务器就炸。

解决：统一编译和运行环境的版本。看一个 class 到底是哪个版本编译的，可以直接查：

:: 进入应用目录，查这个类的 class 文件版本，major 52 就是 JDK 8 编译的 cd /d C:\app\tomcat7\webapps\report\WEB-INF\classes javap -verbose -classpath . com\example\Main | findstr major

输出里的major version减去 44 就是对应的 JDK 主版本（50 = 6，51 = 7，52 = 8）。对照服务器上java -version的结果，就知道该降编译级别还是升运行时。稳妥的做法是编译插件里显式锁死目标版本，别依赖开发机默认值。

5.4 管理后台 403：角色对了但地址不对

现象：账号密码确认无误，访问/manager/html返回 403，页面提示拒绝访问，日志里没有明显异常。

原因有三层：一是账号没有manager-gui角色，只有manager-script；二是管理应用自带的访问控制默认只允许本机地址访问，从别的机器打开必然 403；三是密码里含有 XML 特殊字符（比如&、<），配置文件解析时被截断，实际生效的密码和你以为的不一样。

解决：先确认角色，再确认访问来源。远程访问需要改管理应用自己的上下文配置里的访问控制白名单，把允许的网段加进去，改完重启。密码统一用字母加数字加少量安全符号，避开 XML 里有特殊含义的字符，能省掉一整类玄学问题。改完记得把这次操作记在部署文档里，否则三个月后换人接手，又得重新查一遍。

5.5 反复热部署后元空间溢出：类加载器的血泪经验

现象：应用跑了几周都好好的，某天开始频繁 Full GC，最终报元空间不足，重启后恢复正常，过几天再来一次。

原因：反复热部署或者应用内部有动态类生成，旧的类加载器因为被某个引用链挂着无法回收——常见的持有者是没注销的数据库驱动、没关闭的线程池、静态变量里的 ThreadLocal、以及某些日志框架的上下文。每一次重载都留下一份无法回收的类，元空间只涨不跌。

解决：短期靠设-XX:MaxMetaspaceSize让它在可控范围内报错，配合定期重启；中期靠规范，在应用里注册一个上下文销毁监听器，把线程池、驱动、定时器都注销掉；长期靠流程，生产环境不做热部署，改代码走停机替换。第三点最有效也最容易被忽视，很多人图省事一直热部署，最后付出的是每天盯内存曲线的代价。

6. 上线前的体检清单：把内存、端口和后台权限一次查干净

正式交付前我会走一遍固定的检查动作，五分鐘能做完，能挡掉后面八成的事故。先看环境配对：java -version是否带 64-Bit，echo %JAVA_HOME%是否指向 JDK 而不是 JRE，容器路径是否无空格无中文。再看端口：netstat -ano | findstr :8080确认监听存在且没有被别的进程抢占，shutdown 端口（8005）不要对外暴露，AJP 端口不用就注释掉。

然后是参数体检，对照着看有没有漏配：

检查项	期望值	漏配的后果
堆大小	Xms 与 Xmx 相等且不超过物理内存一半	运行期反复扩堆，停顿明显
元空间上限	显式设置 MaxMetaspaceSize	异常时无声吃满内存
URL 编码	URIEncoding=UTF-8	GET 中文乱码
文件编码	-Dfile.encoding=UTF-8	日志与配置读取乱码
管理后台	上线前删除或限制访问来源	对外暴露管理入口
示例应用	清空 webapps 下的自带示例	多出几个无用且可访问的路径