核心线程池的“无限等待”逻辑映射长连接常驻管理：$connection如核心线程长期持有、复用上下文、阻塞等待消息；需在onConnect初始化、onMessage读写、onClose清理状态；并用定时器模拟keepAliveTime做心跳超时关闭，配合连接数限流拒绝策略保障稳定性。
核心线程池的“无限等待”逻辑，本质上是让线程不退出、不销毁，持续从任务队列中取任务执行——这个特性，恰好可以映射到服务器端长连接的常驻处理需求：连接对象（如 $connection）不是一次用完就丢，而是长期持有、反复使用、状态可维护。
用核心线程类比连接对象，理解“常驻”本质
在 Workerman 或自研长连接服务中，每个活跃客户端对应一个 $connection 实例。它就像线程池里的一个核心线程：
- $connection 创建后不会自动释放，只要连接没断，它就一直存在内存里；
- 它携带自己的上下文（remoteIp、id、lastMessageTime、user_id 等），跨 onConnect/onMessage/onClose 回调复用；
- 就像核心线程调用 workQueue.take() 阻塞等待新任务，$connection 也在事件循环中“挂起”，等待下一条消息或心跳；
- 你不显式 close 它，它就不会消失；不清理关联资源（如 Redis 订阅、在线列表项），它就会持续占用内存。
把连接当“核心线程”来管理变量生命周期
服务端需主动为每个连接分配并维护一组常驻变量，不能依赖局部作用域或请求生命周期。关键做法包括：
- 在 onConnect 中初始化连接专属状态：$connection->user_id = $uid;、$connection->lastPing = time();、$connection->subscribedTopics = [];
- 在 onMessage 中直接读写这些属性，无需查表或重建上下文；
- 在 onClose 中统一释放：unset($onlineUsers[$connection->user_id]);、Redis::unsubscribe($connection->subscribedTopics);；
- 避免把连接状态存进全局数组却不索引清理——这就像开了线程却忘了回收，最终内存溢出。
用定时器模拟“keepAliveTime”做连接健康管控
线程池靠 keepAliveTime 控制非核心线程存活，而长连接靠心跳超时控制连接存活。两者逻辑一致：
- 服务端启动全局定时器（如 Timer::add(45, […])），遍历所有 $connection；
- 检查 $connection->lastMessageTime 是否超过阈值（如 60 秒）；
- 超时则调用 $connection->close()，触发 onClose 回调完成清理；
- 这个机制不依赖 HTTP Keep-Alive 头，也不靠客户端自觉——它是服务端自主的、强制的“连接 GC”。
拒绝策略 → 连接限流与降级逻辑
当连接数逼近系统瓶颈时，线程池用拒绝策略保护自身；长连接服务同样需要“连接拒绝”：
- 在 onConnect 回调开头判断当前总连接数是否超限；
- 若超限，直接 $connection->close() 并记录日志，不分配任何资源；
- 可配合返回特定错误码（如 "too_many_connections"），便于客户端做重试退避；
- 这相当于把 AbortPolicy 搬到了连接层——宁可拒掉新连接，也不让已连用户因资源争抢变卡顿。
