轉帖：http://www.yanbin.org/2006/12/07/welcome_to_php_5_2/經過 N 次的跳票和等待，PHP 5.2已于 11 月2 日正式發布。根據 PHP 小組不成文的開發習慣，PHP 5.0 系列更大程度上像一個技術展示版，性能低下（甚至還不如 PHP4，這主要歸結與Zend中重寫的更加強大也更加復雜的OO機制），穩定性也有所欠缺，目前 PHP 開發組已經放棄了對這個系列的開發。PHP 5.1 系列則側重于對性能的改善，和 PHP 5.0 系列已經不可同日而語。但隨著 PHP5.2系列的發布，PHP5.1也已經和 PHP4.4系列一樣進入了維護狀態，除非出現重大的BUG和安全隱患否則將不再更新。新發布的 PHP 5.2 除了修復了以往200多個BUG以外，它還將性能進一步提高，尤其是改善了在高負載情況下的表現，而且在安全性的處理上也做出了很大的改進。同時也增加了很多很實用的技術（比如 JSON、Zip等支持），另外還有一些原本定為 PHP6 的特性也已經被提前實現在這個版本當中。可以說，相對于最初的 PHP5 版本，這次的改變幾乎是半革命性的（革命性這個形容詞當然是留給 PHP6 的J）。下面我自己掌握的一些信息和理解，嘗試向大家介紹一下 PHP 5.2的新特性，如有不當之處，還望方家斧正：1、最明顯的當屬 PHP 5.2 在移除了filepro 和 hwapi 兩個擴展（這兩個被移動到了 PECL）的同時另外增加了4個新的擴展：Date、JOSN、Filter和ZIP。;

其實從 PHP 5.1 開始，在 PHP 核心增加了一個 Date 擴展，重寫了對日期/時間（主要是時區方面）的支持。所不同的是，PHP 5.2 更進一步，日期和時區則分別成為了類 DateTime 和 DateTimeZone 的一個對象。大家可以在 PHP CLI 中運行php –rc DateTime 或 php –rc DateTimeZone 來看一下這兩個類的詳細信息。需要注意的是如果你的程序中已經存在有名為DateTime 或 DateTimeZone 類的話，那想在 PHP 5.2 中運行就必須改名了。(著名的開源 CRM ：vtigercrm 已經有了前車之鑒); JSON 擴展實現了則實現對 JavaScript Object Notation (JSON) 這種輕量級數據交換格式的支持。在 PHP 5.2 中這個擴展是默認被啟用的。相信很多開發人員都為 PHP與 JavaScript 之間的通信發愁過，尤其是現在這個流行 Ajax 的時代。而現在，我們用JSON 就可以很輕易的解決這個問題。JSON數據能夠直接為服務器端代碼使用, 并且也能夠讓客戶端的 JavaScript簡單地通過 eval() 來進行讀取，這就大大簡化了服務器端和客戶端的代碼開發量。雖然以前在 PHP 里面也有一些 JSON 類來支持，但這哪有 PHP 的原生支持來得高效和快捷呢？ Filter 擴展負責校驗和過濾數據，這個擴展主要是為了處理像用戶的輸入那樣的不可靠數據而設計的。這個擴展也是默認被啟用的。默認情況下的RAW 模式將不會以任何方式影響輸入的數據，也就是說這不會對現有代碼產生任何影響。但我們在以后的開發中應該盡可能地利用這個擴展來進行敏感字符的過濾，因為這不但簡化了一些表單的驗證工作，而且提高了程序的安全性和運行效率。 ZIP 擴展將允許我們對 Zip 壓縮包及其包內的文件進行讀寫操作。也就是說，我們對 Zip文件不僅能看，而且還能摸：它提供了對 Zip 文件的完全支持。這項特性的應用是非常廣泛的，具體帶來的種種好處我就不再多說了。;

