企业官网建设流程全解析

说实话，这些年帮人排查Tomcat问题，最冤的一种情况就是项目代码本身没问题，栽在第一步"下载"上：有人从搜索引擎前几名的软件站下了个捆绑全家桶的Tomcat，有人装了Tomcat 10跑一个Servlet老项目，结果一启动全是ClassNotFoundException，还有人拿着8.0的远古包配JDK 17，启动日志刷了一屏警告没当回事，等上线才炸。今天这篇就围绕"Tomcat 8安装包下载"这件事，把下载前、下载中、下载后的关键判断一次说清楚。这篇内容适合正在给老项目配环境的人，也适合第一次独立搭Tomcat的同学——先把版本匹配、下载渠道、完整性校验这几件事弄明白，后面配置和部署才会顺，不然坑全在后面等着你。

1. 下载前先做版本判断题，能省一整天折腾时间

很多人下载Tomcat的姿势是：打开官网，看到8就点，下完解压就跑。这么干不是不行，只是后面大概率要返工。下载这个动作本身不费时间，费时间的是你选错版本之后一连串的启动报错和依赖冲突。

1.1 Tomcat 8.0、8.5和9.0，到底该下哪个

先说一个容易被忽略的事实：Tomcat 8这个系列并不是一个版本，它分成了8.0.x和8.5.x两条线，而且两条线的命运完全不同。

Tomcat 8.0.x是最早的8系，对应Servlet 3.1规范，本身没有大毛病，但Apache官方早就把重心转移到了8.5。8.5.x看起来只比8.0多了个"5"，实际上它内部做了大量修复和优化，同时继续沿用Servlet 3.1规范，也就是说8.5对老项目的兼容性和8.0几乎是一样的，但坑更少、维护更久。社区里大家默认说的"Tomcat 8"，基本都是指8.5.x，而不是8.0.x。如果照着几年前的教程下载，很可能会拿到8.0的老包，不是不能用，但没必要。

Tomcat 9.0.x则是另一个物种，对应Servlet 4.0规范，最低要求JDK 8。它和8.5在接口层面大部分项目可以直接平移，但如果你的项目里用了某些老框架对Servlet版本敏感，迁移后还是可能出现奇怪问题。所以分不清版本时就记住一条原则：老项目求稳选8.5.x，新项目求新选9.0.x或更高，8.0.x只适合项目组明确指定必须用它的情况。

1.2 JDK版本匹配关系与"支持Java 21"的真相

热词里有个"支持java21的tomcat"，这个问题我单独说一下。Tomcat 8.5官方最低运行环境是JDK 7或8，但"最低"不等于"随便配多高都行"。你把Tomcat 8.5硬跑在JDK 17甚至JDK 21上，很多场景确实能启动，但要注意几个实际问题：

第一，JDK高版本对非法反射访问管得越来越严，Tomcat内部某些组件如果依赖了被移除的API，启动时会出现警告甚至直接抛异常。第二，Tomcat 8.5的老应用里如果用了CGLIB、旧版MyBatis这类依赖，在JDK 17以上环境极容易踩模块化限制。第三，Apache官方对Tomcat各版本支持的JDK范围是有明确说明的，真要跑Java 21，官方推荐的是Tomcat 10.1.x或11.x，而不是8.5硬凑。

所以这里有个非常容易混淆的点：热词里搜"支持java21的tomcat"，往往是想知道哪个版本能用，但正确答案是"能不能用"和"官方推不推荐"是两码事。对于生产环境，我建议你严格按照官方支持矩阵来选，别拿8.5去赌Java 21的兼容性。

顺带把JDK、Maven、Tomcat三者的配合关系说透。Maven版本本身不直接约束Tomcat，但Maven编译时的target版本会直接影响class文件的字节码版本。如果Maven里配的是<maven.compiler.target>17</maven.compiler.target>，而Tomcat跑在JDK 8上，部署后必报UnsupportedClassVersionError。反过来也一样，JDK 8编译的class放到JDK 17的Tomcat上基本没问题，但老容器跑新字节码就一定报错。这个坑在热词"jdk tomcat maven版本匹配"里被反复搜，说明踩的人真不少。

1.3 配套组件版本（Maven、IDE）的匹配逻辑

