程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> PHP綜合 >> PHP對象相互引用的內存溢出實例分析

PHP對象相互引用的內存溢出實例分析

編輯:PHP綜合

通常來說使用腳本語言最大的好處之一就是可利用其擁有的自動垃圾回收機制來釋放內存。你不需要在使用完變量後做任何釋放內存的處理,因為這些PHP會幫你完成。
當然,我們可以按自己的意願調用 unset() 函數來釋放內存,但通常不需要這麼做。
不過在PHP裡,至少有一種情況內存不會得到自動釋放,即便是手動調用 unset()。詳情可考PHP官網關於內存洩露的分析:http://bugs.php.net/bug.php?id=33595。

問題症狀如下:

如果兩個對象之間存在著相互引用的關系,如“父對象-子對象”,對父對象調用 unset()不會釋放在子對象中引用父對象的內存(即便父對象被垃圾回收,也不行)。

是不是有些糊塗了?我們來看下面的這段代碼:

<?
phpclass Foo {
 function __construct(){
 $this->bar = new Bar($this);
 }
}
class Bar {
 function __construct($foo = null){
 $this->foo = $foo;
 }
}
while (true) {
 $foo = new Foo();
 unset($foo);
 echo number_format(memory_get_usage()) . " ";
}
?>

運行這段代碼,你會看到內存使用率越來越高越來越高,直到用光光。

...33,551,61633,551,97633,552,33633,552,696PHP Fatal error: Allowed memory size of 33554432 bytes exhausted(tried to allocate 16 bytes) in memleak.php on line 17

對大部分PHP程序員來講這種情況不算是什麼問題。可如果你在一個長期運行的代碼中使用到了一大堆相互引用的對象,尤其是在對象相對較大的情況下,內存會迅速地消耗殆盡。

Userland解決方案

雖然有些乏味、不優雅,但之前提到的 bugs.php.net 鏈接中提供了一個解決方案。
這個方案在釋放對象前使用一個 destructor 方法以達到目的。Destructor 方法可將所有內部的父對象引用全部清除,也就是說可以將這部分本來會溢出的內存釋放掉。

以下是“修復後”的代碼:

<?
phpclass Foo {
 function __construct(){
 $this->bar = new Bar($this);
 }
 function __destruct(){
 unset($this->bar);
 }
}
class Bar {
 function __construct($foo = null){
 $this->foo = $foo;
 }
}
while (true) {
 $foo = new Foo();
 $foo->__destruct();
 unset($foo);
 echo number_format(memory_get_usage()) . " ";
}
?>

注意那個新增的Foo::__destruct()方法,以及在釋放對象前對 $foo->__destruct() 的調用。現在這段代碼解決了內存使用率一直增加的問題,這麼一來,代碼就可以很好的工作了。

PHP內核解決方案

為什麼會有內存溢出的發生?我對PHP內核方面的研究並不精通,但可以確定的是此問題與引用計數有關系。
在 $bar 中引用 $foo 的引用計數不會因為父對象 $foo 被釋放而遞減,這時PHP認為你仍需要 $foo 對象,也就不會釋放這部分的內存。原理大致如此。

通俗的來說,大體意思是:一個引用計數沒有遞減,所以一些內存永遠得不到釋放。
此外在前面提到的 bugs.php.net 鏈接中指出了修改垃圾回收的過程將會犧牲極大的性能,需要讀者對此注意。

與其改變垃圾回收的過程,為什麼不用 unset() 對內部對象做釋放的工作呢?(或者在釋放對象的時候調用 __destruct()?)
也許PHP內核開發者可以在此或其他地方,對這種垃圾回收處理機制做出修改。

相信本文所述對大家深入理解PHP運行原理有所幫助。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved