PHP内存占用高不等于内存泄漏；常驻进程或CLI脚本中memory_get_usage()不回落，多因GC未触发或存在循环引用。unset()仅减refcount，ZendMM不立即归还内存给系统，故memory_get_usage()不变属正常；真泄漏需跨生命周期持续增长且gc_collect_cycles()无效。
PHP内存占用过高，不等于发生了内存泄漏；但若在常驻进程（如Swoole）中持续上涨、或 CLI 脚本反复执行后 memory_get_usage() 不回落，大概率是 GC 机制没被正确触发，或存在未破除的循环引用。
为什么 unset() 后 memory_get_usage() 没变
这是最常被误判为“内存没释放”的现象。实际上：unset($var) 只是让 zval 的 refcount__gc 减 1，若降为 0，则其 value（如数组哈希表、字符串内容）会立即释放——但 PHP 的内存分配器（ZendMM）不会立刻把这块内存还给操作系统，而是留在空闲池里复用。
-
memory_get_usage()返回的是 PHP 堆内已分配但未复用的字节数，不是 RSS - 想看真实向系统申请的内存页大小，要用
memory_get_usage(true) - FPM 模式下每次请求结束整个内存空间被销毁，所以该问题只在 CLI 或常驻进程中显著
循环引用导致的内存积压怎么破
当 $a->ref = $b 且 $b->ref = $a 时，两者 refcount 永远 ≥1，常规引用计数失效。这类结构会被暂存进 GC buffer，等待周期性扫描——但默认触发条件苛刻：buffer 满 10,000 个节点，或显式调用 gc_collect_cycles()。
- CLI 测试时，建议在关键循环末尾加
gc_collect_cycles()强制清理 - Swoole Worker 中，应在每次任务处理完后调用，避免跨请求累积
- 不要在高频小循环里滥用
gc_collect_cycles()，它有开销；优先用unset($a, $b)+ 手动断引用（如$a->ref = null）提前解环 - 对象属性中避免无意识的 self-reference，例如事件监听器里存了
$this
哪些变量根本不会触发 refcount 计数
PHP 7+ 对标量做了优化：int、bool、float、null 这些类型不参与引用计数，直接内联存储，refcount__gc 恒为 0。真正受 GC 影响的是以下五类：
立即学习“PHP免费学习笔记（深入）”；
-
string（长字符串才计数，短字符串走 interned string 优化） -
array（尤其嵌套深、元素多的数组） -
object（含属性、方法、闭包） -
resource（如文件句柄、PDOStatement） -
reference（PHP 7.4+ 的引用类型）
也就是说，$arr = [1, 2, 3] 占内存少且不进 GC 流程；但 $arr = array_fill(0, 10000, str_repeat('x', 1024)) 就会大量进 buffer，必须关注。
检测泄漏时别只盯 memory_get_usage
单靠 memory_get_usage() 容易漏掉“伪泄漏”：比如某次请求中创建了大数组又没 unset，下次请求就没了——这不算泄漏。真泄漏是跨生命周期持续增长，且 gc_collect_cycles() 也无法回收的部分。
- 用
xdebug_debug_zval()查看具体变量的refcount和is_ref状态（需启用 Xdebug） - 生成 cachegrind 文件，用
kcachegrind或qcachegrind分析内存分配热点 - CLI 下跑多次相同逻辑，观察
memory_get_usage(true)是否阶梯式上升 - 注意第三方扩展：某些 PECL 扩展（如旧版 redis、mongodb）在 C 层持有 PHP 对象却不减 refcount，会导致“消失的引用”
GC 不是魔法开关，它依赖你对变量生命周期的理解——尤其是对象间引用关系是否可被外部变量自然切断。写完 unset，记得确认有没有其他路径（如全局数组、静态属性、闭包 use）还在持有着它。
