systemd服务反复重启主因是配置不当：应设restart=on-failure、restartsec=10s、successexitstatus=143、startlimitintervalsec=600与startlimitburst=3，并使memorylimit高于-xmx以避免oom静默终止。
systemd 服务反复重启，不是 OpenJDK 的问题，而是服务配置没对——Java 进程崩了、卡死、或启动失败，systemd 只是忠实地执行你写的策略。关键在怎么让 systemd 判得准、等得稳、限得住。
Restart=on-failure 是 Java 服务的默认安全线
Restart=no（默认值）会让崩溃静默消失；Restart=always 则连 systemctl stop 都会立刻拉起，干扰运维。
Java 应用（如 Spring Boot）应明确设为：
[Service] Restart=on-failure RestartSec=10s-
on-failure 覆盖常见崩溃场景：非零退出码、被 SIGKILL/SIGSEGV 终止、超时（TimeoutStartSec 触发）
- RestartSec=10s 给 JVM GC、日志刷盘、端口释放留出缓冲，避免秒级重试导致 OOM 雪崩
SuccessExitStatus=143 必须加，否则正常停机也被当故障
Java 进程收到systemctl stop 时，systemd 默认发 SIGTERM（信号 15），JVM 优雅关闭后常以状态码 143 退出（128 + 15）。
若不声明：
- systemd 把 143 当作异常退出 → 触发 Restart=on-failure → 服务刚停又自启
正确做法：
SuccessExitStatus=143- 可追加
143 0，兼容直接 exit(0) 场景
- 不要写 SuccessExitStatus=0 单独一行，否则掩盖真实崩溃（比如 OOM 后 JVM 强制 exit(1)）
StartLimitIntervalSec + StartLimitBurst 必须配对，防雪崩
没限流的自动重启等于没刹车： - 默认StartLimitIntervalSec=10s + StartLimitBurst=5 → 10 秒内失败 5 次即锁死服务，systemctl start 直接报 Start request repeated too quickly
生产环境建议：
- StartLimitIntervalSec=600（10 分钟窗口）
- StartLimitBurst=3（最多连续失败 3 次）
这样既容许短暂抖动（如 DB 临时不可达），又防止因配置错误、磁盘满、OutOfMemoryError 导致无限循环拉起 JVM 进程吃光内存
MemoryLimit 和 JVM 参数必须对齐，否则 OOM 杀进程不走 Restart 流程
systemd 的 MemoryLimit=2G 和 JVM 的 -Xmx2g 不是一回事：
- MemoryLimit 控制整个 cgroup 内存（含堆外内存、线程栈、JIT 编译缓存）
- JVM 堆上限 -Xmx 只占一部分，实际进程 RSS 常达 -Xmx 的 1.5–2 倍
若 MemoryLimit=2G 但 JVM 设了 -Xmx2g，大概率触发内核 OOM killer —— 进程被无声杀死，systemd 日志只写 Killed，不带退出码，Restart=on-failure 也无效
稳妥做法：
- MemoryLimit=3G（比 -Xmx2g 至少多 1G）
- 加 OOMScoreAdjust=-500 降低被 OOM killer 选中的优先级（仅限必要时）
真正容易被忽略的是：journalctl -u your-service --all 才能看到完整退出链。默认日志会截断中间失败记录，看起来像“刚启动就没了”，其实上一轮崩溃的堆栈可能藏在更早的 --all 输出里。别只看 systemctl status 的最后一行。
