Linux下Tomcat 8.5.35安装配置与部署实战：从tar.gz到systemd自启动

简介一份Linux环境下的Tomcat 8.5.35完整发行包面向需要在Linux服务器上部署、运行Java Web应用的开发与运维人员。该版本基于Apache Tomcat支持Java EE 8规范中的JSP 2.3、EL 3.0、WebSocket等特性并修复了若干安全漏洞适合从开发到生产环境直接采用。资源包含645个文件压缩后约9.2MB核心文件类型涵盖jar库、class类文件、java/jsp源码、html页面、xml配置文件以及sh启动脚本等。其中jar库支撑Servlet容器运行class/java/jsp构成可运行模块与示例xml用于配置端口和访问规则sh脚本用于启停管理。目录结构遵循标准Tomcat布局bin、conf、lib、logs、webapps、work等一应俱全便于快速上手和排查问题。目前已有554人学习或下载。可直接通过设置CATALINA_HOME启动运行也可通过修改server.xml调整访问控制、启用HTTPS或优化连接器参数。对于需要掌握Tomcat内部结构或搭建Java Web服务的人员这份资源提供了可直接对照学习的标杆环境。该版本在稳定性与兼容性上表现良好适合个人学习与团队生产使用。1. 一个 Linux 版 Tomcat 8.5.35 的 tar.gz 包拆开之前先想清楚三件事手上一台干净的 Linux 服务器拿到apache-tomcat-8.5.35.tar.gz你首先要确认的不是解压命令而是三件事JDK 装没装、版本对不对、这个包打算放哪个目录。Tomcat 8.5.35 是一个很典型的过渡版本——它既能吃 JDK 8 的老项目也开了支持 Java 9 的口子但真正生产环境里跑得最稳的依然是 JDK 8。整个安装及配置教程走到最后你会发现花时间最多的不是解压而是 server.xml、catalina.sh 和日志里的那几行报错。这篇笔记讲的就是一条可复现的路径解压 tar.gz配 JDK 环境改连接器与 JVM 参数部署前后端分离或传统 WAR 包最后做 systemd 自启动。顺带把 8.5.35 这个版本特有一些坑标出来比如 AJP 连接器行为差异、JVM 参数踩到高版本 JDK 的不兼容、以及日志里最常见的那几个“假死真因”。2. 解压安装前的准备JDK 版本、tar 命令与目录规划2.1 先确认 Linux 发行版和 JDK 版本8.5.35 对 Java 8 的兼容性Tomcat 8.5.35 是 2019 年初发布的版本官方要求的最低 Java 版本是 JDK 7但实际部署中绝大多数团队都在 JDK 8 上跑它。你如果直接上 JDK 11不是不能跑而是 8.5.35 里某些反射和安全管理器相关的代码在更早版本上做过适配跑在 JDK 11 上偶尔会有类加载时序问题。经验做法是部署 8.5.35 就用 Java 8别给它配 11 或 17。# 查看当前 Java 版本 java -version # 如果没有输出先确认是否有 JDK 安装包 ls /usr/lib/jvm/如果java -version报错说明环境里根本没有 JDK。常见做法是从发行版仓库装 OpenJDK 8。CentOS/RHEL 系执行这条命令安装后/usr/lib/jvm/java-1.8.0-openjdk就是 JDK 根目录。yum install -y java-1.8.0-openjdk-devel这里注意后缀必须是-devel只装java-1.8.0-openjdk是没有javac的。Tomcat 本身不编译 JSP 时可能感知不到但一旦 JSP 页面首次访问需要编译成 class缺 JDK 会直接抛Unable to load class或JasperException。2.2 解压 tar.gz 到指定目录用 tar 命令做最小安装以标题中的安装包命名规律解压命令是标准的tar -zxvf。Linux 下对 tar.gz 文件最常用的解压参数是-zxvf四个字母分别表示解压、gzip 解压、显示过程、指定文件名。# 创建安装目录并解压 mkdir -p /opt/tomcat tar -zxvf apache-tomcat-8.5.35.tar.gz -C /opt/tomcat # 解压后会生成 apache-tomcat-8.5.35 目录 ls -la /opt/tomcat/-C指定了解压目标目录这是很多新手漏掉的参数。如果不写tar 会把目录解到当前所在路径。解压完成后我习惯顺手建立一个不带版本号的软链后面 systemd 脚本和日志路径都引用软链升级时只需要改链不用改配置。ln -s /opt/tomcat/apache-tomcat-8.5.35 /opt/tomcat/tomcat8解压后你应该看到这些目录bin启动脚本、conf配置文件、lib运行时依赖 jar、logs日志输出、webapps部署根目录、workJSP 编译缓存。这里面最容易被忽略的是work目录——你改了一个 JSP 但页面不变时先清work再重启这属于 Tomcat 的常见脾气。2.3 首次启动前检查JAVA_HOME、目录权限和 catalina.out 的定位解压只是把文件摆到位接下来三个检查能避免 90% 的启动翻车。先配JAVA_HOME。Tomcat 的启动脚本catalina.sh会优先读取环境变量JAVA_HOME其次用JAVA_HOME定位java和jdb。把下面两行写进/etc/profile或/root/.bashrcexport JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export CATALINA_HOME/opt/tomcat/tomcat8 export PATH$PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin然后是目录权限。Tomcat 在 Linux 上不会用 root 运行生产上更常见的做法是单独建一个tomcat系统用户把logs、temp、work三个目录的写权限交给它。但如果你只是本地验证先用当前用户跑通再说权限问题后面统一收口。最后确认日志位置。第一次启动不要用startup.sh用前台模式/opt/tomcat/tomcat8/bin/catalina.sh run这样日志直接打到终端启动异常当场可见。等确认正常了再用startup.sh放到后台。catalina.out是 stdout 重定向文件logs/catalina.out会记录所有控制台输出之后排查内存、乱码、部署异常第一手证据都在这里。3. 核心配置server.xml、catalina.sh 与 JVM 参数改动前先备份3.1 server.xml 必改的三个点端口、Host 与 Connector 参数conf/server.xml是 Tomcat 的骨架。8.5.35 在默认配置下有五组端口8005shutdown、8080HTTP、8009AJP、8443HTTPS。多数情况你得动的是 8080 和 8009 这一组。常用做法是给生产环境换掉默认端口避免和同机其他服务撞车。下面这段是生产上最常见的 Connector 配置我把改动集中在port、protocol和URIEncoding三处Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 URIEncodingUTF-8 useBodyEncodingForURItrue maxThreads400 minSpareThreads50 acceptCount200 maxConnections10000 compressionon compressionMinSize2048/逐项解释这些参数的用途maxThreads控制最大工作线程数默认 200 对于接口型应用偏小调到 400 是常见做法minSpareThreads是空闲时保持的线程数设太小会导致瞬时并发时线程创建延迟acceptCount是等待队列长度超过maxThreads acceptCount的请求才会被拒绝。compression打开后能明显压小页面传输体积但对二进制接口没什么意义。改动之前务必备份原文件这是我给自己立的规矩改完 server.xml 再改回来是经常有的事。备份就一条命令cp /opt/tomcat/tomcat8/conf/server.xml \ /opt/tomcat/tomcat8/conf/server.xml.bak.$(date %Y%m%d)改完配置别急着重启先做语法校验bin/catalina.sh configtest会检查 server.xml 的结构输出Server.xml configuration is OK再重启能省不少白等的时间。3.2 给 catalina.sh 加 JAVA_OPTS堆内存、Metaspace 与编码问题Tomcat 默认的 JVM 参数极其保守堆内存只有物理内存的 1/4 左右上限PermGen/Metaspace 也按默认值走。所以你会在日志里看到两种典型挂法堆内存溢出java.lang.OutOfMemoryError: Java heap space和类元数据溢出Metaspace溢出。8.5.35 加上 JDK 8Metaspace 是重点。我一般直接在catalina.sh里追加一段JAVA_OPTS因为这台机器只跑这一套 Tomcat写在全局环境变量里会污染其他应用。# 在 catalina.sh 的 JAVA_OPTS 赋值处追加 JAVA_OPTS$JAVA_OPTS \ -Xms1g \ -Xmx2g \ -XX:MetaspaceSize256m \ -XX:MaxMetaspaceSize512m \ -Dfile.encodingUTF-8 \ -Djava.awt.headlesstrue参数说明-Xms1g和-Xmx2g表示堆初始 1G、最大 2G生产上我习惯把两者设成不同值因为 Tomcat 启动时的类加载并不需要一次性占满堆给初始化留点余地-XX:MetaspaceSize是触发类加载回收的阈值设太小会导致频繁 Full GC-Dfile.encodingUTF-8是应对 Linux 系统默认编码不是 UTF-8 时的兜底方案文件读写、日志输出、网络传输都受它影响。java.awt.headlesstrue是为了防止图形环境缺失时报 NoClassDefFoundError。改完 JAVA_OPTS 后重启看catalina.out里是否出现你设置的值。可以用jps加jinfo验证jps -l | grep Bootstrap jinfo -flags 进程号jinfo如果显示 Available 的-Xmx已是你设置的值说明参数生效。3.3 URIEncoding 与字符集乱码连接器 URL 编码的兜底方案Tomcat 8.5.x 和之前的 7.x 有个行为差异从 8.0 起默认 URIEncoding 已经是 UTF-8所以理论上 GET 请求里的中文参数不会乱码。但现实中乱码依然高频出现原因多为两类一是页面本身没声明 UTF-8提交的请求编码乱掉二是后端代码按 GBK 读取参数。URIEncoding解决的是 URL 解码侧的问题。就算 Tomcat 默认是 UTF-8我在 server.xml 里仍然显式加上它——这个习惯救过多次命特别是当 web.xml 里的编码 filter 被移除或顺序不对时。加上之后配合前端的meta charsetUTF-8与后端的request.setCharacterEncoding(UTF-8)乱码排查范围能直接缩小到代码提交侧。我自己常用的排查路径是# 看访问日志里的原始请求确认是 GET 还是 POST 乱码 tail -f /opt/tomcat/tomcat8/logs/localhost_access_log.txt访问日志里如果原始 URL 已经带%E4%B8%AD%E6%96%87这类 UTF-8 编码说明浏览器侧没问题问题在后端读取或数据库连接串如果原始 URL 里是 GBK 编码的%D6%D0%CE%C4那就要在浏览器或前端框架层处理。这一步让你精确知道该往哪追不靠玄学。4. 部署 WAR 包与日志分析前后端分离项目的两条常规路径4.1 用 webapps 目录直接部署 WAR热替换与解压目录Tomcat 的传统部署方式就是把 WAR 包扔进webapps目录重启后自动解压并加载。8.5.35 默认unpackWARstrue它会先解压到同名目录再从这个目录加载应用。所以你会看到webapps/your-app/和your-app.war同时存在。# 把构建产物放到 webapps 下 cp your-app.war /opt/tomcat/tomcat8/webapps/ # 重启让 Tomcat 重新加载 /opt/tomcat/tomcat8/bin/catalina.sh stop /opt/tomcat/tomcat8/bin/catalina.sh start这里有个 8.5 特有的行为值得注意autoDeploy默认是true。也就是说当你再拷贝一个新your-app.war覆盖旧包Tomcat 会检测到 WAR 文件的修改时间变化自动解压并重新加载应用不需要重启。这个行为在开发环境很爽在生产线是隐患——你在不知情时覆盖了包服务就悄悄重启了连接中的用户直接被断掉。所以生产环境的 Host 标签我一般显式关闭它只保留手动重启Host namelocalhost appBasewebapps unpackWARstrue autoDeployfalse /Host如果保留autoDeploytrue就必须接受“包一换、应用重载”这个事实。应对方法是部署窗口期做替换并且替换后立刻检查日志里的Deployment of web application archive记录。4.2 用软链映射外部目录不在 webapps 下放包的另一种做法对于前端把构建产物打成静态目录、后端只出接口的项目很多人不愿意把前端目录塞进 webapps。Tomcat 支持在conf/server.xml的 Host 节点下加Context映射把来自某个路径的请求指向一个外部目录。这在 Linux 部署前后端分离项目时非常常用。Context docBase/data/static/webroot path/static reloadabletrue/docBase是外部目录的绝对路径path是访问该目录的 URL 前缀。上述配置意味着http://ip:8080/static/index.html会直接读取/data/static/webroot/index.html。这样的好处是前端构建完直接 rsync 到/data/static/webroot不需要打包成 war也不用重启 Tomcat。但这个做法的坑是docBase必须存在且可读Tomcat 启动时如果发现 docBase 不存在或没有权限会报Failed to initialize component [Container]一类错误导致整个 Host 起不来。所以要养成先建目录后加配置的习惯。4.3 catalina.out 与 localhost.log启动异常时先看哪份日志Tomcat 的日志体系在 8.5.35 里是分流的每种日志有独立文件catalina.out所有 JVM 和容器级的 stdout/stderr 输出localhost.logWeb 应用自身标准输出和未捕获异常localhost_access_log.txtHTTP 访问日志记录每次请求的 IP、方法、路径、状态码和耗时manager.log/host-manager.log管理后台相关启动异常时先看catalina.out的最后 50 行基本能定位到是端口占用、类加载失败还是配置语法错误。应用运行时偶发错误看localhost.log比如Servlet.service() for servlet ... threw exception这种异常栈会完整打在这里。按状态码排查访问问题看localhost_access_log.txt。我排查 Tomcat 问题的固定套路是# 1. 看整体启动是否成功 tail -100 /opt/tomcat/tomcat8/logs/catalina.out # 2. 看具体应用的异常栈 tail -100 /opt/tomcat/tomcat8/logs/localhost.log # 3. 看某时间段内的访问状态确认是不是被大量请求拖垮 grep $(date %d/%b/%Y:%H) /opt/tomcat/tomcat8/logs/localhost_access_log.txt | awk {print $9} | sort | uniq -c最后这条命令把某一小时内所有响应状态码聚合如果500或504数量激增那问题通常在后端接口而不是 Tomcat 本身。这个习惯能省掉大把抓瞎时间。5. 五个高频踩坑记录从启动失败到内存溢出现象、原因、解法5.1 现象启动后进程秒退catalina.out 没有任何异常堆栈用startup.sh启动后ps -ef | grep tomcat找不到进程但打开catalina.out又只有几行 INFO 日志没有报错。这种“安静地死掉”特别容易让人一头雾水。原因通常是两个一是JAVA_HOME环境变量没有在启动脚本所在 shell 中生效二是catalina.sh执行时找不到java命令从而静默退出。另一个隐藏原因是内存不足JVM 启动参数-Xmx分配过大而物理机内存不够OOM Killer 直接把进程杀了这种情况下dmesg里能看到痕迹。解决方式是先在前台跑catalina.sh run让日志直接输出到终端没有堆栈也不怕。如果还是只停几行就检查环境变量echo $JAVA_HOME ulimit -a | grep virtualulimit -a中的virtual memory如果是unlimited就没问题如果有限制可能 JVM 都起不来。8.5.35 在容器环境里经常遇到这类 cgroup 限制问题低层根因是系统限制和 JVM 探测内存逻辑冲突。5.2 现象Tomcat 能启动但访问页面全部报 404这个现象在 8.5.35 上有一个非常经典的误导性原因你访问的路径匹配不上 Host 的appBase。如果 WAR 包名是demo.war那么访问路径应该是http://ip:8080/demo/而不是http://ip:8080/。很多人以为把包扔进 webapps 就能根路径访问结果一直 404。另外一类原因是webapps目录下存在同名但残缺的目录比如上一次部署中断留下的demo/目录是空的Tomcat 解压时发现目录已存在但内容不完整不会覆盖直接按目录加载加载出来自然是空的。解决方式是清理后重放# 删除残缺的部署目录 rm -rf /opt/tomcat/tomcat8/webapps/demo # 重新放包 cp demo.war /opt/tomcat/tomcat8/webapps/之后确认webapps/demo目录里确实生成了WEB-INF和页面文件再访问。Tomcat 部署目录和 WAR 包不同步是 404 的最大来源。5.3 现象页面中文全部变成问号或乱码数据库里的中文也是乱码乱码这个问题的定位顺序很重要我按从外到内排个优先级先看页面响应头是否声明了 UTF-8再看 Tomcat 的URIEncoding再看数据库连接串是否带了characterEncodingutf8。三者缺一不可。8.5.35 的Connector上URIEncodingUTF-8只解决 GET 的 URL 参数不解决 POST 表单。POST 乱码的根源在 servlet 容器解析请求体时的默认编码Java Servlet 规范默认是 ISO-8859-1。所以如果你没有在代码里调request.setCharacterEncoding(UTF-8)POST 必乱。# 看访问日志里的原始请求确认浏览器和服务器之间编码是否一致 grep POST /opt/tomcat/tomcat8/logs/localhost_access_log.txt | tail -10如果原始请求里的中文是%E4%B8%AD这类 UTF-8 形态说明浏览器没问题后端读取方式错了。解决就是设置一个编码过滤器把CharacterEncodingFilter重定向到容器级。用 Spring Boot 时server.servlet.encoding.forcetrue是快捷键但 8.5.35 不挂 Spring Boot 时就得自己写 Filter 或调 Catalina 级参数。5.4 现象应用接口调用偶发失败日志出现Connection reset by peer或SocketException: Unexpected end of file这个错误在网上被讨论很多但实际原因比大多数人想的普通一是 KeepAlive 超时和 Nginx 代理超时不匹配浏览器和 Tomcat 保持长连接但代理侧proxy_read_timeout设置太短代理断开连接而 Tomcat 不知道下次复用连接就报错。另一种就是 CPU 或线程池被打满Tomcat 处理不过来时会对积压连接做丢弃表现为reset。8.5.35 的 NIO 连接器在maxThreads200默认值下尤其容易触发接口里如果有慢 SQL 或同步 RPC线程池很容易被打满。解决方向很简单看catalina.out有没有All threads are busy相关日志。有的话提升线程池并压测验证没有的话检查负载均衡与 Tomcat 的超时一致性# 所有线程池状态和当前线程数立即确认是否打满 jstack pid | grep http-nio | wc -ljstack输出当前所有存活的 Java 线程名数一数http-nio-8080-exec-开头的线程数量接近maxThreads就说明池子已满。这时候不是盲目加线程数而是去查哪一个接口占用了最长时长的调用。5.5 现象JVM 内存溢出日志里频繁出现OutOfMemoryError: Metaspace前面讲了改JAVA_OPTS时的-XX:MetaspaceSize与-XX:MaxMetaspaceSize这里出现的是真实踩过的坑Tomcat 8.5 在 JDK 8 下如果部署了多个应用每个应用自带一套第三方依赖Metaspace 会快速涨。默认 20M 左右的上限对稍微复杂的系统都不够用。解决分两步走。第一步改配置JAVA_OPTS$JAVA_OPTS -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m第二步找根因Metaspace 涨得快的项目基本是类加载器泄漏常见是重复部署 WAR 包且依赖了ThreadLocal、单例持有 ClassLoader 引用。所以不要只改配置还要看每次 reload 之后 Metaspace 是否回落。不回落的说明有类加载器被静态引用持有了改配置只是延缓死亡。我验证 Metaspace 是否正常回落的命令是# 连续观察 3 次 GC 后的 Metaspace 占用 jstat -gcmetacapacity pid 1000 5输出里MCMN最小容量和MCMX最大容量如果持续上涨并贴近MaxMetaspaceSize就可以确定类加载器泄漏这时候得去查代码里谁引用了 WebappClassLoader。6. 生产化收尾用 systemd 托管 Tomcat 自启动并验证开机拉起标题这个 tar.gz 包解压出来的 Tomcat 默认没有任何自启动机制。如果你重启一次 Linux 服务器还得手动敲startup.sh这在生产环境是不能接受的。8.5.35 对应最常见的托管方式就是 systemd 服务。先创建一个单元文件tomcat.service将进程以前台方式托管[Unit] DescriptionApache Tomcat 8.5.35 Web Application Container Afternetwork.target [Service] Typesimple Usertomcat Grouptomcat EnvironmentFile/opt/tomcat/tomcat8/conf/tomcat.env ExecStart/opt/tomcat/tomcat8/bin/catalina.sh run ExecStop/opt/tomcat/tomcat8/bin/shutdown.sh 60 Restarton-failure RestartSec10 [Install] WantedBymulti-user.target核心参数说明Typesimple表示catalina.sh run是主进程systemd 直接跟踪它而不是用startup.sh那种 fork 方式去追子进程EnvironmentFile加载 JDK 和内存参数环境变量避免把环境变量写死在全局文件中ExecStop倒计时 60 秒给 Tomcat 足够时间完成优雅停止。如果你只用 root 跑把User和Group两行去掉即可但生产上强烈不建议 root 跑 Tomcat。启用并验证cp tomcat.service /etc/systemd/system/ systemctl daemon-reload systemctl enable tomcat systemctl start tomcat systemctl status tomcatsystemctl status输出里要能看到Active: active (running)才算成功。最后一步我习惯直接 reboot 一次服务器等机器起来后不手动做任何操作直接访问端口验证服务确实被拉起。这一步不能省因为环境变量在重启后的加载时机、网络依赖顺序等问题只会在真实启动流程里暴露。检查访问curl -s -o /dev/null -w %{http_code} http://127.0.0.1:8080/返回 200 且能看到 Tomcat 欢迎页代码时这个 tar.gz 包就算正式投产了。我自己的收尾习惯还有一条把这次部署用到的所有自定义配置——server.xml 改动、JAVA_OPTS、systemd 单元文件——放到一个部署目录统一留存下次换机器时直接拿来 diff不靠记忆还原配置。这套从解压到自启动的流程跑过几遍之后你会发现 Tomcat 8.5.35 真正值钱的地方不在于它有多少黑科技而在于你能把每一步的异常都看得明明白白。希望帮到你。本文还有配套的精品资源点击获取