企业官网建设流程全解析

第一次在Linux服务器上装Tomcat的时候，我以为这事顶多半小时：下载个压缩包，解压，跑一下startup.sh，万事大吉。结果连续踩了好几个坑，先是JAVA_HOME没配导致启动脚本直接报错，后来又是8080端口被占、访问地址死活不通，才意识到Tomcat的安装整体上不难，但前面那些容易被忽略的细节才是真正的分水岭。这篇指南把我在Linux环境下安装、配置、部署Tomcat的完整过程整理了出来，从JDK版本匹配、环境变量设置，到server.xml核心参数、systemd自启、安全加固，适合刚接触Linux服务器部署的开发者，也适合课设/毕设需要交Java Web项目的学生，还给接手旧服务器部署的新手运维留了一份排查速查表。

1. 动手之前，先把Tomcat的版本和JDK关系理清

1.1 Tomcat是什么，为什么你的Java Web应用需要它

Tomcat本质上是一个Servlet容器，同时也是轻量级的Java Web应用服务器。你写的Java Web项目，无论是传统的JSP/Servlet，还是基于Spring Boot打出来的war包，最终都需要一个能理解Servlet规范、能执行JSP、能处理HTTP请求的运行时环境，这个环境就是Tomcat。很多开发者在Windows笔记本上就能跑起来，是因为IDE内置了Tomcat插件，但到了Linux服务器上，你就必须自己在系统里安装一份完整的、独立的Tomcat实例。

我在实际接触的项目里，见过不少人的服务器上只装了JDK，却没有Tomcat，然后问为什么war包部署不上去——因为Spring Boot内嵌Tomcat的玩法让大家忽略了一件事：内嵌容器只对你打包好的jar包有效，如果你拿到的是war包，你仍然需要一个外部Servlet容器来承载。Tomcat就是那个外部容器。

1.2 版本匹配是第一道坎：JDK版本决定了你能用哪个Tomcat

很多新手栽的第一个跟头，不是安装过程，而是版本选错了。Tomcat和JDK之间的兼容关系是硬性的，版本不匹配，启动时轻则告警，重则直接失败。我说一个最常见的对照关系：

这里最坑的一个变化是Tomcat 10。Tomcat 10把Servlet API的包名从javax.servlet改成了jakarta.servlet，这意味着你手上那些基于javax.servlet旧包编写的项目，直接扔进Tomcat 10里是会报ClassNotFoundException的，除非你的项目本身已经迁移到Jakarta命名空间。所以如果你维护的是老项目，我给你的选型建议是：老老实实用Tomcat 9.0.x配JDK 8或JDK 11，这块最稳，遇到问题时搜索引擎能给你的方案也最多。Tomcat 10虽然新，但对于存量项目并不友好，不必为了尝鲜折腾自己。

1.3 二进制包还是源码包，选哪个更省事

Tomcat官方下载页面提供两种包：二进制发行版（Binary Distributions）和源码包（Source Code Distributions）。绝大多数情况下别碰源码包，那是给需要自己编译、定制内核功能的人用的，普通人下载源码包回来还得用Maven和JDK自己构建，纯属浪费时间。二进制包里面又分tar.gz、zip和Windows installer，Linux服务器上认准tar.gz就对了。

我见过有人下载了源码包回来，解压后发现没有bin目录，然后又跑去查“为什么Tomcat没有startup.sh”，其实根源就是下载错了包。记住这个经验：页面里带“src”字样的统统不选，选核心标识为tar.gz的那一栏，文件大小通常在10MB到20MB之间。

2. 安装前的环境准备：JDK、环境变量和目录规划

2.1 JDK装好后，第一步是把JAVA_HOME配明白

Tomcat是用Java写的，它启动时靠JAVA_HOME和JRE_HOME环境变量去找JVM。如果没有设置JAVA_HOME，启动脚本会直接报错，提示信息是：

Neither the JAVA_HOME nor the JRE_HOME environment variable is defined At least one of these environment variable is needed to run this program

这个报错信息极其常见，原因就一个字：没配环境变量。

