1. 项目概述与核心价值最近在帮几个朋友处理他们SpringBoot项目的上线问题发现一个挺普遍的现象很多开发同学在本地IDEA里把项目跑得飞起各种功能测试都没问题但一到要打包部署到服务器上就开始手忙脚乱踩坑不断。尤其是从Windows开发环境切换到Linux生产环境时一个jar包引发的“血案”能折腾大半天。所以今天我想结合自己这些年从开发到运维踩过的坑系统性地聊聊SpringBoot项目如何通过Maven打包成可执行的jar包并分别在Windows和Linux平台上稳定运行。这不仅仅是打一个包、敲一行命令那么简单里面涉及到Maven的配置优化、不同操作系统的环境差异、Java运行时的选择以及部署后如何优雅地管理和监控服务。无论你是刚接触SpringBoot的新手还是想梳理一下部署流程的老手这篇从实战中总结出来的经验应该都能给你提供一个清晰、可复现的路线图。2. 项目整体设计与打包策略解析2.1 为什么选择可执行Jar包部署在SpringBoot的部署选项里除了可执行jar还有传统的WAR包部署到外部Tomcat等方式。但对于大多数微服务或前后端分离的后端项目可执行jar是更主流和推荐的方式。核心原因在于它的“独立性”和“约定大于配置”的理念。一个标准的SpringBoot可执行jar通过spring-boot-maven-plugin插件会把应用本身、所有的依赖库打包到BOOT-INF/lib/下、以及一个内嵌的Web服务器默认是Tomcat全部打包在一起。这意味着你不需要在目标服务器上预装和配置一个复杂的Tomcat只需要有合适的Java运行时环境JRE或JDK就能通过一句java -jar your-app.jar让应用跑起来。这极大地简化了部署流程降低了环境不一致带来的风险特别适合容器化和云原生场景。当然这也对打包过程提出了更细致的要求一个配置不当的pom.xml可能会让打出来的包无法运行或者臃肿不堪。2.2 Maven打包的核心配置与优化要点打包的起点是项目的pom.xml文件。很多初级错误都源于这里的配置疏忽。首先你必须确保引入了spring-boot-maven-plugin插件这是生成可执行jar的关键。build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version你的SpringBoot版本/version !-- 通常继承自父工程无需显式指定 -- executions execution goals goalrepackage/goal !-- 这个goal至关重要它会重新打包成可执行的jar -- /goals /execution /executions configuration !-- 指定主启动类如果项目结构标准可省略 -- mainClasscom.yourcompany.yourapp.Application/mainClass !-- 排除开发工具减小生产包体积 -- excludes exclude groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId /exclude /excludes /configuration /plugin /plugins /build这里有几个关键点goalrepackage/goal这个目标会替换掉Maven默认打包生成的原始jar生成一个新的、包含所有依赖和启动加载器的“fat jar”。如果你发现打出来的jar很小比如几十KB并且运行时报“找不到主清单属性”那十有八九是这个插件没配置或没执行repackage目标。主类配置如果你的启动类不在根目录下或者有多个SpringBootApplication注解的类需要在这里明确指定mainClass。标准单一启动类项目通常可以自动识别。排除依赖像spring-boot-devtools这种仅在开发时使用的模块一定要在生产打包时排除否则可能引起类加载器问题或安全隐患。另一个常见问题是依赖版本冲突。建议在父pom中通过dependencyManagement统一管理所有依赖的版本子模块中声明依赖时不写版本号。打包前可以运行mvn dependency:tree命令查看依赖树检查是否有冲突的库并用exclusions标签排除掉不需要的传递性依赖。注意在IDEA中直接点击Maven侧边栏的package或install默认就会执行完整的生命周期包括compile、test和package并触发spring-boot-maven-plugin的repackage目标。如果你在命令行操作也要使用mvn clean package或mvn clean install。3. Windows平台运行Jar包的实战细节3.1 环境准备与基础运行在Windows上运行SpringBoot的jar包相对直观。首先你需要确保系统已经安装了Java运行环境。打开命令提示符CMD或PowerShell输入java -version来验证。建议使用与开发环境相同的主要版本如Java 8 11 17以避免因版本差异导致的兼容性问题。运行应用的基本命令非常简单java -jar your-application-0.0.1-SNAPSHOT.jar这时控制台会开始输出SpringBoot的启动日志。你会看到熟悉的Spring标志、激活的配置文件application.properties或application.yml、以及内嵌Tomcat的启动端口默认8080。这是一个前台运行模式命令行窗口关闭应用也就停止了。3.2 后台运行、日志管理与进程守护对于生产环境我们肯定需要让应用在后台运行。在Windows上有几种常见做法使用start命令start /B javaw -jar your-application.jarjavaw命令会启动一个不带控制台窗口的Java进程。start /B表示在后台启动程序而不创建新窗口。这种方式简单但缺乏完善的进程管理和日志收集。使用批处理脚本与Windows服务更专业的做法是将jar包注册为Windows服务。这里推荐使用开源的winswWindows Service Wrapper工具。你需要下载一个对应的winsw.exe如myapp.exe并编写一个同名的XML配置文件如myapp.xmlservice idmyapp/id nameMy SpringBoot Application/name descriptionThis is my SpringBoot service./description executablejava/executable arguments-jar C:\apps\your-application.jar --spring.profiles.activeprod/arguments logmoderotate/logmode workingdirectoryC:\apps/workingdirectory /service然后以管理员身份运行myapp.exe install来安装服务之后就可以在“服务”管理器中启动、停止或设置为开机自启。winsw还能自动管理日志轮转非常方便。日志处理无论用哪种方式都要规划好日志输出。在application.yml中配置日志文件路径和滚动策略logging: file: name: C:/logs/myapp/app.log logback: rollingpolicy: max-file-size: 10MB max-history: 30避免日志无限增长占满磁盘。对于后台运行的程序务必将日志重定向到文件而不是输出到空设备nul否则出了问题根本无法排查。3.3 Windows平台常见问题与排查在Windows上部署我遇到最多的问题集中在端口占用、文件路径和编码上。端口占用应用启动失败提示Web server failed to start. Port 8080 was already in use.。解决方法使用netstat -ano | findstr :8080查找占用8080端口的进程IDPID。然后通过任务管理器结束该进程或者使用taskkill /PID PID /F强制结束。更治本的方法是在application.properties中修改应用端口server.port8081。文件路径与权限应用需要读写某个目录如上传文件、生成报表。在开发时可能用的相对路径到了生产环境可能因工作目录变化而失效。建议使用绝对路径并通过配置项外部化如file.upload-dirC:/app_data/uploads。确保运行该Java进程的用户如SYSTEM、或指定的服务账户对该目录有读写权限。字符编码问题如果日志或程序输出的中文变成了乱码这通常是控制台或日志文件的编码与Java程序输出编码不匹配导致的。可以尝试在启动命令中指定JVM参数-Dfile.encodingUTF-8。同时检查你的代码和配置文件是否统一使用了UTF-8编码。4. Linux平台部署全流程详解4.1 Linux服务器Java环境安装与配置Linux是SpringBoot应用更常见的生产环境。第一步就是安装合适的Java环境。我强烈推荐使用JDK而非仅JRE因为某些工具如jstack, jmap用于诊断需要开发工具包。这里以主流的CentOS/RedHat系列使用yum和Ubuntu/Debian系列使用apt为例。对于CentOS/RedHat 7搜索可用的JDK包yum search java-11-openjdk以Java 11为例。安装JDKsudo yum install java-11-openjdk-devel。-devel包包含了完整的JDK。验证安装java -version和javac -version。对于Ubuntu/Debian更新包索引sudo apt update。安装JDKsudo apt install openjdk-11-jdk。验证安装同上。实操心得不建议使用从Oracle官网下载tar.gz包手动配置JAVA_HOME的复杂方式除非有特定版本需求。系统包管理器安装的OpenJDK其更新和依赖管理都由系统负责更省心。安装后通常不需要手动设置JAVA_HOME因为java命令已加入PATH。但如果你用的某些脚本或工具如Maven依赖这个变量可以将其添加到/etc/profile或用户~/.bashrc中export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 # 路径请用which java和readlink -f命令确认 export PATH$JAVA_HOME/bin:$PATH然后执行source ~/.bashrc使其生效。4.2 Jar包上传、运行与进程管理将打包好的jar文件从Windows传到Linux服务器我习惯用scp命令简单直接scp target/your-application.jar useryour-server-ip:/home/user/app/或者使用图形化工具如WinSCP。在Linux上同样使用java -jar命令启动。但生产环境绝不能在前台运行。标准做法是使用nohup配合nohup java -jar your-application.jar --spring.profiles.activeprod app.log 21 nohup让进程忽略挂断信号SIGHUP即使退出终端也不会终止。 app.log将标准输出重定向到app.log文件。21将标准错误2也重定向到标准输出1指向的地方即同一个日志文件。在后台运行。执行后会返回一个进程IDPID。你可以用jobs -l查看后台作业或者用ps -ef | grep java查找进程。然而更优雅、功能更强大的管理方式是使用Systemd主流Linux发行版默认的初始化系统。创建一个服务单元文件例如/etc/systemd/system/myapp.service[Unit] DescriptionMy SpringBoot Application Afternetwork.target [Service] Typesimple Userappuser # 建议使用非root用户运行 WorkingDirectory/home/user/app ExecStart/usr/bin/java -jar /home/user/app/your-application.jar --spring.profiles.activeprod SuccessExitStatus143 Restartalways # 设置进程退出后总是重启 RestartSec10 # 重启前等待10秒 StandardOutputjournal # 输出到系统日志 StandardErrorjournal [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload # 重新加载配置 sudo systemctl start myapp # 启动服务 sudo systemctl enable myapp # 设置开机自启 sudo systemctl status myapp # 查看服务状态Systemd提供了完善的日志集成通过journalctl -u myapp查看、自动重启、资源限制等功能是生产环境的首选。4.3 生产环境配置与优化建议直接运行java -jar通常需要附加一些JVM参数以优化性能和稳定性。基础内存设置根据服务器内存大小设置堆内存。例如一台4G内存的机器可以这样设置java -Xms512m -Xmx2048m -jar your-application.jar-Xms512m初始堆内存为512MB。-Xmx2048m最大堆内存为2048MB。设置相同的-Xms和-Xmx可以避免堆在运行时动态调整带来的性能波动但会一开始就占用更多内存。GC日志与内存溢出转储为了便于故障诊断建议开启GC日志和内存溢出时的堆转储。java -Xms512m -Xmx2048m \ -XX:UseG1GC \ -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/home/user/app/logs/gc.log \ -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/home/user/app/logs/heapdump.hprof \ -jar your-application.jar-XX:UseG1GC使用G1垃圾收集器在大多数场景下比老的Parallel GC或CMS表现更好。-Xloggc将GC日志输出到指定文件。-XX:HeapDumpOnOutOfMemoryError在发生内存溢出错误时自动生成堆转储文件这是分析内存泄漏的利器。应用配置文件外部化绝对不要将数据库密码等敏感信息硬编码在打包的jar内的application.properties中。SpringBoot支持多种外部化配置方式在启动命令中指定--spring.datasource.passwordyour_password。使用外部配置文件--spring.config.location/etc/myapp/application-prod.yml。使用环境变量在Systemd的service文件中用Environment指令设置或在shell中导出。SpringBoot会自动将SPRING_DATASOURCE_PASSWORD这样的环境变量绑定到配置属性。5. 跨平台部署的通用问题与深度排查5.1 打包阶段经典错误与解决“没有主清单属性” (no main manifest attribute)现象运行java -jar时抛出此错误。原因与解决这几乎100%是因为打包出来的jar不是SpringBoot的可执行jar。检查pom.xml中是否正确配置了spring-boot-maven-plugin并执行了repackage目标。可以先用jar tf your-app.jar查看jar包内容一个正确的可执行jar在根目录下应该有META-INF/MANIFEST.MF文件并且其中包含Main-Class: org.springframework.boot.loader.JarLauncher和Start-Class: com.yourcompany.Application。依赖冲突导致类找不到 (ClassNotFoundException/NoClassDefFoundError)现象应用启动时抛出某个类找不到的异常但在IDE里运行正常。原因与解决通常是Maven依赖传递导致了版本冲突或者打包时某些依赖没被正确包含。首先运行mvn dependency:tree -DincludesgroupId:artifactId查看特定依赖的传递路径。使用exclusion排除冲突的旧版本。其次检查是否错误地设置了scopeprovided/scope或scopetest/scope这会导致该依赖不会被打进jar包。资源文件如图片、模板找不到现象程序运行时无法读取src/main/resources下的文件。原因与解决在jar包中资源文件路径与文件系统不同。不要使用new File(“classpath:...”)而应该使用Spring的ResourceLoader或ClassPathResource来加载。例如this.getClass().getResourceAsStream(“/static/image.png”)。5.2 运行阶段问题排查手册当应用在服务器上启动失败或运行异常时需要系统性地排查。第一步查看日志这是最直接有效的方法。根据你的启动方式查看日志如果用了nohup ... app.log看app.log。如果用了Systemd用sudo journalctl -u myapp -f实时跟踪日志或者sudo journalctl -u myapp --since “2024-01-01”查看历史。重点查找ERROR和WARN级别的日志SpringBoot的启动失败信息通常非常详细。第二步检查端口与网络端口占用使用netstat -tlnp | grep :8080或ss -tlnp | grep :8080检查应用端口是否被其他进程占用。防火墙检查服务器防火墙如firewalld、iptables和云服务商的安全组规则是否允许了应用端口如8080的入站流量。对于云服务器安全组配置错误是常见的外部无法访问的原因。第三步JVM与系统资源诊断内存不足观察启动日志是否有OutOfMemoryError。使用free -h查看系统内存用top或htop查看Java进程的内存占用RES列。调整JVM的-Xmx参数。磁盘空间不足使用df -h检查日志所在磁盘分区是否已满。这会导致应用无法写入日志而卡死。检查应用健康端点如果应用已启动但行为异常Spring Boot Actuator提供的/actuator/health端点非常有用。确保它在生产环境已安全开启可通过管理端口或访问控制它能快速告诉你数据库连接、磁盘状态等是否健康。5.3 性能监控与日常维护建议部署上线不是终点持续的监控和维护同样重要。启用Spring Boot Actuator在pom.xml中添加spring-boot-starter-actuator依赖并适当配置application.properties可以暴露丰富的监控端点如/actuator/metrics,/actuator/env方便集成Prometheus等监控系统。management.endpoints.web.exposure.includehealth,info,metrics,prometheus management.endpoint.health.show-detailswhen_authorized # 注意生产环境务必通过security或网络策略保护这些端点日志聚合当服务器数量增多时登录每台机器看日志效率低下。考虑使用ELKElasticsearch, Logstash, Kibana或LokiGrafana搭建集中式日志平台将各台服务器的应用日志统一收集、索引和展示。制定重启与更新流程最简单的重启命令是sudo systemctl restart myapp。但对于需要零停机更新的场景可以考虑更复杂的方案如使用双jar包目录通过软链接切换或者结合负载均衡器进行蓝绿部署。至少你的更新脚本应该包含停止服务、备份旧版本和日志、上传新jar包、启动服务、验证健康状态这几个步骤。定期备份与清理除了备份代码和数据库应用生成的业务数据文件、配置文件和重要的日志文件也需要定期备份。同时设置日志滚动策略如Logback的TimeBasedRollingPolicy和定时任务cron job定期清理过期的日志文件、临时文件和堆转储文件防止磁盘被撑满。
1. 项目概述与核心价值最近在帮几个朋友处理他们SpringBoot项目的上线问题发现一个挺普遍的现象很多开发同学在本地IDEA里把项目跑得飞起各种功能测试都没问题但一到要打包部署到服务器上就开始手忙脚乱踩坑不断。尤其是从Windows开发环境切换到Linux生产环境时一个jar包引发的“血案”能折腾大半天。所以今天我想结合自己这些年从开发到运维踩过的坑系统性地聊聊SpringBoot项目如何通过Maven打包成可执行的jar包并分别在Windows和Linux平台上稳定运行。这不仅仅是打一个包、敲一行命令那么简单里面涉及到Maven的配置优化、不同操作系统的环境差异、Java运行时的选择以及部署后如何优雅地管理和监控服务。无论你是刚接触SpringBoot的新手还是想梳理一下部署流程的老手这篇从实战中总结出来的经验应该都能给你提供一个清晰、可复现的路线图。2. 项目整体设计与打包策略解析2.1 为什么选择可执行Jar包部署在SpringBoot的部署选项里除了可执行jar还有传统的WAR包部署到外部Tomcat等方式。但对于大多数微服务或前后端分离的后端项目可执行jar是更主流和推荐的方式。核心原因在于它的“独立性”和“约定大于配置”的理念。一个标准的SpringBoot可执行jar通过spring-boot-maven-plugin插件会把应用本身、所有的依赖库打包到BOOT-INF/lib/下、以及一个内嵌的Web服务器默认是Tomcat全部打包在一起。这意味着你不需要在目标服务器上预装和配置一个复杂的Tomcat只需要有合适的Java运行时环境JRE或JDK就能通过一句java -jar your-app.jar让应用跑起来。这极大地简化了部署流程降低了环境不一致带来的风险特别适合容器化和云原生场景。当然这也对打包过程提出了更细致的要求一个配置不当的pom.xml可能会让打出来的包无法运行或者臃肿不堪。2.2 Maven打包的核心配置与优化要点打包的起点是项目的pom.xml文件。很多初级错误都源于这里的配置疏忽。首先你必须确保引入了spring-boot-maven-plugin插件这是生成可执行jar的关键。build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version你的SpringBoot版本/version !-- 通常继承自父工程无需显式指定 -- executions execution goals goalrepackage/goal !-- 这个goal至关重要它会重新打包成可执行的jar -- /goals /execution /executions configuration !-- 指定主启动类如果项目结构标准可省略 -- mainClasscom.yourcompany.yourapp.Application/mainClass !-- 排除开发工具减小生产包体积 -- excludes exclude groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId /exclude /excludes /configuration /plugin /plugins /build这里有几个关键点goalrepackage/goal这个目标会替换掉Maven默认打包生成的原始jar生成一个新的、包含所有依赖和启动加载器的“fat jar”。如果你发现打出来的jar很小比如几十KB并且运行时报“找不到主清单属性”那十有八九是这个插件没配置或没执行repackage目标。主类配置如果你的启动类不在根目录下或者有多个SpringBootApplication注解的类需要在这里明确指定mainClass。标准单一启动类项目通常可以自动识别。排除依赖像spring-boot-devtools这种仅在开发时使用的模块一定要在生产打包时排除否则可能引起类加载器问题或安全隐患。另一个常见问题是依赖版本冲突。建议在父pom中通过dependencyManagement统一管理所有依赖的版本子模块中声明依赖时不写版本号。打包前可以运行mvn dependency:tree命令查看依赖树检查是否有冲突的库并用exclusions标签排除掉不需要的传递性依赖。注意在IDEA中直接点击Maven侧边栏的package或install默认就会执行完整的生命周期包括compile、test和package并触发spring-boot-maven-plugin的repackage目标。如果你在命令行操作也要使用mvn clean package或mvn clean install。3. Windows平台运行Jar包的实战细节3.1 环境准备与基础运行在Windows上运行SpringBoot的jar包相对直观。首先你需要确保系统已经安装了Java运行环境。打开命令提示符CMD或PowerShell输入java -version来验证。建议使用与开发环境相同的主要版本如Java 8 11 17以避免因版本差异导致的兼容性问题。运行应用的基本命令非常简单java -jar your-application-0.0.1-SNAPSHOT.jar这时控制台会开始输出SpringBoot的启动日志。你会看到熟悉的Spring标志、激活的配置文件application.properties或application.yml、以及内嵌Tomcat的启动端口默认8080。这是一个前台运行模式命令行窗口关闭应用也就停止了。3.2 后台运行、日志管理与进程守护对于生产环境我们肯定需要让应用在后台运行。在Windows上有几种常见做法使用start命令start /B javaw -jar your-application.jarjavaw命令会启动一个不带控制台窗口的Java进程。start /B表示在后台启动程序而不创建新窗口。这种方式简单但缺乏完善的进程管理和日志收集。使用批处理脚本与Windows服务更专业的做法是将jar包注册为Windows服务。这里推荐使用开源的winswWindows Service Wrapper工具。你需要下载一个对应的winsw.exe如myapp.exe并编写一个同名的XML配置文件如myapp.xmlservice idmyapp/id nameMy SpringBoot Application/name descriptionThis is my SpringBoot service./description executablejava/executable arguments-jar C:\apps\your-application.jar --spring.profiles.activeprod/arguments logmoderotate/logmode workingdirectoryC:\apps/workingdirectory /service然后以管理员身份运行myapp.exe install来安装服务之后就可以在“服务”管理器中启动、停止或设置为开机自启。winsw还能自动管理日志轮转非常方便。日志处理无论用哪种方式都要规划好日志输出。在application.yml中配置日志文件路径和滚动策略logging: file: name: C:/logs/myapp/app.log logback: rollingpolicy: max-file-size: 10MB max-history: 30避免日志无限增长占满磁盘。对于后台运行的程序务必将日志重定向到文件而不是输出到空设备nul否则出了问题根本无法排查。3.3 Windows平台常见问题与排查在Windows上部署我遇到最多的问题集中在端口占用、文件路径和编码上。端口占用应用启动失败提示Web server failed to start. Port 8080 was already in use.。解决方法使用netstat -ano | findstr :8080查找占用8080端口的进程IDPID。然后通过任务管理器结束该进程或者使用taskkill /PID PID /F强制结束。更治本的方法是在application.properties中修改应用端口server.port8081。文件路径与权限应用需要读写某个目录如上传文件、生成报表。在开发时可能用的相对路径到了生产环境可能因工作目录变化而失效。建议使用绝对路径并通过配置项外部化如file.upload-dirC:/app_data/uploads。确保运行该Java进程的用户如SYSTEM、或指定的服务账户对该目录有读写权限。字符编码问题如果日志或程序输出的中文变成了乱码这通常是控制台或日志文件的编码与Java程序输出编码不匹配导致的。可以尝试在启动命令中指定JVM参数-Dfile.encodingUTF-8。同时检查你的代码和配置文件是否统一使用了UTF-8编码。4. Linux平台部署全流程详解4.1 Linux服务器Java环境安装与配置Linux是SpringBoot应用更常见的生产环境。第一步就是安装合适的Java环境。我强烈推荐使用JDK而非仅JRE因为某些工具如jstack, jmap用于诊断需要开发工具包。这里以主流的CentOS/RedHat系列使用yum和Ubuntu/Debian系列使用apt为例。对于CentOS/RedHat 7搜索可用的JDK包yum search java-11-openjdk以Java 11为例。安装JDKsudo yum install java-11-openjdk-devel。-devel包包含了完整的JDK。验证安装java -version和javac -version。对于Ubuntu/Debian更新包索引sudo apt update。安装JDKsudo apt install openjdk-11-jdk。验证安装同上。实操心得不建议使用从Oracle官网下载tar.gz包手动配置JAVA_HOME的复杂方式除非有特定版本需求。系统包管理器安装的OpenJDK其更新和依赖管理都由系统负责更省心。安装后通常不需要手动设置JAVA_HOME因为java命令已加入PATH。但如果你用的某些脚本或工具如Maven依赖这个变量可以将其添加到/etc/profile或用户~/.bashrc中export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 # 路径请用which java和readlink -f命令确认 export PATH$JAVA_HOME/bin:$PATH然后执行source ~/.bashrc使其生效。4.2 Jar包上传、运行与进程管理将打包好的jar文件从Windows传到Linux服务器我习惯用scp命令简单直接scp target/your-application.jar useryour-server-ip:/home/user/app/或者使用图形化工具如WinSCP。在Linux上同样使用java -jar命令启动。但生产环境绝不能在前台运行。标准做法是使用nohup配合nohup java -jar your-application.jar --spring.profiles.activeprod app.log 21 nohup让进程忽略挂断信号SIGHUP即使退出终端也不会终止。 app.log将标准输出重定向到app.log文件。21将标准错误2也重定向到标准输出1指向的地方即同一个日志文件。在后台运行。执行后会返回一个进程IDPID。你可以用jobs -l查看后台作业或者用ps -ef | grep java查找进程。然而更优雅、功能更强大的管理方式是使用Systemd主流Linux发行版默认的初始化系统。创建一个服务单元文件例如/etc/systemd/system/myapp.service[Unit] DescriptionMy SpringBoot Application Afternetwork.target [Service] Typesimple Userappuser # 建议使用非root用户运行 WorkingDirectory/home/user/app ExecStart/usr/bin/java -jar /home/user/app/your-application.jar --spring.profiles.activeprod SuccessExitStatus143 Restartalways # 设置进程退出后总是重启 RestartSec10 # 重启前等待10秒 StandardOutputjournal # 输出到系统日志 StandardErrorjournal [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload # 重新加载配置 sudo systemctl start myapp # 启动服务 sudo systemctl enable myapp # 设置开机自启 sudo systemctl status myapp # 查看服务状态Systemd提供了完善的日志集成通过journalctl -u myapp查看、自动重启、资源限制等功能是生产环境的首选。4.3 生产环境配置与优化建议直接运行java -jar通常需要附加一些JVM参数以优化性能和稳定性。基础内存设置根据服务器内存大小设置堆内存。例如一台4G内存的机器可以这样设置java -Xms512m -Xmx2048m -jar your-application.jar-Xms512m初始堆内存为512MB。-Xmx2048m最大堆内存为2048MB。设置相同的-Xms和-Xmx可以避免堆在运行时动态调整带来的性能波动但会一开始就占用更多内存。GC日志与内存溢出转储为了便于故障诊断建议开启GC日志和内存溢出时的堆转储。java -Xms512m -Xmx2048m \ -XX:UseG1GC \ -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/home/user/app/logs/gc.log \ -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/home/user/app/logs/heapdump.hprof \ -jar your-application.jar-XX:UseG1GC使用G1垃圾收集器在大多数场景下比老的Parallel GC或CMS表现更好。-Xloggc将GC日志输出到指定文件。-XX:HeapDumpOnOutOfMemoryError在发生内存溢出错误时自动生成堆转储文件这是分析内存泄漏的利器。应用配置文件外部化绝对不要将数据库密码等敏感信息硬编码在打包的jar内的application.properties中。SpringBoot支持多种外部化配置方式在启动命令中指定--spring.datasource.passwordyour_password。使用外部配置文件--spring.config.location/etc/myapp/application-prod.yml。使用环境变量在Systemd的service文件中用Environment指令设置或在shell中导出。SpringBoot会自动将SPRING_DATASOURCE_PASSWORD这样的环境变量绑定到配置属性。5. 跨平台部署的通用问题与深度排查5.1 打包阶段经典错误与解决“没有主清单属性” (no main manifest attribute)现象运行java -jar时抛出此错误。原因与解决这几乎100%是因为打包出来的jar不是SpringBoot的可执行jar。检查pom.xml中是否正确配置了spring-boot-maven-plugin并执行了repackage目标。可以先用jar tf your-app.jar查看jar包内容一个正确的可执行jar在根目录下应该有META-INF/MANIFEST.MF文件并且其中包含Main-Class: org.springframework.boot.loader.JarLauncher和Start-Class: com.yourcompany.Application。依赖冲突导致类找不到 (ClassNotFoundException/NoClassDefFoundError)现象应用启动时抛出某个类找不到的异常但在IDE里运行正常。原因与解决通常是Maven依赖传递导致了版本冲突或者打包时某些依赖没被正确包含。首先运行mvn dependency:tree -DincludesgroupId:artifactId查看特定依赖的传递路径。使用exclusion排除冲突的旧版本。其次检查是否错误地设置了scopeprovided/scope或scopetest/scope这会导致该依赖不会被打进jar包。资源文件如图片、模板找不到现象程序运行时无法读取src/main/resources下的文件。原因与解决在jar包中资源文件路径与文件系统不同。不要使用new File(“classpath:...”)而应该使用Spring的ResourceLoader或ClassPathResource来加载。例如this.getClass().getResourceAsStream(“/static/image.png”)。5.2 运行阶段问题排查手册当应用在服务器上启动失败或运行异常时需要系统性地排查。第一步查看日志这是最直接有效的方法。根据你的启动方式查看日志如果用了nohup ... app.log看app.log。如果用了Systemd用sudo journalctl -u myapp -f实时跟踪日志或者sudo journalctl -u myapp --since “2024-01-01”查看历史。重点查找ERROR和WARN级别的日志SpringBoot的启动失败信息通常非常详细。第二步检查端口与网络端口占用使用netstat -tlnp | grep :8080或ss -tlnp | grep :8080检查应用端口是否被其他进程占用。防火墙检查服务器防火墙如firewalld、iptables和云服务商的安全组规则是否允许了应用端口如8080的入站流量。对于云服务器安全组配置错误是常见的外部无法访问的原因。第三步JVM与系统资源诊断内存不足观察启动日志是否有OutOfMemoryError。使用free -h查看系统内存用top或htop查看Java进程的内存占用RES列。调整JVM的-Xmx参数。磁盘空间不足使用df -h检查日志所在磁盘分区是否已满。这会导致应用无法写入日志而卡死。检查应用健康端点如果应用已启动但行为异常Spring Boot Actuator提供的/actuator/health端点非常有用。确保它在生产环境已安全开启可通过管理端口或访问控制它能快速告诉你数据库连接、磁盘状态等是否健康。5.3 性能监控与日常维护建议部署上线不是终点持续的监控和维护同样重要。启用Spring Boot Actuator在pom.xml中添加spring-boot-starter-actuator依赖并适当配置application.properties可以暴露丰富的监控端点如/actuator/metrics,/actuator/env方便集成Prometheus等监控系统。management.endpoints.web.exposure.includehealth,info,metrics,prometheus management.endpoint.health.show-detailswhen_authorized # 注意生产环境务必通过security或网络策略保护这些端点日志聚合当服务器数量增多时登录每台机器看日志效率低下。考虑使用ELKElasticsearch, Logstash, Kibana或LokiGrafana搭建集中式日志平台将各台服务器的应用日志统一收集、索引和展示。制定重启与更新流程最简单的重启命令是sudo systemctl restart myapp。但对于需要零停机更新的场景可以考虑更复杂的方案如使用双jar包目录通过软链接切换或者结合负载均衡器进行蓝绿部署。至少你的更新脚本应该包含停止服务、备份旧版本和日志、上传新jar包、启动服务、验证健康状态这几个步骤。定期备份与清理除了备份代码和数据库应用生成的业务数据文件、配置文件和重要的日志文件也需要定期备份。同时设置日志滚动策略如Logback的TimeBasedRollingPolicy和定时任务cron job定期清理过期的日志文件、临时文件和堆转储文件防止磁盘被撑满。
