Linux下Tomcat安装配置与生产部署实战指南

如果你手里正好有一台Linux服务器，需要把一个Java Web项目跑起来，那么Tomcat的安装和配置几乎是绕不开的一步。网上的Tomcat教程并不少，但大多只告诉你“执行这几条命令就装好了”，真到了生产环境，启动慢得离谱、页面乱码、端口被占、访问管理界面403……每个问题都能让你怀疑人生。这篇文章我想以自己的实操经验为主线，把Linux环境下的Tomcat安装、配置和部署完整过一遍，重点讲清楚“为什么这么做”，而不是光扔给你一堆命令。适合刚接手服务器的新手，也适合那些总在配置上报错但没搞懂原因的同学参考。

1. 装Tomcat前，先把版本选型和环境规划清楚

1.1 先别急着下载，想清楚这台Tomcat要干什么

Tomcat本质上是一个用Java编写的Web应用服务器，核心工作就是接收HTTP请求、把请求交给部署在里面的Servlet或者Spring MVC这类应用去处理、再把结果返回给浏览器。很多人在Windows上开发时用过IDEA内嵌的Tomcat，感觉好像没什么好装的，但到了Linux服务器上情况完全不一样：没有可视化界面、不能点按钮启动、一切都靠命令行和配置文件，而且你还要考虑权限、开机自启、日志切割、端口安全这些东西。

为什么要单独在Linux上部署一个Tomcat，而不是继续用Spring Boot内嵌的Web容器？这是很多人第一个问我的问题。大多数微服务确实用内嵌Tomcat就够了，但不少传统企业项目、老系统、信创类项目，或者需要独立运维、热替换war包、和已有监控系统对接的场景，外置Tomcat仍然是标准做法。我接手过的生产环境里，至今有不少Java服务跑在一台装好的Tomcat 8.5或9.0上，四年不重启也稳如老狗。Linux下部署Tomcat和Windows最大的区别，就是你必须对每一个文件、每一个端口、每一个进程都有掌控力，不能稀里糊涂点鼠标。

1.2 JDK和Tomcat版本怎么搭才不出幺蛾子

版本不匹配是Tomcat启动失败的第一大原因。很多新手下载了最新的Tomcat 11，然后机器上装的是JDK 8，结果启动脚本报错UnsupportedClassVersionError，或者根本起不来。这里面的关键不是Maven版本，不是Node版本，而是JDK版本是否满足Tomcat的要求。

我把常用搭配整理成了表：

这里有个非常容易踩的坑：Tomcat 9及以前使用javax.servlet包名，Tomcat 10开始改成了jakarta.servlet。如果你把老项目编译好的war包直接丢进Tomcat 10，启动时会报ClassNotFoundError甚至NoClassDefFoundError，实际上就是包名变了。所以我的建议是：维护老项目、按教程学习，直接用Tomcat 9.0.x配JDK 8，不要为了“新版”去给自己挖坑；如果是Spring Boot 3项目想外置部署，那就Tomcat 10.1.x配JDK 17。别纠结Maven版本，Maven只是打包工具，跟Tomcat运行没有直接关系，很多博客把Maven版本也列进对应表纯粹是故弄玄虚。

1.3 下载安装包与认识目录结构

下载Tomcat时建议直接从官网tgz包拿，不要用某些来源不明的整合包。命令类似：

bash复制wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.108/bin/apache-tomcat-9.0.108.tar.gz

实际下载时版本号可能已经更新，到Tomcat官网下载页复制当前可用版本即可。我习惯把Tomcat解压到/opt目录下，而不是放在/root或/home里，因为/opt是Linux上放第三方软件的约定位置，结构清晰，后续做权限管理也顺手。

解压后你会得到一个类似apache-tomcat-9.0.108的目录。在动手之前，我建议你先花两分钟把它的内部结构看明白，这比记住一堆配置命令更重要：

• bin/：存放启动和关闭脚本，如startup.sh、shutdown.sh、catalina.sh。
• conf/：全部配置文件都在这里，server.xml、web.xml、tomcat-users.xml等。
• lib/：Tomcat运行需要的公共jar包，也是Web应用共享类库的加载位置。
• logs/：日志目录，Tomcat的日志和应用的System.out输出都会落在这里。
• temp/：运行时的临时文件。
• webapps/：默认的Web应用发布目录，把war包放进去就会自动部署。
• work/：JSP编译后的class文件缓存目录，服务启动后会生成。

