企业官网建设流程全解析

简介：Tomcat 7.0.108 是 Apache 开源的 Java Servlet 容器稳定版本，面向 Java Web 开发初学者与部署运维人员，解决本地运行 JSP/Servlet 项目、配置虚拟主机及发布 WAR 包等常见需求。压缩包共 640 个文件，约 10.38MB，除核心 bin/conf/lib/webapps 等目录外，还包含 228 个 html 页面、106 个 class 文件、78 个 java 源码、58 个 jsp 页面及若干 jar、xml 配置，便于对照学习目录结构与默认应用。内置的 apache-tomcat-7.0.108 目录为完整解压版，可直接设置 CATALINA_HOME 后启动使用。已有 628 人学习下载。通过分析 webapps 下的示例工程、conf/server.xml 配置及 bin 脚本，可以快速掌握 WAR 部署、端口修改、日志查看与 manager 管理台用法，适合在本地搭建轻量级 Java Web 调试环境。 一个老项目的部署文档里，躺着一行下载链接：tomcat-7.0.108.zip。看到这个文件名，懂的人大概会心一笑——这个版本早就不再更新，但不少公司的线上系统还在用它跑着JSP页面和内部接口。它属于 Apache Tomcat 7.x 系列的最终版，2019 年 11 月发布，之后官方就把 7.x 划入了 EOL 名单。放在今天来看，你下载它大概率不是为了追新，而是要复现某个历史环境、接手一个老系统，或者单纯就是教程里指定了这个版本号。

不管你是刚学 Java Web 的小白，还是被老项目“折磨”的维护者，这篇内容都按我实际操作的经验来讲：从版本定位、解压安装、IDEA 调试，到启动慢的坑、线程模型的误区，再到日常排查。目标就一个——让你拿到这个 zip 之后，能少搜几页资料，直接把东西跑起来。

1. 版本定位与选型判断：先搞清楚 7.0.108 是什么

1.1 一个压缩包背后的技术规格

tomcat-7.0.108.zip是 Tomcat 7.x 系列的最后一个版本包。这里的 7.0 是大版本，108 是维护版本号。它在功能上实现了 Servlet 3.0、JSP 2.2、EL 2.2 和 WebSocket 1.1，对应 Java EE 6 Web Profile 的一部分。放到今天看这些规范不算新，但它支撑起了无数遗留系统的日常运转。

后面再没有 7.0.109 了，也不会有。Tomcat 官方对 7.x 的维护在 2021 年 3 月正式截止，之后发现的漏洞不再出补丁。这意味着如果你把它用在公网环境，需要考虑风险；如果是内网系统、开发调试、比赛题目、课程设计，它反而因为稳定、轻量、资料多，成了很省心的选择。

这个 zip 包本身是跨平台的，Windows、Linux、macOS 都能解压使用，内部结构和 tar.gz 包完全一样，并不像 Windows 安装版那样会写注册表、注册系统服务。它解压之后就能跑，这也是很多人喜欢用 zip 版的原因——绿色、干净、不污染系统，删的时候直接删文件夹就行。

1.2 JDK、Maven、Spring 版本怎么匹配才不闹心

老项目最常见的组合是 JDK 8 + Tomcat 7 + Spring 4.x，如果项目里用了 Spring Boot 1.x，它内嵌的也往往是 Tomcat 7 或 8。下面是我整理的一个匹配参考表，列的是实际验证过的稳妥组合：

这里要特别说一个坑：Tomcat 7 官方文档写着最低支持 Java 6，但到了 JDK 9 之后，Java 模块化把javax.annotation这些包移出了默认加载列表，直接拿 JDK 9 以上跑 Tomcat 7，经常启动到一半就抛ClassNotFoundException。强行处理的话要在 JVM 参数里加--add-modules，折腾一圈不如老老实实用 JDK 8。

Maven 方面没什么玄学，老项目一般把maven.compiler.source和target配成 1.8，打出来的 war 包放进 Tomcat 7 就能跑。如果老板让你“支持 Java 21”，那答案也很明确：升级到 Tomcat 10.1 或 11，顺带把代码里的javax.*换成jakarta.*，工程量是逃不掉的。

2. 环境准备与安装配置：解压之后这五步做完就能跑

2.1 解压后先认识目录结构

把tomcat-7.0.108.zip解压到一个没有中文、没有空格的路径，比如D:\apache-tomcat-7.0.108。解压完不要急着双击 startup，先把目录认清楚，后面排错全靠这几个文件夹。

