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