理解这个结构以后你就知道，Tomcat不是那种“装完就完事”的软件，它把运行、配置、日志、部署都分得清清楚楚，你后续做的所有操作都在跟这八个目录打交道。

2. 从命令行开始：安装过程与首次启动避坑

2.1 不建议直接使用root用户运行Tomcat

我知道很多教程为了省事，直接让你用root用户去启动Tomcat，因为root权限最大，不会遇到文件权限问题。但这是一个非常坏的习惯。Tomcat是Web服务，一旦因为应用漏洞被攻破，进程权限越高，攻击者能拿到的东西越多。即便你是内网环境，我也建议你创建一个低权限用户来跑Tomcat。

创建专用用户的命令：

bash复制useradd -r -s /bin/bash -m -d /home/tomcat tomcat
passwd -l tomcat

第一行创建一个名为tomcat的系统用户，第二行锁定密码，防止它被远程登录。然后解压Tomcat并授权：

bash复制mkdir -p /opt
tar -zxvf apache-tomcat-9.0.108.tar.gz -C /opt
mv /opt/apache-tomcat-9.0.108 /opt/tomcat9
chown -R tomcat:tomcat /opt/tomcat9

这里我特意把目录重命名成/opt/tomcat9，因为以后可能还会装Tomcat 10，用带版本号的目录名方便区分。chown这一步很多人会忘，结果启动时tomcat用户无法往logs目录写日志，报各种奇怪的错。记住，logs、temp、work这三个目录在运行时会写入数据，整个Tomcat目录里至少要保证它们对运行用户可写。

2.2 配置JAVA_HOME和CATALINA_HOME

Tomcat是Java写的，启动脚本本质上就是执行java命令，所以必须先让系统能找到JDK。如果你的服务器上已经配好了JDK，可以跳过前面的JAVA_HOME设置，直接验证：

bash复制java -version
echo $JAVA_HOME

如果JAVA_HOME是空的，需要配置。我习惯在/etc/profile.d/下新建一个脚本，而不是去改/etc/profile，因为这样每个用户登录都会自动加载，而且不污染系统主文件：

bash复制vim /etc/profile.d/java-tomcat.sh

写入：

bash复制export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export CATALINA_HOME=/opt/tomcat9
export PATH=$PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin

JAVA_HOME的路径要根据你机器上的实际情况改，不同发行版不一样。配置完以后执行source /etc/profile.d/java-tomcat.sh让它生效。CATALINA_HOME是Tomcat的重要环境变量，后面很多脚本和配置都会引用它，建议一开始就设好，避免后续找到的是一堆相对路径。

2.3 启动、访问与验证一次成功的标准流程

切换到tomcat用户，先从命令行手动启动一次，确认基本流程没有问题：

bash复制su - tomcat -c "/opt/tomcat9/bin/startup.sh"

如果前面的环境和权限都弄对了，终端会输出Tomcat started.。要确认是不是真的启动成功，我用三个命令连环验证：

bash复制ps -ef | grep tomcat
jps -l
ss -ltnp | grep 8080

jps -l能看到一个叫org.apache.catalina.startup.Bootstrap的进程，如果没有，说明JVM里根本没有运行Tomcat主类。ss -ltnp看到8080端口处于LISTEN状态，说明HTTP服务已经对外监听了。然后浏览器访问http://服务器IP:8080/，看到默认的猫头鹰首页就说明安装成功。

需要注意的是，很多云服务器上就算8080端口监听正常，公网还是访问不了，因为云安全组没放行。这是服务器层面的问题，不是Tomcat配置错了。你可以先在本机curl http://localhost:8080验证，能通就说明服务本身没问题，接下来去安全组或防火墙放行8080端口。CentOS上如果是firewalld，用firewall-cmd --permanent --add-port=8080/tcp && firewall-cmd --reload放行。

3. 生产环境需要的不是“能跑”，而是合理配置

3.1 server.xml里的三个端口，哪些要改、哪些要关

conf/server.xml是Tomcat最核心的配置文件，启动阶段读一个字节错一个符号，整个服务都可能起不来，所以修改之前一定先备份一份原文件。默认配置里有三个主要的端口，每个角色都不一样：

