简介一份适用于 Linux 平台的 Tomcat 8.5.35 服务器压缩包面向需要搭建 Java Web 运行环境的开发者、运维人员及初学者。该版本为 Apache 软件基金会的开源 Servlet 容器实现内置 Catalina、Jasper、Coyote 等核心组件可直接解压部署 Java 应用帮助使用者在 Linux 下快速完成从环境配置到服务管理的全流程。整包共 645 个文件包体约 9.2MB主要包含 HTML/JSP 示例页面、Java 源文件与编译后的 class、JAR 依赖库、XML/TXT 配置文档、shell 启停脚本等类型这些文件分别承担页面展示、后端逻辑、运行依赖与参数调整功能覆盖从开发测试到部署运维的完整链路适合对照学习 Tomcat 的目录结构与运行机制。已有 554 人学习使用。解压后可看到 bin、conf、lib、logs、webapps、work 等完整目录bin 目录提供启动与停止脚本conf 中的 server.xml、context.xml 可修改端口和访问控制webapps 用于自动部署 WAR 包work 存放 JSP 编译产物通过调整 server.xml 还能启用 HTTPS满足开发、测试及生产环境需求亦可作为课程设计或入门实践的参考案例。1. 先搞清楚 tomcat8-8.5.35.tar.gz 是什么再决定怎么装如果你下载过 Linux 版本的 tomcat8-8.5.35.tar.gz大概率会以为它跟 Windows 下的 exe 安装包一样双击、下一步、完成。实际不是。这个 tar.gz 是 Tomcat 官方发布的免编译二进制分发包解压即用不写注册表、不依赖系统服务管理器目录结构自带一套完整的启动与停止脚本。它解决的刚需是在一个没有图形界面的 Linux 服务器上用最少的依赖把 Java Web 应用跑起来同时让运维人员能手动控制进程、精确调整 JVM 参数。这个包适合两类人。第一类是刚接触 Linux 部署的开发者手里有一个 WAR 包或前后端分离项目需要快速搞出一个能访问的 HTTP 服务第二类是运维工程师在做版本升级或环境迁移需要把旧 Tomcat 的配置平滑挪到新版本上。8.5.35 是 8.5.x 这条线里一个偏稳定的版本比 8.0 多了 HTTP/2 支持和更灵活的连接器配置又比 9.0 更保守适合生产环境不折腾。这篇文章就按「这个包到底是什么 → 怎么跑起来 → 参数怎么调 → 常见坑在哪 → 升级后怎么验证」的顺序把整条链路讲透。2. 拿到包到跑起来tar.gz 解压与 JDK 版本选择2.1 先校验文件完整性别急着解压从 Apache 官方镜像下载 tar.gz 包之后第一件事不是 tar -zxvf而是校验哈希。Tomcat 发布页面每个文件旁边都会给出 sha512 校验值下载页面同时提供 .sha512 后缀的校验文件。常见做法是把校验文件和 tar.gz 放在同一目录执行cd /opt/src ls -l *.tar.gz *.sha512 sha512sum -c tomcat8-8.5.35.tar.gz.sha512如果输出tomcat8-8.5.35.tar.gz: OK说明文件完整。这一步不是可有可无Tomcat 是 Java Web 的入口一旦被中间人替换等于把整个应用的执行链交给不可信代码。国内网络环境下从官方镜像下载偶尔会断流校验能帮你提前发现半截文件避免解压到一半报gzip: invalid compressed data再回头找原因。2.2 解压到什么位置取决于你的使用习惯Tomcat 本身不强制安装路径但生产环境我建议统一放到/opt/tomcat下用版本号做目录名方便以后多版本共存。命令如下mkdir -p /opt/tomcat tar -zxvf tomcat8-8.5.35.tar.gz -C /opt/tomcat cd /opt/tomcat mv apache-tomcat-8.5.35 tomcat-8.5.35 ln -s tomcat-8.5.35 tomcat解压后建议立即创建软链接tomcat指向当前使用版本。这样以后升级时只要改软链接指向不用去改 systemd 脚本和应用的绝对路径引用。目录内容很小核心就几个子目录bin放启动脚本conf放 server.xml 和 context.xmlwebapps放应用包logs放运行日志lib放 Tomcat 自身依赖的 jar。看清楚这五个目录后面排错基本不迷路。2.3 JDK 版本怎么选8.5.35 的底线是 Java 8Tomcat 8.5.x 的官方要求是 Java 7 以上但现实环境里8.5.35 这个版本是在 Java 8 时代打磨成熟的建议直接用 JDK 8 或 11。如果你装了 JDK 17Tomcat 8.5.35 也能跑但要注意它没有针对高版本 JDK 做完整适配反射相关的模块可能报IllegalAccessError。我的建议是生产用 JDK 8图省心。先确认系统里有没有 Javajava -version which java输出里有openjdk version 1.8.0_xxx就说明 Java 8 已就位。如果没有去下载 Linux x64 的 Java 8 tar.gz 包解压到/opt/java然后编辑/etc/profileexport JAVA_HOME/opt/java/jdk1.8.0_202 export PATH$JAVA_HOME/bin:$PATH这里有个细节Tomcat 启动脚本catalina.sh依赖JAVA_HOME或JRE_HOME环境变量。两者都不设时它会尝试从which java反推但反推结果经常不对所以我一般会先设好 JAVA_HOME再启动避免踩到「能找到 java 但 Tomcat 起不来」的玄学问题。3. 最小启动与自启动环境变量、JVM 参数与 systemd 集成3.1 第一跑用前台模式验证基本盘解压完先别急着配 systemd第一次启动一定要用前台模式把日志直接打到控制台方便第一时间看到异常。/opt/tomcat/tomcat/bin/catalina.sh run看到Server startup in [xxx] milliseconds就说明启动成功。这时按CtrlC停掉再用netstat -tlnp | grep 8080确认端口已释放。第一跑的目的不是「让它跑起来」而是确认 JDK 路径、目录权限、conf 配置三件事都没问题。前台模式理论上会一直占着终端所以确认完就停后面交给守护进程管理。3.2 用 setenv.sh 固化 JVM 参数Tomcat 的catalina.sh会在启动前自动读取bin/setenv.sh这是配置 JVM 参数的标准位置。我不建议直接改catalina.sh因为升级 Tomcat 时整个 bin 目录都会覆盖你的改动会全部丢失。新建setenv.sh是正确姿势#!/bin/bash JAVA_HOME/opt/java/jdk1.8.0_202 JAVA_OPTS-Xms1g -Xmx2g -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -Djava.awt.headlesstrue参数含义要捋清楚Xms和Xmx控制堆内存生产环境两者设成一样更稳避免运行期堆扩容引发停顿MetaspaceSize设一个初始值防止启动阶段频繁触发 Full GC。Djava.awt.headlesstrue是给没有图形环境的服务器准备的不加的话某些调用图像处理接口的应用会抛出 HeadlessException。3.3 用 systemd 托底进程挂了能自己拉起来生产环境没有人 24 小时盯着catalina.sh run所以要用 systemd 把 Tomcat 托管起来。新建/etc/systemd/system/tomcat.service[Unit] DescriptionApache Tomcat 8.5.35 Afternetwork.target [Service] Typeforking EnvironmentJAVA_HOME/opt/java/jdk1.8.0_202 EnvironmentCATALINA_HOME/opt/tomcat/tomcat-8.5.35 EnvironmentCATALINA_BASE/opt/tomcat/tomcat-8.5.35 PIDFile/opt/tomcat/tomcat-8.5.35/temp/catalina.pid ExecStart/opt/tomcat/tomcat-8.5.35/bin/startup.sh ExecStop/opt/tomcat/tomcat-8.5.35/bin/shutdown.sh Restarton-failure Usertomcat Grouptomcat [Install] WantedBymulti-user.target这里Typeforking很关键。Tomcat 的startup.sh启动后会 fork 出一个后台进程然后退出systemd 必须知道这一点才能正确追踪主进程 PID。PIDFile指向catalina.pid这个文件由 Tomcat 在启动时生成前提是catalina.sh里开启了-Dcatalina.base对应的 pid 写入逻辑。实际操作中如果 systemd 经常报「start request repeated too quickly」多半是 PIDFile 路径不对或者 Tomcat 实际监听端口没起来systemd 认为启动失败。写完后执行chown -R tomcat:tomcat /opt/tomcat/tomcat-8.5.35 systemctl daemon-reload systemctl enable tomcat systemctl start tomcat systemctl status tomcat4. 调 8.5.35 的 server.xml 与日志端口、连接器、访问日志与乱码4.1 server.xml 里的连接器参数怎么设conf/server.xml是 Tomcat 的主配置文件大多数人只改端口其实连接器参数对性能影响更大。默认的 HTTP 连接器长这样Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 /生产环境我会在不动默认端口的前提下追加线程池和压缩参数Connector port8080 protocolHTTP/1.1 connectionTimeout10000 redirectPort8443 maxThreads400 minSpareThreads50 acceptCount200 compressionon compressionMinSize2048 noCompressionUserAgentsgozilla, traviata compressableMimeTypetext/html,text/xml,text/css,application/json,image/svgxml /maxThreads决定同时能处理多少请求设太大比如 2000反而会让 CPU 频繁上下文切换acceptCount是等待队列长度超过后新连接直接拒绝。connectionTimeout我习惯从 20000 降到 10000避免大量慢连接占着线程池。压缩参数对带宽有限的内网或移动端很有用但注意图片这类已经压缩过的格式不要再压白费 CPU。4.2 访问日志开启与格式定制默认配置下 Tomcat 不记录访问日志排查问题全靠 catalina.out少了「哪个 IP、什么时间、请求了什么路径」这类关键信息。打开conf/server.xml最底下找到被注释的Valve块改成Valve classNameorg.apache.catalina.valves.AccessLogValve directorylogs prefixlocalhost_access_log suffix.txt pattern%h %l %u %t quot;%rquot; %s %b %D /%h是客户端 IP%D是处理耗时毫秒这两项在定位慢接口时最有用。prefix和suffix控制日志文件名按天滚动的话可以再加rotatabletrue。注意%t的时间格式默认是[dd/MMM/yyyy:HH:mm:ss Z]如果你想改成更直观的格式需要用locale和timeZone属性配合。4.3 中文乱码三个入口一次堵住Linux 下 Tomcat 乱码是高频问题源头有三个请求参数编码、响应编码、日志输出编码。请求参数乱码最常见在conf/server.xml的连接器上补一个属性URIEncodingUTF-8响应编码要确认conf/web.xml里没有强制覆盖字符集日志乱码则在bin/catalina.sh里追加export JAVA_OPTS$JAVA_OPTS -Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8sun.jnu.encoding控制文件名的编码很多人只设file.encoding结果应用日志正常了上传的中文文件名还是乱码。三个入口全部堵住基本能做到从头到尾不乱码。如果还乱检查操作系统本身的 localelocale -a看看有没有en_US.UTF-8没有就装语言包这不是 Tomcat 的锅。5. 部署与避坑从下载到运行的五个「玄学」问题排查5.1 启动闪退catalina.out 里只看到几行日志现象执行startup.sh后进程秒退catalina.out日志停在INFO: Initializing ProtocolHandler [http-nio-8080]附近。原因最常见是 8080 端口被占用或者JAVA_HOME路径写错导致catalina.sh找不到 Java。端口占用时日志里会有一条java.net.BindException: Address already in use但因为日志缓冲没刷出来有时候看不到。解决先netstat -tlnp | grep 8080看端口占用再用catalina.sh run前台启动错误会完整打印到控制台。我之前遇到过一台服务器上同时装了多个 Tomcat后启动的继承了前一个的环境变量CATALINA_BASE导致两个实例共用同一份 conf互相踩踏。5.2 解压完启动时报「Permission denied」现象Tomcat 解压后直接用root跑startup.sh没问题换成普通用户就报权限不足。原因tar.gz 解压后bin目录下的.sh脚本默认没有执行权限。tar -zxvf只保留了解压前打包时的权限位而官方包的脚本权限有时是 644。解决进入bin目录执行chmod x *.sh然后把整个 Tomcat 目录的属主改成运行用户chown -R tomcat:tomcat /opt/tomcat/tomcat-8.5.35。用 root 跑 Tomcat 是安全红线一旦应用被入侵攻击者直接获得 root 权限这点不要图省事。5.3 能访问 8080 却打不开应用报 404现象Tomcat 起来了curl http://localhost:8080能看到默认欢迎页但访问具体应用路径报 404。原因WAR 包没有解压到webapps下或者解压后的目录名和应用上下文路径不一致。Tomcat 的webapps目录是热部署目录WAR 包放进去后会自动解压但如果之前有过同名目录残留WAR 包可能没有被正确处理。解决停掉 Tomcat清空webapps下同名目录和.war包重新放入后启动。另外检查conf/server.xml的Host节点里有没有配置appBase指向其他目录如果在 IDE 里调试时通常指向webapps但命令行部署时会指向 Tomcat 自己的webapps两边不一致就会踩坑。5.4 前后端分离部署静态资源 404接口却能通现象部署前后端分离应用时前端构建出来的dist目录放进去后访问页面白屏接口请求正常。原因前后端分离项目的静态文件不是标准 WAR 结构。常见做法是把dist里的内容直接丢到webapps/ROOT下但很多人会多建一层目录比如webapps/ROOT/dist导致index.html不在访问根路径上。解决把dist目录里的所有文件复制到webapps/ROOT下确保http://ip:8080/能直接返回index.html。如果前端用了路由的 history 模式刷新页面会 404这时候要在应用里配一个转发规则把非/api前缀的请求全部转发到index.html这属于应用层的坑不是 Tomcat 的配置问题。5.5 启动后catalina.out疯狂刷SEVERE日志现象Tomcat 能启动但日志里连续报错比如Unable to process Jar entry或ClassNotFound。原因多数情况是lib目录下引入了多个版本的同一个 jar。Tomcat 8.5.35 的lib目录自带一整套依赖如果应用把自己的 jar 也塞进lib很容易产生冲突。解决不要动lib目录里的任何文件。应用的私有依赖放在webapps/WEB-INF/lib下由应用自己加载。检查方式很简单ls /opt/tomcat/tomcat-8.5.35/lib看看有没有重复或可疑的 jar比如多个版本的ecj.jar或annotations-api.jar。遇到这种问题先把lib目录恢复成官方原样再排查应用侧依赖。6. 升级到 8.5.35 之后的验证方法迁移配置、对比参数、确认补丁生效升级到 8.5.35 不是解压、复制、启动三步就完事需要做一套验证闭环。我的习惯顺序是先比配置、再比 jar、最后逐个应用测。第一步解压新包后不要直接复制conf目录覆盖而是用 diff 对比新旧两份server.xml、web.xml、context.xmldiff /opt/tomcat/tomcat-8.5.35/conf/server.xml /opt/tomcat/tomcat-8.5.47.bak/conf/server.xml重点看连接器参数有没有被新版本改成默认值。第二步对比lib目录下的 jar 列表确认新版本没有移除你依赖的库。第三步逐个应用做冒烟测试静态页能打开、登录接口能通、上传下载功能正常。还有一步容易忽略确认补丁真正生效。8.5.35 之后官方修复过若干安全漏洞升级后要核实实际运行的版本号不要只看解压目录名。执行/opt/tomcat/tomcat/bin/version.sh输出里会有Server version: Apache Tomcat/8.5.35如果是其他版本说明解压目录名和实际包内容不一致或者环境变量指向了旧安装。我个人的习惯是升级后保留catalina.out的前 20 行里面记录了解压路径、JVM 参数和启动时间以后排查问题先看这几行能省掉大量猜时间的功夫。最后说一句经验之谈Tomcat 的版本升级怕的不是新版本不兼容而是旧配置里的坑被带到新版本继续埋着。通过一次完整的迁移验证顺手把历史遗留的无效参数清掉这比单纯换个版本号有意义得多。希望这篇笔记能帮你在 Linux 上把 Tomcat 部署这件事一次性跑顺少走那些我走过的弯路。本文还有配套的精品资源点击获取