淺析php錯誤處理，自動載入，棧堆記憶體以及運行模式

本篇文章給大家分享的內容是淺析php錯誤處理，自動載入，棧堆記憶體以及運行模式，有著一定的參考價值，有需要的朋友可以參考一下

Php錯誤處理

Php錯誤層級:

E_ERROR 致命錯誤,會終止指令碼運行.值為1

E_WARNING 警告錯誤,給出提示,不會終止運行值為2

E_PARSE 編譯時間的文法解析錯誤,解析錯誤僅僅由分析器產生。值為4

E_NOTICE 運行時通知錯誤,表示指令碼可能會遇到錯誤的情況 值為8

E_CORE_ERROR 在PHP初始化啟動過程中發生的致命錯誤。該錯誤類似 E_ERROR，但是是由PHP引擎核心產生的。值為16

E_CORE_WARNING PHP初始化啟動過程中發生的警告 (非致命錯誤) 。類似 E_WARNING，但是是由PHP引擎核心產生的。值為32

E_COMPILE_ERROR 致命編譯時間錯誤。類似E_ERROR, 但是是由Zend指令碼引擎產生的。值為64

E_COMPILE_WARNING 編譯時間警告 (非致命錯誤)。類似 E_WARNING，但是是由Zend指令碼引擎產生的。值為128

E_USER_ERROR 使用者產生的錯誤資訊。類似 E_ERROR, 但是是由使用者自己在代碼中使用PHP函數 trigger_error()來產生的。值為256

E_USER_WARNING 使用者產生的警告資訊。類似 E_WARNING, 但是是由使用者自己在代碼中使用PHP函數 trigger_error()來產生的。值為512

E_USER_NOTICE 使用者產生的通知資訊。類似 E_NOTICE, 但是是由使用者自己在代碼中使用PHP函數 trigger_error()來產生的。值為1024

E_STRICT 啟用 PHP 對代碼的修改建議，以確保代碼具有最佳的互通性和向前相容性。值為2048

E_RECOVERABLE_ERROR可被捕捉的致命錯誤。 它表示發生了一個可能非常危險的錯誤，但是還沒有導致PHP引擎處於不穩定的狀態。 如果該錯誤沒有被使用者自訂控制代碼捕獲 (參見 set_error_handler())，將成為一個 E_ERROR　從而指令碼會終止運行。值為4096

E_DEPRECATED 運行時通知。啟用後將會對在未來版本中可能無法正常工作的代碼給出警告。值為8192

E_USER_DEPRECATED使用者產少的警告資訊。 類似 E_DEPRECATED, 但是是由使用者自己在代碼中使用PHP函數 trigger_error()來產生的。 值為16384

E_ALL 表示E_STRICT除外的所有錯誤和警告資訊。 值為 30719

使用位元運算符組合顯示或屏蔽的錯誤(二進位許可權判斷)

Php有關於錯誤的配置

error_reporting 設定錯誤報表的層級,層級設定可看上面

其預設值為 E_ALL & ~E_NOTICE,表示顯示除了E_NOTICE以及E_STRICT的所有錯誤

E_STRICT錯誤層級不包含在E_ALL裡,必須自己明確啟用該層級才能出現

在php以外使用錯誤層級常量是沒有意義的,可以用十進位數字代替,比如2147483647 包含了所有的錯誤

display_errors 是否將錯誤輸出到螢幕上

雖然可以使用ini_set重新設定,但是當php發生致命錯誤時,是無法設定的

display_startup_errors 是否顯示啟動時的錯誤

log_errors 是否將指令碼的錯誤資訊記錄到log

log_errors_max_len

設定 log_errors 的最大位元組數. 在 error_log 會添加有關錯誤源的資訊。預設值為1024，如果設定為0表示不限長度。該長度設定對記錄的錯誤，顯示的錯誤，以及 $php_errormsg都會有限制作用。

ignore_repeated_errors

