企业官网建设流程全解析

做技术这几年，Tomcat算是我接触最多、也最容易被“坑”的中间件之一。前几天帮同事排查一个服务反复启动失败的问题，折腾了半天，最后发现只是JDK版本和Tomcat版本不匹配。这种问题在论坛里一搜一大把，但真轮到自己遇到，还是容易卡住。所以就想着把Tomcat从安装、配置到部署、调优、排障的完整流程整理成一篇汇总型教程，把我踩过的坑和常用配置都写清楚，后端开发、运维、还有刚入门的小白都能直接参考。

这篇内容我会按一条完整的实操链路来写：先讲清楚安装前必须知道的版本匹配和环境准备，再走一遍Windows和Linux下的安装配置，然后详细拆解server.xml、web.xml这些核心配置的作用，接着讲怎么把项目部署进去、怎么调JVM参数和并发性能，最后把高频故障和排查思路整理成速查表。每一部分都会给出具体操作和参数说明，保证你照着做就能跑起来。

1. 安装前先搞懂这几个底层概念

1.1 Tomcat和JDK的版本匹配怎么看

很多人一上来就下载安装包，结果启动闪退或者报UnsupportedClassVersionError，根本原因基本都是JDK版本和Tomcat版本对不上。Tomcat本身是Java写的，运行必须有JDK或JRE环境，而且每个大版本对Java版本都有明确要求。

• Tomcat 8.5、9.0：最低要求Java 8，日常用JDK 8或JDK 11都没问题。
• Tomcat 10.0、10.1：最低要求Java 11，而且Servlet规范从javax.改成了jakarta.，老项目直接扔进去跑不起来。
• Tomcat 11：要求Java 17及以上。

建议直接用Tomcat 9.0配合JDK 8，这是目前兼容性最稳的组合，也是大多数老项目的标配。如果是新项目，可以考虑Tomcat 10.1配合JDK 17，但要注意项目里的依赖包是否已经迁移到jakarta命名空间。判断方法很简单，打开压缩包里的RELEASE-NOTES文件，里面会明确写着支持的Java版本。

1.2 什么是CATALINA_HOME、CATALINA_BASE

这两个环境变量初学者特别容易搞混。CATALINA_HOME指向Tomcat的安装目录，包含bin、lib这些核心程序；CATALINA_BASE则指向实例的配置目录，默认情况下和CATALINA_HOME相同。如果一个机器上要跑多个Tomcat实例，就可以共享同一个CATALINA_HOME，再各自指定不同的CATALINA_BASE来隔离配置和应用，互不影响。

对于大多数单实例部署场景，只需要设置CATALINA_HOME就够了。启动脚本会优先使用CATALINA_HOME，找不到时再根据当前路径推断。我的建议是不要图省事，直接把它写进系统环境变量，后面写脚本、配监控、维护路径都会方便很多。

1.3 下载安装包时怎么选版本和镜像源

Tomcat官网的下载页面有源码包和二进制包，我们只需要二进制分发包，格式一般是zip或tar.gz。Windows下载zip，Linux下载tar.gz。注意区分“core”和“full distribution”版本，core就足够了，full多了一些文档和示例。

下载速度慢的话，可以使用国内镜像源。不同教育机构和云厂商的镜像站都维护了Tomcat的历史版本，用起来非常稳定。选版本时建议用偶数稳定版，避免直接用最新的奇数版本，比如9.0.x的中间版本，踩坑概率会小很多。

2. 安装与环境变量配置

2.1 Windows下从解压到启动

Windows安装Tomcat非常简单，但有几个细节特别容易出问题。

第一步，把下载好的zip包解压到指定目录。注意路径不能有中文、空格，最好也不要放在系统盘Program Files这种权限受限的目录，否则后面写文件或部署项目时会遇到各种权限问题。我习惯放在D:\dev\tomcat这样的目录。

第二步，确认JDK已安装并配置好JAVA_HOME环境变量。右键“此电脑” → 属性 → 高级系统设置 → 环境变量，新建一个系统变量：

JAVA_HOME=C:\Program Files\Java\jdk1.8.0_301

然后编辑Path，在后面追加%JAVA_HOME%\bin。

第三步，设置CATALINA_HOME：

CATALINA_HOME=D:\dev\tomcat\apache-tomcat-9.0.89