當然，關于這些擴展的具體細節還得查閱我們無所不能的 PHP 手冊。:D2、改進了內存管理器，使之在高負載情況下具有更佳的表現。 按照 “Zend 二老”之一也就是 “Zend”中那個“nd”的說法，這個新的內存管理器是分層（hierarchical）的。這個管理器共有三層：存儲層（storage）、堆（heap）層和emalloc/efree層。存儲層通過malloc()、mmap()等函數向系統真正的申請內存，并通過 free() 函數釋放所申請的內存。存儲層相當于Zend 自己的“內存倉庫”，通常申請的內存塊都比較大。堆層（注意這里的堆并不是指操作系統所管理的堆，而是 Zend 內存管理器的所管理的內存堆）就把它們從存儲層要過來并分割成一些較小的塊。而 emalloc/efree層就是指通過 PHP API的emalloc()/efree() 函數所申請和釋放的內存。emalloc() 并不直接同存儲層打交道，同它們接頭的是堆層。負責把比原來的管理器在同等條件下會分配更小的內存，但速度更快。它首先會從系統（堆）中申請一些較大的內存塊，然后自己來管理這個堆。php.ini 中的memory_limit 值雖然還會被檢用，但已不再是每次emalloc() 調用時都檢用，而僅僅是在向系統申請那些大的內存塊時被檢用。熟悉一些服務器端編程的朋友可能會馬上想到一個詞：內存池！沒錯，這基本上就是一個內存池。至少我是這么認為的。:D

內存池技術其實這是服務端編程中很常見。使用內存池技術可以有效地避免頻繁的內存申請/釋放操作，在內存池技術中，內存釋放時實際上并沒有通知操作系統真實的釋放和回收，而僅僅是對將要釋放的內存做個了標記，表示該部分內存已經不再使用。等下一次申請內存時，就從這些“可用”的內存鏈表中取出一個內存塊，從而避免了頻繁的內存申請/釋放操作，大大節省了系統資源。根據測試和統計，在 PHP 4.4版本中，一個典型的較為簡單的請求就有超過 20,000次的對系統堆的申請和釋放操作，這花費的時間相當于整個腳本所花費時間的 20% 左右。由此可見，若能降低這種資源消耗則效果是極為可觀的。與此同時，采用內存池技術也帶來一個更為重要的“副作用”：避免了大量的“內存碎片”。一般情況下，內存碎片是對系統沒有多大影響的，但服務端應用明顯不同于一般應用，服務端會面臨很高數量級的訪問請求，這些請求也伴隨著更高數量級的內存申請/釋放操作。內存碎片過多將導致內存利用率降低，降低內存分配速度，嚴重時還會觸發內存分配失敗，盡管此時理論上仍有可分配的物理內存。最后，內存池技術還有一個不太引人注意的好處：它能降低內存泄漏的概率。因為實際申請的內存塊雖然尺寸較大，但數量較少，而且一般情況下都是統一申請，實際釋放時也可以統一釋放。顯然，這比代碼中即時申請，而沒有即時釋放所造成內存泄漏的概率要小很多。;

不過采用內存池技術的管理器也明顯要比常規管理器（指的是內存即時申請，即時釋放的管理機制）的內存開銷要大，因為除了真正申請的內存外，管理器還得負責維護每個內存塊的狀態，因此 PHP 5.2 中把 php.ini中 memory_limit 指令值從默認的 8M 提升為 16M 。這看似增加了內存消耗，并且也需要極少量的CPU資源來管理，但由于內存碎片的減少實際上并沒有增加多少消耗，再結合其他方面的表現，可以說是所得遠大于所失，尤其是在高負載情況下。; 3、PHP 5.2 也對 INI 指令的存取方面做了優化。PHPer 都知道，在 PHP 腳本中我們可以用 ini_set() 函數動態改變某個 PHP 指令的值。但問題是在請求結束后你還得把這些改變的值給恢復過來以保證下個腳本能正確使用。在 PHP 5.2 之前，PHP 的做法可謂是不辭勞苦，逐個遍歷 INI 指令并恢復的。如果你是整個腳本都是 ini_set() 也就罷了（當然這個情況也是極其罕見的。：）），萬一我的腳本中很少使用甚至根本就沒有使用這個函數那我不就是虧大了？因此 PHP 5.2 為了解決這個問題又額外增加了一個表專門保存更改過的指令，這樣就不用來回挨個恢復了。4、PHP 5.2 還對 require_once(); 和 include_once() 兩個函數進行了優化。

