Swoole安装后协程死循环检测配置-Swoole-PHP中文网

swoole默认不检测协程死循环，需主动启用deadlock_check；因调度器仅在i/o、yield或超时点切换协程，空while等忙等不触发调度，故无报错、cpu不显高，仅表现为连接堆积、request_count停滞。

swoole安装后协程死循环检测配置

协程死循环不会自动被 Swoole 检测或中断，必须主动启用死锁/阻塞检测机制，否则卡住的协程会一直占用资源、拖垮整个服务。

为什么 `go()` 卡住却没报错？

Swoole 默认不开启协程死锁检测——它把“长时间不 yield”视为合法行为（比如你在协程里写了个 while (true) { usleep(1000); }）。系统级工具（如 top）也看不到 CPU 占用，因为这是纯 PHP 层忙等，没进内核态。真实现象是：连接堆积、tasking_num 持续为 0、request_count 停滞，但 Worker 进程状态正常。

根本原因：Swoole 协程调度器只在遇到 I/O 操作（如 co::sleep、co::readFile）、显式 yield() 或超时点才会切换协程
常见诱因：file_get_contents（未 hook）、curl_exec（无 timeout）、session_start() 文件锁等待、空 while 循环、Redis 同步调用
注意：Swoole\Coroutine::set(['hook_flags' => SWOOLE_HOOK_ALL]) 必须在 Co\run() 或 Server 启动前执行，否则 I/O 不会被协程化，也就无法触发调度点

`Co\run()` 中如何启用死循环检测

在协程入口函数中，用 Co::set() 开启 deadlock_check 并设合理阈值（单位：毫秒），这是最轻量、最直接的方式：

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

Co::set([
    'deadlock_check' => true,
    'deadlock_timeout' => 3000, // 超过 3 秒不 yield 就报 warning
]);
Co::run(function () {
    go(function () {
        while (true) {
            // 没有 yield / sleep / I/O —— 3 秒后会触发日志警告
        }
    });
});

deadlock_timeout 建议设为 2000~5000，太小会误报（如密集计算），太大失去意义
该配置仅对当前 Co::run() 生命周期有效，Server 模式下需在 onStart 或 onWorkerStart 中重复设置
警告日志级别默认为 SWOOLE_LOG_WARNING，确保 swoole.log_level ≥ 3，否则看不到

HTTP Server 场景下怎么加检测

Server 启动后所有请求协程都继承全局配置，但需在 onWorkerStart 中显式设置，否则新 Worker 进程不生效：

$server = new Swoole\Http\Server('0.0.0.0', 9501);
$server->on('workerStart', function ($server, $worker_id) {
    Swoole\Coroutine::set([
        'deadlock_check' => true,
        'deadlock_timeout' => 3000,
        'hook_flags' => SWOOLE_HOOK_ALL,
    ]);
});

别在 onStart 设置——它运行在 Manager 进程，不影响 Worker
如果用了 task_worker_num > 0，也要在 onTask 回调开头手动 Co::set()，因为 task 进程不共享 Worker 配置
配合 swoole.log_file 和磁盘监控，避免日志写满导致检测失效（常见坑：日志路径不可写，错误静默丢弃）