其中有三个目录我要单独提醒。webapps是你部署 war 包的地方，Tomcat 启动时会自动扫描并解压；work是 JSP 第一次访问时编译产物的缓存目录，很多“改了页面不生效”的怪问题，删掉work里的对应目录重启就好；logs里的catalina.out（Linux）或catalina.<日期>.log（Windows）是排查启动失败的首选档案。

2.2 JAVA_HOME 和 CATALINA_HOME 的配置细节

Tomcat 本身是 Java 程序，启动脚本会去找JAVA_HOME或JRE_HOME。如果找不到，Windows 下就是启动窗口一闪而过，Linux 下直接报Neither the JAVA_HOME nor the JRE_HOME environment variable is defined。

我建议把JAVA_HOME指到 JDK 主目录，注意不是 bin 目录，也不是jre目录。比如：

JAVA_HOME=D:\Java\jdk1.8.0_202 CATALINA_HOME=D:\apache-tomcat-7.0.108 PATH=%JAVA_HOME%\bin;%CATALINA_HOME%\bin

Linux 环境则是在/etc/profile或~/.bashrc里加：

export JAVA_HOME=/usr/local/jdk1.8.0_202 export CATALINA_HOME=/opt/apache-tomcat-7.0.108 export PATH=$JAVA_HOME/bin:$CATALINA_HOME/bin:$PATH

CATALINA_HOME不是强制要求，但建议配置。很多脚本和工具会读取它来定位 Tomcat 目录，配好之后避免后续在各种工具里反复选路径。配置完打开新终端，输入java -version和echo %CATALINA_HOME%（或echo $CATALINA_HOME）验证一下，比直接启动 Tomcat 更能确认环境变量有没有生效。

2.3 第一次启动用前台模式，别用 startup

新手最容易犯的错是双击startup.bat，看到一个黑窗口一闪而过就慌了。我自己的习惯是第一次启动一定用前台模式：Windows 下运行catalina.bat run，Linux 下运行catalina.sh run。这样 Tomcat 启动日志会直接打在当前终端，报错信息一屏看得清清楚楚，不存在“闪退找不到原因”的问题。

看到类似下面的输出，就说明启动成功了：

信息: Server startup in [4321] milliseconds

然后用浏览器访问http://localhost:8080，能看到 Tomcat 默认首页。如果页面打不开，先检查 8080 端口是不是被占了，再回头去看控制台日志。确认成功后，后续日常使用再切回startup.bat或startup.sh后台启动。

Tomcat 7 的默认配置里，HTTP 端口是 8080，关闭端口是 8005。这两个端口都写在conf/server.xml里，如果环境里有冲突，改掉后重启即可。

3. IDEA 里跑 Tomcat 的两种主流路子

3.1 企业版：Run Configuration 加 Tomcat Server

IDEA 企业版对 Tomcat 支持得很好。打开Run/Debug Configurations，点左上角+，找到Tomcat Server -> Local，然后在Application server区域点Configure，选中解压出来的 Tomcat 主目录即可。

重点是 Deployment 配置。点击Deployment标签页，+选Artifact，如果是 Web 项目一般会出现两兄弟：xxx:war和xxx:war exploded。我强烈建议调试阶段选war exploded，它把项目按目录结构展开部署，前端页面修改后刷新就能生效，而完整的 war 包每次修改都要重新打包，开发效率差距很大。

然后设置Application context，比如填/classic-web，那访问路径就是http://localhost:8080/classic-web。最后启动，IDEA 会自动拉起 Tomcat，控制台切走，等 “Server startup” 出来就能调试了。

3.2 社区版：用 Smart Tomcat 插件曲线救国

IDEA 社区版免费，但没集成 Tomcat Server 功能。解决办法是装一个名为Smart Tomcat的插件，在插件市场搜一下就能找到。装完重启 IDE，在Run/Debug Configurations里会出现一个Smart Tomcat配置项。

配置也很简单：Tomcat Server path选 Tomcat 解压目录，Context Path填项目上下文路径，Deployment选择war exploded或者直接选项目构建后的输出目录。它本质上是用 java 命令手动把catalina.classpath和你的项目输出目录拼起来启动，省去了社区版没有 Web 模块的麻烦。

实际用下来，Smart Tomcat 应付日常 CRUD 项目的调试完全够用。它的主要短板是没有完整的管理界面和 Deployment 热替换机制，改完 Java 代码后需要手动重启才能看到效果，但配合 IDEA 自带的 Build 和 Debug，调试逻辑已经足够顺手。

3.3 war 包部署路径与常见误区

从 IDEA 或 Maven 打包出来的 war 包，部署路径并不是什么神秘位置：扔到webapps目录下，重启或等 Tomcat 自动解压就行。Tomcat 7 默认开启了autoDeploy，它会检测 war 包变化并自动展开。