Maven项目里最简单稳妥的做法是把编译版本锁死在JDK 8：

<properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>

这样无论开发机装的是JDK 11还是17，编译产物都保持在1.8字节码级别，放到Tomcat 8.5上是安全的。这里还有个小经验：如果本地同时装了多个JDK，一定要在IDEA的Maven配置里指定同一个JDK，否则编译用的JDK和运行Tomcat的JDK不一致，很容易出现"我本地能跑、测试环境不能跑"的诡异问题。

IDE方面，IDEA 2024.2、Eclipse最新版对Tomcat 8.5的识别都很成熟，但记住一个前提：IDE只是把Tomcat当成一个外部应用来管理，它不负责替你判断版本匹配。你在IDEA里配Tomcat之前，先把Java环境变量和Tomcat版本关系理清楚，否则配置界面再友好也没用。

2. 官方下载、镜像加速与安装包完整性校验

确认好版本之后，第二步就是搞清楚从哪下载。这看起来最简单，实际是翻车率最高的环节。搜索框里输入"Tomcat 8安装包下载"，前排那一堆结果十有八九不是官方，点进去全是"高速下载""一键安装"，装完桌面多出一堆全家桶。下面这套流程是我自己长期在用的，照着走基本不会中招。

2.1 官方下载页面怎么看，哪些文件才是真正需要的

Tomcat官网下载入口在tomcat.apache.org，进入后找到"Tomcat 8"的下载页，页面里列了一堆文件。很多人第一次看直接懵，不知道该下哪个。

核心要下的是Binary Distributions下的Core列，这才是我们平时说的Tomcat本体。具体到文件：

• apache-tomcat-8.5.100.zip：通用二进制的压缩包，Windows和Linux都能用，解压即安装。
• apache-tomcat-8.5.100.tar.gz：Linux上更常用的压缩格式，和zip内容一致。
• apache-tomcat-8.5.100-windows-x64.zip：Windows专用包，里面额外带了一些Windows原生组件，如果计划注册成Windows系统服务，建议用这个。
• apache-tomcat-8.5.100.exe：Windows Service Installer，图形化安装向导，会自动注册Windows服务，适合不想碰命令行的人。

另外那一堆带src、full documentation、deployer前缀的不用管。Deployer是运维做远程部署扩展用的，普通开发者用不上；Full documentation是文档，不是安装包。

2.2 下载提速：镜像站与版本归档仓库的正确用法

Tomcat官方服务器在国外，直接下载偶尔会慢，可以用国内开源镜像站。清华、阿里、华为等镜像站都同步了Apache目录，路径一般是apache/tomcat/tomcat-8/。下载时进到对应版本目录，比如v8.5.100/bin/，再选你需要的压缩包就行。

还有一类情况是镜像站最新版本还没同步，或者项目里指定了某个历史版本，这时候去版本归档仓库比在官网目录里翻方便得多。Apache的历史归档地址是archive.apache.org/dist/tomcat/，从tomcat-8目录下能看到所有历史版本目录，要找指定版本号直接改路径就行。

这里有个实用技巧：Tomcat的版本号是固定的，官网下载页展示的通常是最新Release。如果你想下载某个特定修复版本，直接在归档站按版本号找，比如tomcat-8/v8.5.100/bin/这一层目录，比在官网页面上翻链接直观得多。

2.3 下载之后立即做的完整性校验（SHA-512实操）

下载完先别急着解压，养成校验哈希的习惯。这一步的作用是确保你拿到的文件在传输过程中没有被损坏，也没有被第三方替换成被植入恶意代码的版本。截断的压缩包会导致解压失败，被替换的版本则是安全隐患，两种情况的成本都比校验那十几秒高得多。

Linux下校验tar.gz包，下载页面里有个.sha512后缀的校验值文件，可以这样对比：

sha512sum apache-tomcat-8.5.100.tar.gz

把输出值和官方给出的SHA-512字符串逐个对比，完全一致才通过。更偷懒的方法是直接用-c参数校验：

echo "官方sha512值 apache-tomcat-8.5.100.tar.gz" | sha512sum -c -

Windows下用PowerShell，命令是：

