PHP通过引用计数实时释放内存，并在PHP 5.3+引入循环垃圾回收器，利用根缓冲区和标记-清除算法周期性识别并清理循环引用，防止内存泄漏。
PHP的垃圾回收机制，核心在于其Zend引擎对内存的精妙管理，它主要通过“引用计数”来追踪变量的使用情况，当一个变量的引用计数归零时，其占用的内存便会被立即释放。然而，为了解决引用计数无法处理的“循环引用”问题，PHP 5.3及更高版本引入了一套复杂的“循环垃圾回收”算法，它能周期性地识别并清理那些相互引用但已不再被程序其他部分访问的对象，从而有效防止内存泄漏。在我看来，这套机制是PHP能够高效运行、同时又保持开发便捷性的关键基石。
解决方案
PHP的垃圾回收机制，其基石是引用计数（Reference Counting）。每个Zval（PHP内部存储变量的结构）都有一个refcount字段，记录有多少个变量指向它。每当一个变量被赋值、作为参数传递或被添加到数组/对象中时，refcount就会增加；当变量超出作用域、被unset()或被重新赋值时，refcount就会减少。一旦refcount降到0，就意味着这个变量不再被任何地方引用，其内存会立即被释放。这种机制简单高效，对于大多数情况都表现良好，内存释放是实时的。
然而，引用计数有一个致命的缺陷：循环引用（Circular References）。想象一下，如果对象A引用了对象B，而对象B又引用了对象A。即使外部已经没有其他变量引用A或B，它们的refcount也永远不会降到0，因为它们内部还在相互引用。这就会导致内存泄漏。
为了解决这个问题，PHP 5.3引入了循环垃圾回收器（Generational Garbage Collector）。它的工作原理是：
立即学习“PHP免费学习笔记（深入）”；
收集潜在垃圾：当一个Zval的refcount从1降到0时，它通常会被立即销毁。但如果refcount从大于1降到1，说明它可能是一个循环引用的一部分，因为它现在只被自己或它所在的循环引用。这样的Zval会被放入一个“根缓冲区”（root buffer）。周期性检查：当根缓冲区达到一定数量（默认是10,000个Zval）时，垃圾回收器就会被触发运行。标记阶段：垃圾回收器会遍历根缓冲区中的所有Zval。对于每一个Zval，它会尝试性地将其以及其引用的所有对象的refcount减1。如果减1后某个Zval的refcount降到了0，说明它是一个孤立的、没有外部引用的对象，可以被回收。如果减1后refcount仍然大于0，说明它还有外部引用，或者它是一个循环引用的一部分但外部引用计数大于1。清理阶段：所有被标记为可回收的Zval（即那些临时减1后refcount变为0的）都会被销毁，其内存被释放。那些临时减1后refcount仍然大于0的Zval，其refcount会被恢复到原来的值。
这个循环垃圾回收器不是实时运行的，它有自己的触发机制，而且运行起来会消耗一定的CPU资源，因为它需要遍历和修改引用计数。因此，PHP提供了gc_enable()、gc_disable()和gc_collect_cycles()等函数，允许开发者手动控制其行为。默认情况下，它是开启的。
PHP的垃圾回收机制是如何解决循环引用问题的？
PHP在处理循环引用时，确实不能简单地依赖引用计数，因为相互引用的对象即便外部不再使用，它们的引用计数也永远不会归零。解决这个问题的核心在于其“循环垃圾回收器”的巧妙设计，它主要通过一个“标记-清除”的变种算法来识别并处理这些顽固的内存块。
当一个变量的引用计数从大于1降到1时，PHP引擎会将其视为潜在的循环引用成员，并将其放入一个特殊的“根缓冲区”（root buffer）。这个缓冲区不是无限大的，当它积累到一定数量（例如，默认是10,000个Zval）时，垃圾回收器就会被激活。
接下来是关键的“标记”过程：回收器会遍历根缓冲区中的每一个Zval。对于每个Zval，它会沿着其内部的引用链条（比如对象属性、数组元素）进行深度优先遍历，并对所有遇到的Zval进行一个临时性的引用计数减一操作。这个操作是试探性的，并非真的释放内存。在遍历过程中，如果一个Zval的引用计数在临时减一后变为0，那么它就被标记为“灰色”，意味着它可能是垃圾的一部分。如果减一后仍然大于0，它就被标记为“黑色”，表示它仍然有外部引用，或者它是一个循环引用的一部分但外部引用计数仍大于1，暂时不能被回收。完成所有遍历和临时减一后，回收器会再次检查那些被标记为“灰色”的Zval。如果一个“灰色”Zval在整个过程中，其内部引用的对象也都被标记为“灰色”且其引用计数最终降到了0，那么这个Zval及其所属的整个循环链条就被确定为真正的垃圾。
最后是“清除”阶段：所有被确定为垃圾的Zval及其内部的引用关系都会被彻底解除，内存被释放。而那些在临时减一后引用计数仍大于0的Zval，它们的引用计数会被恢复到原来的值，并从根缓冲区中移除，等待下一次可能的检查。
这个过程虽然比简单的引用计数复杂，但它确保了即使存在循环引用，那些不再被程序其他部分访问的内存也能最终被回收，避免了长期运行的PHP应用出现内存泄漏。它并不是实时运行的，而是周期性地执行，以平衡性能开销和内存管理效率。
开发者在日常编码中应该如何优化PHP的内存使用，以配合垃圾回收机制？
尽管PHP的垃圾回收机制很强大，但作为开发者，我们依然可以通过一些编码习惯来主动优化内存使用，这不仅能减轻垃圾回收器的负担，还能提升应用的整体性能和稳定性。这不仅仅是“让GC工作”那么简单，更多的是“让GC工作得更轻松，甚至避免它做不必要的工作”。
我个人在写PHP代码时，会特别关注以下几点：
及时unset()不再需要的变量： 这是最直接有效的手段。尤其是对于大型数组、对象或资源句柄，当它们完成使命后，立即使用unset()来解除引用。这会立即将变量的引用计数降下来，如果降到0，内存就会被立即释放，而不是等到垃圾回收器周期性检查。这对于长生命周期的脚本（如CLI脚本、队列处理器）尤为重要，可以显著降低峰值内存占用。比如，处理完一个巨大的CSV文件后，unset($csvData)就很有必要。
警惕并规避不必要的循环引用： 虽然GC能处理循环引用，但如果能从设计上就避免它们，那自然是最好的。在设计对象模型时，要审视对象之间的相互引用关系。例如，如果对象A需要引用B，B也需要引用A，可以考虑是否可以通过传递参数、事件监听器或者引入一个中间的协调者来打破这种直接的循环。如果循环引用是业务逻辑的必然，那也没关系，GC会处理，但我们至少要有所意识。
限制全局变量和静态变量的使用： 全局变量和静态变量的生命周期通常与整个请求或脚本的生命周期一样长，它们引用的对象会一直存在，直到脚本结束。如果这些变量持有大量数据或复杂对象，它们会长时间占用内存，并且可能成为循环引用的根源。能用局部变量解决的问题，就不要用全局或静态变量。
分块处理大数据集： 当需要处理大量数据（如从数据库查询数万条记录，或处理大型文件）时，不要一次性将所有数据加载到内存中。使用迭代器、生成器（yield关键字）或者分批查询（LIMIT和OFFSET）的方式，每次只处理一小部分数据，处理完就释放。这样可以把内存占用控制在一个很低的水平。
合理管理资源句柄： 数据库连接、文件句柄、网络套接字等资源，虽然PHP会在脚本结束时自动关闭，但在长时间运行的脚本中，如果忘记及时关闭，可能会导致资源耗尽。使用fclose()、mysqli_close()等函数，或者利用try-finally结构确保资源在不再需要时被释放。
利用工具进行内存分析： 不要盲目优化。当遇到内存问题时，使用Xdebug的内存分析功能或者memory_get_usage()、memory_get_peak_usage()函数来定位内存热点。这些工具能告诉你哪些代码段消耗了大量内存，从而有针对性地进行优化。
通过这些实践，我们能够编写出更高效、更健壮的PHP应用，让PHP的垃圾回收机制在幕后默默地发挥作用，而不需要我们过多地干预。
PHP垃圾回收机制对应用性能有哪些潜在影响，以及如何进行权衡？
PHP的垃圾回收机制，尤其是那个用于处理循环引用的循环垃圾回收器，对应用性能确实存在一些潜在影响，理解这些影响并学会权衡，对于构建高性能的PHP应用至关重要。
首先，引用计数本身的开销极低。每次变量的赋值、传递或unset()操作，都会伴随着refcount的增减。这个操作非常轻量，通常不会成为性能瓶颈。它最大的优点是内存释放的即时性，这避免了内存长时间占用。
然而，循环垃圾回收器的运行会带来性能开销。当根缓冲区积累到一定数量的Zval时（默认是10,000个），垃圾回收器就会被触发。它的工作流程包括遍历根缓冲区、深度优先遍历对象引用链、临时修改引用计数、恢复引用计数或释放内存等步骤。这个过程是CPU密集型的，而且在执行期间，PHP脚本的正常执行会被“暂停”或“阻塞”一小段时间，这被称为“Stop-the-World”效应。虽然这个暂停时间通常很短（微秒级到毫秒级），但在高并发、低延迟要求的场景下，频繁或长时间的垃圾回收可能会导致请求响应时间波动，甚至出现性能尖刺。
内存消耗也是一个考量点。根缓冲区本身需要占用内存来存储那些潜在的垃圾Zval。此外，由于循环垃圾回收器不是实时运行的，那些形成循环引用的垃圾对象可能会在内存中停留一段时间，直到下一次垃圾回收周期被触发并清理。这意味着在某些峰值时刻，应用的内存占用可能会略高于理想状态。
那么，我们该如何进行权衡呢？
默认开启zend.enable_gc是明智之举： 绝大多数情况下，我们应该保持zend.enable_gc = 1（默认开启）。虽然它有性能开销，但相比于禁用它可能导致的内存泄漏，这个开销是完全值得的。内存泄漏会导致应用长期运行后内存耗尽，最终崩溃，这远比短时间的性能波动更具破坏性。
手动触发gc_collect_cycles()要谨慎： 在Web应用中，一个请求的生命周期通常很短，脚本执行完毕后，所有内存都会被释放，所以手动调用gc_collect_cycles()通常是不必要的，甚至可能适得其反，因为你强制执行了一个可能很昂贵的CPU密集型操作，而此时系统可能并不需要它。但在一些长生命周期的脚本（如CLI脚本、守护进程、队列处理器）中，如果发现内存持续增长且无法通过unset()等方式有效控制，那么在关键的、内存密集型操作之后，适当地调用gc_collect_cycles()来主动清理内存，可以有效防止内存泄漏和内存耗尽。但这需要通过性能分析来验证其效果，而不是凭空猜测。
优化代码以减少垃圾产生： 最好的垃圾回收是避免产生垃圾。遵循前面提到的内存优化建议，如及时unset()、避免不必要的循环引用、分块处理大数据等，可以显著减少需要垃圾回收器处理的对象数量，从而降低其运行频率和开销。
关注gc.collect_interval配置： 这个配置决定了根缓冲区达到多少个Zval时触发垃圾回收。默认值通常是10,000。如果你的应用内存占用极高且有大量短生命周期的对象，可以尝试调整这个值。但同样，这需要通过实际测试来验证，不当的调整可能导致更频繁的GC运行，反而降低性能。
总的来说，对于大多数PHP Web应用而言，PHP垃圾回收机制的默认设置是经过优化的，能够很好地平衡内存管理和性能。我们不应该过度地去“调优”垃圾回收器，而是应该将重心放在编写高效、内存友好的代码上。只有当通过专业的性能分析工具（如Xdebug、Blackfire）明确指出垃圾回收是性能瓶颈时，才需要考虑深入调整GC相关的配置或手动触发。在没有数据支撑的情况下，过早或不当的GC优化往往会带来更多的麻烦。
以上就是PHP源码垃圾回收机制_PHP源码垃圾回收机制分析的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1321118.html
微信扫一扫 
支付宝扫一扫 
