Linux下应使用systemd管理进程自动重启，通过Restart=always实现崩溃即重启，并需在C++中自行实现任务级重试逻辑。
程序崩溃后如何自动重启进程
Linux 下最直接的方式是用 systemd 管理进程，而不是在 C++ 里自己 fork 或 exec —— 自己做容易漏掉信号处理、资源清理、僵尸进程等问题。用 systemd 能真正实现“崩溃即重启”，且可控性强。
写一个 .service 文件（比如 /etc/systemd/system/myapp.service）：
[Unit] Description=My C++ App StartLimitIntervalSec=0 <p>[Service] Type=simple ExecStart=/usr/local/bin/myapp Restart=always RestartSec=1 User=myuser Environment="LD_LIBRARY_PATH=/usr/local/lib"</p><p>[Install] WantedBy=multi-user.target
关键点：
-
Restart=always表示无论退出码是什么都重启（包括exit(0)）；若只想在非零退出时重启，改用Restart=on-failure -
StartLimitIntervalSec=0关闭启动频率限制，否则 systemd 默认 10 秒内最多启动 5 次，频繁崩溃会进入failed状态并停服 -
Type=simple要求你的 C++ 程序不 daemonize（即不要调用fork()+setsid()），否则 systemd 会误判进程已退出
任务级失败如何自动重试（非进程级）
重试逻辑必须由 C++ 自己实现，不能依赖外部进程管理。核心是把“可能失败的操作”封装成可重入、有状态、带退避的函数，而不是裸写 while (retry--) { try { ... } catch (...) { sleep(...) } }。
立即学习“C++免费学习笔记（深入）”；
典型场景：HTTP 请求、数据库连接、文件锁获取。推荐用 RAII + 策略模式封装重试：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template<typename F, typename... Args>
auto retry_with_backoff(F&& f, int max_tries = 3, int base_delay_ms = 100) -> decltype(f()) {
for (int i = 0; i < max_tries; ++i) {
try {
return f();
} catch (const std::exception& e) {
if (i == max_tries - 1) throw;
std::this_thread::sleep_for(std::chrono::milliseconds(base_delay_ms * (1 << i)));
}
}
}注意点：
- 重试前要确认操作是否幂等 —— 比如发两次 HTTP POST 可能重复下单，此时应加唯一 ID 或服务端去重，不能只靠重试
- 指数退避（
1 ）比固定延时更抗雪崩，但首次延迟别设太小（<code>10ms容易打满服务），建议从100ms起 - 不要在重试逻辑里捕获
std::system_error以外的底层错误（如std::bad_alloc），这类错误重试大概率失败，应直接终止
如何让程序感知自身异常并主动触发恢复动作
C++ 没有“运行时健康检查中心”，但你可以用信号 + 全局状态 + 定时器组合出轻量自愈能力。重点不是“发现崩溃”（崩溃时什么都做不了），而是“发现卡死/逻辑异常”并自救。
常见做法：
- 用
std::atomic<bool></bool>标记主线程心跳，配合独立 watchdog 线程每 2 秒检查一次；超时则调用std::abort()或写标记文件后raise(SIGUSR2)触发外部脚本重启 - 对关键模块（如网络收发循环）设置
std::chrono::steady_clock超时计时，单次操作超过阈值就记录日志、重置 socket、清空缓冲区，而不是让整个进程挂住 - 避免在 signal handler 中调用
std::cout、malloc、std::string构造等非异步信号安全函数；只做最简操作：写write(2)到 pipe，或设原子变量
例如注册 SIGSEGV 处理器仅用于记录崩溃位置（用 backtrace() + write()），不尝试恢复 —— 这类信号代表严重错误，强行继续执行风险远大于重启。
重试与自愈容易被忽略的边界问题
最常踩的坑不是代码写错，而是没想清楚“什么算失败”和“谁该负责清理”。比如：
- 数据库事务中重试前没 rollback，第二次执行可能遇到
SQLSTATE 25P02: in failed SQL transaction错误 - 文件写入失败后重试，但没检查原文件是否已部分写入，导致下次读取时解析出错
- 使用
std::thread执行异步任务时重试，却忘了 join 或 detach 已启动的线程，造成资源泄漏 - 重试逻辑嵌套在回调里（如 libcurl 的
CURLOPT_WRITEFUNCTION），异常抛出路径被库截断，根本进不到你的catch
自愈机制的价值不在“多试几次”，而在于明确失败语义、控制副作用范围、留下可追溯的状态痕迹。没有日志、没有指标、没有人工干预入口的“自动恢复”，往往会让问题更难定位。