第四步，进入%CATALINA_HOME%\bin目录，双击startup.bat启动。启动成功会弹出一个命令行窗口，并且最后显示Server startup in [xxx] milliseconds。然后在浏览器访问http://localhost:8080，看到Tomcat默认首页就算安装成功。

如果双击之后窗口一闪而过，多半是环境变量配置有问题。解决办法是在命令行手动执行startup.bat，这样错误信息会停留在窗口里，能看到具体报的是哪个错。最常见的就是“找不到JAVA_HOME”或者“JAVA_HOME路径无效”。

2.2 Linux下安装并配置systemd管理

Linux服务器的Tomcat安装建议使用tar.gz包，解压后放到/usr/local/tomcat，然后做几个关键配置。

解压：

tar -zxvf apache-tomcat-9.0.89.tar.gz -C /usr/local/ mv /usr/local/apache-tomcat-9.0.89 /usr/local/tomcat

设置环境变量，编辑/etc/profile，在末尾追加：

export JAVA_HOME=/usr/local/jdk1.8.0_301 export CATALINA_HOME=/usr/local/tomcat export PATH=$PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin

然后执行source /etc/profile生效。注意还需要给Tomcat的bin目录加执行权限：

chmod +x /usr/local/tomcat/bin/*.sh

启动和关闭：

/usr/local/tomcat/bin/startup.sh /usr/local/tomcat/bin/shutdown.sh

不过更推荐用systemd托管Tomcat进程，这样开机自启、日志收集和异常退出重启都方便很多。创建一个service文件：

vi /etc/systemd/system/tomcat.service

写入以下内容：

[Unit] Description=Apache Tomcat 9 After=network.target [Service] Type=forking Environment=JAVA_HOME=/usr/local/jdk1.8.0_301 Environment=CATALINA_HOME=/usr/local/tomcat ExecStart=/usr/local/tomcat/bin/startup.sh ExecStop=/usr/local/tomcat/bin/shutdown.sh Restart=on-failure User=tomcat Group=tomcat [Install] WantedBy=multi-user.target

然后执行：

systemctl daemon-reload systemctl enable tomcat systemctl start tomcat

这里要注意，Tomcat最好不要直接用root运行，建议单独建一个tomcat用户，并对/usr/local/tomcat目录授权。这样即使Web应用被攻破，攻击者拿到的也只是tomcat用户权限，系统风险会小很多。

2.3 验证安装结果

启动后可以通过两个维度验证是否正常。一是看进程和端口，Linux下用ps -ef | grep tomcat和netstat -nltp | grep 8080，Windows下用任务管理器加netstat -ano。二是看日志文件，日志位于logs/catalina.out（Linux）或logs/catalina.<date>.log（Windows），里面会记录启动时间、端口监听信息和部署的应用。

访问http://ip:8080时，如果服务器有防火墙，记得开放8080端口。以前排查过一个问题，页面一直打不开，结果一切正常，就是安全组没放行端口，白等了好久。

3. 启动、停止与日志分析

3.1 前台启动和后台启动的区别

Tomcat有两种启动方式。Windows下用startup.bat，Linux下用startup.sh，属于后台启动，启动完命令行窗口就可以关闭。还有一种前台启动方式，执行catalina.sh run或直接运行catalina.bat run，这种方式Tomcat进程在前台运行，日志直接打印到当前终端，适合调试时用，Ctrl+C就能停掉进程。

我在生产环境从来不用startup.sh去启动，因为它的日志输出不受控，出了问题不好定位。更推荐的做法是先用catalina.sh run验证环境是否正常，确认没有报错后，再用systemd托管正常启动。

3.2 避免Linux下直接kill -9关闭Tomcat

这个我要单独拎出来强调。shutdown.sh脚本会向Tomcat发送关闭指令，让容器有机会释放资源、停止线程、保存会话状态。如果直接kill -9，进程虽然死了，但是端口可能处于半连接状态，文件锁也可能没有释放，甚至出现之前部署的应用还在跑的情况。

遇到过进程明明在，但shutdown.sh却关不掉的情况吗？这通常是因为有线程阻塞住了，比如数据库连接池没设超时，或者某个长连接一直持有锁。这时候不要重复执行shutdown.sh，先用jstack <pid>导出线程栈，看看主线程卡在哪个方法上，定位到问题再决定处理方式。实在要强制关闭，执行kill -9 <pid>，但记得后续重启时多观察日志。

3.3 日志文件怎么看

Tomcat的logs目录下有几种日志，区分清楚能少走很多弯路：

• catalina.out：标准输出和系统日志，启动异常、OutOfMemoryError都看这个。
• catalina. .log：Tomcat自身运行日志，记录内部事件。
• localhost. .log：Context部署异常的日志，应用启动失败时的报错基本在这。
• access_log日志：访问日志，需要配置才开启，记录每个HTTP请求。

排查问题有个固定的节奏：先看进程在不在，再看端口通不通，最后打开catalina.out从头到尾过一遍关键行。大部分问题都能在这一步直接定位。

4. server.xml核心配置解析

4.1 端口配置与连接器参数

server.xml是Tomcat最核心的配置文件，位于conf目录下。默认有三个端口：8080是HTTP请求入口，8005是关闭指令入口，8009是AJP协议端口。

常用的连接器配置如下：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="200" minSpareThreads="10" maxPostSize="0" URIEncoding="UTF-8"/>

有几个参数值得重点关注。

• connectionTimeout：建立连接后等待读取请求的超时时间，单位毫秒，默认20000。设置过短，慢网络下客户端容易报超时；设置过长，容易积累半连接请求。
• maxThreads：请求处理线程的最大数量，默认200。这个要根据服务器CPU核数和业务耗时来定，不是越大越好，线程过多反而会增加上下文切换开销。
• URIEncoding：强制设置UTF-8可以避免地址栏传中文参数时出现乱码。
• maxPostSize：POST请求表单内容的字节数上限，默认2MB，如果上传文件或提交大表单报413错误，可以调大或设为0表示不限制。

4.2 Host虚拟主机与应用部署目录

Host节点对应一个虚拟主机，默认配置是localhost，appBase指向webapps目录。Tomcat会把appBase目录下的WAR包和文件夹当成Web应用来加载。

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">

• unpackWARs：部署WAR包时是否自动解压成目录，开发环境设为true方便查看文件，生产环境可以设为false省去解压时间。
• autoDeploy：是否开启热部署，false可以防止有人拷贝WAR包导致应用被自动重新加载。

如果一个服务器要跑多个域名，可以配置多个Host，每个Host指向不同的appBase。但要记得在Host节点里配置对应的别名：

<Host name="www.example.com" appBase="/data/webapps" unpackWARs="true" autoDeploy="false"> <Alias>example.com</Alias> </Host>

4.3 Context配置与外部映射目录

有时候应用WAR包不想放在webapps目录里，而是想从别的路径加载，这时需要配置Context。一个不太推荐的做法是直接在server.xml的Host节点里加Context，因为改server.xml需要重启才能生效，而且改错一个字符整个Tomcat可能起不来。

更推荐的做法是使用独立的Context配置文件。在conf/Catalina/localhost/目录下新建一个xml文件，文件名对应访问路径。比如新建myapp.xml：

<Context docBase="/data/myapp" reloadable="true" path="/myapp"/>

访问http://localhost:8080/myapp时就会加载/data/myapp目录下的内容。docBase可以指向WAR包路径，也可以是解压后的目录或纯Class文件目录。这种方式的优点是部署和卸载只需要创建或删除xml文件就行，不需要动主配置。

4.4 web.xml里那些默认配置

Tomcat的conf/web.xml是全局Web应用配置文件，所有部署的应用都会继承这里的配置。里面有三个部分特别常用。

第一个是默认的Servlet，它负责处理静态资源访问。比如CSS、JS、图片，如果没有这个Servlet，浏览器请求静态文件会直接404。

第二个是欢迎文件列表。访问一个目录时默认展示的页面，按顺序匹配：

<welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> </welcome-file-list>

第三个是Session超时时间，默认30分钟：

<session-config> <session-timeout>30</session-timeout> </session-config>

项目如果有自己的web.xml，会覆盖全局配置。所以有时候在项目里改了session超时却不生效，可以先看看全局web.xml是不是有同样的配置项。

5. 把Web项目部署进Tomcat

5.1 静态部署与热部署

部署一个Web项目最简单的方式，就是把WAR包拷贝到webapps目录下，然后重启Tomcat。Tomcat会自动识别WAR包并解压。这种方式适合发布包固定的生产环境。

开发环境频繁改代码，每次重启Tomcat太慢了，可以用热部署。把WAR包直接丢进webapps（autoDeploy为true时），Tomcat会自动加载。如果修改的是JSP或静态资源，连重新部署都不用，直接刷新页面就能看到效果。如果是Java类文件发生变更，则需要重新加载整个Context。

需要注意，Tomcat把WAR包解压出来以后，如果原WAR包不变，默认不会覆盖解压目录。所以改完代码重新打包，最好先把旧目录删掉，再把新包放进去。否则你看到的一直是旧代码，排查起来极其崩溃。

5.2 使用Manager应用远程部署

Tomcat自带一个Manager管理应用，可以实现在线部署、卸载、查看运行状态。地址是http://localhost:8080/manager/html。默认没有配置访问权限，需要修改conf/tomcat-users.xml：

<role rolename="manager-gui"/> <role rolename="manager-script"/> <user username="admin" password="admin123" roles="manager-gui,manager-script"/>

配置好后重启Tomcat，就能通过Manager界面一键部署WAR包。脚本方式也能支持自动化，通过curl请求到/manager/text/deploy接口完成发布。线上有多台机器的时候，可以做一个简单的发布脚本，批量上传WAR包之后调用Manager接口。

5.3 IDEA中配置Tomcat并部署项目

IDEA配置Tomcat是很多新手绕不开的坎。步骤不复杂，但界面选项多容易点错。

打开IDEA，进入Run菜单下的Edit Configurations，点击加号，找到Tomcat Server，选择Local。在Application server区域点击Configure，选择Tomcat安装目录。切换到Deployment标签页，点击加号选Artifact，选择war exploded（开发时用，无需打包）或war（模拟生产部署）。确认后设置Application context，比如设为/demo，保存即可。

启动之后，IDEA会自动启动Tomcat，并在浏览器打开http://localhost:8080/demo/。如果启动失败，八成是同一个端口被其他进程占用了，IDEA会明确提示Address already in use，这时候用netstat -ano找到占用端口的PID，要么结束进程，要么把server.xml里的8080改成8081。

5.4 IDEA远程调试Tomcat的配置方法

线上问题只能在测试环境复现不了，那就直接在IDEA里挂上远程调试。原理不复杂：JVM提供远程调试端口，IDEA作为调试客户端连上去。

先在服务器上修改Tomcat的bin/catalina.sh，在文件头部添加一段JVM参数：

CATALINA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005"

然后重启Tomcat。本机IDEA打开Run/Debug Configurations，新增一个Remote JVM Debug配置，Host填服务器IP，Port填5005，然后用Debug模式启动这个配置。连接成功后，项目里的断点会命中等远程请求。这种方式的调试体验和本地调试几乎一样，只是代码要保证和线上一致，否则行号和变量对不上。

6. JVM参数与性能调优

6.1 怎么设置JVM内存参数

JVM内存设置不合理是导致Tomcat频繁Full GC甚至OOM的主因。Tomcat是Java应用，默认堆内存可能只有256MB，稍微跑点量就撑不住了。

Windows下修改bin/catalina.bat，Linux下修改bin/catalina.sh，在注释下方添加JAVA_OPTS：

JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxMetaspaceSize=256m -XX:+UseG1GC"

-Xms和-Xmx建议设置成相同值，这样JVM启动时就一次性分配好堆内存，避免了运行时动态扩容带来的性能损耗。-Xmx设置多大取决于服务器物理内存和机器上跑了几套服务，保守起见最大不要超过物理内存的一半。如果设置了800MB却频繁OOM，加内存或排查内存泄漏才是根治办法，光调大堆内存只能缓解。

6.2 线程池Executor配置

Tomcat默认的线程池使用maxThreads参数控制并发数。业务逻辑比较重、线程处理时间较长的情况下，建议单独定义Executor：

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="300" minSpareThreads="20" maxIdleTime="60000"/>

然后在Connector里引用这个线程池：

<Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1"/>

连接器的最大处理能力由maxThreads和acceptCount共同决定。acceptCount表示请求队列的长度，如果线程全都在忙，新来的请求会排队。业务有突发流量，可以适当调大acceptCount，但要注意这只是把高峰期的请求堆积在队列里，延迟还是会变高。并发和延迟在这个模型下是互相牵制的，搜索“Tomcat最大并发公式”能算出理论值，但实际最优值还是要做压测，用JMeter或wrk压几轮再看RT和错误率。

6.3 APR模式与native library警告

启动Tomcat时经常看到一行警告：

The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path

这个警告的意思是Tomcat没有找到APR本地库。APR是Tomcat Native提供的底层IO加速组件，利用操作系统原生能力处理高并发连接。开发环境忽略这个警告不影响使用，但生产环境面对高并发，建议装一下。

Linux下安装方式很简单，Ubuntu执行：

apt-get install libtcnative-1

CentOS执行：

yum install tomcat-native

编译安装方式稍微麻烦一些，需要安装OpenSSL和APR开发包，再用./configure配置。装好之后重启Tomcat，日志里会变成：

Using APR connector [org.apache.catalina.core.AprLifecycleListener]

说明APR模式已经加载成功。如果项目并发量不大，这个优化感受不明显，但堆满并发时，APR模式下Tomcat能支撑的长连接数量确实比纯Java模式高不少。

6.4 日志乱码问题处理

Tomcat在Windows下启动时中文乱码是常见问题。原因是Windows控制台默认编码是GBK，而Tomcat内部日志使用的UTF-8编码。

最简单的办法是修改conf/logging.properties，把日志输出控制台的部分改成GBK编码：

java.util.logging.ConsoleHandler.encoding = GBK

改完重启Tomcat，中文日志就正常显示了。Linux环境下一般不会遇到这个问题，因为默认语言环境是UTF-8。

7. Tomcat安全加固的几个建议

7.1 清理默认内容和禁用危险功能

装完Tomcat的默认目录里有几个内置应用，比如docs示例文档、ROOT默认首页、host-manager管理后台。生产环境这些应用建议直接清理掉，尤其是manager和host-manager，如果没配好密码，等于把后台管理权限挂在了公网上。

把webapps目录下除了admin之外的应用都删掉，或者保留一个空ROOT目录避免访问根路径返回404。另外，server.xml里的8009端口（AJP协议）如果不确定用途，直接注释掉，历史上出过多起通过AJP协议攻击的漏洞。

7.2 限制端口访问和管理权限

8080端口不一定要绑定所有网卡，只允许内网或指定IP访问的话，可以修改Connector的address属性：

<Connector port="8080" address="192.168.1.100" .../>

如果有多块网卡，只绑定内网IP就可以避免外部直接访问。对manager-web只能通过manager-gui角色访问，不要把admin和manager-gui混着用，同时给用户设置强密码。

7.3 Web应用安全头与访问控制

在应用层面，可以利用Tomcat自带的Filter或Valve功能做安全增强。不确定是否开启安全头检查，可以先用curl查看响应头，如果缺少X-Content-Type-Options和X-Frame-Options这些字段，可以考虑通过Filter补充：

<filter> <filter-name>HttpHeaderSecurity</filter-name> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class> </filter>

如果需要限制指定IP段才能访问某个应用，可以在Context里配置RemoteAddrValve：

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192.168.1.*|127.0.0.1"/>

这样配置后，不满足条件的IP访问会直接被拒绝，不需要应用代码里做任何处理。

8. 高频故障排查对照表

把平时遇到过的Tomcat常见问题整理成一个速查表，定位思路和处理办法放在一起，排查的时候能省不少时间。

上面表格里有一项，启动慢的问题值得展开说。有些服务器用的是低熵源的云主机，Java 8在启动时会从/dev/random取随机数，而这个设备在某些环境下阻塞非常严重，导致Tomcat启动耗时几十秒甚至几分钟。解决的方案是启动时加上面参数，让JVM使用/dev/urandom，效果立竿见影。这是我在某次项目上线时遇到的，当时排查了很久，最后就是这一行配置搞定的。

另外关于“大量RMI TCP Connection线程”这个问题，我观察过很多次，这些人不是内存泄漏，是JVM内部通信机制的正常体现，包括JMX远程连接、GC线程日志和RMI垃圾回收通信。如果线程数持续增长或者占用CPU很高，才需要关注，结合jstack去看线程栈基本就能判断。

9. 最后分享一个我的习惯

我在实际维护Tomcat服务器时，每次上线前都会固定做一遍检查：确认版本匹配、检查JAVA_OPTS是否符合业务需求、看server.xml里有没有多余配置、确认manager被清掉或加了强密码，最后用sh catalina.sh start启动，盯着catalina.out看前10秒的日志。

这两年来这套流程帮我躲过了不少服务不可用的问题，也让我形成了很好的排障节奏。比如那种“莫名其妙起不来”的情况，八成都是环境变量或者目录权限的问题。Tomcat本身不复杂，复杂的是和它配合的环境。你把这套链路里的每个环节都摸透了，再遇到别的Java中间件也会从容很多。