不記錄重複的錯誤資訊,

ignore_repeated_source

忽略重複訊息時，也忽略訊息的來源。當該設定開啟時，重複資訊將不會記錄它是由不同的檔案還是不同的原始碼行產生的。

report_memleaks

如果這個參數設定為Off，則記憶體泄露資訊不會顯示 (在 stdout 或者日誌中)。This report will be send to stderr on Posix platforms. On Windows, it will be send to the debugger using OutputDebugString(), and can be viewed with tools like » DbgView。這隻對調試編譯有效，而且需要 error_reporting 包含了 E_WARNING 才會起作用

track_errors

如果開啟，最後的一個錯誤將永遠存在於變數 $php_errormsg 中。

html_errors

在錯誤資訊中關閉HTML標籤。這種新的HTML格式的錯誤資訊是可以點擊，它引導使用者前往描述該錯誤或者導致該錯誤發生的函數的參考資訊頁面。 這些參考與 docref_root 和 docref_ext 的設定有關。

error_prepend_string string

錯誤資訊之前輸出的內容。

error_append_string string

錯誤資訊之後輸出的內容。

error_log

設定指令碼錯誤將被記錄到的檔案。該檔案必須是web伺服器使用者可寫的。如果特殊值 syslog 被設定，則將錯誤資訊發送到系統日誌記錄器。在Unix以及類似系統上，使用的是 syslog(3) ，而在 Windows NT 類系統上則為事件記錄。Windows 95上不支援系統日誌記錄。參見： syslog(). 如果該配置沒有設定，則錯誤資訊會被發送到 SAPI 錯誤記錄器。例如，出現在Apache的錯誤記錄檔中，或者在CLI中發送到 stderr。

錯誤處理相關方法以及用法個人理解

debug_backtrace — 產生一條回溯跟蹤(backtrace) 可設定參數限制返回的堆棧數量,

可以查出調用該函數的堆棧資訊,對查錯很有協助,和tp的debug類似

debug_print_backtrace();直接列印回溯,和debug_backtrace類似,

error_clear_last — 清除最近一次錯誤

error_get_last — 擷取最後發生的錯誤

error_log — 發送錯誤資訊到某個地方,可將錯誤存進一個檔案,但是錯誤資訊不能有null

error_reporting — 設定應該報告何種 PHP 錯誤,和php.ini 一樣

restore_error_handler — 還原之前的錯誤處理函數,

restore_exception_handler — 恢複之前定義過的異常處理函數。

set_error_handler — 設定使用者自訂的錯誤處理函數,需要在錯誤之前就定義

以下層級的錯誤不能由使用者定義的函數來處理： E_ERROR、 E_PARSE、 E_CORE_ERROR、 E_CORE_WARNING、 E_COMPILE_ERROR、 E_COMPILE_WARNING，和在 調用 set_error_handler() 函數所在檔案中產生的大多數 E_STRICT。

就像error_reporting 的 ini 設定能夠控制錯誤的顯示一樣， 第2個參數能夠用於屏蔽 error_handler 的觸發。 如果沒有該掩碼， 無論 error_reporting 是如何設定的， error_handler 都會在每個錯誤發生時被調用。

set_exception_handler — 設定使用者自訂的異常處理函數

trigger_error — 產生一個使用者層級的 error/warning/notice 資訊

user_error — trigger_error 的別名

register_shutdown_function 在php終止指令碼之後執行的註冊函數,第一個參數支援函數,以及一個包含執行個體化類的語句,類方法的數組(註冊時會先執行個體化該類);(只要註冊成功,啥錯誤都可以捕獲)

Php自動載入

個人見解

spl_autoload_register 和__autoload主要區別在於

__autoload 只是個函數 只能在php中定義一次,如果要載入外掛程式等,需要不斷的if else判斷,或者是composer,將會很麻煩

