PHP垃圾回收依赖引用计数（refcount）日常释放和循环检测（cycle collection）兜底；refcount为0时zval值立即释放，但内存不返操作系统；循环引用需gc_collect_cycles()触发扫描清除。
PHP 的垃圾回收（GC）不是“用完就清”的即时释放机制，它依赖两个层级：引用计数（refcount）主导日常回收，循环检测（cycle collection）兜底处理引用环。你写完 unset($var) 或函数退出后变量自然消失，大部分时候内存确实会松动，但不等于立刻还给操作系统——这点常被误认为“内存没释放”。
refcount 是怎么决定一个变量能否被回收的
每个 PHP 变量底层都存于 zval 结构中，其中 refcount__gc 字段记录当前有多少个符号（比如变量名、数组元素、对象属性）指向它。只要这个值降为 0，对应 value 就会被立即释放（比如字符串内容、数组哈希表内存）。
-
string、array、object、resource、reference这五类才参与 refcount；标量如int、bool在 PHP 7+ 中不计数，直接内联存储，refcount恒为 0 - 赋值时
$b = $a不复制数据，只让$b和$a共享同一个zval，refcount加 1 - 修改时触发“写时复制（copy-on-write）”：一旦
$b['key'] = 'new'，PHP 才真正复制一份zval给$b，原$a的refcount减 1 -
unset($a)不是“删内存”，而是从符号表中移除键，并将对应zval的refcount减 1；若此时为 0，value 立即释放
为什么 unset 后 memory_get_usage() 没变
这是最常被误解的一点：memory_get_usage() 返回的是 PHP 自己管理的堆内存用量，不是 OS 层面的 RSS。PHP 的内存分配器（如 emalloc）会向系统预申请大块内存，再自行切分复用。即使某个 zval 的 value 被释放了，这块内存大概率仍留在 PHP 的空闲池里，等待下一次分配，不会立刻交还 OS。
- 调用
gc_collect_cycles()强制触发一次完整 GC 循环，可能让memory_get_usage()下降更明显（尤其存在大量循环引用时） - 在 CLI 模式下反复测试时，建议加
true参数：memory_get_usage(true)查看真实分配的内存页大小 - FPM 模式下每次请求结束，整个请求内存空间会被整体销毁，所以无需手动干预；Swoole 常驻进程必须关注 refcount 和循环引用，否则内存只增不减
循环引用靠什么破局：gc_collect_cycles 的实际作用
当 $objA->ref = $objB 且 $objB->ref = $objA 时，两者 refcount 永远 ≥1，常规 refcount 机制失效。PHP 5.3+ 引入的周期性循环检测器会把疑似循环结构暂存进 GC buffer，等缓冲区满（默认 10,000 个节点）或显式调用 gc_collect_cycles() 时启动扫描。
立即学习“PHP免费学习笔记（深入）”；
- 扫描过程分两步：先对 buffer 中所有节点的
refcount减 1（模拟“去掉外部引用”），再检查哪些节点变成 0；为 0 的就是纯内部循环，标记为垃圾 - 该机制仅对
array和object生效，因为只有它们能形成引用闭环；string、int等无法持有其他变量引用 -
zend.enable_gc = 1（默认开启），但若确认业务绝无循环引用，可关掉以省去 buffer 维护开销 - 不要在热循环里频繁调用
gc_collect_cycles()，它本身有性能成本；优先靠设计规避循环引用（例如用 ID 替代对象引用）
真正容易被忽略的不是“怎么触发 GC”，而是 refcount 的隐式变化时机——比如函数返回数组时是否被赋值、foreach 中的 $v 是副本还是引用、json_encode() 是否产生新 zval。这些细节不靠 xdebug_debug_zval() 观察 refcount，几乎无法凭直觉判断内存归属。