安装JDK有两种路径。第一种是系统包管理器安装，比如在CentOS/RHEL系的系统上用：

yum install -y java-1.8.0-openjdk-devel

这种安装方式的好处是JDK会被安放到统一的系统路径下，比如/usr/lib/jvm/java-1.8.0-openjdk。安装完之后可以用readlink或ls命令确认具体路径，因为不同系统上这个路径的结尾可能会有差异。

第二种是手动安装Oracle JDK或OpenJDK的tar包，解压到一个固定目录，比如/usr/local/java/jdk1.8.0_xxx，然后手动设置JAVA_HOME。这种方式更灵活，但需要你自己保证PATH变量里包含$JAVA_HOME/bin。

设置环境变量时，我习惯把配置写进/etc/profile，因为这个文件对所有用户生效，Tomcat哪怕以专用用户运行，也能读到。文件末尾追加：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export PATH=$PATH:$JAVA_HOME/bin export CATALINA_HOME=/opt/tomcat

然后执行source /etc/profile让配置立即生效。这里有个实操细节：如果你用sudo su切换到root再执行source，那么当前shell的环境变量会更新，但如果你是通过su直接切过去，部分系统上PATH可能不刷新，遇到“java: command not found”时，先检查是不是环境变量没生效，别急着重装JDK。

2.2 目录结构说明：bin、conf、logs、webapps各自管什么

Tomcat解压后的目录看起来不复杂，但每个目录都有明确分工，后面排错基本都会用到：

其中logs目录是我最看重的。Tomcat的“黑匣子”就在logs下面，catalina.out记录启动过程和控制台输出，localhost.YYYY-MM-DD.log记录应用上下文初始化信息，manager等自带应用还有单独的日志文件。任何启动异常，第一步都是打开catalina.out看最后几十行。

2.3 装载目录选择：我为什么建议放在/opt/tomcat

Tomcat解压到哪个目录，其实没有硬性规定，但选对位置能让后续维护省心很多。我比较推荐放在/opt/tomcat，原因有三个：第一，/opt目录在Linux文件系统标准里就是给第三方独立软件预留的，不会跟系统自带软件混在一起；第二，很多公司的部署脚本、监控脚本默认会去/opt或/usr/local下找中间件，保持一致可以减少沟通成本；第三，Tomcat的war包、日志、临时文件都会在安装目录下产生，把它单独放在一个干净目录，备份和迁移时直接打包整个目录就行。

如果你习惯用/usr/local/tomcat也没问题，但千万不要把Tomcat解压到某个人的家目录里，否则一旦切换用户或者家目录权限变动，服务起不来的时候你都不知道去哪找问题。

3. 从下载到启动：完整安装流程实录

3.1 下载与解压：版本号怎么选、镜像怎么挑

Tomcat的官方下载地址是Apache官网，进入下载页后选择对应大版本下面的“Binary Distributions”。我给一个通用的下载方法：先确定大版本，比如9.0.x，然后点进当前最新小版本的tar.gz链接。在服务器上用wget直接拉包：

cd /usr/local/src wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.98/bin/apache-tomcat-9.0.98.tar.gz

这里的v9.0.98是我写稿时某个可用的小版本号，实际下载时请以官网当前发布的最新小版本为准。如果你在服务器上下载外网速度慢，可以改用你本地下好后再传上去的方式，或者在官方镜像列表里挑一个离你近的镜像地址。Apache官方会把最新版本放在dlcdn子域名下，但归档版本在archive.apache.org里也能找到，这一点对复现旧版本环境很有用。

下载后解压：

tar -zxvf apache-tomcat-9.0.98.tar.gz -C /opt mv /opt/apache-tomcat-9.0.98 /opt/tomcat

把目录名改成tomcat，可以让CATALINA_HOME路径简短且固定，避免以后升级版本时还要回头改一堆配置文件里的路径引用。

3.2 环境变量与启动脚本：startup.sh成功启动的关键

前文已经在/etc/profile里配置过JAVA_HOME和CATALINA_HOME了。现在检查一下配置是否生效，再启动：

source /etc/profile echo $JAVA_HOME echo $CATALINA_HOME /opt/tomcat/bin/startup.sh