spl_autoload_register 可以根據檔案夾,或外掛程式,自訂各種處理函數,創造一個自動載入的隊列,會根據隊列一直找下去;直到隊列完畢或者返回true(找到檔案預設返回true)

堆棧記憶體(個人理解)

堆:存放使用者定義變數的

棧:在函數中定義的一些基本類型變數,對象的引用變數,都在棧空間,超出該範圍時將會自動釋放

資料補充:

堆:

當在檔案中定義的變數被static修飾之後,將改變到全域資料區,不佔用堆棧記憶體

棧:

棧記憶體一般儲存的是函數的調用資訊和函數中申明的變數，因為函數的調用是遞迴的，外層函數一定比內層被調用的函數先載入和執行，而一定等到內層被調用函數結束後才能結束，這個先進後出的機制就是為什麼叫棧記憶體的原因。

PS：在編譯時間編譯器會先收集此函數中所有定義的變數，將他們放在函數最前面申請記憶體，所以他們進出棧的順序不是你在編寫程式時定義的順序，而是在函數執行前進棧，函數執行完成後出棧。

其他:

Const,global,static修飾之後都存放在全域資料區

超全域變數,全域變數,都屬於靜態變數,存放在全域資料區

資料較少,等待糾正以及完善

Phpweb運行模式

Php運行模式:

1）CGI（通用閘道介面/ Common Gateway Interface）

一般是可執行程式，例如EXE檔案，和WEB伺服器各自佔據著不同的進程,而且一般一個CGI程式只能處理一個使用者請求。這樣，當用 戶請求數量非常多時，會大量佔用系統的資源，如記憶體、CPU時間等，造成效能低下。

1. 2.FastCGI（常駐型CGI / Long-Live CGI）

FastCGI是CGI的升級版本，FastCGI像是一個常駐 (long-live)型的 CGI，它可以一直執行著，只要啟用後，不會每次都要花費時間去 Fork 一次 （這是 CGI 最為人詬病的 fork-and-execute 模式）。

FastCGI是一個可伸縮地、高速地在HTTP server和動態指令碼語言間通訊的介面。多數流行的HTTP server都支援FastCGI，包括Apache、Nginx和lighttpd等，同時，FastCGI也被許多指令碼語言所支援，其中就有PHP。

FastCGI介面方式採用C/S結構，可以將HTTP伺服器和指令碼解析伺服器分開，同時在指令碼解析伺服器上啟動一個或者多個指令碼解析守護進程。當HTTP伺服器每次遇到動態程式時，可以將其直接交付給FastCGI進程來執行，然後將得到的結果返回給瀏覽器。這種方式可以讓HTTP伺服器專一地處理靜態請求或者將動態指令碼伺服器的結果返回給用戶端，這在很大程度上提高了整個應用系統的效能。

Php-fpm 是php中內建的fastcgi管理器

3）CLI（命令列運行 / Command Line Interface）

1. 4.Web模組模式（Apache等Web伺服器啟動並執行模式)

該模式是apache在cgi基礎上的一個擴充

1. 5.ISAPI（Internet Server Application Program Interface)是微軟提供的一套面向WEB服務的API介面，它能實現CGI提供的全部功能，並在此基礎上進行了擴充，如提供了過濾器應用程式接 口。ISAPI應用大多數以DLL動態庫的形式使用，可以在被使用者請求後執行，在處理完一個使用者請求後不會馬上消失，而是繼續駐留在記憶體中等待處理別的 使用者輸入。此外，ISAPI的DLL應用程式和WEB伺服器處於同一個進程中，效率要顯著高於CGI。

Php2種與web伺服器互動:

Nginx:

使用者發起請求,以nginx現行握手,當nginx接收到之後,推送給php-fpm進行處理,當php-fpm繁忙時,nginx將返回504 getway

Apache:

Apache有3種運行模式,prefork,worker,Event,

根據不同的模式而建立不同的處理進程以及線程,接收到有關php時則交給apache模組處理