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</p>
关键点：
-
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(...) } }。
典型场景：HTTP 请求、数据库连接、文件锁获取。推荐用 RAII + 策略模式封装重试：
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 <p><strong>注意点</strong>：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul>
<li>重试前要确认操作是否幂等 —— 比如发两次 HTTP POST 可能重复下单，此时应加唯一 ID 或服务端去重，不能只靠重试</li>
<li>指数退避（<code>1 ）比固定延时更抗雪崩，但首次延迟别设太小（<code>10ms</code> 容易打满服务），建议从 <code>100ms</code> 起</code>
</li>
<li>不要在重试逻辑里捕获 <code>std::system_error</code> 以外的底层错误（如 <code>std::bad_alloc</code>），这类错误重试大概率失败，应直接终止</li>
</ul>
<h3>如何让程序感知自身异常并主动触发恢复动作</h3>
<p>C++ 没有“运行时健康检查中心”，但你可以用信号 + 全局状态 + 定时器组合出轻量自愈能力。重点不是“发现崩溃”（崩溃时什么都做不了），而是“发现卡死/逻辑异常”并自救。</p>
<p>常见做法：</p>
<ul>
<li>用 <code>std::atomic<bool></bool></code> 标记主线程心跳，配合独立 watchdog 线程每 2 秒检查一次；超时则调用 <code>std::abort()</code> 或写标记文件后 <code>raise(SIGUSR2)</code> 触发外部脚本重启</li>
<li>对关键模块（如网络收发循环）设置 <code>std::chrono::steady_clock</code> 超时计时，单次操作超过阈值就记录日志、重置 socket、清空缓冲区，而不是让整个进程挂住</li>
<li>避免在 signal handler 中调用 <code>std::cout</code>、<code>malloc</code>、<code>std::string</code> 构造等非异步信号安全函数；只做最简操作：写 <code>write(2)</code> 到 pipe，或设原子变量</li>
</ul>
<p>例如注册 <code>SIGSEGV</code> 处理器仅用于记录崩溃位置（用 <code>backtrace()</code> + <code>write()</code>），不尝试恢复 —— 这类信号代表严重错误，强行继续执行风险远大于重启。</p>
<h3>重试与自愈容易被忽略的边界问题</h3>
<p>最常踩的坑不是代码写错，而是没想清楚“什么算失败”和“谁该负责清理”。比如：</p>
<ul>
<li>数据库事务中重试前没 rollback，第二次执行可能遇到 <code>SQLSTATE 25P02: in failed SQL transaction</code> 错误</li>
<li>文件写入失败后重试，但没检查原文件是否已部分写入，导致下次读取时解析出错</li>
<li>使用 <code>std::thread</code> 执行异步任务时重试，却忘了 join 或 detach 已启动的线程，造成资源泄漏</li>
<li>重试逻辑嵌套在回调里（如 libcurl 的 <code>CURLOPT_WRITEFUNCTION</code>），异常抛出路径被库截断，根本进不到你的 <code>catch</code>
</li>
</ul>
<p>自愈机制的价值不在“多试几次”，而在于明确失败语义、控制副作用范围、留下可追溯的状态痕迹。没有日志、没有指标、没有人工干预入口的“自动恢复”，往往会让问题更难定位。</p></typename>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