Get-FileHash .\apache-tomcat-8.5.100-windows-x64.zip -Algorithm SHA512

如果追求更高的防篡改级别，还可以用PGP签名校验。官方下载目录里有.asc签名文件和KEYS公钥文件，操作流程是：先用gpg --import KEYS导入官方公钥，再执行gpg --verify 文件名.asc 安装包。这套流程比SHA-512更严谨，但对个人开发者来说，SHA-512校验已经能挡住绝大多数问题。

2.4 第三方下载站的陷阱

我不建议从非官方非镜像的下载站拿Tomcat，原因很简单：Tomcat是Apache基金会下的开源项目，本身就是免费的，第三方下载站没有理由帮你"加速""优化"，他们给你装的东西要么打包了推广广告，要么替换了核心文件，要么捆绑了全家桶软件。实践中我见过最严重的例子是，某下载站的"安全版Tomcat"里被塞了挖矿程序，部署到服务器上之后CPU飙到接近100%，排查了大半天才发现是安装包的问题。

判断一个下载源靠不靠谱，就三条：看域名是不是官方或知名镜像站点，看文件体积是否正常（Tomcat 8.5的zip包在10MB左右，如果只有几MB或者几十MB，都要警惕），看有没有提供SHA-512校验文件。不符合任何一条的，宁可多等一会儿从官方源下，也别贪快。

3. Windows和Linux两种安装方式的完整落脚点

下载校验完成之后才真正进入安装环节。这里分别讲Windows和Linux两条路径，因为两条路径的踩坑点完全不同：Windows上最大的坑是环境变量和路径空格，Linux上最大的坑是权限和进程管理。

3.1 Windows环境下解压、环境变量与启动答疑

Windows上安装Tomcat非常简单，解压zip包就能用，但解压路径有讲究。我习惯把Tomcat放到D:\server\apache-tomcat-8.5.100这种无空格无中文的路径下，不推荐放到C:\Program Files目录。虽然Tomcat本身并不禁止带空格路径，但后续你在Maven插件、IDEA部署、脚本调用时，路径带空格经常会莫名其妙地让某些配置解析失败，何必给自己埋雷。

解压后先配环境变量。JAVA_HOME指向JDK安装根目录，路径里不要带bin，比如C:\Program Files\Java\jdk1.8.0_202。CATALINA_HOME指向Tomcat解压根目录，比如D:\server\apache-tomcat-8.5.100。然后在Path变量里追加%JAVA_HOME%\bin和%CATALINA_HOME%\bin。

为什么要专门设JAVA_HOME？因为Tomcat的启动脚本在找Java时，会优先读这个变量。如果你不设，脚本会去PATH里找java.exe，这样存在一个隐患：机器上装了多个JDK时，你永远不知道当前启动Tomcat的到底是哪个JDK，编译和运行环境不一致的问题就是这么来的。把所有路径都显式配置好，启动的就是你预期的那一个。

启动方式有两种。第一次建议在bin目录下打开命令行窗口，执行catalina.bat run在前台运行，这样所有日志都直接打在控制台，出问题能立刻看到。如果直接用startup.bat，启动窗口一闪而过，很多新手都不知道去哪看错误，误以为Tomcat坏了。启动成功后浏览器访问http://localhost:8080，能看到Tomcat主页就基本算成功了。

如果你想把Tomcat注册成Windows服务，在bin目录下执行：

service.bat install Tomcat8

然后到Windows服务管理里找到Apache Tomcat 8.5 Tomcat8，设置启动类型并启动即可。想卸载服务就用service.bat remove Tomcat8。

3.2 Linux环境下解压、用户隔离与systemd托管

Linux上推荐用tar.gz包。假设包已经下到/opt目录，执行：

tar -zxvf apache-tomcat-8.5.100.tar.gz -C /opt

接下来有一件事很多人会忽略：不要长期用root用户跑Tomcat。Tomcat本质是一个Web应用容器，只要里面部署的应用有一个远程命令执行漏洞，攻击者拿到的权限就是Tomcat进程的权限。如果直接用root跑，风险直接拉满。正确做法是单独建一个普通用户：

groupadd tomcat useradd -g tomcat -d /opt/apache-tomcat-8.5.100 tomcat chown -R tomcat:tomcat /opt/apache-tomcat-8.5.100