startup.sh成功执行后，终端会输出类似“Tomcat started.”的提示。但这里有个容易误导新手的细节：启动脚本本身不会阻塞终端，它把Tomcat进程放到后台运行了，看到提示不代表服务真的起来了。紧接着要做状态验证。

Tomcat启动依赖的关键脚本是catalina.sh，startup.sh本质上就是调用它来启动。如果你在startup.sh执行后出现异常，想查看详细的JVM参数、类加载信息，可以手动执行：

/opt/tomcat/bin/catalina.sh run

这种方式会让Tomcat以前台模式运行，所有日志直接打在屏幕上，非常适合调试启动失败的问题。调试完按Ctrl+C停掉，再恢复正常启动方式。

3.3 启动验证：进程、端口、页面三层检查

启动之后不要急着关终端，先做三层验证：

第一层，看进程是否存在：

ps -ef | grep tomcat

正常情况下能看到两个Java进程，一个是Tomcat主进程，一个是它的子进程。如果进程瞬间消失，别猜了，去logs/catalina.out里看报错。

第二层，看端口监听：

ss -lntp | grep 8080

8080端口处于LISTEN状态，说明HTTP连接器已经正常工作。如果不通，可能是端口被改过，也可能是别的问题，此时检查conf/server.xml里的Connector端口配置。

第三层，用curl验证HTTP响应：

curl http://localhost:8080/

正常返回200状态码，并且页面内容里包含Tomcat字样，说明服务已经跑起来了。到这里，安装与基础验证环节就算完成了。如果本机curl能通，但浏览器访问不通，问题通常出在防火墙或云服务器的安全组规则上，这两项在后面的章节里展开说明。

4. 核心配置文件server.xml详解与常见改动

4.1 三个端口各管什么事：8005、8080、8009

打开conf/server.xml，第一眼看到的通常是三个端口配置，很多人不知道这三个端口分别是什么角色，乱改一通导致服务起不来。

Server port那行配置是这个样子的：

<Server port="8005" shutdown="SHUTDOWN">

这个端口的设计初衷是运维在本地向Tomcat发送关闭指令。它默认只绑定127.0.0.1，在没改过配置的情况下，外网是访问不到这个端口的。我见过有人为了省事把这个端口改成0，Tomcat确实也能启动，但会失去关闭指令的通道，shutdown.sh就关不掉服务，所以不建议乱改。

4.2 线程池与连接参数：maxThreads、acceptCount这些值怎么调

server.xml里HTTP Connector的配置是最值得花时间琢磨的，默认配置大致是这样：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

这里没有显式写明的参数还有一堆。我挑几个高频调整项说明：

• maxThreads：处理请求的最大工作线程数，默认200。线程数不是越大越好，因为每个线程都会占用内存，线程过多时CPU上下文切换开销会抵消并发收益。如果压测发现请求排队严重，可以逐步加到400到800，但要看服务器自身CPU核心数和物理内存来定。
• acceptCount：操作系统层面排队等待处理的连接数，默认100。当所有线程都在忙时，新连接会进入accept队列。这个值可以适当加大，比如512，因为如果队列满了，客户端会直接收到Connection refused。
• maxConnections：服务器允许同时建立的TCP连接数，默认取决于操作系统和应用场景，一般是8192。这个参数要比maxThreads大，因为连接建立不等于立即处理请求。

调优实战中我更推荐先压测再调整，而不是照抄网上的“万能参数”。比如你要测试一个接口的吞吐量，可以用压测工具先打一轮，观察Threads Busy指标和请求失败率，再决定是否需要调大maxThreads。盲目把线程数调到2000，在高并发场景下很容易把服务器内存吃完，然后OOM，得不偿失。

4.3 修改默认端口：把8080换成80的真实约束

很多人希望访问Tomcat时不用加端口号，也就是用http://域名/这种方式，那意味着要把端口改成80。以前老教程都喜欢教iptables做端口转发，但新版Tomcat的server.xml里，直接把HTTP Connector端口改成80就能用：

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