第一个让你改的是8005。Tomcat默认通过这个端口接收关闭指令，如果有人能访问到这个端口，直接发送字符串SHUTDOWN就能把服务干掉。虽然新版本默认绑定了localhost，但保险起见仍然要把端口改成一个不常用的数值，并加上address="127.0.0.1"来限制本机访问。第二个是8009，AJP协议当初是为了让Apache转发动态请求用的，现在已经很少直接用AJP，把它留在外面反而是攻击面。我自己在部署时，如果确定应用不走AJP，就会把整个Connector注释掉，很多安全扫描工具也会揪着这个端口不放。

8080是HTTP主端口，一般不用改，但如果这台机器上已经有别的服务占用8080，就需要用文本替换大法把把端口改掉。另外注意，如果你把端口改成80，Tomcat要以root用户启动才能绑定1024以下的端口，这和我前面说的低权限运行是冲突的。生产环境更常见的方案是让Nginx监听80/443，再把请求反向代理到内网的8080，这个模式我建议你在规划架构时就定下来。

3.2 线程池和连接器参数调整：别让Tomcat默默排队

Tomcat默认配置能跑，但扛不住高并发。很多人遇到的现象是：服务看起来没挂，CPU也不高，但请求非常慢，或者偶尔出现连接超时。这时候往往不是应用代码的问题，而是Connector和Executor的线程模型没有调好。

Tomcat从8.5开始默认使用NIO模型，可并发处理的连接数大幅提升，但真正处理Servlet请求的线程池大小依然有限。默认的maxThreads是200，如果应用内部有数据库慢查询、第三方接口调用等阻塞操作，200个线程很快就占满，后面的请求全部排队。我常用的配置是在server.xml的Server节点下加一个Executor，再让Connector引用它：

xml复制<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
          maxThreads="500"
          minSpareThreads="50"
          maxIdleTime="60000"/>

然后在Connector里改成：

xml复制<Connector port="8080"
           protocol="HTTP/1.1"
           executor="tomcatThreadPool"
           connectionTimeout="20000"
           acceptCount="200"
           maxKeepAliveRequests="-1"
           URIEncoding="UTF-8"/>

需要理解背后的逻辑，而不是照抄数字。maxThreads是同时处理请求的最大工作线程数；acceptCount是等待队列的长度，当线程都被占用时新连接先进入这个队列；maxKeepAliveRequests="-1"表示HTTP长连接不限制复用次数。每个线程都会占用一块Java堆栈内存，线程不是越多越好，比较合理的方式是同时观察应用的TP99延迟和线程使用率，如果长时间跑满再逐步上调。acceptCount也别设太大，否则用户感觉不到报错，只是被无限期挂起，更糟糕。

3.3 JVM内存参数和setenv.sh的配置习惯

Tomcat完全运行在JVM里，如果JVM堆内存不够，就会出现java.lang.OutOfMemoryError: Java heap space。默认情况下JVM会根据物理内存自动决定堆大小，通常约是物理内存的1/4，小内存机器可能不够，大内存机器又没充分利用。生产环境我强烈建议显式指定堆大小，而不是让JVM自动调整。

Tomcat官方其实不推荐去改catalina.sh主脚本，因为它每次升级都可能被覆盖。更规范的做法是在bin/目录下新建一个setenv.sh，catalina.sh启动时会自动检测这个文件并加载它。我常用的参数：

bash复制# /opt/tomcat9/bin/setenv.sh
JAVA_OPTS="-Xms2g -Xmx2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/tomcat9/logs/heapdump.hprof -Djava.security.egd=file:/dev/./urandom"

解释一下这几个参数。-Xms和-Xmx分别代表初始堆和最大堆，我习惯设成相同值，避免JVM在运行中反复扩容缩容，这种动态调整会导致不必要的停顿。-XX:MetaspaceSize和-XX:MaxMetaspaceSize控制的是类元数据区域，Tomcat会加载很多类，老项目尤其要注意，设512M已经能覆盖绝大多数场景。-Djava.security.egd=file:/dev/./urandom这个参数和启动慢有直接关系，后面的排查章节我会详细说。

设置堆大小时可以参考物理内存来定，比如4G内存的机器，堆给2G是比较稳妥的，还要留一部分给操作系统、堆外内存和线程栈。给JVM用完所有内存导致系统开始频繁swap，那比OOM更可怕。

3.4 让systemd接管Tomcat的启停和开机自启

手动执行startup.sh只能临时启动Tomcat，服务器一重启服务就丢了。生产环境必须把Tomcat交给systemd管理，实现开机自启、异常退出自动拉起、统一查看日志。我自己用systemd unit文件的方式是让Tomcat跑在前台模式，而不是用startup.sh那种fork后台模式，因为systemd对前台进程的状态判断更可靠。

在/etc/systemd/system/tomcat.service中写入：

ini复制[Unit]
Description=Apache Tomcat 9 Web Application Container
After=network.target

[Service]
Type=simple
User=tomcat
Group=tomcat
Environment="JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64"
Environment="CATALINA_HOME=/opt/tomcat9"
Environment="CATALINA_BASE=/opt/tomcat9"
ExecStart=/opt/tomcat9/bin/catalina.sh run
ExecStop=/bin/kill -15 $MAINPID
SuccessExitStatus=143
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

这里ExecStart用的是catalina.sh run，它会一直占据前台进程，systemd的Type=simple只管这个主进程，启停状态一目了然。ExecStop写成优雅停机，给JVM发SIGTERM信号，让Tomcat有机会处理清理工作，而不是直接kill -9。JAVA_HOME的路径改成你服务器上的实际JDK路径。

配置完成后执行：

bash复制systemctl daemon-reload
systemctl enable --now tomcat
systemctl status tomcat

以后就不用再手动执行startup.sh和shutdown.sh了，统一用systemctl restart tomcat管理。查看启动日志也不再翻文件，直接journalctl -u tomcat -f就能实时看到标准输出，这个体验比手动脚本舒服太多。

4. 正式部署Web项目与高频问题排查指南

4.1 war包部署的推荐操作路径

部署Web项目最基础的方式是把war包丢进webapps目录，但如果项目已经在线上运行，直接覆盖会有一堆坑，比如旧目录没清理、jar包被占用、解压后文件残缺。我自己有一套相对稳妥的部署流程，特别是更新生产环境时，按这个顺序做能最大程度避免故障。

先把war包上传到临时目录，然后停掉Tomcat，再清理旧的webapps下的应用目录和旧war包，最后放入新war包并启动：

bash复制systemctl stop tomcat
rm -rf /opt/tomcat9/webapps/myapp
rm -f /opt/tomcat9/webapps/myapp.war
cp /tmp/myapp.war /opt/tomcat9/webapps/
systemctl start tomcat
startup后检查 /opt/tomcat9/logs/catalina.out

有人会觉得每次部署都要停机太麻烦，想利用Tomcat自动解压的热部署能力直接copywar包进去。我试过很多次，热部署确实能触发自动解压，但如果旧版本有线程没释放干净，经常出现“旧代码还在跑”或者文件锁占用。特别是大的war包，解压过程中一旦用户访问，可能读到半个文件。所以部署到Web项目，我强烈建议走“停服务-替换-启动”的流程，别贪那几分钟在线时间。

如果应用不希望放在webapps下面，比如项目文件很大、磁盘挂载在别的分区，可以用一个Context描述文件把应用指向外部路径。在conf/Catalina/localhost/下建一个myapp.xml：

xml复制<Context docBase="/data/apps/myapp.war" reloadable="false"/>

这样Tomcat启动时会自动加载myapp.xml，并把/data/apps/myapp.war映射到http://ip:8080/myapp。这种方式把应用数据和Tomcat本身分离开，升级Tomcat时不用动应用文件，是比较干净的做法。

4.2 从启动慢到403：六个高频问题一次说清

我在实际调配Tomcat过程中积累了一些高频问题，几乎每个服务器上都会遇到，这里按现象排序整理一下。

启动慢的问题要单独提。Tomcat在Linux上启动特别慢，有时要等几十秒甚至几分钟，网上最常见的解决办法是在JAVA_OPTS里加一行参数：-Djava.security.egd=file:/dev/./urandom。原因在于JVM在启动时要从/dev/random读取随机数来初始化安全相关的类，而/dev/random如果熵池不够就会阻塞等待。改成/dev/./urandom后，使用伪随机数生成器，启动速度会快很多。这个参数我实测非常有效，尤其是虚拟机环境，几乎立竿见影。