启动前先确认环境变量。如果系统里已经配好JAVA_HOME，直接执行/opt/apache-tomcat-8.5.100/bin/startup.sh就行；如果没配，至少要在启动前声明：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk

Linux下我更推荐用systemd托管Tomcat，这样开机自启、崩溃自动拉起、日志统一管理都比裸启动脚本强得多。在/etc/systemd/system/tomcat.service里写：

[Unit] Description=Apache Tomcat 8.5 After=network.target [Service] Type=simple User=tomcat Group=tomcat Environment="JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk" ExecStart=/opt/apache-tomcat-8.5.100/bin/catalina.sh run ExecStop=/opt/apache-tomcat-8.5.100/bin/catalina.sh stop Restart=on-failure [Install] WantedBy=multi-user.target

保存后执行systemctl daemon-reload，再systemctl start tomcat，用systemctl enable tomcat设置开机自启。这里的关键是ExecStart必须用catalina.sh run，不要用startup.sh，因为run模式是前台运行，systemd才能真正接管这个进程；用startup.sh的话，Tomcat会自己fork一个后台进程出来，systemd会误以为服务已经退出了。

启动后别忘了检查防火墙，云服务器还要在安全组里放行8080端口，不然本地能访问、外部访问不了。

3.3 启动界面验证与目录结构说明

Tomcat启动后访问主页，左侧有Server Status、Manager App等入口，点进去会提示权限不足。这是正常的，需要先配置管理用户。在conf/tomcat-users.xml里添加：

<role rolename="manager-gui"/> <user username="admin" password="改成你自己的强密码" roles="manager-gui"/>

改完重启Tomcat，就能在Manager App里看到已部署的应用列表了。这个界面配合热词里的"tomcat部署web项目"，能省不少事，可以直接在页面上传war包、查看应用状态。

顺手把Tomcat目录结构过一遍：bin是启动和关闭脚本，conf是所有配置文件，lib存放公共JAR包，logs是日志目录，webapps是Web应用部署目录，work是JSP编译后的临时目录。遇到任何启动异常，第一反应先去logs目录看两个文件：catalina.out是主日志，localhost.log里有应用部署时的异常堆栈。我把这当作黄金法则——先看日志再百度，效率完全不一样。

4. 启动阶段四类高频报错的排查清单

下载和安装本身不难，真正让新手崩溃的是启动阶段的报错。这里把几个被搜烂了的高频问题集中讲一遍，每一类我都给排查思路，而不是只给一个"直接改成这样"的答案。

4.1 启动闪退与JAVA_HOME定位

Windows下双击startup.bat窗口一闪而过，是最经典的问题。原因就是启动脚本执行失败，但窗口关了看不到错误。正确打开方式是在bin目录下开命令行执行catalina.bat run，错误信息会留在屏幕上。

排查顺序先看JAVA_HOME是否配置正确。注意区分两点：一是JAVA_HOME必须指向JDK根目录，不是bin目录，也不是JRE目录，Tomcat启动不仅需要java.exe，还需要JDK里的工具类；二是如果本地装了多个版本的JDK，JAVA_HOME和PATH里实际生效的版本可能不一致，在命令行执行java -version确认一下。

后台跑一个Tomcat，又在bin目录下双击一次startup.bat，窗口同样会闪退，但原因不是配置问题，而是端口被自己的旧进程占用了。这种隐蔽情况通过看logs/catalina.out里的报错就能区分。

4.2 "/dev/random"拖慢启动速度的真相与处理

Linux上Tomcat启动慢是最容易被误判的问题之一。症状是Tomcat已经执行了startup，日志里停在Deploying web application archive很久，项目不大但启动就是能卡几十秒甚至几分钟。

根因是JDK里的SecureRandom在某些场景会读取/dev/random，而虚拟机、云主机里的熵池普遍不足，读取操作会阻塞在等待系统产生足够熵上。Tomcat在生成Session ID、UUID等场景都要用到随机数，于是启动过程就被卡住。

最常见的解决办法是在setenv.sh里加一条JVM参数：

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

