在 Linux 环境下部署 Java 应用，核心在于如何高效、稳定地启动 JAR 包，这不仅仅是执行一条简单的命令，更涉及到 JVM 参数调优、后台进程管理、日志规范以及服务自启 等运维层面的深度考量，为了确保生产环境的高可用性，必须摒弃简单的运行方式，转而采用一套包含资源限制、异常自动重启及标准化日志输出的专业启动方案。
基础启动命令与环境配置
最基础的启动方式是使用 java -jar 命令，但在实际生产环境中，必须明确指定运行环境配置，通常建议通过 --spring.profiles.active 参数来区分开发、测试和生产环境,确保应用加载正确的配置文件。
执行以下命令可以启动一个指定了生产环境配置的 JAR 包：
java -jar application.jar --spring.profiles.active=prod
直接运行此命令会占用当前终端会话，一旦断开 SSH 连接，进程就会终止。必须结合后台运行技术或服务管理工具来维持进程的生命周期，还需确保服务器已安装正确版本的 JDK，并且环境变量 JAVA_HOME 已配置妥当,这是应用能够被系统正确识别和调用的前提。
JVM 性能调优参数详解
启动 JAR 包的核心在于 JVM 内存参数的合理配置，这直接关系到应用的吞吐量和稳定性，默认的 JVM 配置往往无法满足生产级的高并发需求，容易导致频繁的 Full GC（全量垃圾回收）,造成服务卡顿甚至宕机。
在启动命令中,必须重点设置以下参数：
- 堆内存设置（-Xms 和 -Xmx）：建议将初始堆内存（
-Xms）与最大堆内存（-Xmx）设置为相同的值，这样做的好处是避免 JVM 在运行过程中动态调整堆内存大小所带来的性能损耗，通常设置为服务器物理内存的 60% 到 70%，对于 4G 内存的服务器，可配置-Xms2g -Xmx2g。 - 元空间设置（-MetaspaceSize 和 -MaxMetaspaceSize）：用于存储类元数据，如果设置过小，在频繁加载类的情况下会导致
OutOfMemoryError: Metaspace，一般建议配置为-MetaspaceSize128m -MaxMetaspaceSize256m。 - 垃圾回收器选择：对于 JDK 8 及以上版本，推荐使用 G1 垃圾收集器，它在低延迟和高吞吐量之间提供了更好的平衡，参数配置为
-XX:+UseG1GC。
一个经过优化的启动命令示例：
java -Xms2g -Xmx2g -XX:+UseG1GC -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -jar application.jar
后台运行与日志重定向
为了防止应用随终端关闭而停止，传统的做法是使用 nohup 命令结合 & 符号，但专业的运维方案更注重日志的规范管理，不能让日志无限制地输出到 nohup.out 文件中,否则会导致磁盘写满或日志文件过大难以检索。
推荐的做法是将标准输出和错误输出重定向到指定的日志文件中，并利用 cron 任务或脚本进行日志轮转,标准的后台启动命令如下：
nohup java -jar application.jar > /var/log/app.log 2>&1 &
在这个命令中，> 表示将标准输出重定向到日志文件，2>&1 表示将标准错误输出也重定向到标准输出中，确保所有信息都能被记录。末尾的 & 符号至关重要，它将命令放入后台执行，执行后，可以使用 jobs -l 或 ps -ef | grep java 来查看进程是否已成功启动。
Systemd 服务化管理（专业方案）
虽然 nohup 能够实现后台运行，但现代 Linux 发行版（如 CentOS 7+、Ubuntu 16+）更推荐使用 Systemd 来管理 JAR 应用，Systemd 提供了开机自启、崩溃自动重启、服务状态监控等企业级功能,是管理长期运行进程的最佳实践。
需要在 /etc/systemd/system/ 目录下创建一个服务文件，app.service示例如下：
[Unit] Description=Java Application Service After=syslog.target network.target [Service] User=www Group=www ExecStart=/usr/bin/java -Xms2g -Xmx2g -jar /opt/app/application.jar SuccessExitStatus=143 Restart=always RestartSec=10 StandardOutput=syslog StandardError=syslog SyslogIdentifier=java-app [Install] WantedBy=multi-user.target
配置完成后，执行 systemctl daemon-reload 重载配置，之后，就可以使用 systemctl start app 启动服务，systemctl stop app 停止服务，systemctl status app 查看状态。Restart=always 指令是高可用的关键，它确保了无论进程是正常退出还是异常崩溃，系统都会尝试自动重启它,极大地减少了人工干预的时间。
Shell 脚本封装与进程守护
在某些不支持 Systemd 的旧环境中，编写健壮的 Shell 启动脚本也是一种专业的解决方案，脚本应具备环境检查、进程防重、PID 记录等功能。
一个专业的启动脚本逻辑通常包含以下步骤：
- 定义应用名称、JAR 包路径和 PID 文件路径。
- 检查是否已有该进程在运行（通过读取 PID 文件或
ps命令查询）。 - 如果进程已存在，则提示用户并退出,防止重复启动导致端口冲突。
- 如果不存在，则执行
java -jar命令，并将进程 ID（）写入 PID 文件。 - 提供停止脚本功能，通过读取 PID 文件中的 ID 执行
kill命令,确保服务能够被优雅地关闭。
这种脚本封装方式将复杂的命令行参数隐藏在内部，对于操作人员来说，只需要执行 ./start.sh 和 ./stop.sh 即可，降低了运维门槛并提高了操作的安全性。
安全与故障排查
在启动 JAR 文件时，安全性往往被忽视，切勿以 root 用户身份运行 Java 应用，一旦应用被攻破，攻击者将获得服务器最高权限，应在启动脚本或 Systemd 配置中指定普通用户（如 www 或 appuser）来运行服务。
当遇到启动失败时,应优先查看以下两点：
- 端口占用：使用
netstat -tunlp | grep 端口检查端口是否被其他进程占用。 - 日志详情：查看重定向的日志文件末尾，
Exception或Error信息会明确指出是内存溢出、配置文件缺失还是数据库连接失败。
相关问答
Q1：如何在 Linux 启动 JAR 包时指定外部配置文件，而不是使用 JAR 包内部的配置？
A： 可以使用 Spring Boot 提供的 --spring.config.location 参数，命令如下：java -jar application.jar --spring.config.location=/opt/config/application-prod.properties，这种方式实现了配置文件与代码包的分离,便于在不重新打包的情况下修改配置。
Q2：启动 JAR 包时提示 “Error: Could not find or load main class” 是什么原因？
A： 这个错误通常由三个原因引起，第一，JAR 包本身损坏或未正确打包（不是可执行 JAR）；第二，MANIFEST.MF 文件中缺少 Main-Class 属性定义；第三，命令行中指定的 JAR 文件路径错误或文件名不匹配，建议使用 unzip -p app.jar META-INF/MANIFEST.MF 命令检查 JAR 包内的清单文件。
希望以上关于 Linux 启动 JAR 包的详细方案能帮助您更好地管理服务，如果您在配置 JVM 参数或编写 Systemd 脚本时有遇到具体问题，欢迎在评论区留言交流,我们可以共同探讨最佳实践。
