简介Apache Tomcat 8.5.100 是应用广泛的开源 Java 服务器软件面向需要部署 Servlet 和 JSP 应用的开发者与系统运维人员可帮助他们快速搭建稳定高效的 Web 运行环境。该版本基于 Java EE 8 规范支持 Servlet 4.0、JSP 2.3 等新特性适配现代 Web 应用开发需求。这份压缩包共包含 623 个文件打包后体积约 10.38MB其中有 227 个网页文件、98 个字节码类文件、72 个 Java 源文件、59 个 JSP 动态页面、34 个 Java 归档依赖库还配有扩展名为 XML 的配置文件、Shell 和 Bat 启停脚本、样式表与脚本文件等能够满足安装配置、应用部署和二次开发等多种场景。包内默认带有启动与停止脚本以及 Room.class 等示例部件便于对照研究 Tomcat 的目录组成、部署机制和默认 Web 应用样例。已有 2025 人学习下载既适合 Java Web 初学者从零掌握服务器搭建流程也可供生产环境快速初始化基础服务或进行功能验证时参考。 搞了大半天的 Linux 服务器最后发现真正折腾人的不是业务代码反而是把一个 apache-tomcat-8.5.100.tar.gz 装对、配好、顺利跑起来。作为一个从 Tomcat 7 一路用到 9 的老部署选手我这些年在这上面踩过的坑、填过的土比写业务代码还多。这篇东西我不打算写成官方文档的复述就把我这次部署 Tomcat 8.5.100 时的完整思路、关键配置和排障过程摊开来讲尤其是那些容易忽略又特别影响后续使用的小细节希望看完你能少走点弯路。1. 为什么还是选 8.5这个版本到底强在哪1.1 8.5 在 Java Web 生态里的真实位置Tomcat 8.5 是 8.0 和 9.0 之间的过渡版本从规范层面看它实现的是 Servlet 3.1、JSP 2.3、EL 3.0 和 WebSocket 1.1。很多朋友一看“过渡版本”就觉得不靠谱其实恰恰相反8.5 的设计目标就是帮老项目平滑升级到新 IO 模型同时不强迫业务代码从 javax 迁移到 jakarta。对于还在跑 Spring 4、Spring 5、或者各种依赖 javax.servlet 的老系统来说Tomcat 8.5 是成本最低、兼容性最好的那一档。我们这次要部署的是一个企业内部的报表管理系统代码里大量使用javax.servlet.http.HttpServlet和旧式 web.xml 配置如果贸然上 Tomcat 10 或者 11光改包名就得忙活大半天还要面对不少第三方库版本冲突问题。用 8.5.100 就完全没有这种顾虑解压之后直接把 war 丢进去基本是原生态无缝跑起来。1.2 8.5.100 这个版本号意味着什么Tomcat 的版本号规则很有意思8.5.100 属于 8.5 分支的后期维护版本。到了这个阶段官方修复了大量安全漏洞和稳定性 bug例如连接器在高并发下的异常处理、WebSocket 协议的边缘场景等都经过了长时间社区验证。对于生产环境来说“老版本的最新补丁号”是性价比极高的选择因为它的功能特性经过多年打磨又不像大版本升级那样需要迁移改造风险相对可控。我个人的习惯是能用稳定维护版就别用刚发布的大版本除非项目有明确的新规范需求。尤其很多公司内部的服务器环境还停留在 CentOS 7 或类似的老系统安装包自带的 glibc、openssl 版本都比较旧Tomcat 8.5 对这类环境的兼容性也比新版好得多。1.3 tar.gz 格式比 zip 更适合服务器部署的原因既然标题是 apache-tomcat-8.5.100.tar.gz就绕不开 tar.gz 这个话题。很多人困惑官网明明也提供 zip 包为啥服务器上大家默认都用 tar.gz。这其实是 Linux 使用习惯造成的。tar 本来只是归档工具gzip 负责压缩两者合在一起就成了 Linux 世界最通用的分发格式几乎所有发行版都内置了 tar 命令而 zip 在某些最小化安装的机器上还需要额外装 unzip。更重要的是权限信息能被保留。tar.gz 包从官方站点下载后自带的 bin 目录里所有脚本本来就有执行权限同时各类配置文件权限也正常解压完就能直接跑。用 zip 包的话解压后 bin/*.sh 经常会丢执行权限你还得手动 chmod x多一步操作不说还特别容易漏。这个坑我一开始部署时踩过后来凡是上生产机器一律优先找 tar.gz。2. 下载、解压与安装前的几项检查2.1 获取安装包的途径既然是 apache-tomcat-8.5.100.tar.gz下载渠道一般就两个Apache 官网的 /dist/tomcat/tomcat-8/ 目录或者国内镜像站。官网下载时注意选 tar.gz 那个文件同时建议把同目录下的 sha512 校验文件也一起下载校验一下哈希防止文件在下载过程中损坏或被篡改。wget https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.100/bin/apache-tomcat-8.5.100.tar.gz wget https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.100/bin/apache-tomcat-8.5.100.tar.gz.sha512校验方式是sha512sum -c apache-tomcat-8.5.100.tar.gz.sha512看到返回 OK 再继续否则重新下载不要硬着头皮解压。很多时候启动报错根源就是安装包不完整。2.2 解压一句话命令和一目录规划拿到 tar.gz 后解压前建议先确认一下目标目录是不是有空间毕竟 Tomcat 解压后差不多百来 MB 大小日志跑久了还会膨胀。解压命令如下tar -zxvf apache-tomcat-8.5.100.tar.gz如果你用的 tar 版本较新也可以直接tar -xzf apache-tomcat-8.5.100.tar.gz效果一样。解压后得到目录 apache-tomcat-8.5.100我一般习惯把它移动到 /usr/local/tomcat 这种不带版本号的位置好处是以后升级不用改一堆脚本里的路径引用。mv apache-tomcat-8.5.100 /usr/local/tomcat接下来看一眼目录结构bin 是所有启动停止脚本的所在地conf 放着 server.xml、web.xml 这些核心配置webapps 默认是应用部署目录logs 记录运行日志lib 里全是 Tomcat 自身运行需要的 jar 包。这个结构从 Tomcat 5 到现在都没大的变化熟悉一遍后面排障会顺手很多。2.3 安装前必须先确认 JDK 版本Tomcat 本身是 Java 写的没装 JDK 一切都白搭。Tomcat 8.5 最低要求 Java 7但到 8.5.100 这个阶段官方建议直接用 Java 8 或更高版本。如果你的项目用到了 Java 11 的语法特性也可以跑在 8.5 上等于 Tomcat 是向上兼容的只要别用 Java 7 编译 class 文件再丢给高版本 Tomcat 就行。安装 JDK 后检查一下版本确保 JAVA_HOME 指向正确java -version echo $JAVA_HOME如果 JAVA_HOME 没配置Tomcat 启动脚本会直接用 PATH 里的 java 命令这种方式容易在系统里装了多个 JDK 时踩雷明明 java -version 是 1.8结果 Tomcat 跑起来用的是另一个目录下的老版本。建议把 JAVA_HOME 写进 /etc/profile 或者 /etc/environment一劳永逸。3. 正式使用前要动的那几个配置文件3.1 server.xml端口、Host 和 Connector 的关系Tomcat 安装完成先别急着启动跟我一样先把 conf/server.xml 打开看一遍。这个文件是整个 Tomcat 的枢纽主要包括 Server、Service、Connector、Engine、Host 这几个层级关系可以把它理解成一个俄罗斯套娃最外层是 Server 管理整个 Tomcat 生命周期里面是 ServiceService 里面再挂连接器和引擎引擎下面又有虚拟主机。最常见的改动是端口。默认 HTTP 连接器监听 8080 端口如果这台机器上已经有别的服务占了 8080就需要改端口Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 /把 port 改成 8090 或者你需要的其他空闲端口再顺手把 redirectPort 从 8443 改成 8443 或其他 SSL 端口。改完端口还要记得检查防火墙很多次我明明 Tomcat 起来了浏览器就是访问不了最后发现是 firewalld 没放行端口。连接器里的 connectionTimeout 表示建立连接后等待读请求的超时时间默认 20 秒如果是在内网高并发场景可以适度调小防止大量慢速连接占据线程资源。maxThreads 我一般也会根据机器核数调整比如 8 核机器设置 400 到 600别盲目开上千线程调度开销反而拖慢性能。3.2 用 setenv.sh 统一管 JVM 参数很多刚接触 Tomcat 的同学喜欢直接修改 catalina.sh 来调 JVM 参数我强烈建议别这么做。catalina.sh 是官方脚本升级 Tomcat 时会被整个覆盖你改的东西全没。正确做法是在 bin 目录下新建 setenv.shTomcat 启动时只要检测到这个文件就会自动加载里面的变量。我这次给报表系统设置的 JVM 参数是这样的export CATALINA_HOME/usr/local/tomcat export CATALINA_BASE/usr/local/tomcat export JAVA_HOME/usr/local/java/jdk1.8.0_202 export JAVA_OPTS-server -Xms1024m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -Dfile.encodingUTF-8-Xms 和 -Xmx 分别是最小堆和最大堆生产环境建议设成一样的值避免运行过程中堆扩容带来的性能抖动。MetaspaceSize 是元空间初始大小8.5 已经不用永久代了老项目迁移过来要注意改这个参数否则默认值太小加载类一多就容易撑爆。创建setenv.sh 后记得要给它执行权限chmod x /usr/local/tomcat/bin/setenv.sh3.3 开启 manager 应用和管理员用户Tomcat 默认关闭了 manager 和 host-manager 两个管理应用如果希望通过网页部署应用就需要在 conf/tomcat-users.xml 里配置用户角色。这里有一个安全习惯要养成管理账号密码别设置太弱别用 admin/admin 这种组合不然 Tomcat 暴露在公网就非常危险。role rolenamemanager-gui/ role rolenamemanager-script/ user usernamedeployer password这里换成强密码 rolesmanager-gui,manager-script/配置完重启 Tomcat就能通过 http://ip:8080/manager/html 访问管理控制台。如果只想让本地局域网访问管理页面可以在 conf/Catalina/localhost/manager.xml 里加个 Valve 配置来限制来源 IP具体就不展开了生产环境必做。4. 启动、验证与部署应用的实操过程4.1 启动 Tomcat 的操作细节配置都改好了第一次启动可以前台运行方便直接看日志判断有没有报错/usr/local/tomcat/bin/catalina.sh run看到类似INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [4326] milliseconds就说明启动成功。前台模式适合排障确认没问题后再改用后台方式/usr/local/tomcat/bin/startup.sh停止服务用 shutdown.sh但它可能不会立刻杀干净所有进程如果遇到端口还没释放的情况用 ps 查一下再手动 killps -ef | grep tomcat kill -9 pid很多人一开始不理解 shutdown 为什么会残留进程其实就是应用里还有非守护线程没退出。这种情况我也遇到过最稳妥的做法是配置好应用里的线程池在 contextDestroyed 时把线程都清理掉否则每次重启都得手动 kill。4.2 部署 War 包的两种常用方式第一种最简单把打好的 war 包直接丢进 webapps 目录Tomcat 会自动解压并部署。注意同一名称的 war 包不要重复放置否则可能触发重复部署导致冲突。cp /data/app/report.war /usr/local/tomcat/webapps/第二种是图形化部署用前面配置好的 manager 页面进入后选择 war 包点击部署Tomcat 会自动处理文件名和上下文路径。这种方式对小团队日常更新应用比较友好但我个人更建议走自动化脚本因为网页操作无法标准化也少了日志留痕。4.3 日志是判断健康状态的第一手资料部署完第一个 war 包后一定要学会看 logs 目录下的日志。catalina.out 记录整个 Tomcat 生命周期信息localhost.log 记录虚拟主机相关的请求和异常manager.log 记录管理应用的操作记录。比如要确认一个应用是否部署成功直接tail -f /usr/local/tomcat/logs/catalina.out看到Deployment of web application archive [report.war] has finished就说明成功了如果出现SEVERE开头的错误那八成是代码或者依赖有问题从这里开始排查比瞎猜快得多。5. 实际部署中常见问题与排查技巧5.1 端口占用怎么定位这个问题我帮同事排查过无数次Tomcat 起不来第一反应看日志其实未必有用最快的方法是先确认端口占用情况lsof -i :8080 netstat -tlnp | grep 8080如果发现被其他进程占用要么改 Tomcat 端口要么把占用端口的服务停掉。顺便提一句如果有人启动过 Tomcat 但没关干净会导致 8080 被一个孤儿 java 进程占着杀完之后再启动就正常了。5.2 应用内存不够怎么办Tomcat 本身跑得挺稳应用经常出问题的根源大多是堆内存设置不合理。只要看到日志里出现java.lang.OutOfMemoryError: Java heap space第一反应就是 Xmx 设小了调大堆内存上限。别一上来就怀疑代码泄漏在没有 dump 文件之前先把资源给足。还有一种情况是元空间不够报错信息类似java.lang.OutOfMemoryError: Metaspace这时候需要调整 -XX:MaxMetaspaceSize。如果应用特别复杂、加载的第三方类特别多建议把 MaxMetaspaceSize 设置到 1g 以上。5.3 启动慢、卡在 Deploying web application archive 怎么办这个问题很经典表现为 Tomcat 启动时日志停在某个应用部署位置一停就是几分钟。本质原因通常是 Tomcat 在生成安全随机数时阻塞了因为/dev/random熵源不足。解决办法是修改 JVM 参数让 Tomcat 使用/dev/urandomexport JAVA_OPTS$JAVA_OPTS -Djava.security.egdfile:/dev/./urandom别小看这个参数很多服务器在启动时卡几分钟都是因为它改完以后启动时间能明显缩短。5.4 目录权限导致的诡异问题Tomcat 的 webapps 目录权限不对会出现一类很奇怪的报错启动日志看着一切正常但应用就是访问不了或者上传附件时一直失败。尤其用 nginx 反向代理到 Tomcat再配合独立用户运行 Tomcat 时权限问题会更加隐蔽。我这里沉淀了一张简易排查表基本覆盖了新手常见的坑现象常用排查命令大概率原因启动失败日志提示端口被占lsof -i :8080端口冲突或残留进程能访问首页但访问应用 404ls webapps 查看目录war 包解压失败或上下文路径不对页面加载极慢tail -f logs/catalina.out随机数源问题调 urandom上传文件失败检查 webapps 目录权限Tomcat 运行用户无写权限页面中文乱码检查请求编码和文件编码URIEncoding 或 file.encoding 设置错误5.5 安全加固默认配置不能直接上生产装好 Tomcat 不等于能上生产默认配置里有很多安全隐患。我自己的习惯是第一次启动后第一时间删除或注释掉默认的 docs 和 examples 应用保留 ROOT、manager 和 host-manager 时也要限制访问来源。webapps 目录里至少删掉 docs/examples 这两个长得像官方教程的目录避免被人利用历史漏洞扫描到。再一个是关闭一些不需要的连接器。如果只提供 HTTP就把默认注释掉的 AJP Connector 继续注释不要因为网上教程提醒“性能好”就打开用不到就尽量不暴露。Tomcat 的 AJP 端口一旦暴露很容易被利用来进行非法访问这一点真不是危言耸听。最后在 conf/web.xml 里把默认的目录列出来行为关掉或者通过应用层做访问控制做到纵深防御。6. 一点经验之谈这次把 apache-tomcat-8.5.100.tar.gz 从下载到部署全流程跑下来我最想说的一点是别嫌麻烦把 conf 下的每个文件都打开翻一遍搞清楚每个参数是干什么的再动手改。很多人出了故障只能上网搜答案很难搜周全就是因为对自己环境的具体配置背景不够清楚。如果后续升级记得做好 conf 目录的备份因为升级主要就是换一个新的解压目录然后把旧 conf 里的配置迁移过去。再分享一个小技巧我在 /opt 下建了一个 tomcat-backup 目录每次升级前会把 app 的 webapps 和 conf 整个压缩备份进去等新版本跑几天没问题再删。这个习惯已经帮我躲过不少“升级一时爽回滚火葬场”的尴尬。本文还有配套的精品资源点击获取