/dev/urandom和/dev/random的区别可以简单理解为：后者是阻塞式的，熵不够就等；前者是伪随机的，速度很快，安全性在绝大多数业务场景下完全够用。

但这只是一条缓解措施。如果服务器熵池实在太小，更治本的办法是安装rng-tools或haveged这类工具来扩充系统熵池，尤其在容器环境里。我遇到过一次极端情况，一台虚拟机无论怎么加egd参数启动都慢，后来装了haveged就正常了。所以遇到这种问题，先加JVM参数，再用cat /proc/sys/kernel/random/entropy_avail看一眼当前熵池值，如果长期低于几百，就考虑从系统层面解决。

4.3 "The APR based Apache Tomcat Native library..."是警告还是错误

启动日志里有一行：

The APR based Apache Tomcat Native library which allows optimal performance was not found on the java.library.path

很多人看到"not found"就紧张，以为环境坏了。这其实只是INFO级别的提示，不是错误。它的意思是当前Tomcat没有加载到APR/Native库，所以会用Java实现的方式处理网络连接。对开发环境和中小型项目来说，性能差异根本感知不到，完全可以不理会。

如果想消除这个提示或者追求更高性能，Linux下最省事的方式是装系统自带的Tomcat Native库，比如Debian/Ubuntu上执行apt install libtcnative-1，装好后再启动日志里就不会再报这个提示了。Windows下官方发行包里本来就有tcnative-1.dll，一般也不会出现这条提示。总之这个看到就当没看到，不影响任何功能。

4.4 "Address already in use"端口占用排查

启动时报Address already in use，或者访问8080端口出来的是另一个应用页面，基本就是端口被占用了。Linux下排查：

lsof -i :8080 netstat -tlnp | grep 8080

找到占用进程的PID后先确认是不是你自己的旧Tomcat进程，如果是就按第6节讲的流程正常关闭；如果是别的服务占了8080，可以换端口，改conf/server.xml里Connector的port属性就行。Windows下对应命令是：

netstat -ano | findstr 8080 taskkill /PID <pid> /F

4.5 后台的"RMI TCP Connection"线程扫描

有段时间经常有人在论坛问：用jstack查看Tomcat线程时，发现一堆RMI TCP Connection(idle)线程，这算不算内存泄漏？这些线程是在Tomcat启用JMX管理时，JVM的RMI连接器为了接受JMX客户端连接而创建的。正常情况下它们大部分时间处于idle状态，占用资源很少，不是内存泄漏。

判断标准很简单：如果线程数量稳定，空闲连接数没有无限增长，就没有问题；如果怀疑有异常，用lsof -p <tomcat_pid> | grep TCP看socket连接数，再配合JConsole连接一次观察连接释放情况。一般不会出问题，不必强杀。

5. 下载完成后的典型部署问题：从war包到IDE配置

装好Tomcat之后，紧接着就是部署JavaWeb项目。下面这堆问题都是热词里被高频搜索的，我按实际使用频率逐个拆解。

5.1 war包到底部署到哪个目录，真实部署路径

web应用最常见的形式是war包，正常情况下把它丢到$CATALINA_BASE/webapps/目录，重启Tomcat后就会自动解压部署。访问路径默认就是war包的文件名，比如myapp.war放到webapps下，访问地址就是http://localhost:8080/myapp/。

如果不想用war包文件名作为访问路径，两种做法：一是直接改war包文件名，简单粗暴；二是用Context配置指定docBase指向外部目录。在conf/Catalina/localhost/下新建一个myapp.xml，内容：

<Context docBase="/data/projects/myapp" reloadable="true" />

这样项目代码可以放在任意磁盘目录，不必复制到webapps里。这个机制也是IDE部署时经常用到的底层原理，理解了它你就能明白为什么IDEA里改了Tomcat的webapps目录，但实际部署的文件却没出现在里面——因为IDE根本不是用拷贝war包的方式部署，而是通过写这种Context文件把编译输出目录指向了Tomcat。

另外提醒一个经验：改了代码不生效时，先清空work目录下的缓存再重启，比反复重启靠谱得多。JSP编译产物缓存或静态资源缓存经常会给人"没改成功"的错觉。

5.2 IDEA配置Tomcat与"社区版能不能用"的澄清

