workerman协程内存泄漏需及时干预，通过rss与memory_get_peak_usage(true)联合观测确认泄漏；用strace、gc_collect_cycles()和xdebug_debug_zval三步定位；重点检查静态变量、闭包捕获及协程取消机制；修复后需10分钟rss波动≤±500kb且峰值无跃升方可确认生效。
Workerman协程内存持续上涨会导致进程被OOM Killer强制杀死、连接拒绝、响应延迟飙升，必须在RSS值开始线性增长时立即介入，不能等服务崩溃才行动。
确认是否真泄漏而非正常增长
执行ps aux --sort=-%mem | grep php，挑出运行超5分钟的Worker进程，记录其RSS值（单位KB）；连续观测10分钟，若RSS每分钟涨超2MB且memory_get_peak_usage(true)打点同步攀升，则确认为泄漏。
若仅启动初期快速上涨后趋于平稳，大概率是opcache预热或连接缓冲区分配所致，非泄漏。
【不要依赖memory_get_usage()单次返回值】，它只反映脚本堆内存，完全无法体现闭包捕获、静态变量、底层扩展持有的“僵尸对象”。
定位泄漏源头的三步法
第一步：用strace -tt -p PID观察进程行为。若每秒刷出数十行epoll_pwait且返回值为0或毫秒级超时，说明事件循环空转——这往往不是业务代码问题，而是内核层面连接关闭风暴或全连接队列溢出引发的sys CPU高，需同步检查net.core.somaxconn和backlog配置。
第二步：在onMessage、onClose、定时器回调入口处插入gc_collect_cycles()并记录memory_get_peak_usage(true)，对比两次调用差值。若某次回调后峰值猛增5MB以上，该回调即为高危区。
第三步：对可疑对象执行xdebug_debug_zval($obj)（需启用Xdebug），重点看refcount是否异常高（如≥3）、is_ref是否为1。若一个TcpConnection对象refcount卡在4且无法下降，基本可断定它被闭包→类实例→静态数组三级强引用锁死。
高频泄漏点检查与修复
方法一：静态变量清理缺失
检查所有self::$connections、static $cache = []类定义，在onClose中是否执行unset(self::$connections[$connection->id])；【键必须是标量ID，绝不可用$connection对象本身作键】，否则unset()无效。
方法二：闭包隐式捕获
将Timer::add(1, function() use ($this) { })全部替换为Timer::add(1, [$this, 'tick'])或独立静态函数；【Timer::add传数组回调比匿名函数更危险——它给实例加了一条强引用链】。
方法三：协程未绑定取消机制
所有go(function () { ... })必须包裹try-catch，并在关键路径加入Swoole\Coroutine::defer()释放大对象；若使用PHP 8.0+，改用WeakMap替代静态数组存储连接上下文。
验证修复效果的操作路径
① 修改代码后重启Worker进程 →
② 等待进程稳定运行5分钟 →
③ 执行ps aux --sort=-%mem | grep php抓取当前RSS值 →
④ 每2分钟重复执行一次，持续记录10分钟 →
⑤ 若RSS波动范围始终控制在±500KB内，且memory_get_peak_usage(true)无阶梯式跃升，则修复生效。
