有幸參與2015年的PHP技術峰會（PHPCON），聽了鳥哥（惠新宸）的關於PHP7的新特性和效能優化的分享，一切都令人感到激動。鳥哥是國內最權威的PHP專家，他的分享有很多非常有價值的東西，我通過整理分享的PPT和收集相關資料，整理為這篇解讀性質的技術文章，希望能給做PHP開發的同學一些幫助。
PHP已經走過了20年的歷史，直到今天，PHP7都發布了RC版，據說，PHP7正式版應該會在2015年11月份左右釋出。PHP7對於上一個系列的PHP5.*，可以說是一個大規模的革新，尤其是在效能方面實現跨越式的大幅提升。
PHP是一種在全球範圍內被廣泛使用的Web開發語言，PHP7的革新也當然會給這些Web服務帶來更深刻的變化。這裡引用鳥哥PPT中的一個圖表（82%的Web站點有使用PHP作為開發語言）：
（注：一個web站點可以會使用多種語言作為它的開發語言）
（注：本文含有不少從鳥哥PPT裡的截圖，圖片版權歸鳥哥所有）
我們先看看兩張激動人心的效能測試結果圖：
Benchmark對比（圖片來自於PPT）：
PHP7的效能測試結果，效能壓測結果，耗時從2.991下降到1.186，大幅度下降60%。
WordPress的QPS壓測（圖片來自於PPT）：
而在WordPress專案中，PHP7對比PHP5.6，QPS提升2.77倍。
看完令人激動的效能測試結果對比，我們就進入正題哈。PHP7的新增特性很多，不過，我們會更聚焦於那些主要的變化。
一、新增特性和改變
1. 標量型別和返回型別宣告（Scalar Type Declarations & Scalar Type Declarations）
PHP語言一個非常重要的特點就是“弱型別”，它讓PHP的程式變得非常容易編寫，新手接觸PHP能夠快速上手，不過，它也伴隨著一些爭議。支援變數型別的定義，可以說是革新性質的變化，PHP開始以可選的方式支援型別定義。除此之外，還引入了一個開關指令declare(strict_type=1);，當這個指令一旦開啟，將會強制當前檔案下的程式遵循嚴格的函式傳參型別和返回型別。
例如一個add函式加上型別定義，可以寫成這樣：
如果配合強制型別開關指令，則可以變為這樣：
如果不開啟strict_type，PHP將會嘗試幫你轉換成要求的型別，而開啟之後，會改變PHP就不再做型別轉換，型別不匹配就會丟擲錯誤。對於喜歡“強型別”語言的同學來說，這是一大福音。
更為詳細的介紹：PHP7標量型別宣告RFC[翻譯]
2. 更多的Error變為可捕獲的Exception
PHP7實現了一個全域性的throwable介面，原來的Exception和部分Error都實現了這個介面（interface）， 以介面的方式定義了異常的繼承結構。於是，PHP7中更多的Error變為可捕獲的Exception返回給開發者，如果不進行捕獲則為Error，如果捕獲就變為一個可在程式內處理的Exception。這些可被捕獲的Error通常都是不會對程式造成致命傷害的Error，例如函式不存。PHP7進一步方便開發者處理，讓開發者對程式的掌控能力更強。因為在預設情況下，Error會直接導致程式中斷，而PHP7則提供捕獲並且處理的能力，讓程式繼續執行下去，為程式設計師提供更靈活的選擇。
例如，執行一個我們不確定是否存在的函式，PHP5相容的做法是在函式被呼叫之前追加的判斷function_exist，而PHP7則支援捕獲Exception的處理方式。
如下圖中的例子（截圖來源於PPT內）：
3. AST（Abstract Syntax Tree，抽象語法樹）
AST在PHP編譯過程作為一箇中介軟體的角色，替換原來直接從直譯器吐出opcode的方式，讓直譯器（parser）和編譯器（compliler）解耦，可以減少一些Hack程式碼，同時，讓實現更容易理解和可維護。
PHP5：
PHP7：
更多AST資訊：https://wiki.php.net/rfc/abstract_syntax_tree
4. Native TLS（Native Thread local storage，原生執行緒本地儲存）
PHP在多執行緒模式下（例如，Web伺服器Apache的woker和event模式，就是多執行緒），需要解決“執行緒安全”（TS，Thread Safe）的問題，因為執行緒是共享程式的記憶體空間的，所以每個執行緒本身需要通過某種方式，構建私有的空間來儲存自己的私有資料，避免和其他執行緒相互汙染。而PHP5採用的方式，就是維護一個全域性大陣列，為每一個執行緒分配一份獨立的儲存空間，執行緒通過各自擁有的key值來訪問這個全域性資料組。
而這個獨有的key值在PHP5中需要傳遞給每一個需要用到全域性變數的函式，PHP7認為這種傳遞的方式並不友好，並且存在一些問題。因而，嘗試採用一個全域性的執行緒特定變數來儲存這個key值。
相關的Native TLS問題：
https://wiki.php.net/rfc/native-tls
5. 其他新特性
PHP7新特性和變化不少，我們這裡並不全部展開來細說哈。
（1） Int64支援，統一不同平臺下的整型長度，字串和檔案上傳都支援大於2GB。
（2） 統一變數語法（Uniform variable syntax）。
（3） foreach表現行為一致（Consistently foreach behaviors）
（4） 新的操作符 <=>, ??
（5） Unicode字元格式支援（\u{xxxxx}）
（6） 匿名類支援（Anonymous Class）
… …
二、跨越式的效能突破：全速前進
1. JIT與效能
Just In Time（即時編譯）是一種軟體優化技術，指在執行時才會去編譯位元組碼為機器碼。從直覺出發，我們都很容易認為，機器碼是計算機能夠直接識別和執行的，比起Zend讀取opcode逐條執行效率會更高。其中，HHVM（HipHop Virtual Machine，HHVM是一個Facebook開源的PHP虛擬機器）就採用JIT，讓他們的PHP效能測試提升了一個數量級，放出一個令人震驚的測試結果，也讓我們直觀地認為JIT是一項點石成金的強大技術。
而實際上，在2013年的時候，鳥哥和Dmitry（PHP語言核心開發者之一）就曾經在PHP5.5的版本上做過一個JIT的嘗試（並沒有釋出）。PHP5.5的原來的執行流程，是將PHP程式碼通過詞法和語法分析，編譯成opcode位元組碼（格式和彙編有點像），然後，Zend引擎讀取這些opcode指令，逐條解析執行。
而他們在opcode環節後引入了型別推斷（TypeInf），然後通過JIT生成ByteCodes，然後再執行。
於是，在benchmark（測試程式）中得到令人興奮的結果，實現JIT後效能比PHP5.5提升了8倍。然而，當他們把這個優化放入到實際的專案WordPress（一個開源部落格專案）中，卻幾乎看不見效能的提升，得到了一個令人費解的測試結果。
於是，他們使用Linux下的profile型別工具，對程式執行進行CPU耗時佔用分析。
執行100次WordPress的CPU消耗的分佈（截圖來自PPT）：
註解：
21%CPU時間花費在記憶體管理。
12%CPU時間花費在hash table操作，主要是PHP陣列的增刪改查。
30%CPU時間花費在內建函式，例如strlen。
25%CPU時間花費在VM（Zend引擎）。
經過分析之後，得到了兩個結論：
（1）JIT生成的ByteCodes如果太大，會引起CPU快取命中率下降（CPU Cache Miss）
在PHP5.5的程式碼裡，因為並沒有明顯型別定義，只能靠型別推斷。儘可能將可以推斷出來的變數型別，定義出來，然後，結合型別推斷，將非該型別的分支程式碼去掉，生成直接可執行的機器碼。然而，型別推斷不能推斷出全部型別，在WordPress中，能夠推斷出來的型別資訊只有不到30%，能夠減少的分支程式碼有限。導致JIT以後，直接生成機器碼，生成的ByteCodes太大，最終引起CPU快取命中大幅度下降（CPU Cache Miss）。
CPU快取命中是指，CPU在讀取並執行指令的過程中，如果需要的資料在CPU一級快取（L1）中讀取不到，就不得不往下繼續尋找，一直到二級快取（L2）和三級快取（L3），最終會嘗試到記憶體區域裡尋找所需要的指令資料，而記憶體和CPU快取之間的讀取耗時差距可以達到100倍級別。所以，ByteCodes如果過大，執行指令數量過多，導致多級快取無法容納如此之多的資料，部分指令將不得不被存放到記憶體區域。
CPU的各級快取的大小也是有限的，下圖是Intel i7 920的配置資訊：
因此，CPU快取命中率下降會帶來嚴重的耗時增加，另一方面，JIT帶來的效能提升，也被它所抵消掉了。
通過JIT，可以降低VM的開銷，同時，通過指令優化，可以間接降低記憶體管理的開發，因為可以減少記憶體分配的次數。然而，對於真實的WordPress專案來說，CPU耗時只有25%在VM上，主要的問題和瓶頸實際上並不在VM上。因此，JIT的優化計劃，最後沒有被列入該版本的PHP7特性中。不過，它很可能會在更後面的版本中實現，這點也非常值得我們期待哈。
（2）JIT效能的提升效果取決於專案的實際瓶頸
JIT在benchmark中有大幅度的提升，是因為程式碼量比較少，最終生成的ByteCodes也比較小，同時主要的開銷是在VM中。而應用在WordPress實際專案中並沒有明顯的效能提升，原因WordPress的程式碼量要比benchmark大得多，雖然JIT降低了VM的開銷，但是因為ByteCodes太大而又引起CPU快取命中下降和額外的記憶體開銷，最終變成沒有提升。
不同型別的專案會有不同的CPU開銷比例，也會得到不同的結果，脫離實際專案的效能測試，並不具有很好的代表性。
2. Zval的改變
PHP的各種型別的變數，其實，真正儲存的載體就是Zval，它特點是海納百川，有容乃大。從本質上看，它是C語言實現的一個結構體（struct）。對於寫PHP的同學，可以將它粗略理解為是一個類似array陣列的東西。
PHP5的Zval，記憶體佔據24個位元組（截圖來自PPT）：
PHP7的Zval，記憶體佔據16個位元組（截圖來自PPT）：
Zval從24個位元組下降到16個位元組，為什麼會下降呢，這裡需要補一點點的C語言基礎，輔助不熟悉C的同學理解。struct和union（聯合體）有點不同，Struct的每一個成員變數要各自佔據一塊獨立的記憶體空間，而union裡的成員變數是共用一塊記憶體空間（也就是說修改其中一個成員變數，公有空間就被修改了，其他成員變數的記錄也就沒有了）。因此，雖然成員變數看起來多了不少，但是實際佔據的記憶體空間卻下降了。
除此之外，還有被明顯改變的特性，部分簡單型別不再使用引用。
Zval結構圖（來源於PPT中）：
圖中Zval的由2個64bits（1位元組=8bit，bit是“位”）組成，如果變數型別是long、bealoon這些長度不超過64bit的，則直接儲存到value中，就沒有下面的引用了。當變數型別是array、objec、string等超過64bit的，value儲存的就是一個指標，指向真實的儲存結構地址。
對於簡單的變數型別來說，Zval的儲存變得非常簡單和高效。
不需要引用的型別：NULL、Boolean、Long、Double
需要引用的型別：String、Array、Object、Resource、Reference
3. 內部型別zend_string
Zend_string是實際儲存字串的結構體，實際的內容會儲存在val（char，字元型）中，而val是一個char陣列，長度為1（方便成員變數佔位）。
結構體最後一個成員變數採用char陣列，而不是使用char*，這裡有一個小優化技巧，可以降低CPU的cache miss。
如果使用char陣列，當malloc申請上述結構體記憶體，是申請在同一片區域的，通常是長度是sizeof(_zend_string) + 實際char儲存空間。但是，如果使用char*，那個這個位置儲存的只是一個指標，真實的儲存又在另外一片獨立的記憶體區域內。
使用char[1]和char*的記憶體分配對比：
從邏輯實現的角度來看，兩者其實也沒有多大區別，效果很類似。而實際上，當這些記憶體塊被載入到CPU的中，就顯得非常不一樣。前者因為是連續分配在一起的同一塊記憶體，在CPU讀取時，通常都可以一同獲得（因為會在同一級快取中）。而後者，因為是兩塊記憶體的資料，CPU讀取第一塊記憶體的時候，很可能第二塊記憶體資料不在同一級快取中，使CPU不得不往L2（二級快取）以下尋找，甚至到記憶體區域查到想要的第二塊記憶體資料。這裡就會引起CPU Cache Miss，而兩者的耗時最高可以相差100倍。
另外，在字串複製的時候，採用引用賦值，zend_string可以避免的記憶體拷貝。
6. PHP陣列的變化（HashTable和Zend Array）
在編寫PHP程式過程中，使用最頻繁的型別莫過於陣列，PHP5的陣列採用HashTable實現。如果用比較粗略的概括方式來說，它算是一個支援雙向連結串列的HashTable，不僅支援通過陣列的key來做hash對映訪問元素，也能通過foreach以訪問雙向連結串列的方式遍歷陣列元素。
PHP5的HashTable（截圖來自於PPT）：
這個圖看起來很複雜，各種指標跳來跳去，當我們通過key值訪問一個元素內容的時候，有時需要3次的指標跳躍才能找對需要的內容。而最重要的一點，就在於這些陣列元素儲存，都是分散在各個不同的記憶體區域的。同理可得，在CPU讀取的時候，因為它們就很可能不在同一級快取中，會導致CPU不得不到下級快取甚至記憶體區域查詢，也就是引起CPU快取命中下降，進而增加更多的耗時。
PHP7的Zend Array（截圖來源於PPT）：
新版本的陣列結構，非常簡潔，讓人眼前一亮。最大的特點是，整塊的陣列元素和hash對映表全部連線在一起，被分配在同一塊記憶體內。如果是遍歷一個整型的簡單型別陣列，效率會非常快，因為，陣列元素（Bucket）本身是連續分配在同一塊記憶體裡，並且，陣列元素的zval會把整型元素儲存在內部，也不再有指標外鏈，全部資料都儲存在當前記憶體區域內。當然，最重要的是，它能夠避免CPU Cache Miss（CPU快取命中率下降）。
Zend Array的變化：
（1） 陣列的value預設為zval。
（2） HashTable的大小從72下降到56位元組，減少22%。
（3） Buckets的大小從72下降到32位元組，減少50%。
（4） 陣列元素的Buckets的記憶體空間是一同分配的。
（5） 陣列元素的key（Bucket.key）指向zend_string。
（6） 陣列元素的value被嵌入到Bucket中。
（7） 降低CPU Cache Miss。
7. 函式呼叫機制（Function Calling Convention）
PHP7改進了函式的呼叫機制，通過優化引數傳遞的環節，減少了一些指令，提高執行效率。
PHP5的函式呼叫機制（截圖來自於PPT）：
圖中，在vm棧中的指令send_val和recv引數的指令是相同，PHP7通過減少這兩條重複，來達到對函式呼叫機制的底層優化。
PHP7的函式呼叫機制（截圖來自於PPT）：
8. 通過巨集定義和行內函數（inline），讓編譯器提前完成部分工作
C語言的巨集定義會被在預處理階段（編譯階段）執行，提前將部分工作完成，無需在程式執行時分配記憶體，能夠實現類似函式的功能，卻沒有函式呼叫的壓棧、彈棧開銷，效率會比較高。行內函數也類似，在預處理階段，將程式中的函式替換為函式體，真實執行的程式執行到這裡，就不會產生函式呼叫的開銷。
PHP7在這方面做了不少的優化，將不少需要在執行階段要執行的工作，放到了編譯階段。例如引數型別的判斷（Parameters Parsing），因為這裡涉及的都是固定的字元常量，因此，可以放到到編譯階段來完成，進而提升後續的執行效率。
例如下圖中處理傳遞引數型別的方式，從左邊的寫法，優化為右邊巨集的寫法。
三、小結
鳥哥的PPT裡放出過一組對比資料，就是WordPress在PHP5.6執行100次會產生70億次的CPU指令執行數目，而在PHP7中只需要25億次，減少64.2%，這是一個令人震撼的資料。
在鳥哥的整個分享中，給我最深刻的一個觀點是：要注意細節，很多個細小的優化，一點點持續地積累，積少成多，最終匯聚為驚豔的成果。為山九仞，豈一日之功，我想大概也是這個道理。
毫無疑問，PHP7在效能方面實現跨越式的提升，如果能夠將這些成果應用在PHP的Web系統中，也許我們只需要更少的機器，就可以支撐起更高請求量的服務。PHP7正式版的釋出，令人充滿無限憧憬。