傳統上，像以前的 php 用到的引用計數內存機制，無法處理循環(huán)的引用內存泄漏。然而 5.3.0 PHP 使用文章? 引用計數系統中的同步周期回收(Concurrent Cycle Collection in Reference Counted Systems)中的同步算法，來處理這個內存泄漏問題。

對算法的完全說明有點超出這部分內容的范圍，將只介紹其中基礎部分。首先，我們先要建立一些基本規(guī)則，如果一個引用計數增加，它將繼續(xù)被使用，當然就不再在垃圾中。如果引用計數減少到零，所在變量容器將被清除(free)。就是說，僅僅在引用計數減少到非零值時，才會產生垃圾周期(garbage cycle)。其次，在一個垃圾周期中，通過檢查引用計數是否減1，并且檢查哪些變量容器的引用次數是零，來發(fā)現哪部分是垃圾。

為避免不得不檢查所有引用計數可能減少的垃圾周期，這個算法把所有可能根(possible roots 都是zval變量容器),放在根緩沖區(qū)(root buffer)中(用紫色來標記)，這樣可以同時確保每個可能的垃圾根(possible garbage root)在緩沖區(qū)中只出現一次。僅僅在根緩沖區(qū)滿了時，才對緩沖區(qū)內部所有不同的變量容器執(zhí)行垃圾回收操作。看上圖的步驟 A。

在步驟 B 中，算法使用深度優(yōu)先搜索查找所有可能的根，找到后將每個變量容器中的引用計數減“1'，為確保不會對同一個變量容器減兩次'1'，用灰色標記已減過“1”的。在步驟 C 中，算法再一次對每個根節(jié)點使用深度優(yōu)先搜索，檢查每個變量容器的引用計數。如果引用計數是 0 ，變量容器用白色來標記（圖中的藍色）。如果引用次數大于0，則恢復在這個點上使用深度優(yōu)先搜索而將引用計數減”1“的操作（即引用計數加“1”），然后將它們重新用黑色標記。在最后一步 D 中，算法遍歷根緩沖區(qū)以從那里刪除變量容器根(zval roots)，同時，檢查是否有在上一步中被白色標記的變量容器。每個被白色標記的變量容器都被清除。

現在，你已經對這個算法有了基本了解，我們回頭來看這個如何與PHP集成。默認的，PHP的垃圾回收機制是打開的，然后有個 php.ini 設置允許你修改它：zend.enable_gc。

當垃圾回收機制打開時，每當根緩存區(qū)存滿時，就會執(zhí)行上面描述的循環(huán)查找算法。根緩存區(qū)有固定的大小，可存10,000個可能根,當然你可以通過修改PHP源碼文件Zend/zend_gc.c中的常量GC_ROOT_BUFFER_MAX_ENTRIES，然后重新編譯PHP，來修改這個10,000值。當垃圾回收機制關閉時，循環(huán)查找算法永不執(zhí)行，然而，可能根將一直存在根緩沖區(qū)中，不管在配置中垃圾回收機制是否激活。

當垃圾回收機制關閉時，如果根緩沖區(qū)存滿了可能根，更多的可能根顯然不會被記錄。那些沒被記錄的可能根，將不會被這個算法來分析處理。如果他們是循環(huán)引用周期的一部分，將永不能被清除進而導致內存泄漏。

即使在垃圾回收機制不可用時，可能根也被記錄的原因是，相對于每次找到可能根后檢查垃圾回收機制是否打開而言，記錄可能根的操作更快。不過垃圾回收和分析機制本身要耗不少時間。

除了修改配置zend.enable_gc ，也能通過分別調用 gc_enable() 和 gc_disable()函數來打開和關閉垃圾回收機制。調用這些函數，與修改配置項來打開或關閉垃圾回收機制的效果是一樣的。即使在可能根緩沖區(qū)還沒滿時，也能強制執(zhí)行周期回收。你能調用 gc_collect_cycles()函數達到這個目的。這個函數將返回使用這個算法回收的周期數。

允許打開和關閉垃圾回收機制并且允許自主的初始化的原因，是由于你的應用程序的某部分可能是高時效性的。在這種情況下，你可能不想使用垃圾回收機制。當然，對你的應用程序的某部分關閉垃圾回收機制，是在冒著可能內存泄漏的風險，因為一些可能根也許存不進有限的根緩沖區(qū)。因此，就在你調用 gc_disable()函數釋放內存之前，先調用 gc_collect_cycles()函數可能比較明智。因為這將清除已存放在根緩沖區(qū)中的所有可能根，然后在垃圾回收機制被關閉時，可留下空緩沖區(qū)以有更多空間存儲可能根。