端口被占用同样是老熟人，错误日志类似Port 8080 required by Tomcat v9.0 Server at localhost is already in use，说明8080被别的进程占用了。排查命令：

bash复制ss -ltnp | grep 8080
lsof -i:8080

看到PID以后用ps -ef | grep PID确认是什么程序，再决定是kill还是改端口。还有一个更隐蔽的情况是Tomcat自己已经启动过一遍，第二次执行startup.sh报端口占用，其实只是因为前一个进程没停干净。

乱码分两种。页面返回的响应乱码，首先检查应用自身编码是不是UTF-8，如果代码里写了GBK，Tomcat怎么配都没用。请求参数的乱码，比如URL传中文参数乱码，检查Connector里有没有加URIEncoding="UTF-8"，更新版本的Tomcat虽然默认已经是UTF-8，但老版本不指定就可能是ISO-8859-1。日志乱码通常和Linux的locale有关，如果locale命令输出不是UTF-8，可能在conf/logging.properties里修改java.util.logging.ConsoleHandler.encoding=UTF-8。

403的问题很多人也遇到过。Tomcat管理页面默认被限制只能本机访问，配置文件是conf/Catalina/localhost/manager.xml，里面有一个RemoteAddrValve的访问控制阀，默认只允许127.0.0.1和::1访问。如果你需要远程管理，要修改或注释掉这个Valve，同时在conf/tomcat-users.xml中配置用户角色：

xml复制<role rolename="manager-gui"/>
<user username="admin" password="StrongPassword" roles="manager-gui,manager-script,admin-gui"/>

注意，这个用户和Linux系统用户没有任何关系，而且生产环境如果想暴露出manager页面，一定别用弱口令，很多扫描工具第一个目标就是Tomcat的默认管理接口。

4.3 日志、OOM与CPU排查速记

日志是排查问题的第一入口，但很多新手会分不清各种日志文件。catalina.out是Tomcat进程的标准输出和标准错误输出，System.out打印的内容、未捕获的异常都会落到这里，也是排查问题时最常看的文件。catalina.YYYY-MM-DD.log是Tomcat自身通过java.util.logging记录的运行日志，按天滚动。localhost.YYYY-MM-DD.log记录Tomcat启动过程中的应用加载信息。manager和host-manager的日志则与管理界面相关。

关于catalina.out，有一个坑就是它默认不会自动切割，长期运行的服务器上这个文件可能膨胀到几十G。我处理的方式是通过logrotate定期切割，新建/etc/logrotate.d/tomcat：

text复制/opt/tomcat9/logs/catalina.out {
    copytruncate
    daily
    rotate 15
    compress
    missingok
}

Tomcat进程会持续向catalina.out写入文件句柄，普通rename方式切割后Tomcat还在往旧文件里写，所以要加copytruncate参数，先复制再截断原文件，这种方式虽然会丢一点点尾部日志，但对在运行中的Java进程已经是最实用的方案了。

遇到内存溢出，日志里会出现java.lang.OutOfMemoryError，如果你按前面说的设置了HeapDumpOnOutOfMemoryError，在指定目录会生成一个heapdump.hprof文件，用MAT或VisualVM分析就能定位是哪个对象占了大头。CPU飙高的排查思路是：先用top看哪个Java进程占用CPU高，再用top -Hp 进程ID找到CPU最高的线程ID，把线程ID转成16进制，最后用jstack抓线程栈：

bash复制top -Hp $(pidof java)
printf '%x\n' 线程ID
jstack 进程ID | grep -A 20 "0x线程ID"

执行到这里基本就能看清是业务线程在死循环、GC线程在疯狂回收，还是一个莫名其妙的外挂线程在作妖。这套命令组合在很多情况下都能救命，我建议你把它们抄进自己的运维笔记里。

最后再分享一个我自己的习惯：每次调整server.xml或JVM参数后，重启之前我会先用/opt/tomcat9/bin/configtest.sh预检一遍配置文件，确认没有语法错误再执行systemctl restart tomcat。这样一个小的前置检查，能让你避免改完配置文件后服务起不来的尴尬场面，省下的时间足够喝好几杯咖啡了。