PHP 5.2 以前 require_once(); 和 include_once() 的做法是無論某個文件是否已經被緩存或編譯過，統統是先 fopen() 再說，打開成功后在查詢一下是否已經緩存過。這么處理的原因就是 在 PHP 5.1 以前沒有很完美的解決 realpath() 相對路徑和符號連接方面的問題。因為若不能唯一地正確地確定某個路徑的真實路徑表示那么你就無法利用這個路徑的唯一性去解決某個問題。而 fopen 則沒有這個顧慮。realpath() 的這個問題在 PHP 5.1 中被徹底搞定了，但還沒來得及應用到 require_once(); 和 include_once() ，結果就拖遲到現在。解決這個問題的好處是在于避免了 fopen 這個 I/O 操作，在很多高負載情形中，通常都是 數據庫、網絡或者磁盤 I/O 而不是 CPU 成為瓶頸。5、對HashTable 的復制也進行了優化。HashTable在ZendEngine是一個很基本的數據結構，數組本質上就是一個 HashTable。對HashTable 的優化也將意味著對數組的復制操作（無論是顯式還是隱式）速度將會有一定的提升。;

6、其他的一些性能方面的改進。PHP 5.2 也對在FastCGI SAPI 模塊中訪問環境變量的性能做了少許優化。以前則是逐行搜索，現在則是通過 Hash 值來存取。除此之外，PHP 5.2還對str_replace() 和 implode() 函數以及“try {} catch {}”塊等都做了一定的優化。 下面是對一些語言特性和安全特性方面的改進：

1、繼PHP 5.0增加了一個 E_STRICT的錯誤報告級別（常量值為 2048）之后，PHP 5.2 也新增了一個錯誤報告級別：E_RECOVERABLE_ERROR ，其常量值為 4096 。這個級別的錯誤主要是從E_ERROR中但可以被用戶自定義的錯誤處理程序（一般通過set_error_handler() 函數指定）所捕捉的情況轉化而來。如果一個E_RECOVERABLE_ERROR 未被捕捉并處理，那么它的表現就和所有 PHP 版本中的E_ERROR一樣會導致程序中止。在錯誤日志中，該類型的錯誤將被記錄成“可捕捉的致命錯誤（Catchable fatal error）”。;

導致 PHP 拋出 E_RECOVERABLE_ERROR 的情況通常是指那些很危險，但還不足以讓 Zend Engine 崩潰的情況。比方說，有下面一段代碼： class foo {function bar(foo $a) { } }

$a = new foo ; $a->bar(new stdClass) ;很明顯，類 foo 的bar 函數要求一個 foo 類型的參數，但實際代碼中卻給了一個 stdClass 類型的參數。在PHP 5.2 以前，這會導致一個 E_ERROR（Fatal error: Argument 1 passed to foo::bar() must be an instance of foo……）。但在 PHP 5.2（包括以后的 PHP6）則會導致一個E_RECOVERABLE_ERROR（Catchable fatal error: Argument 1 passed to foo::bar() must be an instance of foo……）。這種錯誤是可以被捕捉的，如果你通過set_error_handler() 指定了一個錯誤處理函數（即使是你在這個函數中沒有處理E_RECOVERABLE_ERROR），那么程序就會繼續運行。但如果你沒有指定一個錯誤處理函數，那么這個 E_RECOVERABLE_ERROR 錯誤就會和 E_ERROR 一樣，會立即導致程序中止。;

