做Java后端的基本上都会撞上这么一天本地用SSM框架写得好好的项目一放到Linux云服务器上就各种不适应要么数据库连不上要么端口访问不了要么干脆启动就报错。这篇文章就把SSM项目通过Tomcat部署到Linux云服务器的完整链路拆开讲透从本地改配置、Maven打包到服务器装JDK、Tomcat、MySQL再到放行端口、上线验证每一步都给你可以直接照着操作的命令和不踩坑的理由。不管你是学生交课程设计还是刚工作的开发第一次独立上线项目又或者是想搞明白部署原理的运维新人这套流程都适用。我不会讲太虚的东西所有内容都是我从实际部署当中反复试出来的版本坑、防火墙坑、日志坑都会提到你照着走能少走很多弯路。1. 部署前的整体规划先想清楚再动手别急着敲命令很多人一拿到服务器就开始下载JDK、装Tomcat结果折腾一晚上发现项目还是跑不起来。其实部署SSM项目这件事功夫在“动手之前”。先把下面这几件事想清楚后面每一步都是在填你已经规划好的坑位。部署的本质就是把你在本地开发环境已经验证过的代码搬运到一个干净、独立的生产环境里重新组装。本地环境有IDE、有本机数据库、有一堆开发辅助工具服务器上什么都没有所有依赖都要从零铺开。所以第一步不是问“怎么装Tomcat”而是问“我的项目到底需要什么”。1.1 先搞清楚SSM项目跑起来需要哪三样东西SSM是Spring、SpringMVC、MyBatis三者的组合。它的运行模式是客户端发HTTP请求Tomcat接收后交给SpringMVC做路由分发Service层处理业务逻辑MyBatis负责操作数据库完成持久化。从这个流程可以推导出它最少依赖三样东西Java运行环境、Web容器、数据库。Java运行环境对应JDK这是所有Java程序的地基没它连javac、java命令都跑不起来。Web容器对应Tomcat它负责实现Servlet规范、监听端口、管理请求线程。数据库对应MySQLSSM项目的数据几乎都存在MySQL里除非你的项目接的是别的数据库或者内存库。这三样东西在服务器上的安装顺序一般也是JDK优先、Tomcat其次、MySQL最后因为Tomcat安装脚本本身就要用到JAVA_HOME环境变量而MySQL虽然独立但项目启动时连接数据库的成功与否直接决定服务是否能对外提供完整功能。搞清楚这个依赖关系你就不至于装完Tomcat才发现JDK没配好白折腾一趟。1.2 部署方案选型为什么坚持手动部署Tomcat现在部署Java项目的方案非常多Docker容器化、Kubernetes编排、Jenkins持续集成还有各种自动化平台。但对一个SSM项目来说手动部署Tomcat依然有它不可替代的价值尤其对刚接触部署的人来说这就是基本功。手动部署的好处是每一步都透明。JDK装在哪个目录、Tomcat跑在哪个端口、配置文件的哪一行影响什么行为你全部可控。Docker确实能一键起环境但如果遇到容器内部日志看不到、时区不对、容器重启丢失配置这类问题不懂底层的人连排查方向都没有。我见过太多用Docker部署的开发者出了问题只会删了容器重新run治标不治本。单台云服务器、中小型SSM项目、访问量不大手动部署在资源占用上也是最省的。Tomcat本身就是一个进程不需要额外跑守护程序内存占用可控。以后项目复杂了再迁移到容器化也不冲突因为你已经理解了每个组件干什么的迁移只是换个方式启动罢了。1.3 部署前要准备的资源清单在做任何操作之前建议你先建一个文本文件把下面这些东西列清楚。这不是形式主义是防止你在部署过程中反复犯低级错误。一台Linux云服务器建议2核4G起步这是底线1G内存跑Tomcat加MySQL会非常吃力动不动就OOM一个SSH终端工具命令行操作要用JDK安装包建议下载tar.gz版本不要用系统包管理器自带的旧版本Tomcat安装包tar.gz版本即可MySQL数据库版本和本地开发库保持一致Maven构建工具本地打包要用数据库连接客户端比如命令行或者图形工具用来初始化和验证MySQLSSM项目的完整源码或者已经打好的War包清单里每一项缺失都会造成中断。我遇到过好几次的情况是服务器装到一半发现JDK下错版本Tomcat启动JVM直接报UnsupportedClassVersionError又从头来过。提前核对版本等于把最容易浪费时间的坑提前填了。1.4 版本兼容性部署时最容易被忽视的第一道坎版本兼容性这个问题我在部署和帮别人排查时遇到太多次。一个典型场景是本地用的JDK 8项目里用了高版本的Spring和MyBatis本地跑得好好的。服务器上yum默认装了一个JDK 17Tomcat 9 倒是启动正常但项目一部署就报错因为字节码版本对不上。版本搭配有一个基本对照JDK 8可以用Tomcat 8.5或9JDK 11以上可以用Tomcat 9或10Tomcat 10及以上的包名从javax.改成了jakarta.这会导致老项目里import javax.servlet报错除非你更新代码。所以稳妥的组合是JDK 8加Tomcat 8.5或9加MySQL 5.7或MySQL 8但要配合新版本驱动。数据库版本也容易触雷。MySQL 8的默认认证插件是caching_sha2_password老版本的mysql-connector-java驱动连接时会报Public Key Retrieval is not allowed。解决办法是换8.0驱动或者连接URL带上allowPublicKeyRetrievaltrue和useSSLfalse。我建议部署前先统一版本策略本地用什么数据库版本服务器就装什么版本驱动也统一能少掉一大半的兼容性错误。以上这些事想清楚了你再动手装环境每一步都有方向感。2. 本地代码调整与打包服务器上的一切问题都是从这里带过去的服务器装好之前还有一件特别重要的事要在本地完成把代码调整成能被“生产环境”使用的状态并且打成一个标准的War包。这一步被很多人忽略他们直接从IDE里跑一下项目觉得能启动就上传结果到了服务器上各种路径错误、配置错误排查起来极其痛苦。2.1 多环境配置别让本地数据库密码跑到生产环境里SSM项目里最常见的配置是jdbc.properties或者application.properties里面写着数据库地址、账号、密码。本地开发时通常连的是127.0.0.1密码简单比如123456。如果你直接把这份配置打进War包带到服务器上项目启动时就会尝试连本机的数据库而服务器上虽然可能装了MySQL但用户和密码都对不上于是报Access denied。解决办法是做多环境配置用Spring的Profile机制或者Maven的Profile机制区分开发、测试、生产环境。以Maven为例在pom.xml里定义多个profile分别指定资源目录比如src/main/resources-dev和src/main/resources-prod每个目录下放各自的配置文件。打包时加上参数-Pprod就能把生产配置打进去。生产环境的配置项里面数据库地址建议填服务器内网IP因为MySQL部署在同一台机器上时用内网IP比外网IP更快更安全。密码不要沿用本地弱口令单独设一个强密码。配置文件中如果有文件上传路径、日志输出路径也要改成Linux路径比如/opt/app/upload而不是Windows下的D:/upload。我之前就是没做多环境隔离把本地密码带上了生产结果数据库被扫到弱口令服务器遭了殃。从那以后我打包前必做一次配置检查把本地的绝对路径、测试开关全部扫一遍。2.2 用Maven打War包命令和注意事项SSM项目是用Maven管理的打包命令看着简单但用不好也会出问题。推荐的命令是mvn clean package -Dmaven.test.skiptrueclean会删除之前的target目录保证打包结果干净package会按照pom.xml里的packaging标签执行打包如果packaging是war就会生成War包。这里有个细节很多教程写的是-DskipTests意思是跳过测试执行但会编译测试类。在有些项目里测试类会连接本地数据库编译不报错但打包时测试跑起来会卡住甚至失败。所以我会用-Dmaven.test.skiptrue它连测试代码的编译都跳过打包更快更稳。还有一个高频坑如果你用的是IDE千万别直接选择IDE自带的Artifacts来打War包或者从target目录里手工拷文件。这种方式打出来的包可能不包含依赖的jar包或者包含的是不完全的class文件。必须通过Maven命令来打这样依赖解析和资源过滤都会按pom.xml执行。打完包后target目录下会生成一个xxx.war文件。可以用压缩工具打开看看内部应该包含WEB-INF/classes目录这里是编译后的class文件、WEB-INF/lib目录这里躺着所有依赖jar包包括Spring、MyBatis、数据库驱动等、META-INF目录。看到lib目录里有东西说明打包正常。2.3 上传前自检War包里最容易藏雷的三个地方打包完成不等于可以上传了。我会在每次部署之前用压缩工具或者命令行打开War包做一次“考古式”检查。重点看三个方面。第一检查配置文件。解压出WEB-INF/classes下面的jdbc.properties或者application-prod.properties确认数据库地址是服务器的IP或者域名用户名密码对得上。这一步能避免九成以上的启动失败。第二检查日志路径。项目里如果配置了log4j或者logback日志输出路径可能是Windows盘符格式比如D:/logs部署到Linux以后目录不存在日志写不进去表面上看项目启动起来了但没有任何日志输出排查问题就会变成瞎子。最好改成相对路径比如./logs或者/var/log/项目名并且在服务器上提前建好目录。第三检查静态资源的相对路径。有些项目在HTML或者JS里写死了资源的绝对路径比如/img/xx.png部署到服务器后在项目上下文路径下访问不到。这个问题和部署本身关系不大但上了服务器之后更容易暴露因为本地IDE帮你做了很多路径适配而Tomcat不会。做完这三项检查War包才算真正具备上传条件。这一步花十分钟省下来的可能是整个下午的排查时间。3. 服务器环境搭建JDK、Tomcat、MySQL一次装到位到了服务器端顺序很重要。我会严格按照JDK、MySQL、Tomcat的顺序来因为Tomcat启动时需要JDK项目启动时需要MySQL先装好底层依赖后面排错时能一眼看出问题是出在哪个环节。3.1 安装并配置JDK版本选型和环境变量我最推荐的方式是直接把tar.gz包解压到Linux指定的目录而不是用yum install java-1.8.0-openjdk。原因是系统包管理器默认装的JDK版本和路径不完全可控有时装完了还没有jps、jstat这些诊断工具你得额外装openjdk-devel才能用。而手动解压的方式位置固定工具齐全想切换版本时改一下环境变量就行。具体步骤大致是这样# 下载JDK 8的tar.gz版本到/opt目录并解压 cd /opt tar -zxvf jdk-8u202-linux-x64.tar.gz mv jdk1.8.0_202 /usr/local/java然后配置环境变量。编辑/etc/profile文件在文件末尾加入export JAVA_HOME/usr/local/java export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar很多新教程已经不写CLASSPATH了但对老SSM项目来说加上它避免一些由类加载路径引发的奇怪异常。修改完让配置生效用source /etc/profile加载然后验证java -version javac -version如果这两个命令能正常输出版本信息JDK这步就过了。这里有一个特别常见的坑服务器上可能预装了旧版本OpenJDK或者你的JAVA_HOME指错了位置导致Tomcat启动时用的是系统自带的Java而不是你装的。排查方法是运行echo $JAVA_HOME看一下值对不对再跑which java看它指向的路径是不是/usr/local/java/bin/java。3.2 安装Tomcat目录结构和启动逻辑Tomcat的安装比JDK还简单下载tar.gz包解压即可。我把Tomcat统一放在/usr/local/tomcat目录内部有bin、conf、lib、logs、webapps、work这六个关键目录。bin目录放启动和停止脚本conf目录放server.xml等配置文件logs目录是日志的家webapps目录是部署War包的地方work目录存放JSP编译后的临时文件。cd /opt tar -zxvf apache-tomcat-9.0.85.tar.gz mv apache-tomcat-9.0.85 /usr/local/tomcat chmod x /usr/local/tomcat/bin/*.sh启动之前建议先确认一下环境变量JAVA_HOME是否已生效。Tomcat的启动脚本catalina.sh会读取JAVA_HOME来定位JDK如果为空启动脚本会直接报错。第一次启动使用的是/usr/local/tomcat/bin/startup.sh启动后同时运行一个命令验证进程是否真的起来了ps -ef | grep tomcat如果进程存在再查看日志文件/usr/local/tomcat/logs/catalina.out确认没有异常。Tomcat默认监听8080端口此时在服务器本地可以先用curl命令测试curl http://localhost:8080如果返回HTML内容说明Tomcat装好了。很多人在这一步卡住可能就是解压后忘了给脚本加执行权限或者JAVA_HOME没配置对导致startup.sh提示找不到命令。3.3 安装MySQL初始化、库表创建和远程访问授权MySQL的安装方式根据自己的系统和喜好来Ubuntu可以用apt install mysql-serverCentOS可以用yum install mysql-server。安装完成之后第一步是启动服务并查看状态systemctl start mysqld systemctl enable mysqld systemctl status mysqldMySQL 5.7及以上版本在安装时会生成一个临时密码写在日志文件里你需要先找到这个密码再改掉。搜索方式grep temporary password /var/log/mysqld.log如果版本没有临时密码机制可以直接用mysql命令进入。进入MySQL之后先创建业务库和业务账号。这里我给一个标准参考CREATE DATABASE ssm_project DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER ssm_user% IDENTIFIED BY 这里填强密码; GRANT ALL PRIVILEGES ON ssm_project.* TO ssm_user%; FLUSH PRIVILEGES;这里的%表示允许任意主机远程连接。在实际生产环境从安全角度考虑可以限制为应用服务器内网IP但如果你的项目暂时只有一台服务器而且Tomcat和MySQL在同一台机器上可以考虑只允许localhost登录。不过为了调试方便一般还是先放开%同时配合防火墙和数据库IP白名单来约束。为什么这个环节容易出问题因为默认情况下MySQL只监听127.0.0.1这个地址外部其他机器就连不上。你需要在配置文件my.cnf里检查bind-address这一项如果设成了127.0.0.1就把它注释掉或者改成0.0.0.0。改完重启MySQL服务才能生效。远程连接的另一个大坑是MySQL 8的认证插件。如果在授权时用了caching_sha2_password老版本的Java驱动会连不上。我会建议同时更新项目里的数据库驱动到8.0并在JDBC连接串上追加两个参数jdbc:mysql://127.0.0.1:3306/ssm_project?useSSLfalseallowPublicKeyRetrievaltruecharacterEncodingutf8其中allowPublicKeyRetrievaltrue专门解决数据库驱动在连接MySQL 8时无法获取公钥的报错useSSLfalse则跳过了本地SSL认证环节。这两个参数在本地开发时可能不需要但到了MySQL 8环境经常会遇到直接加上是为了稳妥。3.4 防火墙与安全组部署完连不上VMware的常见原因项目部署完浏览器访问不了很多人第一反应是项目代码有问题或者Tomcat没启动。但我见过的真实案例里有一大半其实是防火墙或者云服务器安全组没放行对应端口。这里要区分两套东西。第一套是服务器操作系统自带的防火墙。如果用的是firewalld用下面的命令放行8080和3306端口firewall-cmd --permanent --add-port8080/tcp firewall-cmd --permanent --add-port3306/tcp firewall-cmd --reload如果用的是ufw则是ufw allow 8080/tcp ufw allow 3306/tcp第二套是云服务器厂商控制台里的安全组规则。这个要登录到云厂商的网页控制台去操作把8080、3306、80等端口加进入方向的放行列表。不同厂商的安全组界面不一样但逻辑相同默认都是“拒绝所有入站仅放行22端口”你需要手动添加新规则。这一步是最容易忽略的很多人捣鼓半天防火墙结果发现安全组压根没放行。排查这类问题时建议先用一台外部机器做telnet测试telnet 服务器公网IP 8080如果连接成功说明端口通了如果超时多半是安全组或防火墙没放行。别在本地反复折腾Tomcat配置方向错了纯属浪费时间。4. 项目部署与验证从War包上传到全链路跑通环境装好了配置做好了接下来就是真正把项目放上去。这个阶段虽然命令不多但每个动作背后都有明确的目的特别是重部署时只有理解了Tomcat的目录和缓存逻辑才不会出现“改了代码没生效”的诡异问题。4.1 上传War包scp命令和安全校验上传War包最直接的方式是用scp命令在本地终端执行scp target/ssm_project.war root服务器公网IP:/usr/local/tomcat/webapps/如果你用的是密钥登录命令里不需要输密码如果用的是密码登录会提示输入服务器root密码。上传完成后建议先检查文件大小避免传输出错导致War包不完整ls -lh /usr/local/tomcat/webapps/ssm_project.war一个完整的SSM项目War包大小通常在几十兆到上百兆之间。如果文件只有几个KB你得怀疑是不是本地打包出了问题或者上传中断了。4.2 选择部署方式自动解压和Context配置Tomcat部署War包有两种常用方式。最简单的是把War包直接放进webapps目录Tomcat启动时会自动解压成同名目录然后通过http://服务器IP:8080/ssm_project访问。这种方式适合日常部署重部署时只需覆盖War包并重启。第二种方式是在conf/server.xml里配置Context显式指定项目路径和物理目录。比如Host namelocalhost appBasewebapps unpackWARstrue autoDeploytrue Context path/ssm docBase/data/app/ssm_project reloadabletrue / /HostdocBase指向War包解压后的目录或者War包本身均可。这种方式比较适合项目路径和Webapps目录不在一起或者想把项目放到独立磁盘上的场景。但对于单机单项目第一种方式已经足够。我平时默认用第一种只在需要把不同目录下的多个应用都挂在同一个Tomcat时才用Context。这里有个很容易踩的细节Tomcat在自动解压时会创建同名的文件夹如果这个文件夹已经存在且内容不是最新的Tomcat会直接使用旧目录导致你上传了新War包却跑的是旧代码。遇到这种情况先删掉旧的解压目录再重启Tomcat。rm -rf /usr/local/tomcat/webapps/ssm_project4.3 修改Tomcat配置端口、字符编码和内存参数Tomcat启动之前有三类配置建议先改好不然项目跑起来后会发现各种别扭。第一是端口。如果服务器上只有这一个项目用8080没问题。但如果要把80端口对外开放简化访问地址就需要修改conf/server.xml里Connector的port属性。不过我不建议一上来就改端口先用默认8080把项目调通了再加Nginx做转发这样每一层的问题都清清楚楚。第二是字符编码。Tomcat 8.5及以上版本默认URI编码已经是UTF-8不需要额外设置。但如果你用的是老版本Tomcat或者项目里有复杂的QueryString参数建议在server.xml的Connector标签里加上URIEncodingUTF-8否则中文字符在URL请求里会变成乱码接口返回的数据也可能因此对不上。第三是JVM内存。Tomcat启动时默认的堆内存很可能不适合SSM项目特别是在访问量稍高或者项目依赖较多的时候会频繁触发Full GC甚至OOM。推荐在bin/catalina.sh或者bin/setenv.sh里显式指定JVM参数JAVA_OPTS-Xms512m -Xmx1024m -XX:MetaspaceSize128m -XX:MaxMetaspaceSize256m -Dfile.encodingUTF-8-Xms是初始堆大小-Xmx是最大堆大小MetaspaceSize是元空间初始大小。设置时有个原则物理内存4G的服务器JVM堆内存不要超过2G要留内存给操作系统、MySQL和Tomcat自身否则系统会开始使用Swap交换分区整个服务性能急剧下降。我这里给的是保守值实际可以按项目情况上调到1G对2G但别盲目贪大。4.4 启动项目与日志观察配置改完之后就可以启动了。启动命令还是/usr/local/tomcat/bin/startup.sh这里注意执行startup.sh之后终端会显示Tomcat started提示但项目是否真正启动成功要等几秒钟才能确定。SSM项目启动时要初始化Spring容器、创建数据源、执行MyBatis映射通常需要5到15秒。可以通过查看catalina.out确认启动进度。tail -f /usr/local/tomcat/logs/catalina.out你会看到很多日志。关键看最后有没有下面这些标志Spring WebApplicationInitializers detected on classpath说明Spring容器开始初始化Root WebApplicationContext: initialization completed in xxx ms说明Spring根容器创建完成Deploying web application archive ...和Deployment of web application archive ... has finished说明Tomcat部署完成如果日志里出现Exception、Error字样项目多半没起来。此时需要往下翻找到第一个异常堆栈。看堆栈信息时不要只看第一行要往下面找Caused by那才是真正的根因。项目启动成功的判断标准不是Tomcat进程在跑而是你通过HTTP请求能拿到业务响应。先在服务器本地验证curl http://localhost:8080/ssm_project/如果返回了HTML页面内容说明项目本身没问题。然后再通过浏览器访问http://公网IP:8080/ssm_project/这个能通整个部署链路才算完成。4.5 从IP访问到域名和HTTP简化项目通过IP加端口访问成功后还有一个可选的优化给项目配一个域名并把访问端口从8080改成80。改端口有两种方式一种是在server.xml里直接改另一种是引入Nginx做反向代理。我更推荐后者因为Nginx可以做静态资源缓存、请求日志、SSL证书终止以后扩展也更灵活。用Nginx时配置很简单server { listen 80; server_name www.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }把域名解析到服务器IPNginx监听80端口所有请求都转发给本机8080的Tomcat。这样访问者只需输入域名或IP就能访问无需记住端口号。域名解析生效需要一些时间如果你只是临时测试可以直接用IP访问。5. 常见问题与排查技巧部署过程中踩过的坑都在这了部署这种事说得再详细实际操作中还是会出现各种意外。我把这几年帮别人排查和自己在部署过程中遇到的高频问题整理出来每个问题都给出可以照抄的排查步骤。日志看不懂、404解决不了、数据库连不上、内存爆掉这类问题看这一节就够了。5.1 部署后访问出现404先分清是Tomcat的问题还是项目的问题404是最常见的错误但很多人一看到404就去改代码方向错了。首先要分清楚你是访问Tomcat根路径就404还是访问你的项目路径才404。在服务器本地执行curl http://localhost:8080如果返回的是Tomcat默认首页的HTML内容说明Tomcat正常。如果这一步就404可能是webapps目录下缺少ROOT目录或者Tomcat部署异常。此时再执行curl http://localhost:8080/ssm_project如果返回404则说明项目没有被正确部署。排查项目没部署成功先回车看logs/catalina.out里有没有异常的部署日志。日志里如果出现Deployment of web application archive ... has finished但访问仍然404那大概率是项目的上下文路径不对。比如你的War包名是ssm_project但项目内部配置的context path是/ssm两者不一致就会404。统一它们的方法是别去改代码而是调整访问URL让它跟上War包名称一致重部署的时候也保持名称稳定。另外还有一个隐蔽原因项目中配置了SpringMVC的路由默认首页不是根路径而是/index或者/login。所以访问/的时候可能确实没有可用路由此时在浏览器里打开/ssm_project/login试试如果页面正常说明项目其实是好的只是你没有访问对的入口。5.2 数据库连接报错一堆密码错误和SSL问题的速诊数据库连接报错几乎每个SSM项目部署都会遇到。常见报错有以下几类我把它们和解决思路放在一起说。第一类Access denied for user。数据库账号密码不对或者该账号没有被授权从当前主机连接。解决思路是在MySQL里重新授权账号并把授权范围定到%或者确认连接串里的密码真的和生产库密码一致。这类问题要特别注意很多人在本地数据库上改了密码但项目配置文件里还是旧密码打包时又没注意多环境配置于是带到服务器上。第二类Host xxx is not allowed to connect to this MySQL server。这是MySQL没有授权这个IP来源。解决思路就是执行之前提到的授权语句并在my.cnf里把bind-address注释掉或改成0.0.0.0。第三类Public Key Retrieval is not allowed。这是MySQL 8和新版驱动之间的问题解决方式很直接JDBC连接串加上allowPublicKeyRetrievaltrue和useSSLfalse。第四类Communications link failure。原因很多MySQL服务没启动、3306端口被防火墙拦截、或者连接串里的IP和端口写错。逐项排查顺序是服务器上systemctl status mysqld确认服务在跑然后mysql -h 127.0.0.1 -P 3306测试本机连接最后检查防火墙和安全组是否放行3306。5.3 内存溢出和不定期假死Tomcat崩溃的三板斧Tomcat运行几天后内存占满进程还在但请求都不响应这是另一种让人头疼的情况。基本原因都在JVM内存参数上。如果你启动Tomcat时没有显式设置-XmxJVM默认只取物理内存的四分之一而且元空间也会因为Spring、MyBatis的类加载量过大而频繁扩张。处理方式首先是查看崩溃前留下的日志。OutOfMemoryError会直接打印在catalina.out里搜索关键字就能定位问题发生在哪个线程。然后用jstat命令观察JVM运行状态jstat -gcutil Tomcat的Java进程PID 1000 10如果老年代使用率长期在90%以上说明堆内存确实不够或者代码里有内存泄漏。堆内存不够时调大-Xmx值但注意不要超过物理内存的一半。如果是代码泄漏导致的调大内存只是拖延时间更根本的还是要查业务代码里的集合缓存、数据库连接是否正常释放。还有一种“假死”是线程池被占满表现是Tomcat进程活着但新请求全部排队超时。这种情况多在接口响应过慢或者有阻塞操作时发生和内存关系不大。排查时在服务器上执行jstack导出线程快照看有没有线程长时间卡在某个锁上就能还原现场。5.4 日志文件不输出部署后最容易被忽视的盲区项目启动成功接口也通但服务的日志里什么都没有或者日志写到了奇怪的地方。这种问题属于“慢性病”不影响上线但不方便维护。原因主要有两个一是log4j或logback配置里写的是Windows路径二是配置文件没有跟随打包进入生产环境。排查思路很简单先看项目里日志配置文件是log4j.properties还是logback.xml找到里面日志路径的配置项。如果是D:/logs/app.log这种绝对路径改成Linux路径比如/var/log/ssm_project/并在系统里提前创建目录。这里有个细节路径别用相对路径和绝对路径混杂最好统一绝对路径避免Tomcat在不同的启动位置下路径解析不一致。还有一个常见问题是多个应用共用一个Tomcat时日志会混合写进同一个catalina.out。解决办法是在logback配置里单独给每个应用设置文件名并开启按天滚动。这样后续排查问题只需要盯着自己项目的日志文件看效率高得多。5.5 日志排查速查表按图索骥找根因为了方便你部署时不慌我整理了一张表格覆盖最常见的几种报错和对应的排查方向。报错或现象可能原因排查方向访问8080无响应防火墙/安全组未放行端口查安全组和firewall-cmdTomcat启动报错找不到JAVA_HOMEJDK环境变量没配置检查/etc/profileUnsupportedClassVersionErrorJDK版本过低不兼容编译版本换JDK 8或重新编译Access denied for user数据库账号密码或授权不对重新授权核对密码Public Key Retrieval is not allowedMySQL 8认证插件问题JDBC URL加allowPublicKeyRetrievaltrueCommunications link failureMySQL未启动或3306不通查MySQL状态、防火墙OutOfMemoryError: Java heap spaceJVM堆内存过小或泄漏调大-Xmx或排查泄漏页面中文乱码字符编码不一致设URIEncodingUTF-8和-Dfile.encodingUTF-8上传新War包没生效旧的解压目录未被清理删除webapps下旧目录再重启Spring容器初始化报错后退出配置或依赖缺失看catalina.out中Caused by这张表不能覆盖所有情况但能帮你在遇到报错时先过滤掉最常规的坑。拿到一条报错信息后先别急着全文搜先把报错里的关键名词拆出来比如SecurityException、ClassNotFoundException、SocketException再对应到上面的方向上去查效率会高很多。部署这件事说到底就是一个把“本机能跑”变成“服务器上能跑”的过程。我第一次手动部署SSM项目时也折腾了一整晚后来发现大部分时间都耗在防火墙、版本兼容和配置路径上。有过这次经历后我每次部署都会先做版本清单、先改生产配置、先放行端口再真正启动项目。按照这个顺序来整个流程其实很顺。我的个人体会是手动部署一次SSM项目比看十篇部署教程都管用因为在踩坑和填坑之间你会真正理解每一个组件在整个链条中的位置。希望你也能在自己的服务器上一步步把项目跑起来。