一个经常出现的误区是：改完代码重新打了 war 包，覆盖到webapps下，结果访问还是旧页面。这种情况十有八九是work目录里的旧编译缓存还在，停掉 Tomcat，删除work目录下的对应项目文件夹，再重启就好。另外，war 包正确部署后，logs下会生成类似localhost.2024-01-01.log的日志文件，里面记录了部署时报的异常，比浏览器里看到的 404 有用得多。

如果你不想把项目塞进webapps，也可以在conf/server.xml的 Host 节点下配一个 Context，用docBase指向外部的项目目录。但这种做法我建议只在开发联调时用，生产环境还是标准化 war 包，维护成本最低。

这里还顺带提一句：如果你用的是 Spring Boot 项目（比如常见的“诺依”框架），外部 Tomcat 和内嵌 Tomcat 会是两个容易互相干扰的存在。Spring Boot 默认内嵌 Tomcat 并占用 8080，如果同时开了外部 Tomcat 也监听 8080，启动必然报端口冲突。要打 war 包丢到外部 Tomcat 跑，需要在pom.xml里把spring-boot-starter-web的tomcat依赖排除掉，同时让启动类继承SpringBootServletInitializer并重写configure方法。这两步做完，外部 Tomcat 才能正常接管请求。

4. 启动慢、APR、线程池与 JVM 参数：把默认配置调顺手

4.1 启动慢的最常见原因

Tomcat 启动慢是个老话题。如果你在 Linux 上启动一个简单的空 Tomcat 都要几十秒甚至几分钟，第一个要怀疑的就是SecureRandom问题。JDK 在 Linux 上默认从/dev/random读取随机数，而/dev/random在没有足够系统熵时会阻塞等待，导致 Tomcat 卡在 SessionID 生成上。

解决办法是在启动脚本里加上 JVM 参数，让 JDK 从/dev/urandom读取随机数。在catalina.sh或catalina.bat顶部附近添加：

JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom"

注意这里写的是file:/dev/./urandom，中间有个多余的./，看着别扭，但这是网上流传广泛且实测有效的写法，能绕过某些 Java 版本的 bug，不要自作主张改成干净的路径。

另一个启动慢根源是 Jar 扫描。Tomcat 7 的JarScanner会扫描 webapp 下所有依赖 jar 去查找META-INF/web-fragment.xml和 TLD 文件，依赖多了启动自然慢。如果只是内部老系统，可以在conf/catalina.properties的org.apache.catalina.startup.ContextConfig.jarsToSkip列表里把无注解的通用 jar 加进去，减少扫描范围。不过这个配置改起来要小心，不认识的 jar 先别乱加，否则 JSP 标签库可能失效。

4.2 APR 那个红色提示是错误吗

启动 Tomcat 时看到一行红色英文字母，写着The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path。不少第一次见的人以为 Tomcat 坏了，跑过来问“启动失败”。

它不是错误，只是一个提升性能的建议。APR 是 Tomcat Native 库，利用操作系统层面的特性优化 IO 和内存使用。没有它，Tomcat 走的是 JVM 自带的 NIO/BIO 通路，完全不影响正常运行。如果只是开发调试，看到这行字忽略即可。

如果确实要装，Windows 平台需要下载tcnative-1.dll放到PATH能找到的目录，Linux 需要安装libtcnative相关的系统包，装完后重启就能看到Loaded APR based Apache Tomcat Native library之类的提示。说实话，在 7.x 版本上，APR 主要对静态文件传输和 SSL 有一定提升，老项目用不上就不必折腾。

4.3 线程模型和线程池怎么调才有效

Tomcat 7 默认的 HTTP Connector 用的是 BIO 模型，也就是一个请求占一个线程，线程粒度比较重。面对长连接或高并发场景，这种模型很快会把线程池打满。

如果你要优化，可以在conf/server.xml的 Connector 上把 protocol 改成 NIO：

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="400" minSpareThreads="40" acceptCount="200" connectionTimeout="20000" redirectPort="8443" />

NIO 模型下，一个选择器线程可以同时监控大量连接，线程不再和请求一一对应。说回热词里那个“Tomcat 里一个线程对应 Linux 线程”的问题：在 HotSpot JVM 里，Java 线程和操作系统内核线程基本是一对一映射的，每个 Java 线程最终会对应一个内核级线程；但 Tomcat 的请求处理线程池和 NIO 选择器线程不是同一个概念，BIO 模式下一个连接占一个 Tomcat 工作线程，NIO 模式下连接被 Selector 管理，工作线程只是在数据就绪时才被分配过去。