2、相應的，錯誤報告級別 E_ALL 也將會包含上述E_RECOVERABLE_ERROR。這也就意味著常量 E_ALL 的值將會從原來的2047 變為 6143。注意，在 PHP 5.0和 PHP 5.1中雖然增加了E_STRICT，但在這兩個版本中 E_ALL 并不包含E_STRICT。而在以后的版本（如 PHP5.2、PHP6等）中E_ALL 則包含了包括E_STRICT和E_RECOVERABLE_ERROR在內的所有錯誤級別。 在PHP 5.0/5.1 中我們想設置error_reporting為E_ALL就不得不采用error_reporting(E_ALL | E_STRICT) 的寫法，感覺極為別扭，也很容易造成一些疏忽和誤導。在 PHP5.2當中我們就沒有這個苦惱了。另外如果你在 Apache 的配置文件（如 httpd.conf）或 .htaccess 文件中用error_reporting 設置了錯誤報告級別（比如：php_value error_reporting 4095），由于 Apache 不支持 PHP 常量 ，那你還得手工去適當調整這些錯誤報告級別的數值。 3、添加了allow_url_include 這個 ini 指令來輔助 allow_url_fopen 操作；這個是 PHP 5.2 在安全方面的重大更新之一。使用這個指令可以讓我們區分開對遠程文件的標準文件操作和包含操作。我們通常需要進行前面的標準操作，而后面的包含操作則通常是危險的發源地。從 PHP 5.2 開始，你的本地腳本可以在禁止遠程包含操作的同時進行標準遠程文件操作。事實上，這個就是默認配置。 PHP 5.2 把原來的allow_url_fopen 指令分成了allow_url_fopen 和allow_url_include 兩個指令。如果allow_url_fopen 操作是禁止的，那么allow_url_include 也將被禁止。默認情況下將會允許進行 allow_url_fopen 操作，但是禁止allow_url_include 。這樣就能非常有效的避免遠程代碼注入（remote code injection）。這個本來也是打算在 PHP6中添加的，現在我們提前用到了。:D4、PHP 5.2 增加了對接口中構造函數類型(簽名) 強制性檢查的支持。 從 PHP 5.2 開始，如果你在一個接口中聲明了一個構造函數，那么在所有實現該接口的類都必須包含一個構造函數，并且這個構造函數要與該接口的構造函數的簽名完全一致。這里術語“簽名”的意思是函數的參數和返回值的類型（包括其語言類型以及是引用傳遞還是值傳遞），這個概念有點類似于C 語言中 “原型”。看以下代碼：interface constr { function __construct() ;}

