內存管理對于長(cháng)期運行的程序，例如服務(wù)器守護程序，是相當重要的影響；因此，理解PHP是如何分配與釋放內存的對于創(chuàng )建這類(lèi)程序極為重要。本文將重點(diǎn)探討PHP的內存管理問(wèn)題。
一、 內存
在PHP中，填充一個(gè)字符串變量相當簡(jiǎn)單，這只需要一個(gè)語(yǔ)句"＜?php $str = ‘hello world ‘; ?＞"即可，并且該字符串能夠被自由地修改、拷貝和移動(dòng)。而在C語(yǔ)言中，盡管你能夠編寫(xiě)例如"char *str = "hello world ";"這樣的一個(gè)簡(jiǎn)單的靜態(tài)字符串；但是，卻不能修改該字符串，因為它生存于程序空間內。為了創(chuàng )建一個(gè)可操縱的字符串，你必須分配一個(gè)內存塊，并且通過(guò)一 個(gè)函數（例如strdup()）來(lái)復制其內容。
{
char *str;
str = strdup("hello world");
if (!str) {
fprintf(stderr， "Unable to allocate memory!");
}
}
由于后面我們將分析的各種原因，傳統型內存管理函數（例如malloc()，free()，strdup()，realloc()，calloc()，等等）幾乎都不能直接為PHP源代碼所使用。
二、 釋放內存
在幾乎所有的平臺上，內存管理都是通過(guò)一種請求和釋放模式實(shí)現的。首先，一個(gè)應用程序請求它下面的層(通常指"操作系統")："我想使用一些內存空間"。如果存在可用的空間，操作系統就會(huì )把它提供給該程序并且打上一個(gè)標記以便不會(huì )再把這部分內存分配給其它程序。
當 應用程序使用完這部分內存，它應該被返回到OS；這樣以來(lái)，它就能夠被繼續分配給其它程序。如果該程序不返回這部分內存，那么OS無(wú)法知道是否這塊內存不 再使用并進(jìn)而再分配給另一個(gè)進(jìn)程。如果一個(gè)內存塊沒(méi)有釋放，并且所有者應用程序丟失了它，那么，我們就說(shuō)此應用程序"存在漏洞"，因為這部分內存無(wú)法再為 其它程序可用。
在一個(gè)典型的客戶(hù)端應用程序中，較小的不太經(jīng)常的內存泄漏有時(shí)能夠為OS所"容忍"，因為在這個(gè)進(jìn)程稍后結束時(shí)該泄漏內存會(huì )被隱式返回到OS。這并沒(méi)有什么，因為OS知道它把該內存分配給了哪個(gè)程序，并且它能夠確信當該程序終止時(shí)不再需要該內存。
而對于長(cháng)時(shí)間運行的服務(wù)器守護程序，包括象Apache這樣的web服務(wù)器和擴展php模塊來(lái)說(shuō)，進(jìn)程往往被設計為相當長(cháng)時(shí)間一直運行。因為OS不能清理內存使用，所以，任何程序的泄漏-無(wú)論是多么小-都將導致重復操作并最終耗盡所有的系統資源。
現在，我們不妨考慮用戶(hù)空間內的stristr()函數；為了使用大小寫(xiě)不敏感的搜索來(lái)查找一個(gè)字符串，它實(shí)際上創(chuàng )建了兩個(gè)串的各自的一個(gè)小型 副本，然后執行一個(gè)更傳統型的大小寫(xiě)敏感的搜索來(lái)查找相對的偏移量。然而，在定位該字符串的偏移量之后，它不再使用這些小寫(xiě)版本的字符串。如果它不釋放這 些副本，那么，每一個(gè)使用stristr()的腳本在每次調用它時(shí)都將泄漏一些內存。最后，web服務(wù)器進(jìn)程將擁有所有的系統內存，但卻不能夠使用它。
你可以理直氣壯地說(shuō)，理想的解決方案就是編寫(xiě)良好、干凈的、一致的代碼。這當然不錯；但是，在一個(gè)象PHP解釋器這樣的環(huán)境中，這種觀(guān)點(diǎn)僅對了一半。
三、 錯誤處理
為了實(shí)現"跳出"對用戶(hù)空間腳本及其依賴(lài)的擴展函數的一個(gè)活動(dòng)請求，需要使用一種方法來(lái)完全"跳出"一個(gè)活動(dòng)請求。這是在Zend引擎內實(shí)現的：在一個(gè)請求的開(kāi)始設置一個(gè)"跳出"地址，然后在任何die()或exit()調用或在遇到任何關(guān)鍵錯誤(E_ERROR)時(shí)執行一個(gè)longjmp()以跳轉到該"跳出"地址。
盡管這個(gè)"跳出"進(jìn)程能夠簡(jiǎn)化程序執行的流程，但是，在絕大多數情況下，這會(huì )意味著(zhù)將會(huì )跳過(guò)資源清除代碼部分(例如free()調用)并最終導致出現內存漏洞?，F在，讓我們來(lái)考慮下面這個(gè)簡(jiǎn)化版本的處理函數調用的引擎代碼：
void call_function(const char *fname， int fname_len TSRMLS_DC){
zend_function *fe;
char *lcase_fname;
/* PHP函數名是大小寫(xiě)不敏感的，
*為了簡(jiǎn)化在函數表中對它們的定位，
*所有函數名都隱含地翻譯為小寫(xiě)的
*/
lcase_fname = estrndup(fname， fname_len);
zend_str_tolower(lcase_fname， fname_len);
if (zend_hash_find(EG(function_table)，lcase_fname， fname_len + 1， (void **)&fe) == FAILURE) {
zend_execute(fe-＞op_array TSRMLS_CC);
} else {
php_error_docref(NULL TSRMLS_CC， E_ERROR，"Call to undefined function: %s()"， fname);
}
efree(lcase_fname);
}
當執行到php_error_docref()這一行時(shí)，內部錯誤處理器就會(huì )明白該錯誤級別是critical，并相應地調用longjmp ()來(lái)中斷當前程序流程并離開(kāi)call_function()函數，甚至根本不會(huì )執行到efree(lcase_fname)這一行。你可能想把 efree()代碼行移動(dòng)到zend_error()代碼行的上面；但是，調用這個(gè)call_function()例程的代碼行會(huì )怎么樣呢？fname本 身很可能就是一個(gè)分配的字符串，并且，在它被錯誤消息處理使用完之前，你根本不能釋放它。
注意，這個(gè)php_error_docref()函數是trigger_error()函數的一個(gè)內部等價(jià)實(shí)現。它的第一個(gè)參數是一個(gè)將被添加 到docref的可選的文檔引用。第三個(gè)參數可以是任何我們熟悉的E_*家族常量，用于指示錯誤的嚴重程度。第四個(gè)參數（最后一個(gè)）遵循printf() 風(fēng)格的格式化和變量參數列表式樣。
四、 Zend內存管理器
在上面的"跳出"請求期間解決內存泄漏的方案之一是：使用Zend內存管理(ZendMM)層。引擎的這一部分非常類(lèi)似于操作系統的內存管理行 為-分配內存給調用程序。區別在于，它處于進(jìn)程空間中非常低的位置而且是"請求感知"的；這樣以來(lái)，當一個(gè)請求結束時(shí)，它能夠執行與OS在一個(gè)進(jìn)程終止時(shí) 相同的行為。也就是說(shuō)，它會(huì )隱式地釋放所有的為該請求所占用的內存。圖1展示了ZendMM與OS以及PHP進(jìn)程之間的關(guān)系。
除了提供隱式內存清除功能之外，ZendMM還能夠根據php.ini中memory_limit的設置控制每一種內存請求的用法。如果一個(gè)腳本試圖請求 比系統中可用內存更多的內存，或大于它每次應該請求的最大量，那么，ZendMM將自動(dòng)地發(fā)出一個(gè)E_ERROR消息并且啟動(dòng)相應的"跳出"進(jìn)程。這種方 法的一個(gè)額外優(yōu)點(diǎn)在于，大多數內存分配調用的返回值并不需要檢查，因為如果失敗的話(huà)將會(huì )導致立即跳轉到引擎的退出部分。
把PHP內部代碼和OS的實(shí)際的內存管理層"鉤"在一起的原理并不復雜：所有內部分配的內存都要使用一組特定的可選函數實(shí)現。例如，PHP代碼 不是使用malloc(16)來(lái)分配一個(gè)16字節內存塊而是使用了emalloc(16)。除了實(shí)現實(shí)際的內存分配任務(wù)外，ZendMM還會(huì )使用相應的綁 定請求類(lèi)型來(lái)標志該內存塊；這樣以來(lái)，當一個(gè)請求"跳出"時(shí)，ZendMM可以隱式地釋放它。
經(jīng)常情況下，內存一般都需要被分配比單個(gè)請求持續時(shí)間更長(cháng)的一段時(shí)間。這種類(lèi)型的分配（因其在一次請求結束之后仍然存在而被稱(chēng)為"永久性分配 "），可以使用傳統型內存分配器來(lái)實(shí)現，因為這些分配并不會(huì )添加ZendMM使用的那些額外的相應于每種請求的信息。然而有時(shí)，直到運行時(shí)刻才會(huì )確定是否 一個(gè)特定的分配需要永久性分配，因此ZendMM導出了一組幫助宏，其行為類(lèi)似于其它的內存分配函數，但是使用最后一個(gè)額外參數來(lái)指示是否為永久性分配。
如果你確實(shí)想實(shí)現一個(gè)永久性分配，那么這個(gè)參數應該被設置為1；在這種情況下，請求是通過(guò)傳統型malloc()分配器家族進(jìn)行傳遞的。然而， 如果運行時(shí)刻邏輯認為這個(gè)塊不需要永久性分配；那么，這個(gè)參數可以被設置為零，并且調用將會(huì )被調整到針對每種請求的內存分配器函數。
例如，pemalloc(buffer_len，1)將映射到malloc(buffer_len)，而pemalloc(buffer_len，0)將被使用下列語(yǔ)句映射到emalloc(buffer_len)：
#define in Zend/zend_alloc.h:
#define pemalloc(size， persistent) ((persistent)?malloc(size): emalloc(size))
所有這些在ZendMM中提供的分配器函數都能夠從下表中找到其更傳統的對應實(shí)現。
表格（下）展示了ZendMM支持下的每一個(gè)分配器函數以及它們的e/pe對應實(shí)現：
你可能會(huì )注意到，即使是pefree()函數也要求使用永久性標志。這是因為在調用pefree()時(shí)，它實(shí)際上并不知道是否ptr是 一種永久性分配。針對一個(gè)非永久性分配調用free()能夠導致雙倍的空間釋放，而針對一種永久性分配調用efree()有可能會(huì )導致一個(gè)段錯誤，因為內 存管理器會(huì )試圖查找并不存在的管理信息。因此，你的代碼需要記住它分配的數據結構是否是永久性的。
除了分配器函數核心部分外，還存在其它一些非常方便的ZendMM特定的函數，例如：
void *estrndup(void *ptr，int len);
該函數能夠分配len+1個(gè)字節的內存并且從ptr處復制len個(gè)字節到最新分配的塊。這個(gè)estrndup()函數的行為可以大致描述如下：
void *estrndup(void *ptr， int len)
{
char *dst = emalloc(len + 1);
memcpy(dst， ptr， len);
dst[len] = 0;
return dst;
}
在此，被隱式放置在緩沖區最后的NULL字節可以確保任何使用estrndup()實(shí)現字符串復制操作的函數都不需要擔心會(huì )把結果緩沖區傳遞給 一個(gè)例如printf()這樣的希望以為NULL為結束符的函數。當使用estrndup()來(lái)復制非字符串數據時(shí)，最后一個(gè)字節實(shí)質(zhì)上都浪費了，但其中 的利明顯大于弊。
void *safe_emalloc(size_t size， size_t count， size_t addtl);
void *safe_pemalloc(size_t size， size_t count，size_t addtl，char persistent);
這些函數分配的內存空間最終大小是((size*count)+addtl)。你可以會(huì )問(wèn)："為什么還要提供額外函數呢？為什么不使用一個(gè) emalloc/pemalloc呢？"原因很簡(jiǎn)單：為了安全。盡管有時(shí)候可能性相當小，但是，正是這一"可能性相當小"的結果導致宿主平臺的內存溢出。 這可能會(huì )導致分配負數個(gè)數的字節空間，或更有甚者，會(huì )導致分配一個(gè)小于調用程序要求大小的字節空間。而safe_emalloc()能夠避免這種類(lèi)型的陷 井-通過(guò)檢查整數溢出并且在發(fā)生這樣的溢出時(shí)顯式地預以結束。
注意，并不是所有的內存分配例程都有一個(gè)相應的p*對等實(shí)現。例如，不存在pestrndup()，并且在PHP 5.1版本前也不存在safe_pemalloc()。
五、 引用計數
慎重的內存分配與釋放對于PHP（它是一種多請求進(jìn)程）的長(cháng)期性能有極其重大的影響；但是，這還僅是問(wèn)題的一半。為了使一個(gè)每秒處理上千次點(diǎn)擊的服務(wù)器高效地運行，每一次請求都需要使用盡可能少的內存并且要盡可能減少不必要的數據復制操作。請考慮下列PHP代碼片斷：
＜?php
$a = ‘Hello World‘;
$b = $a;
unset($a);
＞
在第一次調用之后，只有一個(gè)變量被創(chuàng )建，并且一個(gè)12字節的內存塊指派給它以便存儲字符串"Hello World"，還包括一個(gè)結尾處的NULL字符?，F在，讓我們來(lái)觀(guān)察后面的兩行：$b被置為與變量$a相同的值，然后變量$a被釋放。
如果PHP因每次變量賦值都要復制變量?jì)热莸脑?huà)，那么，對于上例中要復制的字符串還需要復制額外的12個(gè)字節，并且在數據復制期間還要進(jìn)行另外 的處理器加載。這一行為乍看起來(lái)有點(diǎn)荒謬，因為當第三行代碼出現時(shí)，原始變量被釋放，從而使得整個(gè)數據復制顯得完全不必要。其實(shí)，我們不妨再遠一層考慮， 讓我們設想當一個(gè)10MB大小的文件的內容被裝載到兩個(gè)變量中時(shí)會(huì )發(fā)生什么。這將會(huì )占用20MB的空間，此時(shí)，10已經(jīng)足夠了。引擎會(huì )把那么多的時(shí)間和內 存浪費在這樣一種無(wú)用的努力上嗎？
你應該知道，PHP的設計者早已深諳此理。
記住，在引擎中，變量名和它們的值實(shí)際上是兩個(gè)不同的概念。值本身是一個(gè)無(wú)名的zval*存儲體（在本例中，是一個(gè)字符串值），它被通過(guò)zend_hash_add()賦給變量$a。如果兩個(gè)變量名都指向同一個(gè)值，會(huì )發(fā)生什么呢？
{
zval *helloval;
MAKE_STD_ZVAL(helloval);
ZVAL_STRING(helloval， "Hello World"， 1);
zend_hash_add(EG(active_symbol_table)， "a"， sizeof("a")，&helloval， sizeof(zval*)， NULL);
zend_hash_add(EG(active_symbol_table)， "b"， sizeof("b")，&helloval， sizeof(zval*)， NULL);
}
此時(shí)，你可以實(shí)際地觀(guān)察$a或$b，并且會(huì )看到它們都包含字符串"Hello World"。遺憾的是，接下來(lái)，你繼續執行第三行代碼"unset($a);"。此時(shí)，unset()并不知道$a變量指向的數據還被另一個(gè)變量所使 用，因此它只是盲目地釋放掉該內存。任何隨后的對變量$b的存取都將被分析為已經(jīng)釋放的內存空間并因此導致引擎崩潰。
這個(gè)問(wèn)題可以借助于zval（它有好幾種形式）的第四個(gè)成員refcount加以解決。當一個(gè)變量被首次創(chuàng )建并賦值時(shí)，它的refcount被 初始化為1，因為它被假定僅由最初創(chuàng )建它時(shí)相應的變量所使用。當你的代碼片斷開(kāi)始把helloval賦給$b時(shí)，它需要把refcount的值增加為2； 這樣以來(lái)，現在該值被兩個(gè)變量所引用：
{
zval *helloval;
MAKE_STD_ZVAL(helloval);
ZVAL_STRING(helloval， "Hello World"， 1);
zend_hash_add(EG(active_symbol_table)， "a"， sizeof("a")，&helloval， sizeof(zval*)， NULL);
ZVAL_ADDREF(helloval);
zend_hash_add(EG(active_symbol_table)， "b"， sizeof("b")，&helloval，sizeof(zval*)，NULL);
}
現在，當unset()刪除原變量的$a相應的副本時(shí)，它就能夠從refcount參數中看到，還有另外其他人對該數據感興趣；因此，它應該只是減少refcount的計數值，然后不再管它。
六、 寫(xiě)復制（Copy on Write）
通過(guò)refcounting來(lái)節約內存的確是不錯的主意，但是，當你僅想改變其中一個(gè)變量的值時(shí)情況會(huì )如何呢？為此，請考慮下面的代碼片斷：
＜?php
$a = 1;
$b = $a;
$b += 5;
＞
通過(guò)上面的邏輯流程，你當然知道$a的值仍然等于1，而$b的值最后將是6。并且此時(shí)，你還知道，Zend在盡力節省內存-通過(guò)使$a和$b都引用相同的zval（見(jiàn)第二行代碼）。那么，當執行到第三行并且必須改變$b變量的值時(shí)，會(huì )發(fā)生什么情況呢？
回答是，Zend要查看refcount的值，并且確保在它的值大于1時(shí)對之進(jìn)行分離。在Zend引擎中，分離是破壞一個(gè)引用對的過(guò)程，正好與你剛才看到的過(guò)程相反：
zval *get_var_and_separate(char *varname， int varname_len TSRMLS_DC)
{
zval **varval， *varcopy;
if (zend_hash_find(EG(active_symbol_table)，varname， varname_len + 1， (void**)&varval) == FAILURE) {
/* 變量根本并不存在-失敗而導致退出*/
return NULL;
}
if ((*varval)-＞refcount ＜ 2) {
/* varname是唯一的實(shí)際引用，
*不需要進(jìn)行分離
*/
return *varval;
}
/* 否則，再復制一份zval*的值*/
MAKE_STD_ZVAL(varcopy);
varcopy = *varval;
/* 復制任何在zval*內的已分配的結構*/
zval_copy_ctor(varcopy);
/*刪除舊版本的varname
*這將減少該過(guò)程中varval的refcount的值
*/
zend_hash_del(EG(active_symbol_table)， varname， varname_len + 1);
/*初始化新創(chuàng )建的值的引用計數，并把它依附到
* varname變量
*/
varcopy-＞refcount = 1;
varcopy-＞is_ref = 0;
zend_hash_add(EG(active_symbol_table)， varname， varname_len + 1，&varcopy， sizeof(zval*)， NULL);
/*返回新的zval* */
return varcopy;
}
現在，既然引擎有一個(gè)僅為變量$b所擁有的zval*（引擎能知道這一點(diǎn)），所以它能夠把這個(gè)值轉換成一個(gè)long型值并根據腳本的請求給它增加5。
七、 寫(xiě)改變（change-on-write）
引用計數概念的引入還導致了一個(gè)新的數據操作可能性，其形式從用戶(hù)空間腳本管理器看來(lái)與"引用"有一定關(guān)系。請考慮下列的用戶(hù)空間代碼片斷：
＜?php
$a = 1;
$b = &$a;
$b += 5;
＞
在上面的PHP代碼中，你能看出$a的值現在為6，盡管它一開(kāi)始為1并且從未(直接)發(fā)生變化。之所以會(huì )發(fā)生這種情況是因為當引擎開(kāi)始把$b的 值增加5時(shí)，它注意到$b是一個(gè)對$a的引用并且認為"我可以改變該值而不必分離它，因為我想使所有的引用變量都能看到這一改變"。
但是，引擎是如何知道的呢？很簡(jiǎn)單，它只要查看一下zval結構的第四個(gè)和最后一個(gè)元素（is_ref）即可。這是一個(gè)簡(jiǎn)單的開(kāi)/關(guān)位，它定義 了該值是否實(shí)際上是一個(gè)用戶(hù)空間風(fēng)格引用集的一部分。在前面的代碼片斷中，當執行第一行時(shí)，為$a創(chuàng )建的值得到一個(gè)refcount為1，還有一個(gè) is_ref值為0，因為它僅為一個(gè)變量($a)所擁有并且沒(méi)有其它變量對它產(chǎn)生寫(xiě)引用改變。在第二行，這個(gè)值的refcount元素被增加為2，除了這 次is_ref元素被置為1之外（因為腳本中包含了一個(gè)"&"符號以指示是完全引用）。
最后，在第三行，引擎再一次取出與變量$b相關(guān)的值并且檢查是否有必要進(jìn)行分離。這一次該值沒(méi)有被分離，因為前面沒(méi)有包括一個(gè)檢查。下面是get_var_and_separate()函數中與refcount檢查有關(guān)的部分代碼：
if ((*varval)-＞is_ref || (*varval)-＞refcount ＜ 2) {
/* varname是唯一的實(shí)際引用，
* 或者它是對其它變量的一個(gè)完全引用
*任何一種方式：都沒(méi)有進(jìn)行分離
*/
return *varval;
}
這一次，盡管refcount為2，卻沒(méi)有實(shí)現分離，因為這個(gè)值是一個(gè)完全引用。引擎能夠自由地修改它而不必關(guān)心其它變量值的變化。
八、 分離問(wèn)題
盡管已經(jīng)存在上面討論到的復制和引用技術(shù)，但是還存在一些不能通過(guò)is_ref和refcount操作來(lái)解決的問(wèn)題。請考慮下面這個(gè)PHP代碼塊：
＜?php
$a = 1;
$b = $a;
$c = &$a;
＞
在此，你有一個(gè)需要與三個(gè)不同的變量相關(guān)聯(lián)的值。其中，兩個(gè)變量是使用了"change-on-write"完全引用方式，而第三個(gè)變量處于一 種可分離的"copy-on-write"（寫(xiě)復制）上下文中。如果僅使用is_ref和refcount來(lái)描述這種關(guān)系，有哪些值能夠工作呢？
回答是：沒(méi)有一個(gè)能工作。在這種情況下，這個(gè)值必須被復制到兩個(gè)分離的zval*中，盡管兩者都包含完全相同的數據(見(jiàn)圖3)。
同樣，下列代碼塊將引起相同的沖突并且強迫該值分離出一個(gè)副本(見(jiàn)圖4)。
＜?php
$a = 1;
$b = &$a;
$c = $a;
＞
注意，在這里的兩種情況下，$b都與原始的zval對象相關(guān)聯(lián)，因為在分離發(fā)生時(shí)引擎無(wú)法知道介于到該操作當中的第三個(gè)變量的名字。
九、 總結
PHP是一種托管語(yǔ)言。從普通用戶(hù)角度來(lái)看，這種仔細地控制資源和內存的方式意味著(zhù)更為容易地進(jìn)行原型開(kāi)發(fā)并導致出現更少的沖突。然而，當我們深入"內里"之后，一切的承諾似乎都不復存在，最終還要依賴(lài)于真正有責任心的開(kāi)發(fā)者來(lái)維持整個(gè)運行時(shí)刻環(huán)境的一致性。
from: http://www.phpchina.com/?action_viewnews_itemid_2447.html
聯(lián)系客服