线程池参数也别盲目调大。maxThreads默认 200，对绝大多数内部系统都够用。调得太大，线程上下文切换开销反而拖垮性能；而且线程池大小要和应用后端的数据库连接池、下游接口耗时一起估算，比如每个请求阻塞在数据库 200ms，那你线程开 500 个，数据库连接池只有 50，等着排队的效果和 200 个线程基本没差。

更精细的做法是定义独立的 Executor：

<Executor name="myExec" namePrefix="catalina-exec-" maxThreads="300" minSpareThreads="30" maxQueueSize="200"/> <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" executor="myExec" ... />

这种方式把线程池从 Connector 里解耦出来，多个 Connector（比如 HTTP 和 HTTPS）可以共用同一个池。

5. 折腾中遇到的问题排查实录

5.1 启动闪退与端口占用

Tomcat 启动闪退，九成以上是环境变量配置问题。Windows 双击startup.bat后窗口一闪就没，先打开命令行手动执行catalina.bat run，这样错误信息会留在终端里。最常见的是JAVA_HOME没配好，或者配到了 JRE 目录而不是 JDK 目录。

端口占用是第二大类。启动时报Address already in use: JVM_Bind，那就是端口被别的进程占了。Windows 下用命令行查：

netstat -ano | findstr 8080 taskkill /F /PID 进程号

Linux 下用：

ss -lntp | grep 8080 kill -9 进程号

需要注意别只查 HTTP 端口 8080，Tomcat 的关闭端口 8005 也可能冲突。有时候防火墙或 Docker 转发规则会把 8005 悄悄占掉，启动日志里能看到Server.close相关异常。两个端口一起确认，省得反复启动失败找不到原因。

5.2 RMI TCP Connection 线程是从哪来的

有人用 jstack 或 jconsole 查看 Tomcat 进程时会发现不少名为RMI TCP Connection的线程，以为是什么恶意连接。这些线程不是 Tomcat 处理 HTTP 请求的工作线程，而是 JVM 自带的 JMX/RMI 通信线程。

来源主要有两个。一个是 JVM 参数里开了 JMX 远程管理，比如启动脚本里有-Dcom.sun.management.jmxremote之类的配置，JVM 会启动 RMI 注册服务和 TCP 连接监听线程。另一个是 IDE 调试 Tomcat 时，IDEA 会自动往 JVM 里注入 JMX 参数来获取进程状态，所以你自己没配过也会有这些线程。

排查方法很简单：看启动日志和启动命令。如果是在 IDEA 里跑的，那基本是 IDE 加的参数；如果是独立服务器上出现，查一下catalina.sh或环境变量里的JAVA_OPTS有没有相关配置。不需要刻意去杀这些线程，正确做法是去掉不需要的 JMX 配置然后重启。

5.3 优雅关闭与强制关闭

正常情况下，关闭 Tomcat 用shutdown.sh或shutdown.bat。它会向关闭端口（默认 8005）发送一条SHUTDOWN命令，让 Tomcat 走完清理流程再退出。

但实际运维中经常遇到关闭脚本执行后半天不退出，那是因为 Web 应用里还有非守护线程活着，Tomcat 在等待线程池回收。这时候只能强制结束：Linux 可以先kill（对应 SIGTERM），给它几秒时间，再不行就kill -9。快捷一点的命令：

pkill -9 -f "catalina"

这会按命令行匹配杀掉所有 Tomcat 相关进程，切记在服务器上执行前先确认匹配范围。Windows 下taskkill /F /IM java.exe会把所有 Java 进程一起干掉，如果机器上跑了别的 Java 服务，慎用。从稳妥角度讲，shutdown.sh后等 10 秒，再检查进程是否还在，最后才上kill -9，这个顺序才是完整的“优雅关闭”。

5.4 高频问题速查表

还有一点要单独说：conf/web.xml是全局部署描述符，它会被所有 web 应用继承，conf/server.xml、conf/context.xml同理。改这三个文件之前，先备份。我见过有人在全局web.xml里加了自定义过滤器，直接导致所有应用启动异常。能用应用自身WEB-INF/web.xml解决的，就别去动全局配置。

最后再说两句

接手老项目时最忌讳“手痒升级”。Tomcat 7.0.108 配 JDK 8 是很多系统验证过的稳定组合，只要你不用它暴露公网、不追求 HTTP/2 这类新特性，它就能一直安静地跑下去。平时排查问题时也多看logs目录和work目录，这两个地方能解释绝大多数“诡异现象”。

如果后续真要迁移，我的建议是先在测试环境用同一份 war 包分别跑 Tomcat 9 和 10.1，观察依赖兼容性，再决定改造成本。老系统最怕的从来不是版本旧，而是没有任何预案的原地升级。先跑通、再调优，永远比先调优、再跑通靠谱。

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