云海天狼这篇自启动的坑，我前前后后踩了不少，尤其在混用 Linux 和 Windows 两台机器的时候。jar 包这种东西，不像 exe 那样双击就能跑，也不像安装包那样有官方服务注册工具，想让它在系统启动时自己起来，不依赖人肉 SSH 上去敲 java -jar，是有一套固定路数要走的。这篇文章我把两端的方案和排错过程全拆开讲清楚。
1. 先搞清楚为何这么难：Java 进程与服务化之间的天然鸿沟
很多人第一次接触 java -jar app.jar 觉得很简单，但到了"开机自启动"这一步就发现不对了：为什么我在 Windows 上随手丢进"启动"文件夹的 bat 没生效？为什么 Linux 上把命令写进 /etc/rc.local 也起不来？问题出在Java 进程本身没有服务自愈能力。
1.1 裸奔的 Java 进程：终端一关进程就没了
jar 包启动通常通过命令行执行，但这种方式启动的进程是当前终端会话的子进程。终端窗口关闭、SSH 断开、或者系统注销，这个 Java 进程会被 SIGHUP 信号直接杀掉。我们在 Linux 上常用的 nohup 只是忽略了挂断信号，但进程本身还是"孤儿"，没人看管、没人拉起、没有日志轮转、没有依赖管理和启动顺序控制。
Windows 上更典型——很多人在"启动"文件夹里放一个 start.bat，但 Windows 登录界面还没完全加载完时，脚本就被执行了，结果 JAVA_HOME 环境变量还没生效，或者当前用户桌面还没准备好，jar 包就启动失败，而且失败了你连日志都找不到。说白了，自启动本质上是个"服务化"问题，不是"加一行命令"的问题。
1.2 操作系统亲儿子 vs 野路子方案
所谓"自启动"，有两条路线：
- 走系统服务管理器：Linux 上用 systemd（或 init.d），Windows 上用服务控制管理器（SCM）。让操作系统直接管理进程生命周期、自动拉起、崩溃重启，这是亲儿子方案。
- 走用户级启动器：Linux 的 rc.local、crontab @reboot，Windows 的启动文件夹、任务计划程序。这属于"借助工具触发"，实现简单、但也容易翻车。
我建议直接把 jar 包当成"服务器上一个需要常驻的服务"来对待，而不是一个"程序"。这个思维转变很关键——一旦你预设了 jar 包是一个服务，你就会主动思考：它要不要开机自启、要不要自动重启、要不要写日志、日志轮转怎么做、端口冲突怎么办、启动顺序怎么排。这篇博文后面所有的内容，都是围绕这套思路展开的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Linux 方案：systemd 才是亲儿子
Linux 下自启动 jar 包，主流且唯一推荐的是 systemd。现在几乎所有的发行版（CentOS 7+、Ubuntu 16.04+、Debian 8+）都默认使用 systemd，它有完善的依赖管理、自动重启、日志收集和权限控制。虽然也可以用 /etc/rc.local 或者 crontab 凑合，但生产环境里别用野路子。
2.1 一个能用的 unit 文件长什么样
先别急着写一堆复杂参数，一个最小可用的 systemd service 文件，长这样：
ini复制[Unit]
Description=My Spring Boot App
After=network.target
[Service]
Type=simple
User=deploy
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/java -Xms256m -Xmx512m -jar /opt/myapp/app.jar
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
把这个文件保存为 /etc/systemd/system/myapp.service，然后执行：
bash复制sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp
从此以后，服务器开机就会自动拉起这个 jar 包。如果进程崩溃了，Restart=on-failure 会在等待 10 秒后重新拉起。
2.2 参数逐行拆解：每个字段背后都有一堂课
很多教程会直接把上面的文件丢给你，但你不理解参数含义，遇到问题就无从下手。我拆开讲。
After=network.target：这个字段决定服务在什么之后启动。对于 Java 应用，通常等网络就绪之后再启动，因为很多 jar 包启动时会连数据库、连注册中心。注意，它只保证"网络目标已激活"，不保证网络完全可用，如果你的应用对网络强依赖，建议配合 Wants=network-online.target 和 After=network-online.target 一起用。
Type=simple：这是 systemd 最常见的启动类型。它表示 ExecStart 启动的命令就是主进程，systemd 不会等待额外通知。如果你的启动命令是通过一个 shell 脚本间接启动 Java 进程（比如 ExecStart=/opt/myapp/start.sh），建议改成 Type=forking，因为脚本会先返回，Java 进程变成子进程，systemd 需要知道真正的 PID。不过我建议尽量直接用 java 命令，少套一层脚本，省掉 PID 追踪的麻烦。
User=deploy：指定以哪个用户身份运行。这一点非常重要，永远不要用 root 启动应用服务。单独建一个 deploy 用户，给应用目录授权，这样即使应用被攻破，也拿不到 root 权限。
WorkingDirectory=/opt/myapp：设置工作目录。Java 应用通常会读取相对路径的配置文件、日志目录等，如果不设置 WorkingDirectory，默认是根目录 /，你会一脸懵地发现日志不知道写到哪里去了。
Restart=on-failure 和 RestartSec=10：这是"崩溃自动拉起"的核心。on-failure 表示只有非正常退出（退出码非 0）才重启。如果应用自己处理了停机逻辑并正常退出（比如 Spring Boot 的优雅停机），systemd 不会强行重启。RestartSec=10 是重启间隔，防止进程启动失败后疯狂死循环，把 CPU 打满。
[Install] 部分的关键是 WantedBy=multi-user.target：enable 命令会把这个服务符号链接到 /etc/systemd/system/multi-user.target.wants/ 下，系统进入多用户模式（也就是正常启动状态）时会自动拉起。
2.3 老派但有效的备用方案：rc.local 与 crontab
如果你用的是老系统，或者你只是临时凑合，不想写 systemd 配置文件，有两个备用方案。但先说清楚：备用方案不能用于生产环境，因为它们没有崩溃自动拉起的能力。
rc.local 方案：
编辑 /etc/rc.local，在 exit 0 之前加一行：
bash复制su - deploy -c "nohup /usr/bin/java -jar /opt/myapp/app.jar > /opt/myapp/logs/app.log 2>&1 &"
注意几个细节：
su - deploy -c是切换用户执行，避免 root 权限。nohup ... &必须要有，否则系统启动时终端会话结束，进程会被带走。- 重定向
> /opt/myapp/logs/app.log 2>&1是必需的，不然日志会写到系统日志里，排查非常难受。 - 确认
/etc/rc.local有可执行权限：chmod +x /etc/rc.local。 - 在 systemd 系统上，rc.local 本身被封装成了一个 service，如果没启用会不执行，用
systemctl status rc-local检查。
crontab 方案：
bash复制crontab -e -u deploy
@reboot /usr/bin/java -jar /opt/myapp/app.jar > /opt/myapp/logs/app.log 2>&1
@reboot 是在系统启动时执行一次。这个方案比 rc.local 稍微方便一点（不用管 rc.local 的可执行权限），但同样没有进程守护。而且 crontab 的 @reboot 执行时机是在 systemd 启动用户环境之后，依赖的系统服务可能还没就绪，需要自己加 sleep 之类的防护：
bash复制@reboot sleep 30 && /usr/bin/java -jar /opt/myapp/app.jar ...
我个人不推荐这种 sleep 大法，太脆弱了。网络服务慢一秒和慢三十秒，你的应用启动失败概率完全不同。systemd 的依赖管理才靠谱。
2.4 启用自启动的完整命令链
把 service 文件放好后，正确的命令顺序是：
bash复制# 1. 重新加载 systemd 配置，让新 unit 生效
sudo systemctl daemon-reload
# 2. 设为开机自启
sudo systemctl enable myapp
# 3. 立刻启动，不用等重启吧
sudo systemctl start myapp
# 4. 查看运行状态
sudo systemctl status myapp
daemon-reload 这步非常关键。如果你修改了 .service 文件，不执行 daemon-reload 直接 restart，systemd 用的还是旧配置。我实验过好多次，改完 RestartSec 忘了 reload，服务重启后用的还是原来的值，排查了半天才发现是这个问题。
enable 之后，你可以检查一下符号链接是否建立成功：
bash复制ls -l /etc/systemd/system/multi-user.target.wants/myapp.service
看到链接指向你的真实 service 文件，就说明开机自启的链路已经打通了。
3. Windows 方案：不只一条路，但选错会很难受
Windows 下自启动 jar 包的花样比 Linux 多，但坑也比 Linux 多。我按推荐程度从低到高，把几种方案都捋一遍。
3.1 最无脑的启动文件夹法：只适合个人开发机
把 jar 包或一个 start.bat 放进"启动"文件夹（shell:startup），系统登录时会自动执行。
一个典型的 start.bat：
bat复制@echo off
set JAVA_HOME=C:\Program Files\Java\jdk-17
set PATH=%JAVA_HOME%\bin;%PATH%
start "" "C:\Program Files\Java\jdk-17\bin\java.exe" -jar D:\apps\myapp.jar
pause
这个方案的最大问题是依赖用户登录。如果服务器是开机不自动登录的，或者登录界面锁着没进桌面，这个 bat 不会执行。而且启动时机很早，容易和系统初始化打架。
所以我只推荐在本地开发环境、或者你确定服务器会自动登录且桌面常驻的场景下用。生产环境的 Windows 服务器，别用这个。
3.2 任务计划程序：比启动文件夹优雅，能设延迟
Windows 的任务计划程序（Task Scheduler）比启动文件夹强很多，可以指定"启动时"或"登录时"触发、延迟执行、以 system 账户运行、失败重试。
操作路径：Win+R 输入 taskschd.msc 打开任务计划程序，创建基本任务。关键配置如下：
- 触发器：选择"计算机启动时"。
- 操作：启动程序，程序填
java.exe的完整路径，参数填-jar D:\apps\myapp.jar，起始于填D:\apps。 - 条件：取消勾选"只有在计算机使用交流电源时才启动此任务"，防止笔记本插电才触发。
- 设置：勾选"如果任务失败，按以下频率重新启动"，可以设置重启间隔和次数。
用命令行创建任务计划也可以，支持脚本化部署：
bat复制schtasks /create /tn "MyApp" /tr "C:\Program Files\Java\jdk-17\bin\java.exe -jar D:\apps\myapp.jar" /sc onstart /ru SYSTEM /rl HIGHEST
注意，/sc onstart 表示开机触发，/ru SYSTEM 使用 SYSTEM 账户运行，不依赖用户登录。这个方案比启动文件夹靠谱，但它本质上还是"触发一次命令"，如果 jar 包进程崩了，任务计划不会自动拉起——除非你嵌套一层批处理循环监控，但那太勉强了。
3.3 winsw 注册服务：生产环境最省心的方案
Windows 上真正靠谱的做法，是把 jar 包封装成 Windows 服务。Windows 服务由 SCM 管理，开机自动启动、崩溃可配置重启、不依赖用户登录、还能用 sc query 和 net start 控制。把 jar 包注册成 Windows 服务最常用的工具是 winsw。
先说为什么不用 NSSM（另一个常用工具）。NSSM 很多人在用，但 winsw 的优势是配置文件是 XML，可以直接扔进项目仓库做版本管理，还能显式配置 Java 的版本、内存参数、环境变量、日志目录和 onfailure 策略。NSSM 用 GUI 配置，适合单机手动操作，不便于自动化交付。所以我下面以 winsw 为例。
第一步：下载 winsw.exe 并改名
从 GitHub releases 下载 WinSW-x64.exe，把它放到你的应用目录，比如 D:\apps\myapp\，然后改名为 myapp.exe（要和 XML 配置文件名对应）。
第二步：写 myapp.xml 配置文件
xml复制<configuration>
<id>myapp</id>
<name>My Java Application</name>
<description>This is a Spring Boot application deployed as a Windows service.</description>
<executable>C:\Program Files\Java\jdk-17\bin\java.exe</executable>
<arguments>-Xms256m -Xmx512m -jar D:\apps\myapp\app.jar</arguments>
<logmode>rotate</logmode>
<logpath>D:\apps\myapp\logs</logpath>
<onfailure action="restart" delay="10 sec"/>
<onfailure action="restart" delay="20 sec"/>
<onfailure action="restart" delay="30 sec"/>
</configuration>
几个关键配置的说明：
<id>是服务唯一标识，安装后会在 Windows 服务列表显示，建议用简短英文字母。<executable>必须写 java.exe 的完整路径。即使你系统环境变量配置了 JAVA_HOME，Windows 服务环境中可能拿不到，或者拿到的是错的，所以显式指定最保险。<arguments>里的-jar和 jar 包路径都作为参数传给 java.exe，注意路径不要加引号（除非路径含空格）。如果路径里确实有空格，需要在 XML 里用"转义。<logmode>rotate</logmode>让 winsw 管理 Java 进程的标准输出和错误输出，按大小轮转，防止日志文件无限增长。<onfailure>配置了三次失败后不断重启的策略，每次重启间隔递增，这个模式叫"退避重试"，比固定间隔更合理。
第三步：安装服务
在 D:\apps\myapp\ 目录打开管理员命令行：
bat复制myapp.exe install
然后启动服务：
bat复制net start myapp
或者用 PowerShell：
powershell复制Start-Service myapp
去服务列表里看一眼，services.msc 打开，应该能看到 myapp 服务了。
第四步：配置失败后的自动重启
winsw 的 onfailure 已经配了重启策略，但建议另外再做一层保险：打开 services.msc，右键服务 -> 恢复选项卡，设置"第一次失败：重新启动服务"。这两个机制叠加，进程级崩溃由 winsw 拉，系统服务状态异常由 SCM 拉，双保险。
3.4 表格对比：三种 Windows 方案的取舍
| 方案 | 开机自启 | 不依赖登录 | 崩溃自动拉起 | 日志管理 | 适用场景 |
|---|---|---|---|---|---|
| 启动文件夹 | 是 | 否 | 否 | 自行重定向 | 个人开发机 |
| 任务计划程序 | 是 | 是 | 需配置重试策略 | 自行管理 | 轻量部署，临时服务 |
| winsw | 是 | 是 | 是 | 内置 rotate | 生产环境推荐 |
如果你负责的是生产环境的 Windows 部署，直接上 winsw，不要犹豫。任务计划程序虽然也能开机触发，但进程守护和日志管理都不到位，出了问题你连崩溃原因都找不到。
4. 自启动只是第一步：守护、日志、优雅停止全得安排
自启动跑通不等于万事大吉。上线几天后你会发现，比"开机没起来"更常见的问题是：跑着跑着挂了没人知道、日志把磁盘写满、需要停机维护时 kill 不掉。这些都必须提前设计进来。
4.1 进程挂了谁来拉：systemd 和 winsw 的守护机制
上面讲过 systemd 的 Restart=on-failure 和 winsw 的 onfailure，这里补充两个容易忽略的细节。
细节一：警惕"正常退出"的假象
有些 Java 应用在被系统 OOM kill 时，退出码可能是 137（SIGKILL）；但有些情况，比如 System.exit(0) 被业务代码误调用，退出码是 0。如果你配置的是 Restart=on-failure，退出码为 0 时 systemd 不会重启。解决办法是把 Restart 改成 always：
ini复制Restart=always
这样无论退出码是什么，都重启。但对那种接收停止指令正常退出的场景，always 也会把它拉起来，这时候需要配合 systemd 的停止操作：systemctl stop 明确停止的服务，systemd 不会根据 Restart 自动拉起。所以 Restart=always 是安全的，放心用。
细节二：启动顺序的依赖
如果你的多个 jar 包之间有调用关系，比如 A 依赖 B 的接口，那就必须在 unit 文件里配置依赖：
ini复制[Unit]
Description=App A
After=network.target app-b.service
Requires=app-b.service
After 保证 B 先启动，Requires 保证 B 启动失败时 A 不会启动。但这里有个坑：Requires 只是 B 服务 active 之后就会启动 A，B 里的应用端口真正 ready 可能还需要几秒。如果你对启动顺序极其敏感，建议在应用里做重试机制，连接失败后 sleep 几秒再连，比在 systemd 里死磕顺序更可靠。
4.2 日志去哪了：标准输出统一管理的必要性
Java 应用打印到 System.out 和 System.err 的内容，在 systemd 下会进 journald，用 journalctl -u myapp -f 实时查看，这是很多人喜欢的做法。但 journald 的日志默认会轮转，存储在 /var/log/journal，如果磁盘空间紧张，得注意限制 journal 的大小：
bash复制# 限制 journal 最大 500M
sudo journalctl --vacuum-size=500M
建议在 unit 文件里用 StandardOutput=append:/opt/myapp/logs/app.log 直接把标准输出写到指定文件，这样更方便接收集日志工具（比如 filebeat、Loki 等）：
ini复制[Service]
StandardOutput=append:/opt/myapp/logs/app.log
StandardError=append:/opt/myapp/logs/app.log
Windows 上用 winsw 时，<logmode>rotate</logmode> 已经处理了这个，日志默认写在 <logpath> 目录下。
4.3 停止和重启的规范操作
很多 Java 应用支持优雅停机，比如 Spring Boot 的 actuator 的 shutdown endpoint，或者注册了 shutdown hook。但如果你是 kill 命令裸杀，进程可能来不及收尾，导致数据不一致或端口未释放。
最简单的方式是用系统服务管理器来控制：
bash复制# Linux
sudo systemctl stop myapp
sudo systemctl start myapp
sudo systemctl restart myapp
# Windows
net stop myapp
net start myapp
Restart-Service myapp
系统服务管理器会先给进程发送 SIGTERM（或等效信号），等进程优雅退出后再做后续动作。不要 kill -9，除非确认进程已经卡死。另外，systemd 默认等待进程退出的时间是 90 秒（TimeoutStopSec），如果应用优雅停机需要更长时间，记得调大：
ini复制TimeoutStopSec=120
5. 实操中容易踩的坑：我把常见的都列一遍
自启动方案本身不难，但实际部署时九成时间都耗在排错上。我把这几年遇到的高频问题全部摊开，每个都附排查链路。
5.1 Linux 下 Java 环境变量丢失
现象：手动在终端敲 java -jar 能启动，但 systemd 服务启动失败，journalctl -u myapp 日志显示 java: command not found。
原因：systemd 的 service 环境非常干净，不像登录 shell 会自动加载 /etc/profile、~/.bashrc 里的环境变量。你要是用了：
ini复制ExecStart=java -jar /opt/myapp/app.jar
而 java 是通过 PATH 找到的，那大概率失败。
解法：不要在 ExecStart 里写裸的 java，写完整路径 /usr/bin/java 或 /usr/local/jdk-17/bin/java。更稳妥的方式是在 service 里显式导入环境变量：
ini复制[Service]
Environment=JAVA_HOME=/usr/local/jdk-17
Environment=PATH=/usr/local/jdk-17/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
5.2 Windows 下 jdk 版本不对导致启动失败
现象：本地跑得好好的 jar 包，服务里启动就报 UnsupportedClassVersionError，或直接 Could not find or load main class。
原因：注册服务时把 java.exe 的路径写错了，或者指向的是机器上另装的旧 JDK。我在一台装了 JDK 8 和 JDK 17 的机器上遇到过——手动执行时 PATH 指向 17，但 winsw 配置里写死了 8，于是打包时用 17 编译、运行时用 8，直接崩。
排错：不要在服务里写 java 试试。先确认 jar 包编译版本，用命令查看 class 文件版本号（52=Java 8，61=Java 17）：
bash复制javap -verbose your-app.jar | findstr "major"
然后确认 java 路径是你需要的版本：
bat复制wmic service myapp get PathName
5.3 端口被占用导致启动失败，但服务状态显示 running
现象：systemd 显示服务 active（running），但业务请求全都失败，端口根本没监听。
原因：这是个经典的"假 running"问题。Type=simple 情况下，systemd 认为主进程启动即服务成功，不会去检查端口是否监听。如果 jar 包里的 web 容器（如 Tomcat）启动失败——端口被占、数据库连接不上——但主进程没有退出，systemd 依然觉得它活着。
排错：用 ss -lntp | grep 8080 查看端口监听，用 curl http://127.0.0.1:8080/actuator/health 做健康检查。如果你希望 systemd 更可靠地判断健康状态，可以用 ExecStartPost 加一段检查脚本：
ini复制ExecStartPost=/bin/sh -c 'for i in {1..30}; do curl -sf http://127.0.0.1:8080/actuator/health && exit 0; sleep 2; done; exit 1'
这样端口或健康检查失败，服务会进入 failed 状态并触发 Restart。
5.4 systemd 服务的权限不够，文件读不了
现象：服务启动失败，日志显示 Permission denied 或 Unable to read config file。
原因：你用 User=deploy 跑服务，但配置文件在 /root 目录下，或者 jar 包属于 root 拥有且权限是 600，deploy 用户读不了。
解法：规范目录结构，把应用统一放 /opt/myapp，属主改成 deploy：
bash复制sudo chown -R deploy:deploy /opt/myapp
sudo chmod -R 750 /opt/myapp
配置文件路径不要在代码里写死相对路径，尽量用绝对路径，或者在 service 文件里用 Environment=SPRING_CONFIG_LOCATION=file:/opt/myapp/conf/application.yml 指定。
5.5 Windows 服务在日志里显示 "1053 服务没有及时响应启动或控制请求"
现象：winsw net start myapp 报错，服务启动失败，系统日志里出现 1053。
原因：SCM 默认给服务 30 秒启动超时。如果你的 jar 包启动特别慢——比如要加载大量数据、连数据库重试——SCM 就会认为服务没响应。winsw 自己其实是无缝转发的，但 Java 持久层启动慢时容易踩中。
解法：修改 SCM 的服务超时时间。在注册表：
code复制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
新建 ServicesPipeTimeout（DWORD），值为 60000（毫秒），然后重启机器，超时时间就会变成 60 秒。这个不完美，但实测有效。
另外，winsw 配置文件里可以加 <stopexecutable> 等参数做优雅停止，让服务在收到 stop 命令时通过 /actuator/shutdown 先停业务，再退出进程。
6. 两个提高效率的小技巧
技巧一：用一套脚本管理多实例。如果你一台机器上有多个 jar 包要管理，写一个批量控制脚本会很方便。Linux 下用 systemd 加模板 unit：
创建 /etc/systemd/system/myapp@.service：
ini复制[Unit]
Description=My App Instance %i
After=network.target
[Service]
Type=simple
User=deploy
WorkingDirectory=/opt/myapp/%i
ExecStart=/usr/bin/java -jar /opt/myapp/%i/app.jar
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
然后每个实例只需建目录 /opt/myapp/app1、/opt/myapp/app2，执行：
bash复制sudo systemctl enable myapp@app1
sudo systemctl start myapp@app1
sudo systemctl enable myapp@app2
sudo systemctl start myapp@app2
不用为每个实例复制一份 unit 文件，清爽很多。
技巧二：把部署脚本写进 CI/CD。自启动配置写好后，别只在服务器上手工操作，把整个初始化流程脚本化。我在项目里会放一个 deploy/linux-install.sh 和一个 deploy/windows-install.bat，内容包括创建用户、目录授权、生成 systemd/winsw 配置、执行 enable/install。这样每次新环境上线，一行命令就把自启动全部搞定，不用靠人肉记忆。
提示：改完 systemd 或 winsw 配置，一定要先
daemon-reload或myapp.exe restart验证配置生效，再重启机器做最终验证。我曾经有一次改完RestartSec忘了 reload，重启服务器后服务还是按旧配置跑，排查了半天才发现是 systemd 缓存的问题。
最后再分享一个折腾下来的心得：自启动配置看起来是"小功能"，但它决定了你的服务在无人值守时是否可靠。把 systemd 和 winsw 这两套方案吃透，比在网上搜十个脚本都管用。如果你在部署中遇到了上面没覆盖的问题，日志永远是最好的老师——先看日志，再猜原因。