class implem implements constr { function __construct ($a) { }}這段代碼在 PHP5.0和 PHP 5.1 里面運行是毫無問題的，但在 PHP 5.2中則會拋出一個錯誤：Fatal error: Declaration of implem::__construct() must be compatible with that of constr::__construct()，提示類implem 的構造函數與接口constr 的構造函數的聲明不匹配。值得一提的是這項新特性的添加過程是很有意思。，有興趣的朋友可以到Zend 的每周總結（http://www.zend.com/zend/week/week279.php#Heading9）里面看看來龍去脈，此處不再贅述。5、__toString() 函數將會在任何合適的地方被調用。魔術方法 __toString() 現在會在一個字符串上下文環境中被調用。換句話說，一個對象在任何地方都可以作為一個字符串來使用，只要它實現了 __toString() 函數。當然你實現的 __toString() 函數不能拋出異常，否則腳本將會中止運行。以前為防萬一，PHP 5.0/5.1會在必要時會把對象標識(Id)作為一個字符串返回，這個特性在 PHP 5.2中已經被拋棄。因此這帶來的問題就可能是不能保證一個對象的標識總是唯一的。如果你在程序中利用了對象標識符的唯一性，那這將會是某種缺陷。如果沒有實現類的 __toString()函數但卻把其對象作為作為一個字符串來使用就會導致一個“可捕捉的致命錯誤”。 還有個特例，就是對象也不能作為作為數組的索引或者鍵名，即使是它有一個 __toString() 方法。以后 PHP 可能會內建一個 Hash機制來提供對對象唯一性的支持，但就現在來說，你必須自己提供一個對象的 hash 算法，或者干脆就用新提供的 SPL 函數：spl_object_hash()； 6、為在寫模式下訪問 __get() 的返回值這種情況增加了E_NOTICE 級錯誤提示。顯然 __get() 函數只能在讀模式下返回一個值，并且也不可能把一個值寫入 __get() 函數。但在以前的版本中并沒有為這種不正確的用法給予提示。從 PHP 5.2 開始將會為這種情況拋出一個E_NOTICE。注意：如果你對 foreach() 和其他的一些更改數組內部指針的函數也采取了同樣的操作（即給 foreach 所“抽”出來的值進行賦值），那也會觸發一個E_NOTICE ，因為這些“抽”出來的值都是處于讀模式。如果你的代碼中存在這種情況，那你應該把 __get() 函數的返回值轉換為一個數組，或者用 SPL 里面的ArrayObject 來代替這個數組。 7、丟棄了抽象靜態的類函數。由于“筆漏”，PHP 5.0和5.1 版本竟然允許類具有抽象靜態函數，不過現在不行了。現在只允許接口有抽象靜態函數。 8、其他一些語言特性的改變：－ SPL 新增了正則迭代器(Regex Iterators)、文件對象（SplFileObject）的CSV 支持等。 － 增加了對 RFC2397 （數據流）的支持。－ 增加了對Apache 2.2的支持。－ 現在可以在上傳文件時實時取得文件的上傳進度了。－ 對PHP或其擴展所需 OpenSSL 庫、PCRE 庫、MySQL客戶端庫、PostgreSQL 客戶端庫、SQLite 庫等均進行更新升級。最后再來介紹一下 PHP 運行模式方面的改動：; 1、首先是 PHP 5.2 改變了 Win32 環境下 PHPRC 環境變量的優先級。在以前搜索 php.ini 的路徑順序為：·SAPI 模塊所指定的位置（Apache 2 中的 PHPIniDir 指令，CGI 和 CLI 中的 -c 命令行選項，NSAPI 中的 php_ini 參數，THTTPD 中的 PHP_INI_PATH 環境變量） ·HKEY_LOCAL_MACHINESOFTWAREPHPIniFilePath（Windows 注冊表位置） ·PHPRC 環境變量 ·當前工作目錄（對于 CLI） ·web 服務器目錄（對于 SAPI 模塊）或 PHP 所在目錄（Windows 下其它情況） ·Windows 目錄（C:windows 或 C:winnt），或 –with-config-file-path 編譯時選項指定的位置現在 PHPRC 環境變量由第三優先權變為第二優先權，高于Windows 注冊表所指定的位置。 2、PHP 的命令行模式（CLI SAPI）不再在CWD（當前工作目錄）里查找 php.ini 或php-cli.ini 文件。在 PHP 5.1.x 中有一個未公開的特性就是 CLI會自動在當前目錄中搜索 PHP 的配置文件。這種隨便讀入一個未經許可的配置文件的行為將可能會導致一個不可預知的錯誤。在 PHP 5.2 版本里已經將該特性移除，不再再在CWD（當前工作目錄）里查找 php.ini 或php-cli.ini 文件了。 總結： 總體來說，從性能上 PHP 5.2 已經超越 PHP4.x成為目前速度最快的版本，從語言及安全特性上也是無出其右。即便是 PHP4.x 有一些代碼緩存工具（如 eAccelerator）可以提高性能，但目前也已經有 APC、X-Cache等表示可以支持 5.2 版本（eAccelerator 可能還需要一段時間來完善）。雖然 APC 等在性能還略輸于eAccelerator，但加上PHP5.2的種種優化措施，至少不會比 PHP4+eAccelerator 差到哪去更何況還有很要命的安全更新。既然如此，那我們還有什么理由不升級呢？同時我也推薦各大虛擬主機廠商將其服務器（至少是新增的服務器）更新為 PHP5.2版本。在不增加性能消耗的基礎上還能為客戶提供更多的語言特性，同時也增強了產品的競爭力，何樂而不為呢？讓我們開始全面進入 PHP 5.2 的時代吧！