sleep() 在 pthreads 多线程中仅暂停当前线程，不影响其他线程；需 cli 环境且启用 zts 和 pthreads 扩展；web 环境（如 php-fpm）不支持；应优先使用 cond/mutex 等原语替代轮询式 sleep()。
sleep() 在 PHP 多线程环境（如 pthreads 扩展）中有效，但只作用于当前线程，不阻塞其他线程——这是它能“看似正常工作”的前提，也是多数人误用的起点。
pthread 中 sleep() 确实暂停当前线程
pthreads（v3+，适用于 PHP 7.2+）是真正的用户态线程扩展，sleep() 在其中的行为与系统级线程调度一致：
- 调用
sleep(2)后，当前Thread进入休眠状态，CPU 时间片让出； - 其他线程（包括主线程和其他
Thread实例）照常运行，互不影响； - 返回值逻辑不变：成功返回
0，被信号中断则返回剩余秒数（Linux 下）。
class WorkerThread extends Thread {
public function run() {
echo "线程 {$this->getThreadId()} 开始\n";
sleep(3); // ✅ 只挂起本线程
echo "线程 {$this->getThreadId()} 结束\n";
}
}
$th1 = new WorkerThread();
$th2 = new WorkerThread();
$th1->start(); $th2->start();
$th1->join(); $th2->join();
⚠️ 注意：上述代码需在 CLI 模式下运行，且确保已启用 pthreads（PHP 编译时开启 ZTS，且 extension=php_pthreads.dll/.so 已加载）。
为什么 Web 环境下 pthreads + sleep() 几乎不可用
- Apache/Nginx + PHP-FPM 架构下，pthreads 被明确禁用（启动即报
Fatal error: Pthreads is not supported in this build of PHP），因为 FPM 进程模型与线程不兼容； - 即便强行启用（如 CLI SAPI），Web 请求响应周期内调用
sleep()仍会阻塞当前响应线程，导致 HTTP 超时、浏览器卡死，和单线程无异； - 更关键的是：
sleep()不释放内存锁或对象引用，在 pthreads 中若在线程间共享资源（如Stackable对象）并配合sleep()做轮询，极易引发竞态或死锁。
常见错误现象：Thread 挂起后，其他线程反复尝试获取已被持有锁的共享对象，最终全部阻塞或超时退出。
立即学习“PHP免费学习笔记（深入）”；
sleep() vs usleep() vs time_sleep_until() 怎么选
-
sleep()：单位秒，仅适合 ≥1 秒的粗粒度等待；参数必须是整数，sleep(0.5)等价于sleep(0)； -
usleep()：单位微秒（1e-6 秒），支持更精细控制，例如usleep(500000)≈ 半秒，多线程轮询场景更常用； -
time_sleep_until()：指定绝对时间点唤醒，适合需要对齐某时刻（如每分钟整点触发）的定时逻辑，但要注意传入时间必须大于当前microtime(true)，否则立即返回失败。
性能提示：频繁调用 usleep(1000)（1ms）不如改用事件循环或条件变量，否则大量上下文切换反而拖慢整体吞吐。
替代方案：别靠 sleep() 做协调，用线程原语更可靠
在真正需要线程协同的场景（比如生产者-消费者、任务分发），硬套 sleep() 是反模式：
- 使用
Cond（条件变量） +Mutex实现等待/通知机制； - 用
Pool+Worker+Stackable配合notify()/wait()，避免空转轮询； - 若只是“延后执行”，优先考虑外部调度（Cron、Redis Delayed Queue、ReactPHP 定时器）而非线程内休眠。
容易被忽略的一点：pthreads 的生命周期管理比普通脚本严格得多。一个 sleep() 后忘记 join() 或未处理异常退出，会导致僵尸线程残留，长期运行服务可能内存泄漏。
