PHP内核探索：新垃圾回收机制说明
在5.2及更早版本的PHP中，沒有專門的垃圾回收器GC（Garbage Collection），引擎在判斷一個變量空間是否能夠被釋放的時候是依據(jù)這個變量的zval的refcount的值，如果refcount為0，那么變量的空間可以被釋放，否則就不釋放，這是一種非常簡單的GC實現(xiàn)。然而在這種簡單的GC實現(xiàn)方案中，出現(xiàn)了意想不到的變量內(nèi)存泄漏情況（Bug:http://bugs.php.net/bug.php?id=33595），引擎將無法回收這些內(nèi)存，于是在PHP5.3中出現(xiàn)了新的GC，新的GC有專門的機制負責清理垃圾數(shù)據(jù)，防止內(nèi)存泄漏。本文將詳細的闡述PHP5.3中新的GC運行機制。
目前很少有詳細的資料介紹新的GC，本文將是目前國內(nèi)最為詳細的從源碼角度介紹PHP5.3中GC原理的文章。其中關(guān)于垃圾產(chǎn)生以及算法簡介部分由筆者根據(jù)手冊翻譯而來，當然其中融入了本人的一些看法。手冊中相關(guān)內(nèi)容：Garbage Collection
什么算垃圾
首先我們需要定義一下“垃圾”的概念，新的GC負責清理的垃圾是指變量的容器zval還存在，但是又沒有任何變量名指向此zval。因此GC判斷是否為垃圾的一個重要標準是有沒有變量名指向變量容器zval。
假設(shè)我們有一段PHP代碼，使用了一個臨時變量$tmp存儲了一個字符串，在處理完字符串之后，就不需要這個$tmp變量了，$tmp變量對于我們來說可以算是一個“垃圾”了，但是對于GC來說，$tmp其實并不是一個垃圾，$tmp變量對我們沒有意義，但是這個變量實際還存在，$tmp符號依然指向它所對應(yīng)的zval，GC會認為PHP代碼中可能還會使用到此變量，所以不會將其定義為垃圾。
那么如果我們在PHP代碼中使用完$tmp后，調(diào)用unset刪除這個變量，那么$tmp是不是就成為一個垃圾了呢。很可惜，GC仍然不認為$tmp是一個垃圾，因為$tmp在unset之后，refcount減少1變成了0(這里假設(shè)沒有別的變量和$tmp指向相同的zval),這個時候GC會直接將$tmp對應(yīng)的zval的內(nèi)存空間釋放，$tmp和其對應(yīng)的zval就根本不存在了。此時的$tmp也不是新的GC所要對付的那種“垃圾”。那么新的GC究竟要對付什么樣的垃圾呢，下面我們將生產(chǎn)一個這樣的垃圾。 ?
頑固垃圾的產(chǎn)生過程
如果讀者已經(jīng)閱讀了變量內(nèi)部存儲相關(guān)的內(nèi)容，想必對refcount和isref這些變量內(nèi)部的信息有了一定的了解。這里我們將結(jié)合手冊中的一個例子來介紹垃圾的產(chǎn)生過程：
| 1 2 3 | <?php $a = "new string"; ?> |
在這么簡單的一個代碼中，$a變量內(nèi)部存儲信息為：a: (refcount=1, is_ref=0)='new string'
當把$a賦值給另外一個變量的時候，$a對應(yīng)的zval的refcount會加1。
| 1 2 3 4 | <?php $a = "new string"; $b = $a; ?> |
此時$a和$b變量對應(yīng)的內(nèi)部存儲信息為 a,b: (refcount=2, is_ref=0)='new string'
當我們用unset刪除$b變量的時候，$b對應(yīng)的zval的refcount會減少
| 1 2 3 4 5 | <?php $a = "new string";? //a: (refcount=1, is_ref=0)='new string' $b = $a;???????????//a,b: (refcount=2, is_ref=0)='new string' unset($b);?????????//a: (refcount=1, is_ref=0)='new string' ?> |
對于普通的變量來說，這一切似乎很正常，但是在復合類型變量（數(shù)組和對象）中，會發(fā)生比較有意思的事情：
| 1 2 3 | <?php $a = array('meaning'=> 'life','number' => 42); ?> |
a的內(nèi)部存儲信息為：
a: (refcount=1, is_ref=0)=array (
? 'meaning' => (refcount=1, is_ref=0)='life',
? 'number' => (refcount=1, is_ref=0)=4)
數(shù)組變量本身($a)在引擎內(nèi)部實際上是一個哈希表，這張表中有兩個zval項 meaning和number，所以實際上那一行代碼中一共生成了3個zval,這3個zval都遵循變量的引用和計數(shù)原則，用圖來表示：
下面在$a中添加一個元素，并將現(xiàn)有的一個元素的值賦給新的元素：
| 1 2 3 4 | <?php $a = array('meaning'=> 'life','number' => 42); $a['life'] =$a['meaning']; ?> |
那么$a的內(nèi)部存儲為：
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'
)
其中的meaning元素和life元素之指向同一個zval的：
現(xiàn)在，如果我們試一下，將數(shù)組的引用賦值給數(shù)組中的一個元素，有意思的事情就發(fā)生了：
| 1 2 3 4 | <?php $a = array('one'); $a[] = &$a; ?> |
這樣$a數(shù)組就有兩個元素，一個索引為0，值為字符one,另外一個索引為1，為$a自身的引用，內(nèi)部存儲如下：
a: (refcount=2, is_ref=1)=array (
? 0 => (refcount=1, is_ref=0)='one',
? 1 => (refcount=2, is_ref=1)=...
)
“...”表示1指向a自身，是一個環(huán)形引用：
這個時候我們對$a進行unset,那么$a會從符號表中刪除，同時$a指向的zval的refcount減少
| 1 2 3 4 5 | <?php $a = array('one'); $a[] = &$a; unset($a); ?> |
那么問題也就產(chǎn)生了，$a已經(jīng)不在符號表中了，用戶無法再訪問此變量，但是$a之前指向的zval的refcount變?yōu)?而不是0，因此不能被回收，這樣產(chǎn)生了內(nèi)存泄露：
這樣，這么一個zval就成為了一個真是意義的垃圾了，新的GC要做的工作就是清理這種垃圾。
新的GC算法
為解決這種垃圾，產(chǎn)生了新的GC。
在PHP5.3版本中，使用了專門GC機制清理垃圾，在之前的版本中是沒有專門的GC，那么垃圾產(chǎn)生的時候，沒有辦法清理，內(nèi)存就白白浪費掉了。在PHP5.3源代碼中多了以下文件:{PHPSRC}/Zend/zend_gc.h {PHPSRC}/Zend/zend_gc.c, 這里就是新的GC的實現(xiàn)，我們先簡單的介紹一下算法思路，然后再從源碼的角度詳細介紹引擎中如何實現(xiàn)這個算法的。
在較新的PHP手冊中有簡單的介紹新的GC使用的垃圾清理算法，這個算法名為 Concurrent Cycle Collection in Reference Counted Systems ， 這里不詳細介紹此算法，根據(jù)手冊中的內(nèi)容來先簡單的介紹一下思路：
首先我們有幾個基本的準則：
如果一個zval的refcount增加，那么此zval還在使用，不屬于垃圾
如果一個zval的refcount減少到0， 那么zval可以被釋放掉，不屬于垃圾
如果一個zval的refcount減少之后大于0，那么此zval還不能被釋放，此zval可能成為一個垃圾
只有在準則3下，GC才會把zval收集起來，然后通過新的算法來判斷此zval是否為垃圾。那么如何判斷這么一個變量是否為真正的垃圾呢？
簡單的說，就是對此zval中的每個元素進行一次refcount減1操作，操作完成之后，如果zval的refcount=0，那么這個zval就是一個垃圾。這個原理咋看起來很簡單，但是又不是那么容易理解，起初筆者也無法理解其含義，直到挖掘了源代碼之后才算是了解。如果你現(xiàn)在不理解沒有關(guān)系，后面會詳細介紹，這里先把這算法的幾個步驟描敘一下，首先引用手冊中的一張圖：
A：為了避免每次變量的refcount減少的時候都調(diào)用GC的算法進行垃圾判斷，此算法會先把所有前面準則3情況下的zval節(jié)點放入一個節(jié)點(root)緩沖區(qū)(root buffer)，并且將這些zval節(jié)點標記成紫色，同時算法必須確保每一個zval節(jié)點在緩沖區(qū)中之出現(xiàn)一次。當緩沖區(qū)被節(jié)點塞滿的時候，GC才開始開始對緩沖區(qū)中的zval節(jié)點進行垃圾判斷。
B：當緩沖區(qū)滿了之后，算法以深度優(yōu)先對每一個節(jié)點所包含的zval進行減1操作，為了確保不會對同一個zval的refcount重復執(zhí)行減1操作，一旦zval的refcount減1之后會將zval標記成灰色。需要強調(diào)的是，這個步驟中，起初節(jié)點zval本身不做減1操作，但是如果節(jié)點zval中包含的zval又指向了節(jié)點zval（環(huán)形引用），那么這個時候需要對節(jié)點zval進行減1操作。
C：算法再次以深度優(yōu)先判斷每一個節(jié)點包含的zval的值，如果zval的refcount等于0，那么將其標記成白色(代表垃圾)，如果zval的refcount大于0，那么將對此zval以及其包含的zval進行refcount加1操作，這個是對非垃圾的還原操作，同時將這些zval的顏色變成黑色（zval的默認顏色屬性）。
D：遍歷zval節(jié)點，將C中標記成白色的節(jié)點zval釋放掉。
這ABCD四個過程是手冊中對這個算法的介紹，這還不是那么容易理解其中的原理，這個算法到底是個什么意思呢？我自己的理解是這樣的：
比如還是前面那個變成垃圾的數(shù)組$a對應(yīng)的zval,命名為zval_a, ?如果沒有執(zhí)行unset， zval_a的refcount為2,分別由$a和$a中的索引1指向這個zval。 ?用算法對這個數(shù)組中的所有元素（索引0和索引1）的zval的refcount進行減1操作，由于索引1對應(yīng)的就是zval_a，所以這個時候zval_a的refcount應(yīng)該變成了1，這樣zval_a就不是一個垃圾。如果執(zhí)行了unset操作，zval_a的refcount就是1，由zval_a中的索引1指向zval_a,用算法對數(shù)組中的所有元素（索引0和索引1）的zval的refcount進行減1操作，這樣zval_a的refcount就會變成0，于是就發(fā)現(xiàn)zval_a是一個垃圾了。 算法就這樣發(fā)現(xiàn)了頑固的垃圾數(shù)據(jù)。
舉了這個例子，讀者大概應(yīng)該能夠知道其中的端倪：
對于一個包含環(huán)形引用的數(shù)組，對數(shù)組中包含的每個元素的zval進行減1操作，之后如果發(fā)現(xiàn)數(shù)組自身的zval的refcount變成了0，那么可以判斷這個數(shù)組是一個垃圾。
這個道理其實很簡單，假設(shè)數(shù)組a的refcount等于m, a中有n個元素又指向a,如果m等于n,那么算法的結(jié)果是m減n，m-n=0，那么a就是垃圾，如果m>n,那么算法的結(jié)果m-n>0,所以a就不是垃圾了。
m=n代表什么？ ?代表a的refcount都來自數(shù)組a自身包含的zval元素,代表a之外沒有任何變量指向它，代表用戶代碼空間中無法再訪問到a所對應(yīng)的zval，代表a是泄漏的內(nèi)存，因此GC將a這個垃圾回收了。
在PHP中，GC默認是開啟的，你可以通過ini文件中的 zend.enable_gc 項來開啟或則關(guān)閉GC。當GC開啟的時候，垃圾分析算法將在節(jié)點緩沖區(qū)(roots buffer)滿了之后啟動。緩沖區(qū)默認可以放10,000個節(jié)點，當然你也可以通過修改Zend/zend_gc.c中的GC_ROOT_BUFFER_MAX_ENTRIES 來改變這個數(shù)值，需要重新編譯鏈接PHP。當GC關(guān)閉的時候，垃圾分析算法就不會運行，但是相關(guān)節(jié)點還會被放入節(jié)點緩沖區(qū)，這個時候如果緩沖區(qū)節(jié)點已經(jīng)放滿，那么新的節(jié)點就不會被記錄下來，這些沒有被記錄下來的節(jié)點就永遠也不會被垃圾分析算法分析。如果這些節(jié)點中有循環(huán)引用，那么有可能產(chǎn)生內(nèi)存泄漏。之所以在GC關(guān)閉的時候還要記錄這些節(jié)點，是因為簡單的記錄這些節(jié)點比在每次產(chǎn)生節(jié)點的時候判斷GC是否開啟更快，另外GC是可以在腳本運行中開啟的，所以記錄下這些節(jié)點，在代碼運行的某個時候如果又開啟了GC，這些節(jié)點就能被分析算法分析。當然垃圾分析算法是一個比較耗時的操作。
在PHP代碼中我們可以通過gc_enable()和gc_disable()函數(shù)來開啟和關(guān)閉GC，也可以通過調(diào)用gc_collect_cycles()在節(jié)點緩沖區(qū)未滿的情況下強制執(zhí)行垃圾分析算法。這樣用戶就可以在程序的某些部分關(guān)閉或則開啟GC，也可強制進行垃圾分析算法。
新的GC算法的性能
1. 防止泄漏節(jié)省內(nèi)存
新的GC算法的目的就是為了防止循環(huán)引用的變量引起的內(nèi)存泄漏問題，在PHP中GC算法，當節(jié)點緩沖區(qū)滿了之后，垃圾分析算法會啟動，并且會釋放掉發(fā)現(xiàn)的垃圾，從而回收內(nèi)存，在PHP手冊上給了一段代碼和內(nèi)存使用狀況圖：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | <?php class Foo { ????public$var = '3.1415962654'; } $baseMemory= memory_get_usage(); for ( $i = 0; $i <= 100000; $i++ ) { ????$a= new Foo; ????$a->self =$a; ????if( $i % 500 === 0 ) ????{ ????????echosprintf( '%8d: ',$i ), memory_get_usage() -$baseMemory, "/n"; ????} } ?> |
這段代碼的循環(huán)體中，新建了一個對象變量，并且用對象的一個成員指向了自己，這樣就形成了一個循環(huán)引用，當進入下一次循環(huán)的時候，又一次給對象變量重新賦值，這樣會導致之前的對象變量內(nèi)存泄漏，在這個例子里面有兩個變量泄漏了，一個是對象本身，另外一個是對象中的成員self，但是這兩個變量只有對象會作為垃圾收集器的節(jié)點被放入緩沖區(qū)(因為重新賦值相當于對它進行了unset操作，滿足前面的準則3)。在這里我們進行了100,000次循環(huán)，而GC在緩沖區(qū)中有10,000節(jié)點的時候會啟動垃圾分析算法，所以這里一共會進行10次的垃圾分析算法。從圖中可以清晰的看到，在5.3版本PHP中，每次GC的垃圾分析算法被觸發(fā)后，內(nèi)存會有一個明顯的減少。而在5.2版本的PHP中，內(nèi)存使用量會一直增加。
2. 運行效率影響
啟用了新的GC后，垃圾分析算法將是一個比較耗時的操作，手冊中給了一段測試代碼：
| 1 2 3 4 5 6 7 8 9 10 11 12 | <?php class Foo { ????public$var = '3.1415962654'; } for ( $i = 0; $i <= 1000000; $i++ ) { ????$a= new Foo; ????$a->self =$a; } echo memory_get_peak_usage(), "/n"; ?> |
然后分別在GC開啟和關(guān)閉的情況下執(zhí)行這段代碼：
time php -dzend.enable_gc=0 -dmemory_limit=-1 -n example2.php
# and
time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php
最終在該機器上，第一次執(zhí)行大概使用10.7秒，第二次執(zhí)行大概使用11.4秒，性能大約降低7%,不過內(nèi)存的使用量降低了98%,從931M降低到了10M。當然這并不是一個比較科學的測試方法，但是也能說明一定的問題。這種代碼測試的是一種極端惡劣條件，實際代碼中，特別是在WEB的應(yīng)用中，很難出現(xiàn)大量循環(huán)引用，GC的分析算法的啟動不會這么頻繁，小規(guī)模的代碼中甚至很少有機會啟動GC分析算法。
總結(jié)：
當GC的垃圾分析算法執(zhí)行的時候，PHP腳本的效率會受到一定的影響，但是小規(guī)模的代碼一般不會有這個機會運行這個算法。如果一旦腳本中GC分析算法開始運行了，那么將花費少量的時間節(jié)省出來了大量的內(nèi)存，是一件非常劃算的事情。新的GC對一些長期運行的PHP腳本效果更好，比如PHP的DAEMON守護進程，或則PHP-GTK進程等等。
來源:http://blog.csdn.net/niluchen/article/details/9468365
與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖總結(jié)
以上是生活随笔為你收集整理的PHP内核探索：新垃圾回收机制说明的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 台球桌（说一说台球桌的简介）
- 下一篇： PHP生成日历（实例详解）