网上问"idea社区版配置tomcat"的人特别多，答案是：社区版没有IDEA专业版里那个图形化的Application Server管理和Tomcat运行配置面板。但这不代表社区版不能配Tomcat，只是姿势要换一下——自己手动启动Tomcat，然后用远程调试的方式把IDEA连上去，这样照样能打断点、能热更新。

专业版的配置路径是：Settings -> Build Tools -> Application Servers里添加Tomcat Server，选择Tomcat安装根目录；然后在Run/Debug Configurations里新建Tomcat Server Local，在Deployment标签里添加Artifact。注意使用exploded war格式而不是war包，这样IDEA可以直接把编译输出目录映射给Tomcat，改代码后点"Update resources"就能热生效，不用每次重启容器。

远程调试配置也很简单。Tomcat所在的服务器上设置两个环境变量后启动：

export JPDA_ADDRESS=8000 export JPDA_TRANSPORT=dt_socket bin/catalina.sh jpda start

然后在IDEA里新建Remote JVM Debug配置，Host填服务器IP，Port填8000，点击Debug按钮就能连上。这个方法社区版、专业版通用，甚至不依赖IDE类型，因为本质是标准的JDWP调试协议。唯一要强调的就是：远程调试端口在生产环境千万不能开，等于把服务器大门钥匙递给攻击者。

5.3 ECLIPSE配置Tomcat的要点

Eclipse配置Tomcat的逻辑和IDEA类似。在Window -> Preferences -> Server -> Runtime Environments里点击Add，选择Tomcat版本，然后把Tomcat安装目录填进去。接着在Server视图中New一个Server，选中刚才配置的Runtime，就完成了。

有个新手迷惑点：Eclipse启动Tomcat后，访问度部署的应用是怎么发布的？Eclipse默认会把项目发布到工作空间目录下的.metadata/.plugins/org.eclipse.wst.server.core/里，而不是Tomcat的webapps目录。所以不要在Tomcat的webapps里找你Eclipse部署的项目，找不到是正常的。理解了上一节Context文件的知识，这个现象也就不奇怪了。

5.4 web.xml在全局配置与应用配置中的定位

conf/web.xml是Tomcat的全局部署描述符，配置会被所有应用继承。它里面定义了一些基础且重要的东西：默认Servlet、JspServlet的映射、MIME类型映射、默认欢迎文件列表、Session超时时间等。同一个配置项，如果应用自己的WEB-INF/web.xml也配置了，应用内的配置优先覆盖全局配置。

这个机制给建web.xml带来一个典型坑：有人为了让某个请求走静态资源处理，改动了全局web.xml里默认Servlet的url-pattern映射，结果导致项目里所有JSP请求全乱了，JSP文件甚至直接以源码形式返回给浏览器。所以提醒一句：不要随意改conf/web.xml里的默认映射，大多数时候你真正要改的是应用自己的WEB-INF/web.xml。

5.5 WebDAV等自带工程和扩展场景

下载官方完整版Tomcat后，webapps目录里默认带了好几个工程：ROOT是主页，docs是文档，examples是示例，manager和host-manager是管理后台。很多人下载所谓"精简版"把这些都删了，我倒建议学习阶段留一份原版，因为examples里的示例很直观，遇到Servlet、JSP、WebSocket问题直接看官方示例比自己瞎试快。

WebDAV工程是Tomcat自带的一个比较冷门的功能模块。它是一个基于HTTP的文件管理协议，如果要在Tomcat上启用WebDAV，需要到conf/web.xml里找到WebDAV servlet的定义并取消注释，再配置相应的认证。启用后可以像访问文件系统一样通过浏览器或WebDAV客户端管理文件。但这个功能默认不开放是有原因的，WebDAV涉及文件写入权限，配置不当直接在公网暴露了服务器目录，安全风险很高。个人学习可以折腾，生产环境我建议你直接用成熟的网盘方案，不要拿Tomcat硬凑。

6. 进阶分享：从外置Tomcat联想到的三类关联坑

到这里，Tomcat 8的下载安装和基本部署你已经能完整走通了。最后再分享三个从Tomcat延伸出来的高频问题，这几个问题在热词里也反复出现，虽然和"下载"本身关系不大，但都属于装完Tomcat之后一定会碰到的场景。

