https://mp.weixin.qq.com/s/D3hc03Wqz3aDuabHH2C46g
总结了一下，大概率的三点：
1 coder一欠妥心写了个会导致内存泄露的方法，例子我不举了，网上搜索一大把。
2 php-fpm内存设定值过小，swoole框架表明利用过多，导致内存注入了太多内容，一样平常人都引发不了这问题，此时只须要调大php-fpm默认配置内存即可。
3 gc不及时导致，无cli的swoole没开释内存给系统，我关心的是这最不起眼的点，个中涉及到一个方法php gc_mem_caches(), php版本>7后支持。
搜索了一个这个方法，确实阐明少得可怜，如下:
(PHP 7, PHP 8)
gc_mem_caches — Reclaims memory used by the Zend Engine memory manager
查查php内存干系的文章吧
实在这个引用计数早就不是啥新鲜事了，有兴趣理解其上风与毛病的，链接为你准备好了
https://bk.tw.lvfukeji.com/wiki/%E5%BC%95%E7%94%A8%E8%AE%A1%E6%95%B0
OK回归正题
PHP Garbage Collection 第一篇 阐明引用计数基本知识每个php变量存在一个叫"zval"的变量容器中。一个zval变量容器，除了包含变量的类型和值，还包括两个字节的额外信息。第一个是"is_ref"，是个bool值，用来标识这个变量是否是属于引用凑集(reference set)。通过这个字节，php引擎才能把普通变量和引用变量区分开来，由于php许可用户通过利用&来利用自定义引用，zval变量容器中还有一个内部引用计数机制，来优化内存利用。第二个额外字节是"refcount"，用以表示指向这个zval变量容器的变量(也称符号即symbol)个数。所有的符号存在一个符号表中，个中每个符号都有浸染域(scope)，那些主脚本(比如：通过浏览器要求的的脚本)和每个函数或者方法也都有浸染域。
当一个变量被赋常量值时，就会天生一个zval变量容器，如下例这样：
示例 #1 天生一个新的zval容器
<?php$a="newstring";?>在上例中，新的变量a，是在当前浸染域中天生的。并且天生了类型为 string 和值为new string的变量容器。在额外的两个字节信息中，"is_ref"被默认设置为 false，由于没有任何自定义的引用天生。"refcount" 被设定为 1，由于这里只有一个变量利用这个变量容器. 把稳到当"refcount"的值是1时，"is_ref"的值总是false. 如果你已经安装了» Xdebug，你能通过调用函数 xdebug_debug_zval()显示"refcount"和"is_ref"的值。
示例 #2 显示zval信息
<?phpxdebug_debug_zval('a');?>以上例程会输出：
a: (refcount=3, is_ref=0)='new string'a: (refcount=1, is_ref=0)='new string'把一个变量赋值给另一变量将增加引用次数(refcount).
示例 #3 增加一个zval的引用计数
<?php$a="newstring";$b=$a;xdebug_debug_zval('a');?>以上例程会输出：
a: (refcount=3, is_ref=0)='new string'a: (refcount=1, is_ref=0)='new string'这时，引用次数是2，由于同一个变量容器被变量 a 和变量 b关联.当没必要时，php不会去复制已天生的变量容器。变量容器在”refcount“变成0时就被销毁. 当任何关联到某个变量容器的变量离开它的浸染域(比如：函数实行结束)，或者对变量调用了函数 unset()时，”refcount“就会减1，下面的例子就能解释:
示例 #4 减少引用计数
<?php$a="newstring";$c=$b=$a;xdebug_debug_zval('a');unset($b,$c);xdebug_debug_zval('a');?>以上例程会输出：
a: (refcount=3, is_ref=0)='new string'a: (refcount=1, is_ref=0)='new string'如果我们现在实行 unset($a);，包含类型和值的这个变量容器就会从内存中删除。
复合类型(Compound Types)当考虑像 array和object这样的复合类型时，事情就轻微有点繁芜. 与 标量(scalar)类型的值不同，array和 object类型的变量把它们的成员或属性存在自己的符号表中。这意味着下面的例子将天生三个zval变量容器。
示例 #5 Creating a array zval
<?php$a=array('meaning'=>'life','number'=>42);xdebug_debug_zval('a');?>以上例程的输出类似于：
a: (refcount=1, is_ref=0)=array ( 'meaning' => (refcount=1, is_ref=0)='life', 'number' => (refcount=1, is_ref=0)=42)图示:
Creating a array zval
这三个zval变量容器是: a，meaning和 number。增加和减少”refcount”的规则和上面提到的一样. 下面, 我们在数组中再添加一个元素,并且把它的值设为数组中已存在元素的值:
示例 #6 添加一个已经存在的元素到数组中
<?php$a=array('meaning'=>'life','number'=>42);$a['life']=$a['meaning'];xdebug_debug_zval('a');?>以上例程的输出类似于：
a: (refcount=1, is_ref=0)=array ( 'meaning' => (refcount=2, is_ref=0)='life', 'number' => (refcount=1, is_ref=0)=42, 'life' => (refcount=2, is_ref=0)='life')图示：
从以上的xdebug输出信息，我们看到原有的数组元素和新添加的数组元素关联到同一个"refcount"2的zval变量容器. 只管 Xdebug的输出显示两个值为'life'的 zval 变量容器，实在是同一个。 函数xdebug_debug_zval()不显示这个信息，但是你能通过显示内存指针信息来看到。
删除数组中的一个元素，便是类似于从浸染域中删除一个变量. 删除后,数组中的这个元素所在的容器的“refcount”值减少，同样，当“refcount”为0时，这个变量容器就从内存中被删除，下面又一个例子可以解释：
示例 #7 从数组中删除一个元素
<?php$a=array('meaning'=>'life','number'=>42);$a['life']=$a['meaning'];unset($a['meaning'],$a['number']);xdebug_debug_zval('a');?>以上例程的输出类似于：
a: (refcount=1, is_ref=0)=array ( 'life' => (refcount=1, is_ref=0)='life')现在，当我们添加一个数组本身作为这个数组的元素时，事情就变得有趣，下个例子将解释这个。例中我们加入了引用操作符，否则php将天生一个复制。
示例 #8 把数组作为一个元素添加到自己
<?php$a=array('one');$a[]=&$a;xdebug_debug_zval('a');?>以上例程的输出类似于：
a: (refcount=2, is_ref=1)=array ( 0 => (refcount=1, is_ref=0)='one', 1 => (refcount=2, is_ref=1)=...)图示：
能看到数组变量 (a) 同时也是这个数组的第二个元素(1) 指向的变量容器中“refcount”为 2。上面的输出结果中的"..."解释发生了递归操作, 显然在这种情形下意味着"..."指向原始数组。
跟刚刚一样，对一个变量调用unset，将删除这个符号，且它指向的变量容器中的引用次数也减1。以是，如果我们在实行完上面的代码后，对变量$a调用unset, 那么变量 $a 和数组元素 "1" 所指向的变量容器的引用次数减1, 从"2"变成"1". 下例可以解释:
示例 #9 Unsetting $a
(refcount=1, is_ref=1)=array ( 0 => (refcount=1, is_ref=0)='one', 1 => (refcount=1, is_ref=1)=...)图示：
清理变量容器的问题(Cleanup Problems)
只管不再有某个浸染域中的任何符号指向这个构造(便是变量容器)，由于数组元素“1”仍旧指向数组本身，以是这个容器不能被打消 。由于没有其余的符号指向它，用户没有办法打消这个构造，结果就会导致内存泄露。光彩的是，php将在脚本实行结束时打消这个数据构造，但是在php打消之前，将耗费不少内存。如果你要实现剖析算法，或者要做其他像一个子元素指向它的父元素这样的事情，这种情形就会常常发生。当然，同样的情形也会发生在工具上，实际上工具更有可能涌现这种情形，由于工具总是隐式的被引用。
如果上面的情形发生仅仅一两次倒没什么，但是如果涌现几千次，乃至几十万次的内存泄露，这显然是个大问题。这样的问题每每发生在永劫光运行的脚本中，比如要求基本上不会结束的守护进程(deamons)或者单元测试中的大的套件(sets)中。后者的例子：在给巨大的eZ(一个有名的PHP Library) 组件库的模板组件做单元测试时，就可能会涌现问题。有时测试可能须要耗用2GB的内存，而测试做事器很可能没有这么大的内存。
文章引用：php.net官网
https://www.php.net/manual/zh/features.gc.refcounting-basics.php
