fork 守护与信号处理

fork 守护与信号处理是 Unix 老手艺，但在鸿蒙沙箱里要按新规矩来。这篇讲可用的边界与正确姿势。

▍fork 的可用性边界
先纠正一个流传较广的误解：鸿蒙应用沙箱并不是完全无 fork——创建子进程（fork 自身映像）是可用的，被严格限制的是执行新的程序文件（从应用数据目录 execve 新二进制基本走不通，受执行权限与安全策略约束）。这对移植的含义：依赖 fork 加 exec 模型的代码（起辅助工具、起 shell 命令）要改造成 fork 加分工（子进程在自身映像里跑逻辑）或线程模型；单纯 fork 做并行或守护的代码基本能保留。

▍信号处理的坑
一，线程环境的信号投递：信号会投递给任意未屏蔽该信号的线程，处理器要在专门线程同步等待（经典模式：屏蔽全部加专用等待线程），否则处理器在错误线程跑出竞态。二，不可用信号：个别桌面常用的信号在沙箱里语义受限，代码里逐个核对（ terminate 类的标准信号可用，作业控制类基本无意义）。三，库的信号接管：第三方库（崩溃处理器、性能采样器）自己装信号处理器，多个处理器互相覆盖——注册链要理顺，自己的处理器最后装并记录前一个。

▍守护模式设计
主进程 fork 守护子进程的标准结构：子进程跑核心、主进程监视。要点：等待与超时（子进程退出要立刻知道，用等待接口而不是轮询）；重启策略（次数上限加退避，防崩溃风暴耗电）；退出码约定（正常退出与崩溃退出的区分，决定要不要重启）；僵尸回收（子进程退出后主进程要及时收尸，孤儿与僵尸问题见专篇）。

▍退出清理序列
收到终止信号后的清理顺序：停接收新任务——通知工作线程收尾——等待或超时强停——释放资源——退出。共享资源（锁、共享内存）的清理要幂等（重复清理不出错）。真实坑：退出路径死锁（清理时拿的锁已被销毁），限时锁与跳过策略是解法。

▍验收
反复杀子进程验证守护恢复；应用切后台的信号行为；系统低内存下被杀的路径；连续启停压力。

更多真实移植案例，欢迎到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录。