简介：《tomcat-7.0.108.zip》是一份Apache Tomcat 7.0.108的完整发布包，面向需要在本地搭建Java Web运行与测试环境的开发人员、运维人员以及正在学习Servlet/JSP的开发者。压缩包共640个文件，约10.38MB，类型覆盖广泛：html帮助文档便于查阅说明，java源码与class文件适合二次开发或调试，jsp页面和war示例供部署演练，jar库提供运行依赖，xml/properties用于配置服务，bat/sh脚本则负责启动、停止等日常操作，几乎涵盖Tomcat使用与维护所需的主要文件形式。包内保留了bin、conf、lib、webapps、logs等标准目录，解压并设置CATALINA_HOME后即可通过脚本启停服务。部署Web应用时，可将WAR包放入webapps目录自动发布，也可在server.xml中手动配置Context；运行日志位于logs目录，便于排查问题，还可借助manager工具管理已部署应用。资源目前已有632人学习浏览，无论是刚开始接触Tomcat，还是已有经验的开发者，都能从这份结构清晰、可直接落地的资料中快速获得可运行Tomcat版本、理解目录结构和梳理部署流程。
1. tomcat-7.0.108.zip 值不值得留：老项目复现的刚需
接手一个 2017 年上线的老系统时，你会发现一个尴尬事实：代码是 Servlet 3.0 写的，包里全是 javax.servlet，而 Tomcat 10 之后已经把包名彻底切成 jakarta。拿新容器直接跑，启动是能启动，页面一打开就是 ClassNotFoundException。这时候翻出 tomcat-7.0.108.zip 这种 7 系收尾版本，反而比找任何新东西都省事。
这个压缩包就是 Apache Tomcat 7 分支的解压版，JDK 1.7、1.8 环境下开箱即用，专门对付那些还在用 Spring MVC 3.x、Struts 2、老式 JSP 标签库的项目。你不用改一行代码，解压、配个 JRE、扔 war 包就能把旧服务拉起来。适合三类人：要复现历史问题的运维、在旧项目里做二次开发的工程师、以及课程设计里被要求「必须用 Tomcat 7」的学生。
它不解决性能天花板的问题，也不负责新特性。它能解决的是让老项目在正确版本下跑起来，少一点版本迁移的玄学。
2. 安装与启动：JDK 版本、环境变量与 startup.bat 的一条龙
2.1 先定 JDK 版本：Tomcat 7 对 Java 版本的硬约束
Tomcat 7 在编译和运行时对 Java 版本有明确边界。官方要求的最低版本是 Java 6，实际维护中我基本只在 Java 7 和 Java 8 上跑它，这也是 7.0.108 这个版本生命周期里最主流的搭配。
| JDK 版本 | 表现 | 建议 |
|---|---|---|
| JDK 1.6 / 1.7 | 兼容，老项目常见搭配 | 可用，但 JDK 1.6 已停止维护 |
| JDK 1.8 | 最稳定，JSP 编译、EL 表达式都正常 | 首选，推荐 8u202 及以后 |
| JDK 9 ～ 11 | 启动可能正常，JSP 首次编译常报 NoClassDefFoundError | 不建议 |
| JDK 17+ | 反射访问、模块化限制导致启动即失败 | 直接放弃 |
为什么 JDK 9 以上容易出问题？Tomcat 7 的 Jasper JSP 编译器内部依赖 tools.jar 里的类，JDK 9 开始 JEP 220 把这类工具类从运行时里拆了出去，JSP 页面一多，首次访问必炸。这不是配置能救的，属于代际冲突。
所以拿到这个 zip 的第一步不是解压，是先确认机器上有 JDK 1.8。可以用下面命令检查当前默认版本：
java -version如果输出里不是 1.8 开头，就去装一个 JDK 1.8，并在后面配置 CATALINA_HOME 时让 Tomcat 显式指向它。很多启动失败，问题不在 Tomcat 本身，而是它被默认 JDK 坑了。
2.2 解压与环境变量：CATALINA_HOME、JRE_HOME / JAVA_HOME
把 zip 解压到一个纯英文路径，避免中文和空格。比如 Windows 下解压到D:\apps\tomcat-7.0.108，Linux 下放到/opt/tomcat-7.0.108。路径中间出现空格，脚本里路径拼接经常出问题，这类报错最不值得花时间查。
Tomcat 的启动脚本找 Java 运行环境的顺序是 JRE_HOME 优先，没有 JRE_HOME 才看 JAVA_HOME。我建议直接配 JRE_HOME，指向 JDK 的根目录而不是 bin 目录。Windows 命令行里临时设置：
set CATALINA_HOME=D:\apps\tomcat-7.0.108 set JRE_HOME=D:\Java\jdk1.8.0_202这两个变量只在当前 cmd 窗口有效。想永久生效，去系统环境变量里新建同名变量，值同上。不要画蛇添足再加一个 CATALINA_BASE，默认情况下它和 CATALINA_HOME 相同即可。
Linux 上则是在/etc/profile或用户~/.bashrc里加 export 声明：
export CATALINA_HOME=/opt/tomcat-7.0.108 export JRE_HOME=/usr/lib/jvm/java-1.8.0配好后验证一下目录结构，确认bin/startup.bat、conf/server.xml、webapps这些都在。解压包最常见的损坏就是 bin 目录文件不完整，后面启动时报「不是内部或外部命令」，所以花十秒检查目录比启动后猜原因靠谱。
2.3 启动与验证：startup.bat、catalina.out 与端口检查
Windows 下到 bin 目录双击或命令行执行：
cd D:\apps\tomcat-7.0.108\bin startup.batLinux 下：
/opt/tomcat-7.0.108/bin/startup.sh启动成功的标志是出现一个新的控制台窗口，或者命令行里打出Tomcat started。不要只看窗口还在就以为成功了，我见过不少窗口挂着但进程已经退出的情况。立刻做两件事：看日志，查端口。
Tomcat 7 的日志在logs/catalina.out（Linux）或logs/catalina.<日期>.log（Windows）。重点关注两行——Initializing ProtocolHandler ["http-bio-8080"]和Server startup in xxx ms。前者说明网络层起来了，后者说明整个容器完成初始化。
端口检查更直接：
netstat -ano | findstr :8080Linux 用：
ss -lntp | grep 8080看到 LISTEN 状态就说明 8080 在服务。最后用浏览器访问http://localhost:8080/，出现默认欢迎页即验收通过。注意：如果访问/返回 404，而端口在监听，多半是 ROOT 应用被删了或 webapps 目录是空的，这不是启动失败，是内容缺失，把 ROOT 目录放回去就行。
3. 部署 war 包：webapps 直放与 Manager 后台被限 IP 的处理
3.1 webapps 直放：最简单也最容易忽视的路径
Tomcat 7 的 webapps 目录是默认的应用放置区。把一个myapp.war复制进去，容器会自动解压并部署，通过http://localhost:8080/myapp访问。这个机制在 7.0.108 里默认开启，也就是 autoDeploy 和 unpackWARs 都开着。
我一般建议先做一次「冷部署」，也就是在关闭 Tomcat 时把 war 放进去，再启动。生产环境里热部署虽然方便，但容易出现老类没卸载干净导致的 PermGen 泄漏，这在 Java 8 之前是非常经典的坑。
war 包命名就是上下文路径。myapp.war解压后上下文路径是/myapp，如果你希望根路径访问，就把它改成ROOT.war。注意大小写敏感，Linux 下ROOT.war和root.war是两个东西，后者不会被当成根应用。
部署常见问题是上传的 war 不完整，Tomcat 解压到一半抛异常，页面 404。解决办法是看logs/localhost.<日期>.log，里面会打出部署失败的具体原因。这种日志非常易读，通常是「Exception reading XML」或「ZipException」，直接指向包损坏。
3.2 Manager 后台上传 war 被限制 IP：RemoteAddrValve 的默认拦截
大多数人拿到 Tomcat 后想用后台管理页面上传 war，也就是访问http://localhost:8080/manager/html。第一次访问会看到 401 或 403，这要拆成两个问题看。
401 是身份认证没过，因为 manager 应用默认没有任何用户。需要在conf/tomcat-users.xml里加角色和账号：
<role rolename="manager-gui"/> <user username="admin" password="changeit" roles="manager-gui"/>加了用户后能弹出登录框，但你可能在远程机器上依然看到 403 页面，提示「You are not allowed to view this page」。这才是热搜里说的「tomcat 后台页面上传 war 被限制 ip」的正主。
Tomcat 7 的 manager 应用在webapps/manager/META-INF/context.xml里写死了一个 Valve：
<Context antiResourceLocking="false" privileged="true"> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> </Context>这段配置的含义是：只有来自 127.0.0.1 和 IPv6 回环地址的请求才允许进入 manager。你是远程办公，IP 是公司网段，自然被拦。解决方式是把 allow 改成你的网段，或者删掉这个 Valve。我习惯改成网段白名单：
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192\.168\.\d+\.\d+|127\.\d+\.\d+\.\d+" />注意正则里的反斜杠在 XML 里要写成\d，别画蛇添足。改完重启，后台上传 war 就通了。想彻底关掉限制就删掉整个 Valve，但这是把双刃剑，等于任何人都能访问 manager，前提还得知道密码。生产环境我建议保留白名单，别图省事。
3.3 上传大 war 包报错：maxPostSize 与连接被重置
后台页面上传 war 还有第二个坑：上传几 MB 的小包没问题，传几十 MB 的大包时进度条走完直接报「连接被重置」或者 403。这跟 IP 限制无关，是 Tomcat 7 对 POST 请求体大小有默认限制。
Connector 的 maxPostSize 在 Tomcat 7 里默认是 2097152，也就是 2MB。war 包超过 2MB，容器直接拒绝读取。改conf/server.xml里 8080 对应的 Connector，加一个属性：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxPostSize="10485760" />value 是字节数，这里 10485760 是 10MB。设为 0 或负数表示关闭限制，但我不推荐在大并发生产环境关掉它，给一个合理上限更安全。改完必须重启，这个参数不会热加载。
如果你用 curl 脚本上传 war，也要注意脚本本身有没有超时设置。Tomcat 7 的 connectionTimeout 默认 20000 毫秒，网络慢时大包刚传一半连接就被判超时，这也会表现为上传失败。此时调大 connectionTimeout 或改用内网传输，是更实际的解法。
4. 配置调优：端口冲突、JVM 参数与线程池的翻车现场
4.1 三端口模型：8005、8080、8009 各管什么
Tomcat 7 默认监听三个端口，很多人只知道 8080，出问题后一脸懵。三个端口的职责完全不同：
| 端口 | 用途 | 默认值 |
|---|---|---|
| 8005 | 接收 SHUTDOWN 命令的关闭端口 | 8005 |
| 8080 | HTTP 请求入口，浏览器访问的端口 | 8080 |
| 8009 | AJP 协议端口，给 Apache httpd 或 nginx 做反向代理用 | 8009 |
最常见的问题是机器上已经有一个 Tomcat 占着 8080，新启动的实例报java.net.BindException: Address already in use。很多人只改了 HTTP 端口，启动还是失败，因为 8009 和 8005 也被占了。
改端口时三个要一起考虑。我通常把第一个实例保持 8080，第二个实例改成 8082、8006、8010 这样一组，避免端口冲突排查时顾此失彼：
<Server port="8005" shutdown="SHUTDOWN"> <Connector port="8080" protocol="HTTP/1.1" ... /> <Connector port="8009" protocol="AJP/1.3" ... /> </Server>关掉 8009 也可以，现在的部署很多已经不用 AJP 了。在 Connector 那行注释掉或删掉就行，不影响 HTTP 访问。
4.2 JVM 内存参数：用 setenv.bat 而不是改 catalina.bat
老项目最常见的崩溃是 OutOfMemoryError，Tomcat 7 时代还要分两种：堆内存溢出和 PermGen 溢出。调参的标准姿势是在 bin 目录下新建setenv.bat（Windows）或setenv.sh（Linux），Tomcat 启动脚本会自动加载它。这样可以不动 catalina.bat 本体，以后换版本直接拷贝 setenv 文件。
Windows 下新建bin\setenv.bat：
set "JAVA_OPTS=-Xms256m -Xmx1024m -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8"Linux 下新建bin/setenv.sh：
export JAVA_OPTS="-Xms256m -Xmx1024m -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8"| 参数 | 含义 | 建议值 |
|---|---|---|
| -Xms | 堆初始大小 | 256m，启动时一次分配，减少抖动 |
| -Xmx | 堆最大大小 | 1024m 或机器内存的一半，二者取小 |
| -XX:MaxMetaspaceSize | 类元数据上限 | 256m，JSP 多的项目可以给 512m |
| -Dfile.encoding=UTF-8 | 默认文件编码 | 中文项目务必加 |
如果你在 JDK 1.8 上看到网上教程让你配-XX:MaxPermSize，那是老黄历。JDK 8 已经用 Metaspace 替代 PermGen，配了 MaxPermSize 不会报错但也没效果，纯自我安慰。
4.3 线程池：maxThreads、acceptCount 与 minSpareThreads
并发配置是另一个容易自我感动的地方。有人把 maxThreads 调到 2000 觉得稳了，结果连接一多照样卡死。原因是三个参数是配合的，不是只调一个。
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="200" minSpareThreads="25" acceptCount="100" />maxThreads 是 Tomcat 处理请求的最大工作线程数，请求进来先占用空闲线程。minSpareThreads 是保底空闲线程数，低于这个数就开始新建线程，避免请求来了现场造线程。acceptCount 是排队队列长度，线程全忙时新请求先排在这里。
对老项目，我的经验值是 maxThreads 给 200 到 400，acceptCount 给 100 到 200。别把 acceptCount 当成并发上限，它只是排队缓冲。请求量超过 maxThreads + acceptCount 时，多余连接会被直接拒绝，客户端看到的就是 Connection refused，而不是慢。
还有一个隐蔽点：如果项目里有长时间阻塞的操作，比如同步调用外部接口，线程会被占住不放。此时加大 maxThreads 只能缓解表面现象，真正要做的是给外部调用加超时时间，把线程释放出来。这个属于应用层问题，调 Tomcat 参数没法根治。
5. 避坑手册：启动失败与部署异常的 5 条排错记录
5.1 现象：启动报 Address already in use
原因：三个端口中任何一个被占用都会导致启动失败。尤其 8009 被别的程序占用时，报错信息不会直接写端口号，藏在堆栈里需要翻。
解决：启动前先查端口：
netstat -ano | findstr :8005 netstat -ano | findstr :8009看到占用进程后，要么杀掉进程，要么按前面说的改端口。我的血泪经验是：先查 8009，再查 8005，最后查 8080。因为 8080 冲突最好发现，另外两个才阴险。
5.2 现象：启动成功，但访问 JSP 报 ClassNotFoundException
原因：JDK 版本过新。Tomcat 7 的 JSP 编译在 JDK 9+ 会缺 tools.jar，报错信息里通常带org.apache.jasper.JasperException。
解决：确认 JRE_HOME 指向 JDK 1.8，而不是系统的默认 JDK。改完环境变量后要重启 cmd 窗口，因为变量不会自动刷新。如果是 Linux，export之后也要重新加载 profile 文件。
5.3 现象：war 包部署了，访问返回 404
原因：上下文路径和预期不一致。war 文件名是myapp_v2.war，访问路径就要带_v2，不是myapp。或者把 war 放到了 webapps 之外，比如放到了logs目录。
解决：确认 war 在webapps下，并用http://localhost:8080/war文件名/访问。想换路径就改 war 文件名，或者后面用 context.xml 的 docBase 显式指定。
5.4 现象：页面中文乱码
原因：Tomcat 7 的 GET 请求 URI 编码默认不是 UTF-8，而是 ISO-8859-1。这导致带中文参数的请求到后端全变成问号。
解决：在 Connector 上加URIEncoding="UTF-8"，同时在应用的 web.xml 里确认 request 和 response 编码一致。只改 Tomcat 不改应用，或者只改应用不改 Tomcat，乱码都可能残留一半。这是 7.0.108 和 8.0+ 的一大区别，8.0 之后默认就是 UTF-8，很多人从 8 降到 7 时在这个坑里翻车。
5.5 现象：反复 reload 后 OutOfMemoryError: PermGen space
原因：热部署或 reload 时，旧类加载器没有被完整回收。每次 redeploy 都会创建新的类加载器，老对象被长生命周期的引用挂着，PermGen 或 Metaspace 越积越满。
解决：开发阶段可以用 war exploded 加调试模式，但生产环境尽量不热部署。必要时重启 Tomcat 释放内存，并在 setenv 里给-XX:MaxMetaspaceSize留足余量。这个问题的根子多半是应用持有了静态集合，把类加载器引用住了，不是单靠加大内存能解决的。
6. 在 idea 里复现 tomcat 7：本地 zip 的环境验证技巧
IDEA 配置老 Tomcat 有一条捷径：不用它自带的下载功能，直接用本地解压出来的 tomcat-7.0.108 目录。在 Settings → Build, Execution, Deployment → Application Servers 里点加号，选择 Tomcat Server，把目录指向解压路径。IDEA 会识别出版本号，不用额外装任何东西。
Run Configuration 里两个地方最容易配错。第一是 JRE 要手动选到 JDK 1.8，IDEA 默认会用它自己绑定的 JRE，多半是 17 或更高，跑 Tomcat 7 必挂。第二是 HTTP port，IDEA 在运行时会把 conf/server.xml 复制到它自己的工作目录，端口显示可能和原始 server.xml 不一致，这是正常的。以 IDEA 控制台里打印的端口为准，不要来回改原始配置文件。
部署方式我建议选 war exploded 而不是 war 包。exploded 模式直接把解压目录作为部署单元，修改 JSP 后刷新浏览器就能看到变化，省掉了每次打 war 再上传的等待。对调试老项目来说，这个效率提升非常明显。
验证这套环境是否可用，我总结了一个三分钟检查顺序：看控制台有没有Server startup，访问 IDEA 显示的端口返回 200，再访问一个具体页面确认 JSP 编译通过。三步都过，说明 IDEA、JDK、Tomcat 三者咬合正常。
自从有一次在 IDEA 里用 JDK 17 跑了半天 Tomcat 7，最后发现是 JRE 没切回 1.8，从那以后我每次配置老 Tomcat 环境，都强制先看一眼 JRE 选择框和 CATALINA_BASE 的指向，再开始部署。希望你这次不要踩同一个坑，希望帮到你。
本文还有配套的精品资源，点击获取
