考点归纳 Swoole 的各种进程退出状态码面试点

Swoole 4.1.0+ 中 exit(0) 不等于安全退出，因其抛出 SwooleExitException 而非终止进程，若未在顶层 try/catch 捕获，会导致协程上下文销毁、逻辑丢失、接口空响应或超时。

为什么 exit(0) 在 Swoole 协程里不等于“安全退出”

在 Swoole 4.1.0+ 中，exit(0) 不会直接终止整个进程，而是抛出 SwooleExitException，但这个行为只对当前协程生效。如果没在顶层 go() 或事件回调里 catch 它，异常会冒泡到 Swoole 底层，触发协程调度器中断——此时 Worker 进程可能仍在运行，但该协程上下文已销毁，后续逻辑丢失。

常见错误现象：

• 协程里写 exit(0) 后，HTTP 接口返回空或超时，日志里看不到报错
• 用 co::sleep() 后紧跟 exit()，结果进程卡住不响应新请求

实操建议：

• 必须在 go() 包裹的最外层 try/catch 捕获 SwooleExitException
• 不要在 onReceive、onRequest 等回调内部裸写 exit()，应改用 return 或抛出自定义异常
• 若需退出整个 Worker，调用 $server->stop($worker_id)，而不是 exit()

swoole_process::exit() 的状态码怎么影响父进程判断

swoole_process::exit($status) 的 $status 值（0–255）会被父进程通过 swoole_process::wait() 拿到，存入 StatusInfo->exit_code。但注意：只有 $status !== 0 时，子进程才跳过 PHP 的 shutdown_function 和扩展清理流程，这会导致资源泄漏风险。

使用场景：

• 子进程执行完任务后主动退出，父进程根据 exit_code 判断是否重试
• 子进程因配置错误退出，父进程读到 exit_code === 127（命令未找到）就不再启动同类进程

容易踩的坑：

• 传入负数或大于 255 的值，实际被截断为 $status & 0xFF，比如 exit(300) 等价于 exit(44)
• 误以为 exit(0) 会触发 onWorkerStop——它不会，onWorkerStop 只响应 $server->stop() 或进程被信号杀死
• 子进程用了 exit(1)，但父进程 wait() 后没检查 StatusInfo->exit_code，导致失败静默

Worker 进程退出后，exit_code 和 signal 哪个更可信

当 Worker 进程退出，StatusInfo->exit_code 和 StatusInfo->signal 都会记录退出原因，但优先级不同：signal 更底层、更真实；exit_code 是上层封装，可能被覆盖。

例如：

• 进程被 kill -9 $pid 杀死 → signal === 9，exit_code 通常为 0（系统不保证）
• 代码里调用 exit(123) → exit_code === 123，signal === 0
• OOM Killer 杀掉进程 → signal === 9，exit_code 不可依赖

实操建议：

• 监控脚本中，先查 signal 是否非零，非零就立刻告警“疑似被信号终止”
• 仅当 signal === 0 时，再信任 exit_code 做业务逻辑判断（如重试、降级）
• 用 dmesg -T | grep -i "killed process" 辅助验证 signal === 9 是否由 OOM 引起

如何从 start.php status 输出里快速定位异常退出

执行 php start.php status 后，GLOBAL STATUS 区域的 exit_status 列是关键线索。它不是单次退出码，而是该 worker_name 最近一次退出的 exit_code；exit_count 表示该状态码累计发生的次数。

典型问题模式：

• exit_status: 255 + exit_count 持续增长 → 很可能是 PHP 解析错误（E_PARSE）或扩展初始化失败
• exit_status: 0 但 exit_count > 0 → 进程被正常 stop 或 exit(0) 触发，需结合日志确认是否预期行为
• exit_status: 137 → 几乎肯定是 OOM Killer 干的（128 + 9），不是代码问题

注意点：

• start.php status 读的是共享内存里的快照，若进程刚退出还没来得及刷新，可能看到旧值
• PROCESS STATUS 里的 pid 对应的进程若已不存在，说明它退出后没被 Manager 重建（可能 max_request 耗尽或配置了 reload_async = false）
• 别只盯 exit_status，同步查 error_log 和系统日志，三者交叉验证才可靠