改完重启Tomcat后，访问80端口即可。但这里有一个Linux平台特有的限制：1024以下的端口需要root权限才能绑定。如果你让Tomcat以普通用户运行（这个做法在后面的安全加固章节会推荐），那么即使配置了80端口，进程也可能启动失败，log里会报Permission denied。

解决这个问题有几种思路。一是用iptables或nftables做端口转发，把80请求转发到8080；二是用systemd的AmbientCapabilities给进程绑定80端口的权限；三是最省事的方案，前面挂一个Nginx做反向代理，Nginx监听80，再转发到后端的8080。实际生产环境中，我个人更推荐第三种，因为Nginx还能顺带解决静态资源缓存、HTTPS证书等问题。

4.4 自带的Manager和默认应用怎么处理

Tomcat安装完成后，webapps目录下默认带着ROOT、docs、examples、manager、host-manager这几个应用。其中manager和host-manager是管理应用，可以用浏览器界面来部署和热更新war包。听起来很方便，但对公网暴露的服务器来说，这俩是安全风险的来源，因为很多攻击者会扫描默认的manager路径尝试弱口令。

既然是默认配置，就没有密码，但Tomcat会限制只允许本机访问。生产环境最稳妥的做法是删掉这些默认应用，只留ROOT或者连ROOT都替换成你自己的应用：

