高频定时器应复用而非频繁创建销毁，改用单次长期定时器+状态切换，避免闭包捕获$this，优先使用静态方法或数组回调，并配合定期gc_collect_cycles()防止内存泄漏。
高频创建/销毁定时器会直接拖慢事件循环
Workerman 的 Timer::add() 和 Timer::del() 不是零成本操作。每次调用都会触发底层 swoole_timer_add() 或 swoole_timer_del()，涉及红黑树插入/删除、回调注册/解绑、内存分配等开销。当每秒新建+销毁数百个定时器时，事件循环线程会被频繁打断，CPU 花在管理定时器上远多于执行业务逻辑——你看到的“卡顿”或“延迟升高”，往往不是业务慢，而是定时器调度本身成了瓶颈。
用复用代替新建：把 Timer::add() 改成状态切换
绝大多数高频场景（如心跳检测、超时清理、滑动窗口计数）其实不需要“每次重开一个新定时器”，而是只需“重置倒计时”。正确做法是只创建一次定时器，通过变量控制行为：
- 用一个
static $timerId全局存当前有效定时器 ID，重复调用Timer::del($timerId)再Timer::add()是错的 - 改用单次长期运行的定时器（如 100ms 间隔），在回调里检查每个连接/任务的
last_active_time，超时则处理、不超时则跳过 - 需要差异化超时时间？把待检对象放进
SplMinHeap或按时间分桶的数组，主定时器只扫最近一批
闭包捕获 $this 是隐性性能杀手
写 Timer::add(1, function() { $this->handle(); }) 看似简洁，实际会让整个对象实例被强引用住，GC 无法回收，且每次回调都需重建作用域链。更糟的是，如果这个闭包在 onMessage 中反复定义，等于每条消息都生成一个新闭包函数——PHP 解析器要反复编译，内存碎片飙升。
- 必须绑定实例时，改用
Timer::add(1, [$this, 'handle'])，它不捕获上下文，开销低一个数量级 - 纯函数逻辑优先写成
static方法或独立函数，例如Timer::add(1, [MyClass::class, 'clearCache']) - 确认没有在定时器回调里
var_dump()、print_r()或打日志到文件——IO 阻塞会直接卡死整个 Worker 进程
用 gc_collect_cycles() 验证是否真有泄漏，别靠猜
高频定时器问题常和内存泄漏交织。你以为删了定时器就万事大吉，但若回调里曾引用过大数组、PDOStatement 或 SDK 实例，它们可能还挂在全局静态容器里。这时 memory_get_usage() 可能变化不大，但 gc_collect_cycles() 后暴增的释放量才是真相。
- 在
onClose或关键路径末尾加一行：if (function_exists('gc_collect_cycles')) gc_collect_cycles(); - 用
xdebug_debug_zval('your_object')查看可疑对象的refcount，refcount > 1 且你没主动引用，大概率是定时器闭包或静态属性在 hold 住它 - 禁用
gc_disable()—— Workerman 默认开启 GC，手动关掉等于让所有隐式引用永远不释放
