## 一切的開始: SAPI接口 SAPI(Server Application Programming Interface)指的是PHP具體應用的編程接口，就像PC一樣，無論安裝哪些操作系統，只要滿足了PC的接口規范都可以在PC上正常運行，PHP腳本要執行有很多種方式，通過Web服務器，或者直接在命令行下，也可以嵌入在其他程序中。 通常，我們使用Apache或者Nginx這類Web服務器來測試PHP腳本，或者在命令行下通過PHP解釋器程序來執行。腳本執行完后，Web服務器應答，瀏覽器顯示應答信息，或者在命令行標準輸出上顯示內容。 我們很少關心PHP解釋器在哪里。雖然通過Web服務器和命令行程序執行腳本看起來很不一樣，實際上它們的工作流程是一樣的。命令行參數傳遞給PHP解釋器要執行的腳本，相當于通過url請求一個PHP頁面。腳本執行完成后返回響應結果，只不過命令行的響應結果是顯示在終端上。 腳本執行的開始都是以SAPI接口實現開始的。只是不同的SAPI接口實現會完成他們特定的工作，例如Apache的mod_php SAPI實現需要初始化從Apache獲取的一些信息，在輸出內容是將內容返回給Apache，其他的SAPI實現也類似。 下面幾個小節將對一些常見的SAPI實現進行更為深入的介紹。 ## 開始和結束 PHP開始執行以后會經過兩個主要的階段：處理請求之前的開始階段和請求之后的結束階段。開始階段有兩個過程：第一個過程是模塊初始化階段（MINIT），在整個SAPI生命周期內(例如Apache啟動以后的整個生命周期內或者命令行程序整個執行過程中)，該過程只進行一次。第二個過程是模塊激活階段（RINIT），該過程發生在請求階段，例如通過url請求某個頁面，則在每次請求之前都會進行模塊激活（RINIT請求開始）。例如PHP注冊了一些擴展模塊，則在MINIT階段會回調所有模塊的MINIT函數。模塊在這個階段可以進行一些初始化工作，例如注冊常量，定義模塊使用的類等等。模塊在實現時可以通過如下宏來實現這些回調函數： PHP_MINIT_FUNCTION(myphpextension) { // 注冊常量或者類等初始化操作 return SUCCESS; } 請求到達之后PHP初始化執行腳本的基本環境，例如創建一個執行環境，包括保存PHP運行過程中變量名稱和值內容的符號表，以及當前所有的函數以及類等信息的符號表。然后PHP會調用所有模塊的RINIT函數，在這個階段各個模塊也可以執行一些相關的操作，模塊的RINIT函數和MINIT回調函數類似： PHP_RINIT_FUNCTION(myphpextension) { // 例如記錄請求開始時間 // 隨后在請求結束的時候記錄結束時間。這樣我們就能夠記錄下處理請求所花費的時間了 return SUCCESS; } 請求處理完后就進入了結束階段，一般腳本執行到末尾或者通過調用exit()或die()函數，PHP都將進入結束階段。和開始階段對應，結束階段也分為兩個環節，一個在請求結束后停用模塊(RSHUTDOWN，對應RINIT)，一個在SAPI生命周期結束（Web服務器退出或者命令行腳本執行完畢退出）時關閉模塊(MSHUTDOWN，對應MINIT)。 PHP_RSHUTDOWN_FUNCTION(myphpextension) { // 例如記錄請求結束時間，并把相應的信息寫入到日至文件中。 return SUCCESS; } > 想要了解擴展開發的相關內容，請參考第十三章 擴展開發 ### 單進程SAPI生命周期 CLI/CGI模式的PHP屬于單進程的SAPI模式。這類的請求在處理一次請求后就關閉。也就是只會經過如下幾個環節： 開始 - 請求開始 - 請求關閉 - 結束 SAPI接口實現就完成了其生命周期。如圖2.1所示：  圖2.1 單進程SAPI生命周期 如上的圖是非常簡單，也很好理解。只是在各個階段之間PHP還做了許許多多的工作。這里做一些補充： **啟動** 在調用每個模塊的模塊初始化前，會有一個初始化的過程，它包括： - **初始化若干全局變量** 這里的初始化全局變量大多數情況下是將其設置為NULL，有一些除外，比如設置zuf（zend_utility_functions），以zuf.printf_function = php_printf為例，這里的php_printf在zend_startup函數中會被賦值給zend_printf作為全局函數指針使用，而zend_printf函數通常會作為常規字符串輸出使用，比如顯示程序調用棧的debug_print_backtrace就是使用它打印相關信息。 - **初始化若干常量** 這里的常量是PHP自己的一些常量，這些常量要么是硬編碼在程序中,比如PHP_VERSION，要么是寫在配置頭文件中，比如PEAR_EXTENSION_DIR，這些是寫在config.w32.h文件中。 - **初始化Zend引擎和核心組件** 前面提到的zend_startup函數的作用就是初始化Zend引擎，這里的初始化操作包括內存管理初始化、全局使用的函數指針初始化（如前面所說的zend_printf等），對PHP源文件進行詞法分析、語法分析、中間代碼執行的函數指針的賦值，初始化若干HashTable（比如函數表，常量表等等），為ini文件解析做準備，為PHP源文件解析做準備，注冊內置函數（如strlen、define等），注冊標準常量（如E_ALL、TRUE、NULL等）、注冊GLOBALS全局變量等。 - **解析php.ini** php_init_config函數的作用是讀取php.ini文件，設置配置參數，加載zend擴展并注冊PHP擴展函數。此函數分為如下幾步：初始化參數配置表，調用當前模式下的ini初始化配置，比如CLI模式下，會做如下初始化： INI_DEFAULT("report_zend_debug", "0"); INI_DEFAULT("display_errors", "1"); 不過在其它模式下卻沒有這樣的初始化操作。接下來會的各種操作都是查找ini文件： 1. 判斷是否有php_ini_path_override，在CLI模式下可以通過-c參數指定此路徑（在php的命令參數中-c表示在指定的路徑中查找ini文件）。 1. 如果沒有php_ini_path_override，判斷php_ini_ignore是否為非空（忽略php.ini配置，這里也就CLI模式下有用，使用-n參數）。 1. 如果不忽略ini配置，則開始處理php_ini_search_path（查找ini文件的路徑），這些路徑包括CWD(當前路徑，不過這種不適用CLI模式)、執行腳本所在目錄、環境變量PATH和PHPRC和配置文件中的PHP_CONFIG_FILE_PATH的值。 1. 在準備完查找路徑后，PHP會判斷現在的ini路徑（php_ini_file_name）是否為文件和是否可打開。如果這里ini路徑是文件并且可打開，則會使用此文件， 也就是CLI模式下通過-c參數指定的ini文件的優先級是最高的，其次是PHPRC指定的文件，第三是在搜索路徑中查找php-%sapi-module-name%.ini文件（如CLI模式下應該是查找php-cli.ini文件），最后才是搜索路徑中查找php.ini文件。 - **全局操作函數的初始化** php_startup_auto_globals函數會初始化在用戶空間所使用頻率很高的一些全局變量，如：$_GET、$_POST、$_FILES等。這里只是初始化，所調用的zend_register_auto_global函數也只是將這些變量名添加到CG(auto_globals)這個變量表。 php_startup_sapi_content_types函數用來初始化SAPI對于不同類型內容的處理函數，這里的處理函數包括POST數據默認處理函數、默認數據處理函數等。 - **初始化靜態構建的模塊和共享模塊(MINIT)** php_register_internal_extensions_func函數用來注冊靜態構建的模塊，也就是默認加載的模塊，我們可以將其認為內置模塊。在PHP5.3.0版本中內置的模塊包括PHP標準擴展模塊（/ext/standard/目錄，這里是我們用的最頻繁的函數，比如字符串函數，數學函數，數組操作函數等等），日歷擴展模塊、FTP擴展模塊、session擴展模塊等。這些內置模塊并不是一成不變的，在不同的PHP模板中，由于不同時間的需求或其它影響因素會導致這些默認加載的模塊會變化，比如從代碼中我們就可以看到mysql、xml等擴展模塊曾經或將來會作為內置模塊出現。 模塊初始化會執行兩個操作：1. 將這些模塊注冊到已注冊模塊列表（module_registry），如果注冊的模塊已經注冊過了，PHP會報Module XXX already loaded的錯誤。1. 將每個模塊中包含的函數注冊到函數表（ CG(function_table) ），如果函數無法添加，則會報 Unable to register functions, unable to load。 在注冊了靜態構建的模塊后，PHP會注冊附加的模塊，不同的模式下可以加載不同的模塊集，比如在CLI模式下是沒有這些附加的模塊的。 在內置模塊和附加模塊后，接下來是注冊通過共享對象（比如DLL）和php.ini文件靈活配置的擴展。 在所有的模塊都注冊后，PHP會馬上執行模塊初始化操作（zend_startup_modules）。它的整個過程就是依次遍歷每個模塊，調用每個模塊的模塊初始化函數，也就是在本小節前面所說的用宏PHP_MINIT_FUNCTION包含的內容。 - **禁用函數和類** php_disable_functions函數用來禁用PHP的一些函數。這些被禁用的函數來自PHP的配置文件的disable_functions變量。其禁用的過程是調用zend_disable_function函數將指定的函數名從CG(function_table)函數表中刪除。 php_disable_classes函數用來禁用PHP的一些類。這些被禁用的類來自PHP的配置文件的disable_classes變量。其禁用的過程是調用zend_disable_class函數將指定的類名從CG(class_table)類表中刪除。 **ACTIVATION** 在處理了文件相關的內容，PHP會調用php_request_startup做請求初始化操作。請求初始化操作，除了圖中顯示的調用每個模塊的請求初始化函數外，還做了較多的其它工作，其主要內容如下： - **激活Zend引擎** gc_reset函數用來重置垃圾收集機制，當然這是在PHP5.3之后才有的。 init_compiler函數用來初始化編譯器，比如將編譯過程中在放opcode的數組清空，準備編譯時用來的數據結構等等。 init_executor函數用來初始化中間代碼執行過程。在編譯過程中，函數列表、類列表等都存放在編譯時的全局變量中，在準備執行過程時，會將這些列表賦值給執行的全局變量中，如：EG(function_table) = CG(function_table);中間代碼執行是在PHP的執行虛擬棧中，初始化時這些棧等都會一起被初始化。除了棧，還有存放變量的符號表(EG(symbol_table))會被初始化為50個元素的hashtable，存放對象的EG(objects_store)被初始化了1024個元素。PHP的執行環境除了上面的一些變量外，還有錯誤處理，異常處理等等，這些都是在這里被初始化的。通過php.ini配置的zend_extensions也是在這里被遍歷調用activate函數。 - **激活SAPI** sapi_activate函數用來初始化SG(sapi_headers)和SG(request_info)，并且針對HTTP請求的方法設置一些內容，比如當請求方法為HEAD時，設置SG(request_info).headers_only=1；此函數最重要的一個操作是處理請求的數據，其最終都會調用sapi_module.default_post_reader。而sapi_module.default_post_reader在前面的模塊初始化是通過php_startup_sapi_content_types函數注冊了默認處理函數為main/php_content_types.c文件中php_default_post_reader函數。此函數會將POST的原始數據寫入$HTTP_RAW_POST_DATA變量。 在處理了post數據后，PHP會通過sapi_module.read_cookies讀取cookie的值，在CLI模式下，此函數的實現為sapi_cli_read_cookies，而在函數體中卻只有一個return NULL; 如果當前模式下有設置activate函數，則運行此函數，激活SAPI，在CLI模式下此函數指針被設置為NULL。 - **環境初始化** 這里的環境初始化是指在用戶空間中需要用到的一些環境變量初始化，這里的環境包括服務器環境、請求數據環境等。實際到我們用到的變量，就是$_POST、$_GET、$_COOKIE、$_SERVER、$_ENV、$_FILES。和sapi_module.default_post_reader一樣，sapi_module.treat_data的值也是在模塊初始化時，通過php_startup_sapi_content_types函數注冊了默認數據處理函數為main/php_variables.c文件中php_default_treat_data函數。 以$_COOKIE為例，php_default_treat_data函數會對依據分隔符，將所有的cookie拆分并賦值給對應的變量。 - **模塊請求初始化** PHP通過zend_activate_modules函數實現模塊的請求初始化，也就是我們在圖中看到Call each extension's RINIT。此函數通過遍歷注冊在module_registry變量中的所有模塊，調用其RINIT方法實現模塊的請求初始化操作。 **運行** php_execute_script函數包含了運行PHP腳本的全部過程。 當一個PHP文件需要解析執行時，它可能會需要執行三個文件，其中包括一個前置執行文件、當前需要執行的主文件和一個后置執行文件。非當前的兩個文件可以在php.ini文件通過auto_prepend_file參數和auto_append_file參數設置。如果將這兩個參數設置為空，則禁用對應的執行文件。 對于需要解析執行的文件，通過zend_compile_file（compile_file函數）做詞法分析、語法分析和中間代碼生成操作，返回此文件的所有中間代碼。如果解析的文件有生成有效的中間代碼，則調用zend_execute（execute函數）執行中間代碼。如果在執行過程中出現異常并且用戶有定義對這些異常的處理，則調用這些異常處理函數。在所有的操作都處理完后，PHP通過EG(return_value_ptr_ptr)返回結果。 **DEACTIVATION** PHP關閉請求的過程是一個若干個關閉操作的集合，這個集合存在于php_request_shutdown函數中。這個集合包括如下內容： 1. 調用所有通過register_shutdown_function()注冊的函數。這些在關閉時調用的函數是在用戶空間添加進來的。一個簡單的例子，我們可以在腳本出錯時調用一個統一的函數，給用戶一個友好一些的頁面，這個有點類似于網頁中的404頁面。 1. 執行所有可用的__destruct函數。這里的析構函數包括在對象池（EG(objects_store）中的所有對象的析構函數以及EG(symbol_table)中各個元素的析構方法。 1. 將所有的輸出刷出去。 1. 發送HTTP應答頭。這也是一個輸出字符串的過程，只是這個字符串可能符合某些規范。 1. 遍歷每個模塊的關閉請求方法，執行模塊的請求關閉操作，這就是我們在圖中看到的Call each extension's RSHUTDOWN。 1. 銷毀全局變量表（PG(http_globals)）的變量。 1. 通過zend_deactivate函數，關閉詞法分析器、語法分析器和中間代碼執行器。 1. 調用每個擴展的post-RSHUTDOWN函數。只是基本每個擴展的post_deactivate_func函數指針都是NULL。 1. 關閉SAPI，通過sapi_deactivate銷毀SG(sapi_headers)、SG(request_info)等的內容。 1. 關閉流的包裝器、關閉流的過濾器。 1. 關閉內存管理。 1. 重新設置最大執行時間 **結束** 最終到了要收尾的地方了。 - **flush** sapi_flush將最后的內容刷新出去。其調用的是sapi_module.flush，在CLI模式下等價于fflush函數。 - **關閉Zend引擎** zend_shutdown將關閉Zend引擎。 此時對應圖中的流程，我們應該是執行每個模塊的關閉模塊操作。在這里只有一個zend_hash_graceful_reverse_destroy函數將module_registry銷毀了。當然，它最終也是調用了關閉模塊的方法的，其根源在于在初始化module_registry時就設置了這個hash表析構時調用ZEND_MODULE_DTOR宏。而ZEND_MODULE_DTOR宏對應的是module_destructor函數。在此函數中會調用模塊的module_shutdown_func方法，即PHP_RSHUTDOWN_FUNCTION宏產生的那個函數。 在關閉所有的模塊后，PHP繼續銷毀全局函數表，銷毀全局類表、銷售全局變量表等。通過zend_shutdown_extensions遍歷zend_extensions所有元素，調用每個擴展的shutdown函數。 ### 多進程SAPI生命周期 通常PHP是編譯為apache的一個模塊來處理PHP請求。Apache一般會采用多進程模式，Apache啟動后會fork出多個子進程，每個進程的內存空間獨立，每個子進程都會經過開始和結束環節，不過每個進程的開始階段只在進程fork出來以來后進行，在整個進程的生命周期內可能會處理多個請求。只有在Apache關閉或者進程被結束之后才會進行關閉階段，在這兩個階段之間會隨著每個請求重復請求開始-請求關閉的環節。如圖2.2所示：  圖2.2 多進程SAPI生命周期 ### 多線程的SAPI生命周期 多線程模式和多進程中的某個進程類似，不同的是在整個進程的生命周期內會**并行**的重復著 請求開始-請求關閉的環節  圖2.3 多線程SAPI生命周期 ## Zend引擎 Zend引擎是PHP實現的核心，提供了語言實現上的基礎設施。例如：PHP的語法實現，腳本的編譯運行環境，擴展機制以及內存管理等，當然這里的PHP指的是官方的PHP實現(除了官方的實現，目前比較知名的有facebook的hiphop實現，不過到目前為止，PHP還沒有一個標準的語言規范)，而PHP則提供了請求處理和其他Web服務器的接口(SAPI)。 目前PHP的實現和Zend引擎之間的關系非常緊密，甚至有些過于緊密了，例如很多PHP擴展都是使用的Zend API，而Zend正是PHP語言本身的實現，PHP只是使用Zend這個內核來構建PHP語言的，而PHP擴展大都使用Zend API，這就導致PHP的很多擴展和Zend引擎耦合在一起了，在筆者編寫這本書的時候PHP核心開發者就提出將這種耦合解開， 目前PHP的受歡迎程度是毋庸置疑的，但凡流行的語言通常都會出現這個語言的其他實現版本，這在Java社區里就非常明顯，目前已經有非常多基于JVM的語言了，例如IBM的Project Zero就實現了一個基于JVM的PHP實現，.NET也有類似的實現，通常他們這樣做的原因無非是因為：他們喜歡這個語言，但又不想放棄原有的平臺，或者對現有的語言實現不滿意，處于性能或者語言特性等（HipHop就是這樣誕生的）。 很多腳本語言中都會有語言擴展機制，PHP中的擴展通常是通過Pear庫或者原生擴展，在Ruby中則這兩者的界限不是很明顯，他們甚至會提供兩套實現，一個主要用于在無法編譯的環境下使用，而在合適的環境則使用C實現的原生擴展，這樣在效率和可移植性上都可以保證。目前這些為PHP編寫的擴展通常都無法在其他的PHP實現中實現重用，HipHop的做法是對最為流行的擴展進行重寫。如果PHP擴展能和ZendAPI解耦，則在其他語言中重用這些擴展也將更加容易了。 ## 參考文獻 Extending and Embedding PHP