rm -rf /opt/tomcat/webapps/*

如果你确实需要manager做远程部署，可以单独配置访问账号和角色，并且限制来源IP，但请衡量一下这个便利性值不值得承担风险。我自己的习惯是，测试环境留manager，生产环境一律清空。

5. 把Tomcat注册成systemd服务，实现开机自启

5.1 为什么建议用systemd托管而不是裸跑startup.sh

裸跑startup.sh的问题是：服务器一重启，Tomcat不会自动恢复。你可能会想，那我写个rc.local把启动命令加进去不就完了？从思路上没错，但systemd能给你的不只是开机自启，还有进程守护、崩溃自动拉起、集中日志管理这些能力。

用systemd托管之后，如果Tomcat进程因为内存溢出或者其他原因挂掉了，systemd会根据Restart策略自动帮你拉起来，这个在高可用场景里非常管用。另外systemctl status tomcat能直接看到服务当前状态、主进程PID、最近日志，排查问题时不用再翻demons日志那么费劲。

5.2 用一个独立用户跑Tomcat：安全降权的常规操作

以root身份启动Tomcat是个糟糕的操作习惯，因为Tomcat如果被利用了某个漏洞，攻击者直接就能以root级别权限操作系统。正确的做法是创建一个专用低权限用户，让Tomcat进程只拥有自己目录的读写权限。

创建用户的步骤：

useradd -r -s /sbin/nologin tomcat chown -R tomcat:tomcat /opt/tomcat

-s /sbin/nologin表示这个用户不能用来登录shell，这是服务账号的典型配置。把/opt/tomcat目录归属改成这个用户后，Tomcat才能正常写入logs、work等目录。

如果你之前已经用root启动过一次Tomcat，还需要检查一下/opt/tomcat/logs和work目录里的文件所有权，确保都是tomcat用户所有，否则启动时会遇到无法写入日志的错误。

5.3 unit文件示例与参数说明

在/etc/systemd/system/目录下新建一个tomcat.service文件，内容如下：

[Unit] Description=Apache Tomcat Web Application Container After=network.target [Service] Type=forking User=tomcat Group=tomcat Environment="JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk" Environment="CATALINA_HOME=/opt/tomcat" Environment="CATALINA_BASE=/opt/tomcat" ExecStart=/opt/tomcat/bin/startup.sh ExecStop=/opt/tomcat/bin/shutdown.sh Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target

配置好之后执行：

systemctl daemon-reload systemctl enable tomcat systemctl start tomcat systemctl status tomcat

Type=forking这个设置需要重点说明。Tomcat的startup.sh脚本启动时会创建子进程，然后父进程退出，这正好符合Type=forking的语义：systemd认为父进程退出、子进程存活就是启动成功。如果你用Type=simple，systemd会认为主进程就是startup.sh本身，而它在完成使命后已经退出了，于是systemd就判定服务挂掉，甚至可能把子进程也给清理掉。

5.4 防火墙放行：8080能通，但别随手关防火墙

服务器上装了Tomcat，本机curl能通，浏览器却打不开，十有八九是防火墙阻碍。CentOS/RHEL系默认用firewalld，放行端口的命令是：

firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --reload

Ubuntu/Debian系一般用ufw：

ufw allow 8080/tcp

这里非常不建议直接systemctl stop firewalld或者ufw disable。关掉防火墙确实一了百了，但服务器就裸露在公网上了，等于把门从里面拆了。正确做法是只放行必要端口，Tomcat对外开放80就放行80，对外开放8080就放行8080，其他保持默认拒绝。如果你用的是某云服务器厂商的云主机，还要记得去控制台的安全组规则里放行对应端口，那层规则是在防火墙之外单独生效的。

6. 部署你的第一个Web应用：war包与访问路径

6.1 最简单的方式：扔进webapps，自动解压部署

部署war包最简单粗暴的方式就是把war包丢到/opt/tomcat/webapps目录下，然后Tomcat会自动解压、自动部署。这个机制是在观察webapps目录是否有新文件，发现新war包后会在几秒内完成部署。

具体操作：

cp my-web-app.war /opt/tomcat/webapps/ ls /opt/tomcat/webapps/

完成后，webapps目录下会出现一个与war包同名的目录，比如my-web-app/，访问路径就是：

http://服务器IP:8080/my-web-app/

这里有个关键规则：war包文件名决定访问路径。如果你希望用户直接访问根路径，也就是http://ip:8080/，有两条路可走：一是把war包改名为ROOT.war再放进去；二是先清空webapps下原有内容，再把war包改名为ROOT.war。旧内容不清空的话，ROOT目录和你的新应用会同时存在，访问根路径时依然会命中原来的ROOT。

6.2 外部目录部署：应用和Tomcat分离的玩法

如果把war包直接放进webapps，那应用和Tomcat就绑定在一起了，以后更新应用的时候需要动Tomcat目录。某租户的运维同学更希望应用放在一个独立目录里，Tomcat目录保持干净，升级Tomcat版本时也不影响应用目录。

此时可以用server.xml里的Host节点下面加Context配置：

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Context path="/business" docBase="/data/apps/business" /> </Host>

docBase指向应用实际存放的目录，path是访问路径。这样应用可以放在/data/apps/business下，访问时会通过Tomcat去读取该目录下的资源。

这个方法也有注意点：docBase指向的目录在系统SELinux开启时，Tomcat进程可能没有权限访问。如果页面打不开，日志里报Permission denied，同时SELinux处于enforcing模式，就需要用semanage给Tomcat开放对应目录的访问策略。这个内容在后面的安全章节会继续讲。

6.3 部署失败的常见信号：404和Deployment报错

部署war包后最常见的问题是访问404。排查逻辑要清晰：先确认war包有没有被解压，如果webapps目录下只有一个war文件而没有同名目录，说明自动解压部署阶段根本没成功。这时打开logs/catalina.out，里面通常会有一条以Deployment of web application archive开头的报错信息。

war包部署失败的原因多种多样，Spring Boot打包的war如果依赖冲突，启动类初始化异常，也会在日志里留下SEVERE级别记录。我习惯的排查顺序是：先看war包文件是否完整（用jar tf或者直接对比本地文件的MD5），再看日志里的Caused by，最后才考虑代码问题。

这里分享一个小技巧：修改了webapps下的JSP页面或者配置文件后，如果发现刷新页面没变化，除了浏览器缓存外，还要考虑work目录下的JSP编译缓存。Tomcat部署时会把JSP编译成Java类文件缓存到work目录，这个缓存没清理的话，修改的JSP不会立即生效。手动把work目录下对应的文件删掉再重启，比反复刷新页面有效得多。

7. 常见问题排查：从日志入手，别全靠猜

7.1 先学会看日志：catalina.out与localhost.*.log

Tomcat的logs目录里，catalina.out是启动脚本直接输出的控制台日志，很多启动阶段错误都在里面打印。它其实不会轮转，如果服务器运行很久，catalina.out会变得非常大，这本身也是运维上线前要处理好的问题。

除了catalina.out，logs目录下还有按日期命名的日志文件：

• localhost.YYYY-MM-DD.log：记录Web应用上下文初始化的过程，ClassNotFoundException这类问题常在这里
• manager.YYYY-MM-DD.log：只记录manager应用的操作日志
• host-manager.YYYY-MM-DD.log：Host的部署日志

排查当前问题时，实时跟踪日志是很高效的方式：

tail -f /opt/tomcat/logs/catalina.out

再配合grep过滤掉不需要的信息：

grep -n "SEVERE\|Exception\|Caused by" /opt/tomcat/logs/catalina.out

很多新人不知道什么时候看catalina.out，什么时候看localhost日志。我的经验是：启动级错误，看catalina.out；你部署的具体应用初始化失败，先看localhost日志里的应用名字段；访问报错时的堆栈，两边都可能出现。两个都得学会，不能只看其中之一。

7.2 经典报错速查表

把这些年遇到的高频问题整理成一张速查表，可以直接对照处理：

这张表看起来简单，但每一条背后都有对应的排查经验。比如“地址已经被使用”，很可能是你改了Server port或Connector port后，旧的Tomcat进程没杀掉，新进程又尝试绑定同一个端口。此时先ps -ef | grep tomcat，把残留进程kill掉再启动，别一开始就去怀疑配置文件。

7.3 内存溢出与JVM参数调整

Tomcat作为Java进程，举足轻重的就是JVM内存参数。默认情况下，Tomcat的JVM启动参数可能不够大，尤其当你部署了多个Web应用，或者某个应用有较大的缓存数据时，OutOfMemoryError很快就会出现。

JVM参数通过JAVA_OPTS环境变量传入Tomcat。修改方案是把JAVA_OPTS写到Tomcat的配置里，最推荐的位置是/etc/profile下或Tomcat的bin目录下catalina.sh，但更干净的方式是直接在systemd的unit文件里追加Environment：

Environment="JAVA_OPTS=-Xms512m -Xmx1024m -XX:MaxMetaspaceSize=256m"

参数含义：-Xms是JVM启动时初始堆大小，-Xmx是最大堆大小，-XX:MaxMetaspaceSize是元空间上限。经验是-Xmx和-Xms设成相同值，可以在启动时一次性分配内存，避免运行期频繁扩容带来的性能抖动。

具体设多大，得看服务器物理内存。一个常见误区是“内存越大越好”，实际上-Xmx设得接近物理内存总量时，操作系统会因为频繁的GC导致CPU飙高，甚至系统整体卡死。我给一个经验公式：先看free -m确认可用内存，把-Xmx设为物理内存的50%到70%左右，留出余量给操作系统和监控进程。比如4G内存的机器，-Xmx设2048m起步就比较稳妥。

改了JAVA_OPTS后重启Tomcat才能生效：

systemctl daemon-reload systemctl restart tomcat

重启后怎么确认参数生效？可以通过JVM自带的工具查看，比如jps找到进程号后再jinfo或者jcmd查看参数。如果你没装这些JDK工具，也可以在Tomcat启动日志里找到对应的JVM启动参数行，shutdown后重新启动时输出的第一行日志里就会带上-Xmx等参数。

8. 安全加固与生产环境经验

8.1 装完不是结束，这些默认项需要处理

Tomcat默认配置是为了开箱即用，而不是为了生产安全。除了前面说的删除默认应用之外，下面几项也是装完就要动手的：

一是关闭8009 AJP端口。如果你的架构没用到Apache httpd整合，AJP端口默认开着就是多了一个暴露面。稳妥的办法是在server.xml里把AJP Connector整行注释掉。这一点在旧版本Tomcat上尤为重要，历史上因为AJP协议出现的漏洞不在少数，保留一个用不到的协议没有意义。

二是修改8005关闭指令。虽然默认只监听localhost，但如果你在某些虚拟化环境下碰到了转发问题，8005被公网扫描到也会给你带来不必要的麻烦。可以把默认的shutdown参数改成一个随机字符串，避免别人猜出默认值直接发送关闭指令。

三是隐藏版本信息。Tomcat默认会在HTTP响应头里带上Server: Apache-Coyote/1.1，这个信息对攻击者来说是在帮助他锁定目标版本。隐藏版本信息不是改一个配置就能完成的，通常需要改源码重新编译，或者通过前置Nginx的header配置来覆盖。中小项目可以把重点放在“不对外暴露不必要端口”和“及时升级版本”上。

8.2 SELinux、文件描述符、日志轮转这类系统级事项

SELinux是很多开发者遇到Tomcat权限问题后绕不开的坎。在SELinux强制模式下，Tomcat只能访问系统默认上下文允许的目录，你把应用放到/opt/tomcat/webapps既是默认路径就还好，如果按照前面的介绍把应用放到/data/apps这类自定义目录，SELinux就会拦截Tomcat进程读取该目录。

最简单的确认方式：

getenforce

显示Enforcing时，你可以用ausearch或查看/var/log/audit/audit.log，确认是不是SELinux阻止了Tomcat的访问。解决思路有二：一是调整SELinux布尔值，二是给新目录打上正确的上下文标签：

semanage fcontext -a -t tomcat_t "/data/apps(/.*)?" restorecon -Rv /data/apps

也有些同学为了省事直接setenforce 0关闭SELinux，我不推荐这种做法。SELinux提供的安全边界对公网服务器很有价值，测试环境关掉尚可，生产环境建议保持强制策略，只针对应用目录做精准放行。

文件描述符限制同样容易被忽略。Tomcat在高并发场景下，操作系统默认的进程打开文件数量限制可能成为瓶颈。可以在systemd的unit文件里追加：

LimitNOFILE=65535

这是单个进程允许打开的最大文件数。调大它之后，Tomcat才能承受大量并发TCP连接而不报Too many open files。

日志轮转问题不能等到磁盘满了再去处理。Tomcat的catalina.out默认不会自动清理，所以最好配置logrotate。在/etc/logrotate.d/目录下新建一个tomcat配置：

/opt/tomcat/logs/catalina.out { daily rotate 7 copytruncate compress missingok }

含义是每天轮转一次，保留最近7个备份，使用copytruncate方式在不动Tomcat进程的情况下把当前日志截断。实际生产环境还有更复杂的处理方式，但对大部分中小项目来说，上面这种配置足矣。

9. 写到最后：我踩过的一些坑

Tomcat安装本身不难，难的是安装完到稳定运行之间的这一路。以我自己的经历来说，踩过最大的坑是版本迁移的适配问题——当时把一套老项目从Tomcat 8迁移到Tomcat 10上，项目里到处用的都是javax.servlet的包，启动后一直ClassNotFound，查了半天才发现是命名空间整个变了。那次之后我养成了一个习惯：凡是接手老项目，要做的第一件事就是确认JDK版本、Servlet容器版本和项目的依赖版本三者能否兼容，而不是等启动报错再来翻日志。

还有一个心得是关于“改配置”的纪律。Tomcat的配置项很多，但每次只改一个，改完立刻重启并验证。很多人一上来就同时改了端口、JVM参数、线程池和AJP配置，出错后根本分不清是哪个环节导致的。我自己的操作习惯是准备一台测试环境复现，生产环境只做单点变更，并且在server.xml里改了关键配置前先用cp备份一份带时间戳的原文件。这个小习惯看着笨，但真的能在深夜排障时救你一命。

最后再分享一个小技巧：如果你手上有多个Java应用要跑在同一台服务器上，与其硬塞进同一个Tomcat，我更建议用多个Tomcat实例，用不同的端口和独立的CATALINA_BASE目录。这样应用之间互不干扰，一个实例挂掉不会拖垮另一个，排查问题时边界也清晰得多。把这份指南里的步骤在每个实例上重复一遍，你就会发现，装Tomcat这件事熟练之后，真正拉开差距的是你有没有提前想清楚它的运行边界和运维方式。