PHP腳本的執行在內部是有編譯和運行兩個流程中，具體是第一步把PHP腳本編譯產出 opcode中間碼，第二步是在Zend Engine上執行opcode中間碼，如下圖所示。正因爲存在這個兩步的過程，所以在生產環境中，一般都會採用opcode cache的方式，較少PHP腳本的編譯過程，從而提升PHP的運行性能。其中比較流行的opcode cache工具有eaccelerator、apc、xcache等。eaccelerator是其中比較典型的一款，當然eaccelerator也有單機cache的功能。本文主要深入eaccelerator的opcode cache緩存過程。
Eaccelerator的原理和分析結論
Eacc是一個標準的opcode cache + 共享內存單機cache。其中關於opcode cache部分的實現關鍵是採用eaccelerator_compile_file替換PHP原有的zend_compile_file。衆所周 知，PHP內部執行流程是：PHP代碼->編譯產出opcode-》執行opcode，這麼個三步走，其中opcode cache就是節省掉PHP編碼的編譯過程。
在Eaccelerator的內部也是按照這個步驟來做的。爲了提高大家閱讀效率，首先介紹下分析後的幾個結論：
- eaccelerator的opcode cache方式有兩種，內存+硬盤文件。
- 一個php文件對應一個opcode cache。也就是說opcode cache不會進行文件級別的meger。
- 無論是多進程和多線程，1個php文件只會對應唯一一個opcode cache。不會說多進程則對應多個。由於有讀寫檢查和衝突，所以不可避免的會引入鎖。（在apc中會有一個開關，進行是否開啓更新檢查。eaccelerator目前看起來沒有）
- 特別需要注意一點，在加載opcode cache的時候，是需要首先通過opcode重建類、方法到對應的符號表的（具體可以參考大話PHP之性能中的分析）。
- eaccelerator的鎖在多進程模式下是自旋鎖。（通常的php-fpm、apache下的prefork模式都是這種）。
- eaccelerator的鎖在多線程模式下是線程鎖+自旋鎖。（通常對應apache的worker模式）
由於這些鎖和一些opcode cache更新的檢查，會給PHP帶來一定的性能開銷（從目前初步測試來看，無論是多進程和多線程都回有不小的影響）。具體數據後續會給出。正因爲這些數據，後續有考慮把PHP的編譯和執行直接分成兩個步驟來做。
ok，據此，我們重點分析下eaccelerator_compile_file函數。
摘自:http://blog.xiuwz.com/2011/12/29/%E6%B7%B1%E5%85%A5%E5%88%86%E6%9E%90eaccelerator%E7%9A%84opcode%E7%BC%93%E5%AD%98%E5%8A%9F%E8%83%BD/