如果你是一名Java后端开发者那Tomcat这名字你肯定不陌生。就算你用的是Spring Boot内嵌的容器也总会有那么几个项目需要你在服务器上部署一个独立Tomcat或者接手遗留系统时被迫和它打交道。这篇教程就是写给所有被Tomcat支配过的人——不管你是刚接触JavaWeb的新手还是工作几年想彻底搞懂配置逻辑的老手这篇文章都会把Tomcat从安装、目录结构、核心配置到部署、调优、排错从头到尾讲一遍而且是以一个实际用下来的人的角度去讲不是我抄官方文档那种。我最早接触Tomcat时也被搞得很懵目录一堆、配置一堆改个端口都要百度半天更别提部署war包后经常遇到404或者启动失败。后来用得多了才悟到一个道理——Tomcat的本质没那么复杂它就是一个Java Web应用的楼宇物业。你的Servlet、JSP是房客HTTP请求是访客物业负责开门连接器、安排房间容器、维护秩序生命周期管理。你把它的架构逻辑理清了剩下的配置就都是填空题。这篇教程不需要你有很深的底子我会从安装JDK开始一步步带但内容也不全是大白话配置参数的原理、部署机制的原因我都会解释清楚这样你即便换了一个新的容器中间件也能举一反三。全程没有任何废话能直接抄作业也会告诉你哪些坑是我踩过之后才明白的。1. 从零认识Tomcat它究竟解决了什么问题1.1 Servlet容器是什么和普通Java程序有什么不一样很多人上来就直接用Tomcat但没想过一个问题为什么我的Java Web应用不能像普通Java程序一样直接java -jar或者java Main.class跑起来为什么非要塞进一个Tomcat里才能被浏览器访问答案在于一个Web应用本质上要处理的是HTTP请求而不是单纯的方法调用。浏览器发来一个HTTP请求里面带着URL、请求头、Cookie、参数你的应用需要解析这些信息找到对应的业务逻辑去执行再把结果包装成HTML返回。这一整套流程如果每个应用都自己手写那太痛苦了。Servlet规范就定了一个标准你只需要写一个继承HttpServlet的类实现它的doGet、doPost方法剩下的解析、封装、调用这些事情全交给Servlet容器来做。Tomcat就是这样一个Servlet容器实现。它负责的事情包括监听端口接收HTTP请求解析请求创建HttpServletRequest和HttpServletResponse对象根据URL找到对应的Servlet类加载并实例化它调用Servlet的业务方法管理Servlet的生命周期初始化、服务、销毁管理会话Session、处理并发、支持JSP解析所以Tomcat不是一个Web服务器那么简单严格来说它叫Servlet容器 HTTP服务器二合一。你可以只用它当静态文件服务器但它的核心价值是让Servlet和JSP跑起来。打个比喻Servlet就是你写的业务代码Tomcat是那个负责接待客人HTTP请求、安排服务员线程、管理餐厅库存会话状态的餐厅经理。你只需要把菜做好写业务逻辑剩下的事经理全包了。1.2 什么时候用独立Tomcat什么时候用内嵌的现在有个很普遍的情况很多人用Spring Boot框架开发启动方式就是mvn spring-boot:run或者打包后在命令行java -jar app.jar里面内嵌了一个Tomcat你甚至感受不到它的存在。那为啥还要懂独立部署我的经验是分场景来看。开发调试阶段内嵌确实方便改完代码重启一下就完事。但一旦到了生产环境区别就出来了独立Tomcat更适合多应用共存的场景。比如一台服务器上同时跑三个Web系统内嵌的方式就得开三个Java进程各占各的内存和端口管理起来很分散独立Tomcat在配置里开三个Context或三个虚拟主机就搞定了。独立Tomcat方便统一管理连接数、JVM参数、日志策略。所有应用的连接池、线程配置都集中在同一份server.xml里运维同学一看就懂。有些老项目用的SSH框架或者纯JSP项目压根不支持内嵌运行方式必须打war包扔进Tomcat的webapps目录。所以我个人观点是内嵌适合开发和新项目快速交付独立Tomcat适合生产环境稳定部署和运维管理。不要觉得学会了内嵌就万事大吉独立Tomcat这套逻辑你真的绕不开。1.3 Tomcat版本那么多怎么选才不会踩坑Tomcat的版本号看起来乱实际就三条主线8.5、9.0、10.1以及更新的11.x。不同版本对应的JDK版本和Servlet规范不同。Tomcat版本对应Servlet规范最低JDK版本适合场景Tomcat 7Servlet 3.0JDK 6太老千万别再用Tomcat 8.5Servlet 3.1JDK 7老项目的经典搭配Tomcat 9Servlet 4.0JDK 8最常见的生产选择Tomcat 10.1Servlet 5.0JDK 11新项目就用它Tomcat 11Servlet 6.0JDK 17实验性/特新项目这里面有一个极易踩的坑Tomcat 10开始包名变了。原来的javax.servlet全改成了jakarta.servlet。如果你从旧项目拷贝一个war包直接扔进Tomcat 10大概率直接报ClassNotFoundException: javax.servlet.*。所以在选择Tomcat版本时先确认你的项目依赖的是javax还是jakarta。这也是为什么很多公司明明有新版本却死守Tomcat 9的原因——老代码迁移的成本太高了。2. 环境准备与安装从下载到启动一条龙2.1 JDK安装与JAVA_HOME配置要点Tomcat是Java程序所以它自己跑起来也需要一个JDK或者JRE。安装之前建议先检查一下本机Java版本java -version如果没装或者版本太低先去官网装一个合适的JDK。注意不是装完就完事环境变量必须配置好。Tomcat启动脚本startup.sh / startup.bat会去读JAVA_HOME这个系统变量读不到就直接报找不到JAVA_HOME退出。Windows系统配置环境变量的方式是右键此电脑 → 属性 → 高级系统设置 → 环境变量。新增一个变量JAVA_HOME值是你的JDK安装目录注意不要带后面的\bin。然后在Path变量末尾追加%JAVA_HOME%\bin。Linux系统则在/etc/profile或者/root/.bashrc里面写export JAVA_HOME/usr/local/jdk-17 export PATH$JAVA_HOME/bin:$PATH配完后在命令行输入java -version能正常输出版本信息就说明环境没问题。有个细节容易忽略如果你装了多个JDK一定要检查java -version指向的版本和你设置的JAVA_HOME一致。有时候系统里早就装了一个旧JDK在别的路径导致Tomcat启动时用了错误的Java版本。注意配置完环境变量后新开的终端窗口才会生效。不要在旧窗口里浪费时间排查为什么改了不生效。2.2 下载Tomcat与目录摆放的讲究下载Tomcat没什么难度去官网找对应的Binary Distributions选tar.gzLinux或zipWindows。不要下src那是源码包。下载完解压后建议放一个不含空格的路径比如Linux下的/opt/tomcat、Windows下的D:\tomcat9。路径带空格的坑在配置CATALINA_HOME、执行脚本时都可能出现极其烦人。顺便解释一下CATALINA_HOMETomcat内部通过这个环境变量来定位它自己。启动脚本都会引用它比如运行/opt/tomcat/bin/catalina.sh时脚本里的逻辑会用到$CATALINA_HOME/bin、$CATALINA_HOME/conf。你可以不显式配置Tomcat会自动根据脚本所在位置推导但如果挪动了目录或者用服务方式启动显式配一颗更稳。方法跟JAVA_HOME一样export CATALINA_HOME/opt/tomcat2.3 启动、关闭与启动失败的快速判断Linux启动Tomcat执行cd /opt/tomcat/bin ./startup.shWindows则是双击startup.bat。正常启动后控制台会输出Tomcat started类似的话。但是这里有个极易误导人的点startup.sh出来说启动成功不代表一切OK了。Tomcat的日志输出在logs/catalina.outLinux或者logs/catalina.logWindows。遇到started但浏览器访问不了的情况第一步永远应该是去看日志文件尤其是最后几百行。我见过很多人卡在为什么启动成功但访问404上结果一看日志早就有异常了。验证Tomcat是否真正起来最直观的方式curl http://localhost:8080/如果返回了Tomcat默认首页的HTML说明进程已经正常监听8080端口。如果curl都没反应大概率进程压根没起来可能是端口被占用也可能是JVM参数配错直接启动失败。关闭Tomcat用shutdown.sh/shutdown.bat。强制杀进程的方式是ps -ef | grep tomcat找到PID后kill但这不是常规路顺序关不掉才考虑硬杀。经验之谈Linux下如果报Permission denied是bin目录下的.sh脚本没有执行权限。执行chmod x /opt/tomcat/bin/*.sh就好这种问题在Windows下不会遇到在Linux下几乎必踩一次。3. 目录结构拆解Tomcat每个文件夹是干嘛的3.1 bin与conf决定Tomcat能不能跑和怎么跑bin目录存放的是启动/关闭脚本和Tomcat自身依赖的一些类。除了startup.sh、shutdown.sh还有Linux下运维常用的catalina.sh。这个脚本的重要之处在于你配置JVM参数、JMX监控、调试端口时改的都是它。conf目录是整个Tomcat的大脑枢纽配置文件不多但个个都管核心事server.xml主配置端口、虚拟主机、连接器、上下文全在这。web.xml全局的Servlet映射规则、MIME类型映射、欢迎文件欢迎页面的默认设置。context.xml全局数据源、资源定义的配置。tomcat-users.xml管理Tomcat后台管理页面的用户和角色。catalina.properties包扫描路径、字符集等内部属性。我建议新手先把server.xml完整读一遍标记出每一块的用途再动手改配置。很多莫名其妙的问题根源都是对conf文件里某个节点含义一知半解改坏了。3.2 webapps与work你的应用在这里被处理webapps是部署目录。你把war包丢进去Tomcat会自动解压成同名目录并把它注册为一个Web应用Context。也可以直接放一个已经解压好的文件夹效果一样。一个常见的问题是一个war包在Tomcat里对应一个应用应用路径默认就是war包的名字。比如你部署一个demo.war访问路径就是http://localhost:8080/demo/。如果你希望应用直接跑在根路径http://localhost:8080/可以把war包改名为ROOT.war或者把解压后的目录改名为ROOT。这是Tomcat的特例规则。work目录是Tomcat的工作目录。JSP文件首次被访问时Tomcat会把它翻译成Java源文件再编译成Class文件这些中间产物就放在work/Catalina/hostname/应用名/下。一个常见现象你修改了JSP后刷新浏览器发现没变化除了浏览器缓存之外也可能是work目录里的旧Class缓存导致。删掉整个work目录然后重启Tomcat能解决大部分JSP不生效的灵异问题。3.3 logs与lib日志、依赖和那些看不见但离不开的文件logs目录存放Tomcat运行日志。典型文件包括catalina.out主输出日志控制台打印的内容都在这里。localhost.log应用级别日志有时候异常堆栈在这里而不在catalina.out。manager.log、host-manager.log管理后台的操作日志。排查问题时的经验是先看catalina.out的结尾然后grep异常关键词再针对性搜localhost.log。很多人在catalina.out里找不到关键异常是因为Tomcat把不同类别的输出分开写了。lib目录存放Tomcat运行期依赖的jar包。这里有一个所有人都该知道的禁忌不要随便往lib目录里扔你自己的jar包。Tomcat的类加载策略是父加载器优先你往全局lib里塞一个版本不对的依赖可能污染所有应用。该放应用的WEB-INF/lib就放应用自己的目录别偷懒。4. server.xml主配置逐行解析端口、域名、连接器一次摸透4.1 整体结构Server、Service、Engine、Host、Context的层级关系打开server.xml第一眼会觉得标签嵌套得眼花缭乱。实际拆开以后就是一个树状结构Server Service Connector / Engine Host Context / /Host /Engine /Service /Server我用一句话解释它们的关系Server是一个独立的Tomcat实例Service是这个实例内部提供的一组服务Connector是服务对外开的门端口Engine是请求处理引擎负责分发Host是虚拟主机类似Nginx里的server块区分不同域名Context是一个具体的Web应用实例。正常情况下一个Tomcat实例就一个Server一个Server里一个Service一个Service里一到两个ConnectorHTTP和AJP一个Engine下若干Host一个Host下若干Context。你把它想成一个公司Server有一个销售部Service销售部有几个对外窗口Connector窗口接待的客户按区域分给不同销售小组Host每个销售小组手里管着不同的客户项目Context一下子就清晰了。4.2 Connector节点端口、协议与连接参数详解Connector是server.xml里改动最频繁的节点。我先贴一个最常用到的HTTP/1.1连接器配置Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 maxThreads200 acceptCount100 URIEncodingUTF-8 /逐个说含义port监听端口。改端口改这里比如改成80。protocol用的协议。历史版本里曾出现过protocolHTTP/1.1和protocolorg.apache.coyote.http11.Http11NioProtocol两种写法效果大体相同现在的版本直接用HTTP/1.1即可。NIO和新版本的NIO2是默认IO模型无需手动指定。connectionTimeout建立连接后如果客户端一直不发请求等待多少毫秒后断开。设太短会出现稍微想想就断线设太长会占用服务端资源。20000毫秒20秒是个中庸值。redirectPort当请求是HTTPS但当前Connector是HTTP时重定向到哪个端口。配合8443这个默认HTTPS端口。maxThreads处理请求的最大线程数。这个反而不是越大越好取决于CPU核数和业务耗时后文调优环节细说。acceptCount当线程池打满后还能排队等多少请求。超出这个数量会拒绝连接并报错。URIEncodingURL的字符编码。如果你在地址栏传中文参数比如?name张三不设置这个经常会出现乱码。建议写成UTF-8。一个极易踩的坑把port改成80后程序启动直接失败。很大原因是80端口已经被Nginx或者Apache占用了你需要先检查端口被谁占用再考虑改端口。不要为了让用户不用输入端口就直接改80生产环境常见的做法是80端口交给Nginx然后Nginx反向代理转发到Tomcat的8080端口。4.3 Engine与Host域名、默认站点与应用路径的关系Engine nameCatalina defaultHostlocalhost Host namelocalhost appBasewebapps unpackWARstrue autoDeploytrue /Host /EngineEngine是整个处理引擎的名字默认值Catalina不用动。它的defaultHost属性非常关键当客户端请求的域名没有匹配到任何Host时请求就会落到这个默认Host上。Host可以配多个实现一台Tomcat跑多个域名。比如Host namewww.example.com appBase/data/app1 ... / Host nameadmin.example.com appBase/data/app2 ... /appBase是应用目录的根路径。注意它和Context的关系Host顺着appBase找Web应用war包或目录而Context是在路径映射层面精确指定一个个应用。unpackWARs设为true表示war包自动解压成目录true在开发阶段方便但部署太多应用时会稍微增加启动时间。autoDeploy设为true表示Tomcat会定时扫描appBase发现新的war包就自动部署生产环境如果希望严格手动控制可以设false。4.4 一个多Context应用的真实配置示例现在假设你开发了一个后台管理系统war包叫admin.war但你希望访问路径展示为/backend而不是默认的/admin。有两种做法第一种直接把war包改名为backend.war简单粗暴路径就变成/backend。第二种在conf/Catalina/localhost/目录下新建一个XML文件文件名就叫backend.xml内容Context docBase/data/apps/admin.war reloadabletrue /这样Tomcat启动时会读取这个XML文件自动注册一个路径为/backend的Context指向/data/apps/admin.war。好处是war包可以放在任意磁盘目录不必在appBase里面特别适合那种war包很大不想拷贝多份的场景。这种外部Context文件也支持数据源定义可以给特定应用配专属数据库连接池Context docBase/data/apps/admin.war reloadabletrue Resource namejdbc/mysql authContainer typejavax.sql.DataSource maxTotal20 maxIdle10 maxWaitMillis10000 usernameroot password你的密码 driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/admin_db?useUnicodetrueamp;characterEncodingUTF-8/ /Context在应用里通过jndi方式查这个数据源就可以了连接池直接由Tomcat来管理不需要在应用代码里反复创建连接。这个用法比自己在代码里写连接池干净不少尤其多项目共用一套Tomcat时特别实用。5. 四种Web应用部署方式实操对比从war包到热部署5.1 最朴素的部署复制war包到webapps目录这是最直白的方式没有任何技术含量但也是用的最多的。操作步骤把打好的xxx.war复制到webapps目录启动Tomcat或者如果已经启动等它自动扫描检测到新war包Tomcat会自动解压war包成同名目录浏览器访问http://localhost:8080/xxx/关键点war包怎么打出来的使用Maven的话执行mvn clean package产物在target/xxx.war。如果是手里只有文件夹最原始的方式是cd 你的项目目录 jar cvf xxx.war *jar是JDK自带工具cvf是参数create、verbose、file。这样打出来的war包不一定带正确的目录结构如果缺WEB-INF/web.xml之类Tomcat会拒绝部署哦。所以更推荐用Maven或构建工具去打包手动打容易出幺蛾子。5.2 Manager图形界面部署适合临时管理Tomcat自带一个管理后台。要启用它先编辑conf/tomcat-users.xml添加一个管理员角色role rolenamemanager-gui/ role rolenamemanager-script/ user usernameadmin passwordadmin123 rolesmanager-gui,manager-script/manager-gui角色可以用图形界面上传war包manager-script角色允许你用命令行/脚本方式调用管理接口。配置完重启Tomcat访问http://localhost:8080/manager/html输入账号密码就可以在页面上传war包、启停应用、查看应用状态了。这个方式的好处是零命令操作浏览器点点就好。坏处是管理后台暴露出去有安全风险生产环境建议关闭或者至少限制来源IP。Tomcat的manager页面默认只允许本机访问如果你从远程访问会报403需要在webapps/manager/META-INF/context.xml里修改Valve的allow字段比如Valve classNameorg.apache.catalina.valves.RemoteAddrValve allow127\.0\.0\.1|192\.168\.\d\.\d /这个改动有风险操作前先想清楚你的安全策略。我一般不推荐生产环境开启这个页面除非你确定只有内网能访问。5.3 server.xml配置Context精确指定应用目录前面提到过在conf/Catalina/localhost/下新建XML文件或者直接在server.xml的Host节点内写Context都能注册特定路径的应用。直接写在server.xml里的方式Host namelocalhost appBasewebapps Context path/backend docBase/data/apps/admin.war reloadablefalse / /Hostpath是访问路径docBase是实际war包或目录的位置。这种方式比war包放到webapps更灵活适合应用目录不在webapps下的场景。但它的缺点是在server.xml里写死了应用路径每次部署新版本都要改server.xml然后重启且不适合改动频繁的项目。现在推荐的做法已经是外部Context文件了可以避免修改server.xml。5.4 IDE热部署开发调试阶段的利器用IDE比如主流的Java IDE开发时项目可以直接以Tomcat运行的方式启动修改代码后按热部署按钮更新资源和类让IDE把新Class和资源文件推送到Tomcat里不需要重启Tomcat。这个功能非常适合写Controller和JSP频繁的阶段能极大提高开发效率。但你要知道背后的机制IDE不是把代码编译成war包再丢给Tomcat它是在本地启动了一个Tomcat实例然后把你的项目路径作为Context的docBase挂上去。相当于你的IDE替你管理了配置过程。你改了Java文件IDE可以编译好类文件并热替换你改了JSPTomcat的work目录会重新生成Class。这套调试方式非常爽但它也掩盖了很多部署细节导致很多新人对项目是怎么跑在Tomcat里的没概念。我建议你用IDE跑通一次之后再手动部署一次war包把两种方式都经历一遍实际理解会更上一层楼。6. 高频问题排查速查端口占用、404、启动失败一网打尽6.1 端口被占用启动时报Address already in use: JVM_Bind这是最常见的启动失败原因。你改了端口结果端口被别的进程占着Tomcat起不来。排查手段# Linux查看8080端口被谁占用 lsof -i :8080 netstat -tlnp | grep 8080 # Windows查看8080端口占用 netstat -ano | findstr 8080拿到占用的进程PID之后Linux用ps -ef | grep PID看看是哪个进程Windows用任务管理器找PID。如果是别的Tomcat实例在占把那个先关掉如果是别的不认识的程序谨慎判断能不能结束。很多人在这个坑里反复跌的原因明明把server.xml监听端口改了结果启动的还是旧端口。这种情况是因为你启动的根本不是同一个Tomcat比如机器上装了两份Tomcat或IDE里配置的Tomcat路径跟你在命令行操作的路径不一致。排查时先echo $CATALINA_HOME再确认你执行startup.sh的绝对路径别搞混了。6.2 启动一闪而过先学会看日志Windows双击startup.bat窗口黑屏一闪就消失这是新手最绝望的一刻。原因是脚本报错后窗口自动关闭你根本看不到错误信息。解决思路很简单不要双击bat改用命令行方式手动执行。cd D:\tomcat9\bin catalina.bat run这样拿到的错误信息就会完整打印在控制台里。同样Linux下如果startup.sh异常退出直接执行/opt/tomcat/bin/catalina.sh runrun参数是前台运行模式所有的启动日志都会实时输出。排查启动类问题的首选就是它。常见的前台启动报错包括The CATALINA_HOME environment variable is not defined correctlyJAVA_HOME或CATALINA_HOME配置有问题。Failed to initialize end point associated with ProtocolHandler端口相关通常是端口被占用。Caused by: java.lang.OutOfMemoryError: PermGen space/Metaspace内存不够需要调JVM参数。LifecycleException: Failed to start component ... Filter某个Filter启动失败常见于应用的web.xml里配置了不存在的类。6.3 页面404应用路径、上下文路径、欢迎文件三个方向排查部署成功后访问404这个问题的定位路径比较固定。先分四种情况第一访问http://localhost:8080/显示404。这可能是根路径没有任何应用webapps/ROOT没了也可能是欢迎文件配置问题。第二访问http://localhost:8080/demo/显示404。确认webapps下是否真的有demo.war或demo目录如果war包还没解压完就刷新偶尔会短暂404。第三访问一个具体的Controller地址报404。这种情况多半是应用内部路径映射的问题——你部署成功了但你的Servlet映射/Spring MVC的RequestMapping路径输入错了。责任在应用本身不在Tomcat配置。第四Context路径对不上。比如你改名为ROOT.war却还想用/ROOT访问路径对不上自然会404。还有一个容易被忽略的点conf/web.xml里的欢迎文件配置。Tomcat默认在访问目录时顺序寻找index.html、index.htm、index.jsp。如果你的应用首页文件名不是这些比如login.html那你访问http://localhost:8080/demo/就是404必须完整输入http://localhost:8080/demo/login.html才能打开。这种情况可以通过配置欢迎文件解决。6.4 中文乱码请求参数和搜索引擎参数一起排查中文乱码分两类请求参数乱码和响应内容乱码。请求参数乱码的根源在于URL编码和解码的字符集不一致。浏览器发送请求时用页面字符集编码URLTomcat解析时用URIEncoding二者不一致就乱码。解决方案很明确在Connector上加URIEncodingUTF-8。还有一种是POST表单乱码。Servlet API收到POST请求时需要手动设置request.setCharacterEncoding(UTF-8);如果你用Spring MVC内置的CharacterEncodingFilter已经帮你做了只需要在web.xml注册这个Filter。响应乱码通常就是Content-Type的头没带charset或者JSP页面头部的pageEncoding写的不对。一个全局兜底的方案是修改conf/web.xml把所有常用MIME类型里加上UTF-8的charset或者在每个Response里统一设置。经验如果改完Tomcat配置后乱码依然存在优先检查数据库连接串里有没有characterEncoding很多时候乱码根本不是Tomcat的问题而是JDBC连接时没声明UTF-8。6.5 JSP修改不生效work目录的缓存陷阱开发阶段改动JSP文件后刷新浏览器看到的还是旧页面。这个问题有两个常见原因。第一个是浏览器缓存。按CtrlF5强制刷新或者打开无痕窗口看看。确认不是浏览器缓存再往下查。第二个是work目录缓存。JSP文件在Tomcat里会被编译成Java源文件再编译成Class而且Tomcat默认会检测JSP文件的修改时间理论上改了就重新编译。但如果系统时间错乱、文件时间戳没更新或者某些IDE保存文件时不改变时间戳就可能出现改了等于没改的错觉。解决办法很简单停掉Tomcat删除整个work目录重新启动。Tomcat会自动重新编译所有JSP。这招在常规手段无效时最管用属于重启大法的变种。顺便提一句如果真的访问量不大把JSP页面做修改后直接重启Tomcat是最省心的不要在这方面花太多时间。7. 性能调优与生产避坑心得线程池、连接数与JVM参数7.1 连接器线程参数不要盲目调大maxThreads很多人的第一个调优动作是把maxThreads从默认的200调到1000以为这样就能扛更多并发。实际效果经常适得其反。先理解线程的工作原理Tomcat每收到一个请求会从一个线程池里分配线程执行Servlet代码。一个线程就是一个栈内存区域默认每个请求线程占用可能大几百KB到1MB的虚拟机栈空间。1000个线程光空转就占了近1G内存加上每个线程切换CPU的代价CPU多了很多上下文切换开销。正确的姿势是结合业务看如果你的服务是CPU密集型比如数据计算、加解密线程数建议设为CPU核数的1~2倍如果是纯IO密集型比如大量查数据库、调第三方接口线程数可以多些但也不是无脑加配合压测来找拐点。推荐初始配置Connector port8080 protocolHTTP/1.1 maxThreads200 minSpareThreads20 acceptCount100 connectionTimeout20000 redirectPort8443 /压测工具可以用abApache自带的压测命令ab -n 10000 -c 100 http://localhost:8080/demo/-n是总请求数-c是并发数。跑完看Requests per second和Time per request再调整参数做对比。数据永远比预估靠谱。7.2 JVM内存参数catalina.sh里的JAVA_OPTSTomcat默认JVM内存虽然能用但如果你部署的应用比较大跑一段时间后会出现OutOfMemoryError: Java heap space或者Metaspace异常。在catalina.sh里找到JAVA_OPTS那一行添加参数JAVA_OPTS-server -Xms512m -Xmx1024m -XX:MetaspaceSize128m -XX:MaxMetaspaceSize256m -Dfile.encodingUTF-8简单解释-Xms512m堆内存初始大小。-Xmx1024m堆内存最大值这两个不要完全相等因为Tomcat需要一部分非堆内存但别相差太远避免频繁扩张收缩带来的性能抖动。生产上常把两者设为一致。-XX:MetaspaceSize初始元空间值一般256M起步。-Dfile.encodingUTF-8强制默认文件编码配合前面说的中文乱码预防。改完JVM参数需要重启Tomcat才能生效。可以在启动后查看ps -ef | grep java看重启后的进程命令行里是否包含了这些参数。或者通过jmap -heap PID来确认堆内存配置。7.3 生产环境必做的三个加固动作生产环境部署时有几件小事你很容易忽略但长期运行后都会变成事故导火索。第一禁用没用的AJP连接器。早期版本的server.xml里默认有两个ConnectorHTTP/1.1的8080和一个AJP的8009。如果你不用AJP协议配合Apache HTTP Server时才会用到建议把它注释掉。安全的角度讲AJP端口应该被严格防火墙过滤甚至直接关闭避免不必要的外部暴露面。第二设置合理的session超时时间。默认session有效时间是30分钟。如果你的应用不是那种需要长时间保持登录状态的可以调短一些以减少无谓的session占用内存。改在conf/web.xmlsession-config session-timeout30/session-timeout /session-config单位是分钟设0表示浏览器关闭就失效30分钟比较常见。第三日志切割。Tomcat自身的日志不会自动切割运行久了catalina.out可能变成好几个G。一种解决方案是配置系统日志轮转工具如logrotate另一种是通过catalina.sh启用按天切割的日志策略。至少要把这个事儿提上日程否则某天排查问题时你连tail都不敢执行因为文件太大了。7.4 进程崩溃和假死为什么memory和GC比cpu占用更重要Tomcat假死的经典现象进程还在端口还在但请求全部超时页面根本刷不开。这时候很多人习惯性看CPU占用率发现很低那问题多半就不在CPU。优先检查内存和GC。推荐一个快速排查方式用JDK自带的jstatjstat -gcutil PID 1000持续输出里的FGCFull GC次数、FGCTFull GC时间、O老年代使用率如果能看出来老年代长期90%以上且Full GC频繁那多半是内存泄漏或者堆太小。再配合jmap -dump:formatb,file/tmp/heap.bin PID导出一份堆转储文件做分析。做了几年运维和开发我自己的体会是Tomcat出问题90%都出在内存层而不是并发逻辑。GC导致的停顿、堆内存溢出、Metaspace泄漏这类问题有一个共同点——它不像端口冲突那么直接你只能靠着日志和监控工具的蛛丝马迹去定位。所以建议从一开始就给Tomcat配上GC日志参数-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/opt/tomcat/logs/gc.log等到出问题的时候再临时加参数你已经错过了事故现场的证据链。GC日志看起来枯燥但在关键时刻它就是你的救命稻草。8. 写在最后的一些私货最后说点教程之外的个人体会。Tomcat这东西本质上不复杂但它足够老、足够成熟所以牵涉到的知识点特别碎。端口、目录、部署方式、连接器、JVM参数、日志每一项都不难但串起来以后就形成了一套很庞大的经验体系。很多刚入行的人觉得Tomcat没什么好学的能启动能部署war包就算会了——这种心态会在第一线上突然出事时让你手足无措。我自己的学习路径是先手动部署一个war包走通全流程然后完整读一遍server.xml再亲手配置两个虚拟主机和多个Context最后配合压测工具去调整线程参数把JVM参数从默认值改到合理值再跑一轮压测做对比。这个过程走完你才算真正用过Tomcat。不要停留在能用的舒适区多想一想为什么它能这样工作你真的会少踩很多坑。