Hyperf 3.0对比2.2版本在协程并发处理上有何优化_使用Parallel特性-php教程-PHP中文网

不需要改写用法，仍用hyperf\utils\parallel及add()、wait()方法；但须确保enable_coroutine=>true、连接池配置合理、子任务无阻塞操作，否则会退化为串行或挂起。

hyperf 3.0对比2.2版本在协程并发处理上有何优化_使用parallel特性

Hyperf 3.0 的 Parallel 并发处理能力本身没有新增 API 或语义变化，但底层协程调度、连接池和 I/O 阻塞控制的强化，让 Parallel 在真实场景中更稳、更快、更不容易“假并发”——没调优时可能和 2.2 表现接近，调优后才能真正发挥出设计意图。

不需要。代码层面完全兼容：仍用 use Hyperf\Utils\Parallel，仍调 $parallel->add() 和 $parallel->wait()。但有三点关键差异必须注意：

Parallel 内部依赖 Swoole\Coroutine::create 启动协程，而 3.0 强制 enable_coroutine => true，若 server.php 中未显式开启或被覆盖为 false，Parallel 会退化为同步串行执行（无报错，但压测 QPS 暴跌）
2.2 中 Parallel 可能因 MySQL/Redis 客户端未完全协程化，在高并发下触发隐式阻塞；3.0 默认使用协程版 PDO/Redis 客户端，前提是连接池已启用且配置合理，否则仍会卡在 wait for connection from pool
3.0 的 Parallel 在等待结果时，若某子任务抛出未捕获异常，会直接中断整个 wait()，而 2.2 有时会静默忽略——建议每个 add() 闭包内加 try/catch，统一返回 ['error' => $e->getMessage()]

这不是 Parallel 的问题，而是协程资源被上游耗尽导致的调度失效。常见原因：

Hyperf 3.1.66

本页面提供企业级 PHP 协程框架 Hyperf 3.1.66 版本的官方源码下载与完整更新日志。重点解析 v3.1.66 版本中新增的 gRPC 多客户端负载均衡支持、Pool 连接池全量刷新、Guzzle 持久化 Cookie 以及数据库 JSON 包含键查询等核心优化特性。

下载

max_coroutine 设置过低（如仍沿用 2.2 的默认值 3000），当 new Parallel(100) 启动 100 个协程，每个又调用一次数据库查询，实际可能生成数千协程，超出限制后新协程创建失败，wait() 无限挂起
MySQL 连接池 max_connections 小于并发协程数，比如设为 50，但 Parallel(100) 中 100 个协程同时请求连接，其中 50 个拿到连接执行，另 50 个在池里排队——此时 CPU 利用率低、QPS 卡住、wait() 不返回
子任务中误用了非协程安全操作，例如 file_get_contents()、curl_exec()（未替换为 Co\Http\Client）、或手动 new Redis()（绕过连接池），这些操作会阻塞当前协程，使 Parallel 失去并发意义

不能只看代码有没有 new Parallel，得看运行时行为：

启动服务后执行 php --ri swoole | grep "coroutine => enabled"，确认输出为 coroutine => enabled，否则全链路无效
在 Parallel 的闭包里加一行 Co::sleep(0.001)，再压测；如果响应时间明显增加（比如从 20ms → 100ms），说明协程调度器在工作；如果几乎不变，大概率是伪协程或阻塞调用占满调度器
用 php bin/hyperf.php server:monitor 查看实时协程数，发起一个含 Parallel(50) 的请求，协程数应瞬时上涨约 50+（含框架内部协程），而非只涨 1～2 个
检查日志是否有 WARNING: Coroutine xxx is blocked，这类警告在 3.0 中默认开启，2.2 很少报——一旦出现，说明某个子任务用了阻塞调用