Swoole 5异步事件循环被同步代码阻塞会导致Worker假死；需监控eventLoopDelay（P99＞20ms预警）、用strace/perf定位CPU热点、检查Coroutine::count()异常增长及常见同步陷阱如session_start、flock、未协程化I/O等。
Swoole 5 的异步事件循环一旦被同步代码卡住，整个 Worker 进程就无法处理新请求——不是“慢”，而是“假死”：CPU 占用低、无日志输出、健康检查超时、所有接口集体延迟。定位关键不在于查“哪里慢”，而在于确认“是不是被同步执行堵住了主线程”。
看事件循环是否真在运转
最直接的判断方式是监控事件循环延迟。Swoole 5 内置 perf_hooks 兼容能力（需 PHP ≥ 8.0），可启用 monitorEventLoopDelay：
- 在 Server 启动前加入监控逻辑，每 5 秒打印 P99 延迟（单位毫秒）
- P99 持续高于 20ms 就说明有长任务占着主线程没让出
- 若延迟突增至几百毫秒甚至秒级，基本可锁定为同步 CPU 密集型操作（如大数组遍历、JSON.stringify、正则回溯、未协程化的 file_get_contents）
抓当前线程的 CPU 热点
同步阻塞不会产生大量 I/O 等待，但会持续占用 CPU。用系统级工具定位热点函数：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 对正在卡住的 PHP Worker 进程运行
strace -p <pid> -c，观察是否高频出现read/write系统调用（说明在做同步 I/O） - 用
perf record -p <pid> -g -- sleep 10录制 10 秒栈帧，再perf report查看 top 函数：若php_json_encode、memcpy、zend_hash_apply占比异常高，就是同步序列化或深拷贝在拖住循环 - 避免只看
top的 CPU%，因为同步计算可能只占单核 100%，而整体进程显示 12.5%（八核机器），容易误判
检查协程状态与资源泄漏线索
同步阻塞常伴随协程异常堆积或资源未释放，可用 Swoole 自带指标交叉验证：
- 定时调用
Coroutine::count()：若数值持续上涨且不回落，可能是协程启动后被同步代码卡住，无法执行到return或co::sleep()让出点 - 查看
swoole_get_local_statistics()中server->connection_num是否正常增长，但server->request_count几乎不动——说明连接进来了，但请求回调根本没机会执行 - 检查
memory_get_peak_usage()是否随时间线性增长：同步代码本身不泄漏内存，但如果它卡在某个while(true)或未退出的flock中，会导致协程长期存活并累积引用
快速验证是否为常见同步陷阱
不用等复现，直接排查高频雷区代码：
-
session_start()：PHP 默认文件 session 会加锁，后续请求会卡在该函数，尤其前端轮询时 -
flock($fp, LOCK_EX)：文件锁未释放或持有时间过长，其他协程会在加锁处阻塞 - 未协程化的 I/O 调用：如
file_get_contents()、curl_exec()、sleep()、usleep() - 大对象 JSON 序列化：
json_encode($hugeArray)在主线程执行时，几万行数据可能耗时数百毫秒 - 正则表达式回溯爆炸：
preg_match('/^(a+)+b$/', str_repeat('a', 10000))会彻底卡死
