unset()不会立刻释放内存，仅断开变量名与zval的绑定；zval是否回收取决于引用计数是否归零及gc是否处理循环引用。
PHP的unset()到底有没有立刻释放内存
没有。调用unset($var)只是断开变量名到zval的绑定，zval本身是否被回收，取决于它的引用计数和循环引用状态。
常见错误现象：反复unset($bigArray)后memory_get_usage()几乎不变，误以为内存泄漏。
- 如果该zval还被其他变量、全局数组、闭包的
$this或静态属性引用，引用计数 > 0，zval继续存活 - 如果zval参与了循环引用（比如对象A→属性→对象B→属性→对象A），即使所有外部变量都被
unset()，引用计数也不会归零，必须靠GC周期介入 -
unset()后立即调用gc_collect_cycles()可强制触发一次回收（但不推荐在生产环境频繁调用）
PHP 7+ 的GC如何检测并清理循环引用
PHP 7起使用“同步周期性垃圾回收”：当根缓冲区（root buffer）满（默认10,000个zval）或显式调用gc_collect_cycles()时，GC启动三色标记流程。
使用场景：长期运行的CLI脚本、处理大量嵌套对象/数组时容易触发；Web请求中因生命周期短，多数情况GC根本没机会跑完一轮。
立即学习“PHP免费学习笔记（深入）”；
- GC只扫描疑似根节点（如数组、对象的zval，且refcount > 0但可能存在环）
- 它不遍历整个内存堆，而是从根缓冲区出发做深度优先搜索，标记“可达但refcount异常”的节点
- 性能影响：GC扫描本身有开销，但相比内存持续增长，权衡后默认开启更安全；可通过
zend_gc_disable()关闭（仅限确定无循环引用的极简场景）
gc_enable()和gc_disable()的实际效果边界
它们控制的是GC机制是否注册进执行周期，不是开关“内存是否回收”。即使gc_disable()，普通非循环引用的zval仍靠引用计数即时释放。
参数差异：gc_enable()可带一个整数参数，表示根缓冲区大小（单位：zval数量），默认10000；设太小会导致GC过于频繁，设太大则延迟回收风险升高。
- Web SAPI下，每次请求结束会自动清空根缓冲区并可能触发GC——所以
gc_disable()在fpm里基本无效 - CLI模式下禁用GC后，若存在循环引用，内存只会随脚本退出才释放，中间可能OOM
- 检查当前状态用
gc_enabled()，返回bool；查已收集周期数用gc_status()['collected']
什么时候该怀疑是GC没起作用，而不是代码写错了
当观察到：memory_get_usage(true)（真实分配量）持续上涨，且gc_status()显示roots长期非零、collected长时间为0，同时排除了未unset()的显式引用。
容易踩的坑：把__destruct()当成内存释放钩子——它只保证对象逻辑销毁，不等于zval被回收；zval能否回收，仍由引用计数和GC决定。
- 用
xdebug_debug_zval('var_name')查看refcount和is_ref，确认是否真被孤立 - 用
gc_collect_cycles()手动触发后对比memory_get_usage()变化，判断是否卡在循环引用上 - 对象属性中存了
$this引用、静态数组缓存了对象、Closure绑定到对象实例，都是典型隐式循环来源
GC不是万能的，它只解决“引用计数无法处理的环”，而大多数内存问题其实来自忘了unset()大变量、或意外延长了变量作用域。真要调GC，先确认是不是自己的引用链设计出了问题。
