PHP常驻进程GC卡主线程是因为其同步单线程全量标记-清除机制，触发时工作线程必须停等GC完成；gc_collect_cycles()调用后出现消息延迟、心跳超时、CPU尖峰及memory_get_usage()骤降，根源在于根缓冲区满（默认10000节点）或gc_probability设置过高导致频繁强制扫描。
PHP常驻进程里GC触发时为什么卡主线程
因为PHP的GC是同步、单线程、全量标记-清除式执行，一旦启动，当前工作线程必须停在原地等它跑完。这不是“后台悄悄收垃圾”，而是像突然按了暂停键——所有逻辑（包括WebSocket消息分发、HTTP响应生成、定时任务）全部冻结。
gc_collect_cycles()调用后卡顿的典型表现
你手动调用gc_collect_cycles()或系统按gc_probability自动触发时，会观察到：
- WebSocket服务出现毫秒级消息延迟（比如广播延迟从 2ms 突增至 150ms）
- 长连接心跳响应超时，客户端频繁重连
-
memory_get_usage()返回值瞬间回落，但紧随其后出现 CPU 占用尖峰（GC标记阶段密集计算） - 日志中出现连续多条
gc_collect_cycles(): 1248 cycles collected，且时间戳高度集中
为什么默认gc_probability=1反而更容易卡
这个参数不是“每1次请求触发1次GC”，而是“每次请求有1/1000000概率触发”。但很多项目在常驻进程中把它设成100甚至1000，结果变成平均每百次请求就扫一次——而每次扫描都要遍历整个根缓冲区（root buffer），检查所有疑似循环引用的zval结构。缓冲区越大、对象越复杂，耗时越不可控。
更麻烦的是：GC过程本身也会分配临时内存（比如构建标记栈），可能触发嵌套GC，形成雪崩。
立即学习“PHP免费学习笔记（深入）”；
真正影响卡顿的不是GC频率，而是根缓冲区大小
PHP用gc_collect_cycles()前，先要把待检测对象塞进根缓冲区。这个缓冲区默认大小是 10,000 个zval（由zend_gc_globals.gc_root_buffer_length控制）。一旦缓冲区满，PHP会立即强制触发GC——哪怕离上次才过去100ms。
所以高频卡顿往往源于：
- 大量短生命周期对象反复创建又不及时
unset（比如在for循环里不断new对象并赋给数组） - 全局静态数组持续追加未清理（如
$GLOBALS['cache'][] = $obj） - 使用
__destruct但内部又创建新引用，导致对象无法被快速释放
这些行为会让根缓冲区“提前爆满”，比gc_probability设置更危险。
GC卡顿最隐蔽的地方在于：它不报错、不抛异常，只让系统间歇性“吸一下气”。排查时别只盯着gc_enable()开关，先用gc_status()看roots和collected字段的变化节奏，再结合memory_get_peak_usage()确认是否在GC前后出现陡降——这才是真凶浮现的信号。
