PHP垃圾回收是引用计数+周期检测的混合机制；refcount为0时仅非循环引用的zval立即释放；循环引用需GC周期检测清理，常驻进程中应适时调用gc_collect_cycles()。
PHP 的垃圾回收（GC）不是“用完就清”的即时释放机制，而是一套基于引用计数 + 周期检测的混合策略。它默认开启，但不会在每次 unset 后立刻归还内存——尤其在常驻进程（如 Swoole）中，不理解它的触发条件和边界，很容易积累不可见的内存泄漏。
refcount 为 0 时是否立即释放内存？
是，但仅限于「非循环引用」且「refcount 直接降为 0」的场景。比如：
$a = ['x' => 1]; $b = $a; unset($b); // $a 仍存在，refcount 从 2→1，不释放 unset($a); // refcount 从 1→0，底层立刻释放该 array 的 zval 和其内部元素
注意：这个释放只发生在 zval 的 refcount__gc 归零瞬间，且该 zval 类型必须是 IS_TYPE_REFCOUNTED（如 array、object、string）。整型、浮点等简单类型在 PHP7+ 中 refcount 恒为 0，不走 GC 流程。
-
unset($var)只是从符号表中移除变量名，并不保证立即释放内存——它只是让 refcount 减 1，是否释放取决于减后是否为 0 - 对
string使用unset，若该字符串是 interned string（如字面量'hello'），则refcount不变，根本不会进 GC 流程 - 函数返回后，所有局部变量 zval 的 refcount 自动减 1；若此时为 0，即刻释放
为什么 unset 之后内存没降？循环引用怎么破？
因为循环引用会让 refcount 永远 > 0，即使外部已无任何变量指向它们。典型例子：
立即学习“PHP免费学习笔记（深入）”；
$a = ['child' => null]; $b = ['parent' => null]; $a['child'] = $b; $b['parent'] = $a; unset($a, $b); // 两个 array 的 refcount 都为 1（彼此引用），无法靠 refcount 机制释放
这种结构会进入 GC 的「垃圾缓冲区」，等待周期性检测。但检测不是实时的，也不是每次 unset 都触发。
- PHP 的 GC 周期由
gc_collect_cycles()显式调用，或当垃圾缓冲区达到阈值（默认 10000 个节点）时自动触发 - 检测算法基于 »同步循环回收« 论文，能识别出上述嵌套引用构成的不可达环，然后批量清理
- 手动破环最可靠的方式仍是提前打断：比如在销毁前执行
$a['child'] = null; $b['parent'] = null;，让 refcount 归零 - 对象中使用
__destruct并不能替代 GC——它只在 refcount 为 0 时才被调用，对循环引用无效
gc_collect_cycles() 要不要主动调用？
在 CLI 或常驻进程（Swoole、Workerman）中，有必要，但不能滥用。
FPM 模式下通常不需要：请求结束时整个符号表连同所有 zval 一并销毁，GC 几乎不起作用；但在长生命周期脚本中，如果频繁构造深层嵌套数组或对象图，缓冲区可能长期不满，导致垃圾滞留数秒甚至更久。
- 每调用一次
gc_collect_cycles()，PHP 会暂停当前执行，遍历缓冲区做可达性分析，有明显 CPU 开销 - 建议在关键释放点（如大任务结束、协程退出前）调用一次，而非在循环内高频调用
- 可通过
gc_enabled()查看 GC 是否开启；用gc_status()观察缓冲区大小与已收集周期数 - 极端场景下可临时关闭 GC：
gc_disable()，但务必配对gc_enable()，否则后续无法回收循环垃圾
真正容易被忽略的是：GC 不处理 symbol_table 本身的膨胀，也不清理未被引用的全局变量名——它只管 zval 的 value 部分。如果你在循环中反复用动态键名写入全局数组，unset 掉值之后，符号表里那个 key 名字依然占位，直到脚本结束。
