PHP5.3循环引用回收依赖根缓冲区阈值（默认10000），未满则不触发；PHP7取消标量zval的refcount，降低开销；PHP8 JIT可提前识别不可达临时变量，使GC更及时。
PHP5.3的循环引用回收靠缓冲区阈值触发
PHP5.3首次引入周期回收器，但它的触发完全依赖根缓冲区（root buffer）是否填满，默认阈值是10,000个疑似垃圾节点。这意味着：即使内存中已存在大量无法访问的循环引用对象，只要缓冲区没满，gc_collect_cycles()就不会自动运行。
常见错误现象包括：长时间运行的CLI脚本内存持续上涨、Web请求中大数组嵌套引用后内存不回落。这不是代码写错了，而是回收还没被“轮到”。
- 可通过
gc_status()查看当前缓冲区使用量（PHP7+才支持该函数，PHP5.3需用gc_enabled()+ 估算） - 手动调用
gc_collect_cycles()能强制清理，但频繁调用会带来明显性能抖动 - 调整阈值用
gc_set_threshold(5000)可提前触发，但会增加CPU开销
PHP7取消标量zval的refcount，大幅降低计数开销
PHP7重构了zval结构，整数、浮点数、布尔值、NULL等标量类型不再需要独立分配内存，也不再维护refcount字段。这直接消除了大量无意义的计数操作。
典型影响场景：循环中反复赋值字符串或数字（如 $i++、$str .= "x"），在PHP5中每次赋值都涉及refcount增减；PHP7中这些操作几乎零开销。
立即学习“PHP免费学习笔记（深入）”；
- 复杂类型（数组、对象、资源）仍保留自身refcount，由其结构体内部管理
-
xdebug_debug_zval()在PHP7中对标量显示refcount=0或不显示refcount，不是bug，是设计变更 - 升级到PHP7后，旧代码里为“优化refcount”做的
unset()对小变量已无必要
PHP8的JIT与GC协同降低临时对象压力
PHP8引入JIT编译器后，部分短生命周期的中间变量（如函数返回值、匿名函数闭包中的临时值）能被更早识别为“不可达”，从而更快进入回收队列。这不是GC算法变了，而是JIT让引擎更早知道哪些值“活不过下一条指令”。
但注意：JIT默认不启用，且仅对特定opcode模式生效（如opcache.jit_buffer_size > 0）。未开启JIT时，PHP8的GC行为与PHP7基本一致。
- 开启JIT后，
memory_get_usage()峰值通常下降5%–15%，尤其在密集数学计算或模板渲染场景 -
gc_status()中的collected字段增长更平滑，说明回收更分散、更及时 - JIT不改变循环引用检测逻辑，
gc_collect_cycles()依然必要，只是触发频次可能略降
生产环境调优必须避开的三个惯性操作
很多团队沿用PHP5时代的“经验”，在PHP7/8中反而引发反效果：
- 在循环末尾对局部变量狂打
unset($arr)—— PHP7+已自动分离，且标量无refcount，纯属冗余操作 - 全局启用
gc_enable()并高频调用gc_collect_cycles()—— 现代PHP默认已开启GC，手动干预只在明确检测到循环引用泄漏时才需 - 为“省内存”把大数组拆成多个小数组再
unset—— 实际上PHP的内存池管理更倾向保留连续块，频繁释放小块反而加剧碎片
真正有效的做法是：用 gc_status() 定期采样，关注 roots 和 collected 的差值；发现长期不降的 roots，再用 xdebug_debug_zval() 或 php-meminfo 定位具体变量结构。
