Swoole配置中reload_async的作用

reload_async=true使热重启不阻塞新请求，新worker提前接管流量，旧worker完成异步任务后优雅退出；需Swoole≥4.8.13、禁用daemonize或配systemd ReloadSignal，且worker中不可有阻塞调用。

reload_async=true 是为了让 reload 不阻塞新请求

这个配置项控制的是热重启过程中，新连接能否继续被接受。设为 true 后，主进程收到 SIGUSR1 或 SIGHUP 信号触发 reload 时，不会等待所有 worker 进程退出完才开始处理新请求；而是让新的 worker 进程提前启动、接管流量，旧的 worker 在完成手头异步任务（如协程中的 I/O、task 投递、onClose 回调）后再优雅退出。

• 必须搭配 Swoole ≥ 4.8.13 使用，低版本存在竞态 bug，reload_async 可能静默失效
• 若启用了 daemonize => true，主进程会脱离终端，SIGUSR1 信号可能无法送达——此时需用 systemd 管理，并配置 ReloadSignal=SIGUSR1
• worker 进程里不能有死循环、无超时的阻塞调用（比如没设 timeout 的 curl_exec、卡住的数据库连接池初始化），否则会卡在 “waiting for worker exit” 阶段，整个 reload 就挂住了

为什么 Think-Swoole 默认强制设为 true 却又写死成 false？

Think-Swoole 底层在 InteractsWithServer.php 中硬编码了 'reload_async'=>true，但实际运行时你看到的是 false，是因为它紧接着又覆盖了一次：'reload_async'=>true 被后面显式的 set() 调用覆盖掉了——而该调用里明确写了 'reload_async'=>true 并没被写死，真正被写死的是 max_request 和 task_max_request。

所以你看到的 reload_async 实际值，取决于你自己的 config/swoole.php 里怎么配，不是框架“故意锁死”。但要注意：如果用的是 Think-Swoole v4.1.x 之前的老版本，确实存在部分配置被覆盖后不可修改的问题，升级到 v4.1.5+ 更稳妥。

reload_async 和 max_request 的协作关系容易被忽略

reload_async 解决的是“重启过程是否阻塞”，而 max_request 决定“进程是否自动退出”。两者常一起用，但作用域完全不同：

• reload_async 是主进程级开关，影响信号处理流程
• max_request 是 worker 进程级行为，靠子进程自己计数并退出，不依赖主进程发信号
• 如果你只设了 max_request 却没开 reload_async，worker 退出后主进程仍会阻塞等待，直到所有旧 worker 彻底结束，这期间新连接可能被拒绝或排队积压
• 生产环境建议组合使用：'reload_async'=>true + 'max_request'=>3000，既防内存泄漏，又保热更安全

验证 reload_async 是否真生效的最简方法

别只看日志或进程列表，直接观测行为：

• 起一个长连接客户端（比如 WebSocket 连接后不发任何消息），保持连接打开
• 执行 kill -USR1 `cat /var/run/swoole.pid`
• 立刻发起新连接（比如 curl 或另一个 ws 客户端），确认能连上且不报错
• 等 2–3 秒后，再检查原长连接是否还在（netstat -an | grep :9501 | grep ESTAB），如果仍在，说明旧 worker 没被强杀，reload_async 生效了

最容易漏掉的一点：很多团队开了 reload_async 却没关 inotify_mode，导致开发期文件监听和生产热更混用，反而引发 CPU 飙升——生产环境务必设 'inotify_mode' => SWOOLE_INOTIFY_NONE。