6.1 Linux下"杀掉Tomcat"的正确姿势

热词里有"linux tomcat关闭掉，怎么强制关闭"，说明很多人对shutdown.sh不信任，习惯性kill。先说结论：正常关闭流程是执行bin/shutdown.sh，然后等30秒左右检查端口是否释放。shutdown.sh会发一个关闭指令给Tomcat监听8005端口的管理通道，Tomcat收到后主动停止各个组件、等业务线程处理完成、清理资源，然后退出。

如果shutdown.sh执行后一直没退出，再考虑强制手段：

ps -ef | grep tomcat kill -9 <pid>

不到万不得已，不要上来就kill -9。强制杀进程会跳过Tomcat的清理逻辑，常见后果是：Web应用里的非守护线程直接中断，数据库连接池没来得及关闭，短暂时间内端口还被占用；work目录下的临时文件可能损坏；某些自定义的监听器里该执行的收尾代码全部被跳过。一次两次看不出来，次数多了早晚遇到脏数据问题。

如果业务上经常需要快速启动关闭，建议把第3节的systemd服务配好，用systemctl stop tomcat配合KillMode=control-group，并在service文件里设置TimeoutStopSec，比手动shutdown和kill都稳。

6.2 诺依这类Spring Boot项目如何去掉内置Tomcat

热词里提到的"诺依项目"（RuoYi）是常见的Spring Boot脚手架，它默认使用内嵌Tomcat。如果项目组明确要求把war包部署到已装好的外置Tomcat 8.5上，需要做三件事：

第一，在pom.xml里排除Spring Boot内嵌的Tomcat：

<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>

第二，单独加上Servlet API依赖，scope设置为provided，因为这要由外置Tomcat提供。

第三，打包方式从jar改成war，同时让启动类继承SpringBootServletInitializer并重写configure方法，Spring Boot才能被外置Tomcat按Servlet标准启动。

做这个改造之前先想清楚一件事：Spring Boot 2.x用的还是javax命名空间，配套Tomcat 8.5/9没问题；Spring Boot 3.x切换到jakarta命名空间后，必须用Tomcat 10.x，不然一启动直接报包找不到。很多人只排除了依赖，却忽略了命名空间切换，导致白白排查半天。

6.3 远程Tomcat部署的应用如何配合Jacoco统计覆盖率

最后说一个比较硬核但很实用的场景：如何对远程Tomcat上运行的应用做代码覆盖率统计。热词里的"远程tomcat部署的应用怎么使用jacoco统计代码覆盖率"，思路是在JVM启动时挂一个jacoco agent，让它对运行中的类做on-the-fly字节码插桩，然后通过JMX或者TCPServer方式把覆盖率数据导出。

具体做法是在catalina.sh里给JAVA_OPTS加上：

JAVA_OPTS="$JAVA_OPTS -javaagent:/path/to/jacocoagent.jar=includes=com.yourpackage.*,output=tcpserver,address=*,port=6300"

启动Tomcat后，jacoco agent会监听6300端口。本地执行mvn org.jacoco:jacoco-maven-plugin:dump -Djacoco.destFile=target/jacoco.exec -Djacoco.address=服务器IP -Djacoco.port=6300把执行数据拉回来，然后用mvn jacoco:report生成覆盖率报告。

这里要提醒两点：一是includes参数一定要限定到自己的业务包名，如果写成*会把Tomcat内部类的插桩也统计进去，生成的报告毫无参考价值；二是这个agent端口和远程调试端口一样，相当于给服务器开了一个数据传输通道，只允许在内网用，并且统计完立即摘掉。

把Tomcat 8的安装包下载这件事做到位，说实话不复杂，但每一步都值得认真对待。我自己帮人搭环境这么多年，最终的经验浓缩成一句话：把"下载"当成一个流程，而不是一个动作。先定版本，再选渠道，下载完花十几秒校验哈希，然后才进入安装配置。这个习惯帮我挡掉过不止一次坏包和不兼容版本。最后再补一个小技巧：把常用的Tomcat版本和对应JDK版本整理成一张对照表存起来，下次项目换环境时直接查表，比临时搜半天关键词高效得多。