1：将成员变量设置为public，通过赋值操作给成员变量赋值，直接获取变量

	class Foo {
		public $id;
	}
 
	$data = new Foo;
	$data->id = 10;
	echo $data->id;

2：将成员变量设置为public，通过构造函数设置成员变量的值，直接获取变量

        class Foo2 {
		public $id;
		public function __construct($id) {
			$this->id = $id;
		}
	}
 
	$data = new Foo2(10);
	echo $data->id;

3：将成员变量设置为protected，通过构造函数设置成员变量的值，通过成员方法获取变量

 
     class Foo3 {
		protected $id;
		public function __construct($id) {
			$this->id = $id;
		}
 
		public function getId() {
			return $this->id;
		}
	}
	$data = new Foo3(10);
	echo $data->getId();

4：将成员变量设置为protected，通过构造函数设置成员变量的值，通过魔术方法获取变量

 
     class Foo4 {
		protected $id;
		public function __construct($id) {
			$this->id = $id;
		}
 
		public function __get($key) {
			return $this->id;
		}
	}
	$data = new Foo4(10);
	echo $data->id;

按执行速度快慢排序： 1243
咱们先看其opcode:

1:

   	1  ZEND_FETCH_CLASS	4 	:4 	'Foo'
	2  NEW      			$5	:4
	3  DO_FCALL_BY_NAME			0          
	4  ASSIGN     				!0, $5
	5  ZEND_ASSIGN_OBJ			!0, 'id'
	6  ZEND_OP_DATA				10
	7  FETCH_OBJ_R			$9	!0, 'id'
	8  ECHO        				$9

2:

	1  ZEND_FETCH_CLASS	4 	:10	'Foo2'
	2  NEW             		$11	:10
	3  SEND_VAL        			10
	4  DO_FCALL_BY_NAME		1 
	5  ASSIGN    				!1, $11
	6  FETCH_OBJ_R			$14	!1, 'id'
	7  ECHO        				$14

3:

	1  ZEND_FETCH_CLASS	4 	:15	'Foo3'
	2  NEW         			$16	:15
	3  SEND_VAL     			10
	4  DO_FCALL_BY_NAME			1          
	5  ASSIGN  	   			!2, $16
	6  ZEND_INIT_METHOD_CALL	!2, 'getId'
	7  DO_FCALL_BY_NAME		0 	$20     
	8  ECHO       				$20

4:

	1  ZEND_FETCH_CLASS	4  :21	'Foo4'
	2  NEW          		$22	:21
	3  END_VAL      			10
	4  DO_FCALL_BY_NAME		1          
	5  ASSIGN        			!3, $22
	6  FETCH_OBJ_R  		$25 !3, 'id'
	7   ECHO  				$25

根据上面的opcode，参照其在zend_vm_execute.h文件对应的opcode实现，我们可以发现什么？

一、PHP内核创建对象的过程分为三步：

1. ZEND_FETCH_CLASS 根据类名获取存储类的变量，其实现为一个hashtalbe EG(class_table) 的查找操作
2. NEW 初始化对象，将EX(call)->fbc指向构造函数指针。
3. 调用构造函数，其调用和其它的函数调用是一样，都是调用zend_do_fcall_common_helper_SPEC

二、魔术方法的调用是通过条件触发的，并不是直接调用，如我们示例中的成员变量id的获取（zend_std_read_property），其步骤为:

1. 获取对象的属性，如果存在，转第二步；如果没有相关属性，转第三步
2. 从对象的properties查找是否存在与名称对应的属性存在，如果存在返回结果，如果不存在，转第三步
3. 如果存在__get魔术方法，则调用此方法获取变量，如果不存在，报错

回到排序的问题：

一、第一个和第二个的区别是什么？

第二个的opcode比第一个要少，反而比第一个要慢一些，因为构造函数多了参数，多了一个参数处理的opcode。参数处理是一个比较费时的操作，当我们在做代码优化时，一些不必要的参数能去掉就去掉；当一个函数有多个参数时，可以考虑通过一个数组将其封装后传递进来。

二、为啥第三个最慢？

因为其获取参数其本质上是一次对象成员方法的调用，方法的调用成本高于变量的获取

三、为啥第四个比第三个要快？

因为第四个的操作实质上获取变量，只不过其内部实现了魔术方法的调用，相对于用户定义的方法，内部函数的调用的效率会高。因此，当我们有一些PHP内核实现的方法可以调用时就不要重复发明轮子了。

四、为啥第四个比第二个要慢？

因为在PHP的对象获取变量的过程中，当成员变量在类的定义不在在时，会去调用PHP特有的魔术方法__get，多了一次魔术方法的调用。

总结一下：

1. 使用PHP内置函数
2. 并不是事必面向对象(OOP)，面向对象往往开销很大，每个方法和对象调用都会消耗很多内存。
3. 尽量少用魔术方法 — 除非有必要，不要用框架，因为框架都有大量的魔术方法使用。
4. 在性能优先的应用场景中，将成员变量设置为public，不失为一种比较好的方法，当你需要用到OOP时。
5. 能使用PHP语法结构的不要用函数，能使用内置函数的不要自己写，能用函数的不要用对象

http://www.php.net/manual/zh/language.variables.basics.php

	$this = 'text'; // error
	$name = 'this';
	$$name = 'text'; // sets $this to 'text'
	echo $$name;

在PHP的词法分析时，$this变量是符合其规则的，在语法解析生成中间代码时，PHP内核会根据变量类型在生成赋值的中间代码时判断是否为$this变量，如果是则报错。这里为什么要报错呢？因为this作为一个特殊的变量，在对象的成员方法等调用初始化时会将this变量添加到活动符号表。

在类的成员方法里面，可以用 ->（对象运算符）：$this->property（其中 property 是该属性名）这种方式来访问非静态属性。

当一个方法在类定义内部被调用时，有一个可用的伪变量 $this。$this 是一个到主叫对象的引用（通常是该方法所从属的对象，但如果是从第二个对象静态调用时也可能是另一个对象）。

在词法分析、语法分析并生成中间代码时，$this作为一个特殊的变量存在，特别是在生成中间代码时，代码中充斥着对于this的特殊处理。这些都是为后面的运行做准备，如识别标记出某处使用this变量，在存储opcode的zend_op_array结构体中专门有一个变量this_var标识是否有this变量。一个函数或一个类方法都会生成一个新的zend_op_array，在生成中间代码时，判断当前变量是否为this变量。

this变量在执行过程中会有两种存在状态，一种是全局传递的状态，存储在EG(This)，一种是当前作用域状态，以this变量存储在EG(active_symbol_table)（当前执行环境的活动符号表）。
在我们执行一个 op_array 时，比如一个对象的方法，PHP内核会给这个 op_array 生成一个 zendexecutedata ,在生成初始化时，EG(This) 会添加到EG(active_symbol_table) 。
在方法调用过程中，如果有用到this变量，则会直接取EG(active_symbol_table)的值。

那么一个对象中的EG(This)在哪里初始化呢？
就EG(This)变量本身来说，在我们初始化PHP的执行环境时，它和其它全局变量(如EG(scope)等)一样都会被初始化为NULL。
对于一个对象来说，当我们创建了一个对象，调用时，PHP内核会将当前获得的对象直接赋值给EG(This)，而这个当前获得的对象是在通过new操作生成对象时创建的对象本身。

如下这个简单示例：

	class Foo {
	     public $var = 10;
 
	     function t() {
	          echo $this->var;     
	     }
 
	     function t2() {
	     	echo 33;
		}
	}
 
	$foo = new Foo();
	$foo->t();

其主程序流程生成的中间代码如下：

        function name:  (null)
	number of ops:  8
	compiled vars:  !0 = $foo
	line     # *  op                           fetch          ext  return  operands
	---------------------------------------------------------------------------------
	   2     0  >   NOP                                                      
	  15     1      ZEND_FETCH_CLASS                              4  :1      'Foo'
	         2      NEW                                              $2      :1
	         3      DO_FCALL_BY_NAME                              0          
	         4      ASSIGN                                                   !0, $2
	  16     5      ZEND_INIT_METHOD_CALL                                    !0, 't'
	         6      DO_FCALL_BY_NAME                              0          
	         7    > RETURN                                                   1

this变量原始的对象值出生在 opcode NEW，经过了赋值（ASSIGN）后，在方法初始化时，将变量本身传递给执行环境的调用者，调用者又在执行调用（DO_FCALL_BY_NAME）时将变量传递给EG(This)，当执行这个方法的op_array时，初始化当前作用域的环境（zend_execute_data）时，会将EG(This)作为$this变量添加到活动符号表，后续方法中的$this变量的使用就会直接取符号表的变量。

在PHP的实现过程中，包括PHP语言本身的词法分析，一共有多达8处的地方使用了re2c，如果我们常用的时间函数、pdo扩展等。对re2c的了解更能促进我们进PHP内核实现的认知。

本手册是re2c官网的manual.html文件翻译稿，仅适用于对re2c的初步了解，更多的资料见re2c项目中lessons目录和doc目录。

Name

re2c – 将正则表达式转化成C/C++代码

Synopsisre2c [-bdDefFghisuvVw1] [-o output] [-c [-t header]] file

Description

re2c是一个将正则表达式转化成基于C语言标识的预处理器。

re2c的输入包含C/C++代码，并且以/*!re2c… */注释的格式将扫描标识交错嵌入到这些代码中。在它的输出中，这些注释将会被生成的代码替换掉，当执行时，它将会查找到下一个token，并且执行用户提供的针对该token的特定代码。
如下示例：

char *scan(char *p)
	{
	/*!re2c
	        re2c:define:YYCTYPE  = "unsigned char";
	        re2c:define:YYCURSOR = p;
	        re2c:yyfill:enable   = 0;
	        re2c:yych:conversion = 1;
	        re2c:indent:top      = 1;
	        [0-9]+          {return p;}
	        [^]             {return (char*)0;}
	*/
	}

re2c将生成如下代码：

/* Generated by re2c on Sat Apr 16 11:40:58 1994 */
	char *scan(char *p)
	{
	    {
	        unsigned char yych;
 
	       yych = (unsigned char)*p;
	        if(yych <= '/') goto yy4;
	        if(yych >= ':') goto yy4;
	        ++p;
	        yych = (unsigned char)*p;
	        goto yy7;
	yy3:
	        {return p;}
	yy4:
	        ++p;
	        yych = (unsigned char)*p;
	        {return char*)0;}
	yy6:
	        ++p;
	        yych = (unsigned char)*p;
	yy7:
	        if(yych <= '/') goto yy3;
	        if(yych <= '9') goto yy6;
	        goto yy3;
	    }
 
	}

你可以通过添加注释：/*!max:re2c/ 来输出一个宏定义 YYMAXFILL 来保存输入解析时字符的最大个数。如果使用了-1, YYMAXFILL 只能在最后的 /*!re2c/ 后触发一次。同时，你也可以使用 /*!ignore:re2c */ 来为扫描代码添加注释文档，它们被输出。

Options

re2c提供如下的选项：

• -?
• -h 帮助
• -b 当指定-b参数时，-s参数也会被默认同时指定。 使用位向量尝试着从编译器捣鼓出更好的代码。它对于关键字比较多的规则很有用，比如大部分的编程语言。re2c的实现是通过生成256个ascii字符的映射表，直接判断对应的字符串是否应该跳转到下一个字符，从而实现优化。
• -c 支持类lex或flex的表达式
• -d 创建一个解析器用来打印当前位置的信息，这对于调试非常有用。如果你要使用它，你需要定义一个供解析器调用的YYDEBUG宏，它像一个函数一样，接受两个参数：void YYDEBUG(int state,char current)。第一个参数是state或者-1，第二个参数是当前所解析的代码位置。在每个++YYCURSOR、不同的goto跳转变化处，re2c自动添加YYDEBUG宏调用。如果在规则文件中没定义YYDEUBG宏，在编译C文件时会出错。
• -D 输出Graphviz dot 格式的数据，比如可以使用” dot -Tpng input.dot > output.png”来处理生成图片。注意扫描器中如果包含太多的状态可能会让dot程序崩溃
• -e 从ASCII平台交叉编译EBCDIC
• -f 生成带可存储状态的扫描器。更多详情见下面的可存储的扫描器小节。
• -F 部分支持flex语法。当-F标记有效时，flex的变量用大括号括起来，并且在定义时不需要等号，在结束时不需要用分号。否则，名字被认为是直接被引号的字符串。
• -g 使用GCC的goto特性生成扫描器。当决策复杂时re2c会生成决策跳转表，使用goto针对不同的情况做不同的跳转。仅适用于GCC编译器。注意，这里默认指定了-b参数。re2c的实现中，-g参数会生成yytarget决策跳转表，其实就是一个256个元素的一维数据，针对不同的字符，直接跳转，以优化扫描器。
• -i 不输出行信息，当你的用户从你的代码编译，而你又不要求他们拥有re2c环境，此时你可以使用CMS工具管理re2c的输出文件时，此参数就有用武之地了。-o参数指定输出文件。
  指在生成的.c文件中不使用#line宏。
• -r 允许扫描器在每个 ‘/!use:re2c’块后面重用定义的 ‘/!use:re2c’ 块。这些块可以包含适当的配置，特别是 ‘re2c:flags:w’和re2c:flags:u’。这种方法可能会为不同的字符类型，不同的输入机制或不同的输出机制多次创建相同的扫描器。’/!use:re2c’ 块也可以在 ‘/!rules:re2c’中的规则集中包含额外的规则。
• -s 为一些switch语句生成嵌套的if语句。许多编译器需要这个参数的辅助以便生成更好的代码。
• -t 生成一个类型定义的头文件，以支持类(f)lex条件，当需要使用-t参数时，需同时指定-c参数，-t参数后面接生成的头文件名称。如果只指定re2c会报错：re2c: error: Can only output a header file when using -c switch
• -u 生成一个支持Unicode编码的解析器。这意味着生成的代码能处理任何有效的Unicode字符，直到x10FFFF。当需要支持UTF-8或UTF-16时，你需要自己将输入的数据转化成UTF-32编码。
• -v 查看版本信息。如：re2c 0.13.6
• -V 以数字格式查看版本信息。如：001306
• -w 创建支持宽字符格式的解析器，默认指定-s参数，不能和-e参数共存。
• -1 强制一次生成，它不能和-f组合在一起使用，并且在re2c块结束之前不能禁用YYMAXFILL。
• –no-generation-date 禁止输出生成日志，所以只会输出re2c的版本信息。
• –case-insensitive 所有字符串不区分大小写，所以，双引号中的字符和单引号的意义一样。
• –case-inverted 颠倒单引号和双引号包含的字符中的意思，比如，有了这个开关，单引号内的字符串区分大小写，双引号内的字符串不区分大小写。

Interface Code接口代码

不像其他的扫描器程序，re2c 不会生成完整的扫描器：用户必须提供一些接口代码。用户必须定义下面的宏或者是其他相应的配置。

• YYCONDTYPE 用-c 模式你可以使用-t参数来生成一个包含了会被作为条件使用的枚举类型的文件。枚举类型中的每个值都会在规则集合里面作为条件来使用。
• YYCTYPE 用来维持一个输入符号。通常是 char 或者unsigned char。
• YYCTXMARKER *YYCTYPE类型的表达式，生成的代码回溯信息的上下文会保存在
• YYCTXMARKER。如果扫描器规则需要使用上下文中的一个或多个正则表达式，则用户需要定义这个宏。
• YYCURSOR *YYCTYPE类型的表达式指针指向当前输入的符号，生成的代码作为符号相匹配，在开始的地方，YYCURSOR假定指向当前token的第一个字符。在结束时，YYCURSOR将会指向下一个token的第一个字符。
• YYDEBUG(state,current) 这个只有指定-d标记的时候才会需要。调用用户定义的函数时可以非常容易的调试生成的代码。
  这个函数应该有以下签名：void YYDEBUG(int state,char current)。第一个参数接受 state ，默认值为-1第二个参数接受输入的当前位置。
• YYFILL(n) 当缓冲器需要填充的时候，生成的代码将会调用YYFILL(n)：至少提供n个字符。YYFILL(n)将会根据需要调整YYCURSOR,YYLIMIT,YYMARKER 和 YYCTXMARKER。注意在典型的程序语言当中，n等于最长的关键词的长度加一。用户可以在/*!max:re2c/一次定义YYMAXFILL来指定最长长度。如果使用了-1，YYMAXFILL将会在/*!re2c/之后调用一次阻塞。
• YYGETCONDITION() 如果使用了-c模式，这个定义将会在扫描器代码之前获取条件集。这个值必须初始化为枚举YYCONDTYPE的类型。
• YYGETSTATE() 如果指定了-f模式，用户就需要定义这个宏。此种情况下，扫描器在开始时为了获取保存的状态，生成的代码将会调用YYGETSTATE()。YYGETSTATE()必须返回一个有符号的整数，这个值如果是-1，告诉扫描器这是第一次执行，否则这个值等于以前YYSETSTATE(s) 保存的状态。否则，扫描器将会恢复操作之后立即调用YYFILL(n)。
• YYLIMIT 这是一个类型为*YYCTYPE的表达式，它标记了缓冲器的结尾（YYLIMIT[-1]是缓冲区的最后一个字符）。生成的代码将会不断的比较YYCORSUR 和 YYLIMIT 以决定 什么时候填充缓冲区。
• YYSETCONDITION(c) 这个宏用来在转换规则中设置条件，它只有在指定-c模式和使用转换规则时有用。
• YYSETSTATE(s) 用户只需要在指定-f模式时定义这个宏，如果是这样，生成的代码将会在YYFILL(n)之前调用YYSETSTATE(s)，YYSETSTATE的参数是一个有符号整型，被称为唯一的标示特定的YYFILL(n)实例。
• YYMARKER 类型为*YYCTYPE的表达式，生成的代码保存回溯信息到YYMARKER。一些简单的扫描器可能用不到。
• 解析器支持条件 当使用-c参数时，你可以使用正则表达式条件列表。这样re2c会为每个条件生成扫描块，在每一个生成的扫描器都有自己的先决条件。先决条件是定义YYGETCONDETION ，而且类型必须是YYCONDTYPE。
• YYSETSTATE(s) 用户只需要在指定-f模式时定义这个宏。在此种情况下，生成的代码将会在YYFILL(n)之前调用YYSETSTATE(s)，YYSETSTATE的参数是一个有符号整型，被称为唯一的标示特定的YYFILL(n)实例。如果用户希望保存扫描器的状态并用YYFILL(n) 将状态返回给调用 者，他所需要做的是在变量中保存这个唯一的标识。然后，当再次调用扫描器时，它将调用
• YYGETSTATE()并在恢复到之前离开的地方继续执行。即使禁用了 YYFILL(n) ，生成的代码也会包含YYSETSTATE(s)和YYGETSTATE。

Scanner With Storable States可存储状态的扫描器

当指定-f标记时，re2c会生成一个存储了它当前状态的扫描器，它能精确的恢复到之前离开的位置，并返回给调用者。

re2c的默认行为是拉模式，无论何时需要，它都可以要求额外的输入，然而，这种操作模式是基于扫描器可以控制解析循环这一前提的，而这个前提并不一定会存在。
通常情况下，如果有一个预处理过程或其它相关的源程序数据在扫描器之前先执行，则扫描器无法再要求更多的数据，除非他们都在独立的线程之中。

-f标记刚好可以解决这个问题：它让用户设计的扫描器以拉模式工作，即数据一块一块的输入到扫描器中。当扫描器运行数据时，它仅存储它的状态，并返回给调用者。当更多的输入数据输入到扫描器时，它能很精确的恢复到之前离开的位置。

当re2c使用-f选项时，它不能接收标准输入，因为它必须做两次完整的全局扫描，而两次扫描就需要读取两次。这就意味着，如果不能打开输入两次或第一次输入影响第二次输入，re2c会执行失败。

相对于拉模式，可存储的扫描器有以下不同：

1. 用户必须提供YYSETSTATE() 宏和YYGETSTATE(state)宏
2. -f参数禁止了yych和yyaccept的声明。因此用户必须声明这些，并且必须能够保存和恢复他们。在example/push.re文件的示例中，这些都被声明为C++类的字段，因此他们不再需要明确的保存或恢复。对于C语言来说，我们可以通过宏，以参数传递的方式从结构体中获取这些字段。或者，可以将他们声明为局部变量，当它决定返回并将之作为函数的一个项保存在 YYFILL(n)中。此外， 使用YYFILL(n)保存的效率更高，因为可以无条件的调用YYSETSTATE(state)。然而，YYFILL(n) 并不能将state作为参数，因此，我们必须通过YYSETSTATE(state)将state保存到局部变量中。
3. 如果需要更多的输入，需要修改YYFILL(n) ，使之可以从调用它的函数处返回。
4. 修改调用者的逻辑，使其在需要更多的输入时做出相应的应答。
5. 生成的代码中将包含一个选择逻辑块，这个选择逻辑会被用来通过跳转到相应的YYFILL(n)调用处，以恢复最后的状态。这个代码块会在第一个 “/*!re2c */”块收尾的地方自动生成。通过放置 “/*!getstate:re2c */”注释，可能会触发YYGETSTATE() 的生成操作。这对于被包含在循环中的扫描器非常有用。

请查看 examples/push.re文件中的推模式示例扫描器。它生成的代码可以通过”state:abort”和”state:nextlabel”调整。

Scanner With Condition Support 可判断条件的扫描

当使用-c参数时，你可以在正则表达式之前优先一系统的条件名。在这种情况下，re2c会针对每个条件生成扫描代码块。这些代码块都有它自己的前置条件，这此前置条件都是通过接口定义YYGETCONDITON实现，并且必须为YYCONDTYPE类型。

其中有两个特别的类型，一个是‘*’，它表示满足所有条件；另一个是空条件，它提供一个没有扫描内容的代码块，这意味着不需要任何正则表达式。这个特殊的块始终有一个固定的枚举值0。这些特殊的规则可以被用来初始化一个扫描器。这些特殊的规则并不是必须的，但是有时可以用它来声明一些没有初始化的状态。

非空规则允许指定新的条件，这些条件将导致规则的变化。它会生成定义的YYSETCONDTITION，除此之外再无其它。

还有另一种特殊的规则，它允许在所有的有规则和没有规则代码前添加代码。例如，它可以用来保存扫描的字符串的长度。这个特殊的规则以感叹号开始，后面可以接条件 <! condition, … > 或星号<!*>。当re2c为这个规则生成代码时，如果这个规则的状态没有起始规则或已经在在一个星号规则，那么这个代码将作为起始代码。

Scanner Specifications 扫描器规则

每个扫描器规格都由 规则集、命名定义和配置构成。

规则由正则以及紧跟其后面的C/C++代码构成，当正则匹配时，其后的C/C++代码会被执行。你可以以大括号或：=开始代码。当用大括号开始代码时，re2c会根据大括号判断其尝试并自动结束代码的查找。如果不使用大括号开始代码，则re2c会在第一行不为空时停止查找。

	regular-expression { C/C++ code }
	regular-expression := C/C++ code

如果指定-c参数，则每个正则前面都会有一系列的由逗号分隔的条件名称。除了正常命名的规则以外，有两种特殊的情况。一个规则可能包含一个单独的条件名称’*’和没有条件名称。对于没有条件名称的情况，其后面不能接正则表达式。非空规则可能会进一步指定新的条件。在这种情况下，re2c可能会自动生成必要的代码来改变条件。如上所示代码，其以大括号和’:=’开始代码。更进一步，更多的规则可以使用’:=>’快捷方式来自动生成代码，它不仅仅可以设置新的状态，还可以继续执行新的状态。一个快捷规则不应该在循环中使用，这些循环代码在循环开始和re2c块之间，除非用 re2c:cond:goto使之 ‘continue;’如果一段代码必须放在所有的规则之前，你可以使用<! 伪规则。

    <condition-list> regular-expression { C/C++ code }
    <condition-list> regular-expression := C/C++ code
    <condition-list> regular-expression => condition { C/C++ code }
    <condition-list> regular-expression => condition := C/C++ code
    <condition-list> regular-expression :=> condition
    <*> regular-expression { C/C++ code }
    <*> regular-expression := C/C++ code
    <*> regular-expression => condition { C/C++ code }
    <*> regular-expression => condition := C/C++ code
    <*> regular-expression :=> condition
    <> { C/C++ code }
    <> := C/C++ code
    <> => condition { C/C++ code }
    <> => condition := C/C++ code
    <> :=> condition
    <!condition-list> { C/C++ code }
    <!condition-list> := C/C++ code
    <!*> { C/C++ code }
    <!*> := C/C++ code

命名定义格式如下：

name = regular-expression;

如果使用了-F 模式，可以使用如下命名定义方法：

name regular-expression< /pre>
以"re2c"开始的命名定义配置如下所示：
<pre lang="c">re2c:name = value;
re2c:name = "value";

Summary Of Re2c Regular-expressionsre2c正则表达式小结

• “foo” 字符串foo。可以使用ANSI-C转义序列。
• [xyz] 字符集；此种情况匹配字符x,y或z
• [abj-oZ] 包含区间的字符集，此种情况匹配a,b,j到o之间的任一字符，或z
• [^class] 字符集否定匹配，匹配没有在方括号中定义的字符。
• r\s 匹配非s的正则，r和s都必须是可以表示为字符集的正则表达式
• r* 零次或多次匹配，r是任一正则表达式
• r+ 一次或多次匹配（至少一次）
• r? 零次或一次匹配
• name 这里name就是在前面的定义段给出的名字
• (r) 匹配规则表达式r，圆括号可以提高其优先级。
• rs 匹配规则表达式r，其后紧跟着表达式s。这称为联接(concatenation)。
• r|s 或者匹配规则表达式r，或者匹配表达式s。
• r/s 匹配模式r，但是要求其后紧跟着模式s。s并不会参与文本的匹配。这种正则表达式的匹配称之为“尾部上下文”
• r{n} n次匹配
• r{n,} 至少n次匹配
• r{n,m} 至少n次，至多m次匹配；匹配除换行符外的任意字符
• def 当没有使用-F参数时，匹配的命名定义通过def定义。当-F参数指定时，def语名和双引号包含的效果一样，直接匹配def字符串。字符集和字符串可能包含有八进制或十六进制或如下的转义字符 (\n, \t, \v, \b, \r, \f, \a, \)。一个八进制字符由一个反斜杠和紧跟着它的三个八进制数字组成，一个十六进制字符由一个反斜杠，一个小写的x，以及两个十六进制数字组成，或由一个反斜杠，一个大写的X，以及四个十六进制数字组成。re2c进一步会支持更多的C/C++的unicode符号。这些unicode符号由一个反斜杠+u+四个十六进制数字或一个反斜杠+U+八个十六进制的数字组成。然后，仅当-u模式下才能处理这些uincode字符。

在非unicode模式下，大于\X00FF的字符是无法直接匹配的，除非使用”万金油“类型的 (.|”\n”)和[^]正则表达式匹配所有的字符时，包含它们。

如上所示的正则表达式列表按优先级分组，从最上面的最高优先级到最下面的最低优先级。这些组合之间的优先级相同。

Inplace Configuration现场配置

它可能在re2c块中配置并生成代码，如下所示为可用的配置项：

• re2c:condprefix = yyc_ ;
  允许指定条件标签的前缀。它将在生成的输出文件中的所有条件标签前添加指定的前缀。
• re2c:condenumprefix = yyc ;
  允许指定条件值的前缀。它将在生成的输出文件中的所有条件枚举值前添加指定的前缀。
• re2c:cond:divider = “/* *********************************** */” ;
  允许为条件块自定义分隔符。你可以使用’@@’输出条件的名字或使用
• re2c:cond:divider@cond = @@ ;
  指定即将被 re2c:cond:divider中的条件名替换的占位符。
• re2c:cond:goto = “goto @@;” ;
  允许使用 ‘:=>’ 规则自定义条件跳转语句。你可以使用’@@’输出条件的名字或使用re2c:cond:divider@cond自定义占位符，同时你也可以使用此语句继续下一个循环周期，这个循环周期包括循环开始到re2c块之间的任何代码。
• re2c:cond:goto@cond = @@ ;
  指定即将在 re2c:cond:goto语句中被替换的条件标签占位符
• re2c:indent:top = 0 ;
  指定最小的缩进，大于或等于0
• re2c:indent:string = “\t” ;
  指定缩进用的字符串。除非你想使用外部工具，否则就需要只包含空白字符串。最简单的方法就是用单引号或双引号包含它们。如果你不需要任何缩进，直接使用””即可。
• re2c:yych:conversion = 0 ;
  当此设置非零时，re2c会在读取yych时自动生成转换代码。此时的类型必须使用re2c:define:YYCTYPE定义。
• re2c:yych:emit = 1 ;
  设置为0可以禁止yych的生成。
• re2c:yybm:hex = 0 ;
  如果设置为0，则生成一个十进制表格，否则将生成一个十六进制表格
• re2c:yyfill:enable = 1 ;
  将此设置为0可以禁止YYFILL(n)的生成。当使用它时请确认生成的扫描器在输入之后不再读取。允许此行为将给你的程序引入服务安全问题。
• re2c:yyfill:check = 1 ;
  当YYLIMIT + max(YYFILL)一直可用时，把此设置为0可以禁止使用YYCURSOR和YYLIMIT的先决条件的输出。
• re2c:yyfill:parameter = 1 ;
  允许禁止YYFILL调用的参数传递。如果设置为0，将没有任何参数传递到YYFILL。然而，define:YYFILL@LEN允许指定一个字符串替换实际字符中的长度。如果设置为非0，除非设置re2c:define:YYFILL:naked，否则YYFILL将使用紧跟其后的大括号内的所要求的字符数。其它请参照：re2c:define:YYFILL:naked和re2c:define:YYFILL@LEN.
• re2c:startlabel = 0 ;如果设置为0的整数，即使没有扫描器本身，下一个扫描块的开始标签也会被生成。否则仅在需要的时候生成常规的yy0开始标签。如果设置为一个文本值，不管常规的开始标签生成是否，包含当前文本的标签都会被生成。在开始标签生成后，当前设置会被重置为0。
• re2c:labelprefix = yy ;
  允许修改数字标签的前缀，默认为yy，任何有效的标签都是可以的。
• re2c:state:abort = 0 ;
  当设置为非零，并且开启-f模式时，YYGETSTATE 块会包含一个默认的情况，初始化时设置为-1
• re2c:state:nextlabel = 0 ;
  当开启-f模式时，使用此设置可以控制是否在YYGETSTATE块后面接yyNext标签行。通常，你可以用startlabel配置强制指定开始标签或用默认的yy0作为开始标签，而不是用yyNext。通常我们通过放置”/*!getstate:re2c */” 注释来分隔实际扫描器的YYGETSTATE 代码，而不是专用的标签。
• re2c:cgoto:threshold = 9 ;
  当启用-g模式时，这个值指定生成的跳转表的复杂度阈值，而不是使用嵌套的if语句和决策位字段。
• re2c:yych:conversion = 0 ;
  当输入使用有符号字符时，并且开启-s和-b械时，re2c会自动将其转化为无符号类型。当设置为0时会禁用空字符串转化。设置为非零时，转化将在YYCTYPE处进行。如果这个值通过现场配置，则使用该值。否则，将会变成(YYCTYPE)，并且不能再修改成配置。当设置为一个字符串时，必须用括号括起来。现在，假设你的输入为char*并且使用上述的设置，你可以设置YYCTYPE为unsigned char，并且当前值设置为1或者”(unsigned char)”
• re2c:define:define:YYCONDTYPE = YYCONDTYPE ;枚举用于支持-c模式的条件
• re2c:define:YYCTXMARKER = YYCTXMARKER ;
  允许覆盖定义的YYCTXMARKER ，从而避免将其设置为实际所需的代码。
• re2c:define:YYCTYPE = YYCTYPE ;
  允许覆盖定义的YYCTYPE ，从而避免将其设置为实际所需的代码。
• re2c:define:YYCURSOR = YYCURSOR ;
  允许覆盖定义的YYCURSOR ，从而避免将其设置为实际所需的代码。
• re2c:define:YYDEBUG = YYDEBUG ;
  允许覆盖定义的YYDEBUG ，从而避免将其设置为实际所需的代码。
• re2c:define:YYFILL = YYFILL ;
  允许覆盖定义的YYFILL ，从而避免将其设置为实际所需的代码。
• re2c:define:YYFILL:naked = 0 ;
  当设置为1时，括号、参数、分号都会被发出。
• re2c:define:YYFILL@len = @@ ;
  当使用 re2c:define:YYFILL 时，并且re2c:yyfill:parameter 为0时，YYFILL 中的任何文本将会被新的实际的长度值替换。
• re2c:define:YYGETCONDITION = YYGETCONDITION ;
  允许覆盖定义的YYGETCONDITION
• re2c:define:YYGETCONDITION:naked = ;
  当设置为1时，括号、参数、分号都会被发出。
• re2c:define:YYGETSTATE = YYGETSTATE ;
  允许覆盖定义的YYGETSTATE ，从而避免将其设置为实际所需的代码。
• re2c:define:YYGETSTATE:naked = 0 ;
  当设置为1时，括号、参数、分号都会被发出。
• re2c:define:YYLIMIT = YYLIMIT ;
  允许覆盖定义的YYLIMIT ，从而避免将其设置为实际所需的代码。
• re2c:define:YYMARKER = YYMARKER ;
  允许覆盖定义YYMARKER，从而避免将其设置为实际所需的代码。
• re2c:define:YYSETCONDITION = YYSETCONDITION ;
  允许覆盖定义的YYSETCONDITION
• re2c:define:YYSETCONDITION@cond = @@ ;
  当使用 re2c:define:YYSETCONDITION时，YYSETCONDITION中的任何文本将会被新的实际的
  条件值替换。
• re2c:define:YYSETSTATE = YYSETSTATE ;
  允许覆盖定义的YYSETSTATE，从而避免将其设置为实际所需的代码。
• re2c:define:YYSETSTATE:naked = 0 ;
  当设置为1时，括号、参数、分号都会被发出。
• re2c:define:YYSETSTATE@state = @@ ;
  当使用re2c:define:YYSETSTATE时，YYSETCONDITION中的任何文本将会被新的实际的状态值替换
• re2c:label:yyFillLabel = yyFillLabel ;
  允许覆盖标签yyFillLabel，即可以自定义生成的yyFillLabel 变量名。
• re2c:label:yyNext = yyNext ;
  允许覆盖标签yyNext ，即可以自定义生成的yyNext变量名。
• re2c:variable:yyaccept = yyaccept ;
  允许覆盖变量yyaccept，即可以自定义生成的yyaccept变量名。
• re2c:variable:yybm = yybm ;
  允许覆盖变量yybm，即可以自定义生成的yybm变量名。
• re2c:variable:yych = yych ;
  允许覆盖变量yych，即可以自定义生成的yych变量名。
• re2c:variable:yyctable = yyctable ;
  当指定-c参数和-g参数时，re2c会使用此变量为YYGETCONDITION生成静态跳转表。
• re2c:variable:yystable = yystable ;
  当指定-f参数和-g参数时，re2c会使用此变量为YYGETSTATE生成静态跳转表。
• re2c:variable:yytarget = yytarget ;
  允许覆盖变量yytarget，即可以自定义生成的yytarget变量名。

Understanding Re2c 理解re2c

re2c的子目录中包含各种例子教你一步一步的如何开启re2c的世界，所有的例子都是可编译运行的。

Features特点

re2c不提供默认的动作：生成的代码假定输入包含一系列token。通常，可以通过添加一条规则实现，例如上面示例中的异常字符

因为re2c不提供结束表达式，所以用户必须安排一个输入结束符并让一个规则匹配并捕获它。
如果来源是一个以空字符串结尾的字符串，则匹配一个空字符串就可以了。如果来源是一个文件，你可以在文件后添加一个换行（或其它不会出现的标记）；通过识别这个字符，以检查这是否为一个标记点并执行相应的操作。同样，你也可以使用YYFILL(n)判断是否没有足够的字符可用时结束扫描。

BugsDifference only works for character sets.
The re2c internal algorithms need documentation.
See Alsoflex(1), lex(1).
More information on re2c can be found here:

http://re2c.org/

Authors

Peter Bumbulis peter@csg.uwaterloo.ca
Brian Young bayoung@acm.org
Dan Nuffer nuffer@users.sourceforge.net
Marcus Boerger helly@users.sourceforge.net
Hartmut Kaiser hkaiser@users.sourceforge.net
Emmanuel Mogenet mgix@mgix.com added storable state

英文原地址：http://re2c.org/manual.html
译者：胖子（http://www.phppan.com/）
友情协助：吴帅（http://www.imsiren.com/）
校验：reeze(http://www.reeze.cn)
特别鸣谢：老婆大人的亲自指点和崽崽的听话。 ]]> https://www.phppan.com/2013/09/re2c-chinese-manual/feed/ 0 https://www.phppan.com/2013/02/php-ticks/ https://www.phppan.com/2013/02/php-ticks/#comments Thu, 07 Feb 2013 09:18:38 +0000 http://www.phppan.com/?p=1790 PHP的ticks机制

要过年了，在年前完成这篇文章，如果有缘可以看到，祝福看到的朋友新年快乐，在新的一年里，万事顺意！

按今年的计划每个月至少有两篇文章，而一月份因为各种理由而只有一篇2012的总结，无论什么原因，总归是不对的。这篇算是补上的，也作为今年的开始。

回正题，今天要研究的是PHP的ticks机制。

PHP提供declare关键字和ticks关键字来声明ticks机制。如：declare(ticks = N); 这表示：在当前scope内，每执行N句internal statements（opcodes），就会中断当前的业务语句，去执行通过register_tick_function注册的函数（如果存在的话），然后再继续之前的代码。需要注意的是这里的N是指的PHP的一些OPCODE，而OPCODE与我们见到的PHP语句却不是一一对应的。

最开始我以为PHP内核是在编译时记录是否有ticks机制，在真正执行中间代码时插入判断代码，实现此机制。但是事实上却不是这样滴。

看PHP代码示例1：

    $name = "phppan";
    echo $name;
    class Tipi {
        public function test() {
            echo "test";
        }
    }
    function f_tipi() {
    }

如上代码包括了我们常见的几种语句，赋值，输出，定义类，定义函数。通常我们用VLD查看PHP生成的中间代码，上面的代码通过 php -dvld.active=1 t.php 我们会看到 ECHO、ASSIGN、NOP等中间代码。

现在我们在示例1的代码上添加上ticks机制。如PHP代码示例2：

    declare(ticks=1);
    $name = "phppan";
    echo $name;
    class Tipi {
        public function test() {
            echo "test";
        }
    }
    function f_tipi() {
    }

示例2与示例1相比也就是多了第一条语句： declare(ticks=1); 如果我们此时再次通过VLD查看中间代码，会发现在每个中间代码的后面都多了一句中间代码：TICKS 。

是否因为ticks=1的原因而在每个中间代码的后面添加了TICKS？将declare(ticks=1);换成declare(ticks=100);，再次VLD，结果没有变化。从以上的结果可以看出，PHP内核在语法分析过程中实现了ticks机制。

从实现过程来说定义ticks机制分为两个过程：一个是定义是否需要执行ticks或者说声明ticks机制，另一个实现在声明了ticks机制的情况下控制语句的执行。

声明ticks机制过程

声明的过程就是调用declare(ticks = N); 在语法分析时根据declare关键字和参数中的ticks关键字来声明ticks机制。通过zend_compile.c文件中的zend_do_declare_begin、declare_statement、zend_do_declare_end三个函数来编译声明ticks机制。在declare_statement函数中我们可以看到：declare除了可以声明ticks之外，还可以声明encoding，这在代码里面就是一个if else的判断。

ticks机制的声明仅在编译过程有用，它为后面的声明控制语句服务。其编译过程中的全局变量为：CG(declarables)。这是一个结构体，它仅有一个成员：ticks。当然后面应该还会有更多的成员出现。

声明控制语句

示例1和示例2已经充分说明在每条语句的语法分析时，会根据是否声明了ticks机制来添加TICKS中间代码，其实现在于每条语句在语法解析时都会添加一条函数调用：zend_do_ticks。从zend_language_parser.y文件中可以看出：zend_do_ticks函数添加在类定义语句，函数定义语句和常规语句的后面。 zend_compile.c文件中的zend_do_ticks函数会根据前面提到的 CG(declarables).ticks 来判断是否生成 ZEND_TICKS 中间代码（在VLD中看到的中间代码都是没有ZEND开头）。

除了声明ticks机制，还有执行。执行过程中关键的变量是在声明时的ticks=N。其实这里的N可以换个角度去理解：ticks指定的数字是指执行了多少次TICKS语句。在TICKS中间代码的执行函数ZEND_TICKS_SPEC_CONST_HANDLER中，会统计执行当前函数的次数，存储变量为EG(ticks_count)。当达到当初声明的界限，就会调用一次所有通过register_tick_function注册的函数，并计数清零。

与当初自己设想的实现相比，PHP内核对ticks机制的实现满足了功能单一原则和松耦合原则。将ticks机制作为一个中间代码添加到整个中间代码的执行体系中，包括状态的转移，函数的切换这些都是直接使用原有的机制。

ticks机制的应用场景

手册上说：Ticks 很适合用来做调试，以及实现简单的多任务，后台 I/O 和很多其它任务。

在调试过程中，对于定位一段特定代码中速度慢的语句比较有用，我们可以每执行两条低级语句就记录一次时间。虽然这个过程也可以用其它方法完成，但用 tick 更方便也更容易实现。

PCNTL也使用ticks机制来作为信号处理机制（signal handle callback mechanism），可以最小程度地降低处理异步事件时的负载。这里的关键在于PCNTL扩展的模块初始化函数（PHP_MINIT_FUNCTION(pcntl)）。在此模块做模块初始化时，它会调用： php_add_tick_function(pcntl_signal_dispatch);将pcntl的分发执行函数添加到ticks机制的调用函数中去，从而当ticks触发时就会调用PCNTL扩展函数中指定的所有方法。

在我们平常的开发中，也许曾经都遇到过PHP脚本运行超时的情况，此时PHP会显示错误说： “Fatal error: Maximum execution time of XXX seconds exceeded in XXX”，并终止脚本的运行。当遇到这种情况我们经常会通过使用 set_time_limit（非安全模式），或修改配置文件并重启服务器，或者修改程序减少程序的执行时间，使其在允许的范围之内，以解决此问题。但是，这些都是在应用层上我们可以看到的的表象，在PHP内核中有一套这样的机制支撑这样一个表象。

这是PHP为防止某些业务脚本长时间执行而阻塞其它脚本的处理或耗尽服务器资源，从而实现的脚本运行的超时管理机制。其本质上是PHP通过针对不同的平台实现定时器，依赖运行时的超时全局变量（EG(timeout_seconds)）管理并控制定时器的运行。所有对脚本运行时长的管理，包括接口函数和配置文件对于最大运行时长的配置，最终都是通过管理超时全局变量并重启定时器来实现的。

初始化和超时配置项

在PHP内核的核心层文件/main/main.c文件中，定义了PHP的核心配置项以及每个配置项对应的on_modify方法。在模块初始化（php_module_startup）时，PHP内核会调用ini配置的注册函数，将定义的核心配置项添加到ini配置的指令集中，并且会调用每个配置项对应的on_modify方法。

用于定义脚本运行最长时间的max_execution_time配置项也是这些核心配置项的一员，它的默认值为30秒，对应的on_modify方法是OnUpdateTimeout。当注册这些核心配置项时，max_execution_time的on_modify方法将被调用，此时配置项的值将传递给超时全局变量:EG(timeout_seconds)，并通过zend_set_timeout方法启动定时器。

针对WIN平台和类unix平台，PHP内核实现了不同的定时器。 Win32平台的定时器是在WM_TIME的基础上封装了一个计时器。通过创建一个独立线程控制计时器，并创建一个消息环，WaitForSingleObject用来阻塞zend_init_timeout_thread 返回。当接收到WM_REGISTER_ZEND_TIMEOUT时开始计时，实际上此时计时的任务是SetTimer(timeout_window, wParam, lParam*1000, NULL); 系统会在 seconds *　1000 后发个 WM_TIMER，这个时候就结束计时，中间可以被 WM_UNREGISTER_ZEND_TIMEOUT 打断。

类unix平台使用Linux的API函数setitimer，指定SIGPROF信号为超时处理信号，对应超时处理函数zend_timeout，当发生超时时，会发送此信号并触发函数zend_timeout显示错误信息并中止程序。

如果需要取消定时器，Win平台通过PostThreadMessage发送WM_UNREGISTER_ZEND_TIMEOUT给线程即可，类unix平台会重置定时器的时长为0。

超时管理

超时机制的管理非常灵活，有三种修改运行时长的方法。

1、 修改配置项。默认情况下PHP脚本的最长运行时长为30s。如果需要调整此项，可以通过修改php.ini文件中的max_execution_time项并重启动服务器达到修改最长运行时长的目的。此种方法适用于最开始的默认配置修改，或在其它方法无效的情况下使用。

2、 使用set_time_limit接口函数。此函数的作用是设置脚本最大执行时间。当此函数被调用时，set_time_limit()会从零开始重新启动超时计数器。比如，每一次设置是5秒，待脚本运行4秒后，脚本中又设置了5秒，那么，脚本在超时之前可运行总共时间为10秒。如下脚本示例：

    <?php
    set_time_limit(5);
    for ($i = 0; $i < 4; $i++) {
        sleep(1);
        echo $i, "<br />";
    }
 
    set_time_limit(5);
 
    for ($i = 0; $i < 4; $i++) {
        sleep(1);
        echo $i, "<br />";
    }

如上的代码，程序会执行完两个循环，都输出0,1,2,3。如果我们注释掉中间的set_time_limit(5)，程序再运行一次，此时就会在第二个循环输出0后报错。

在安全模式下，无法通过set_time_limit和ini_set重新设置max_execution_time，只有关闭安全模式或改变php.ini中的时间限制才能达到修改此参数的目的。

3、 通过ini_set修改max_execution_time参数。

以上的三种方法，其实现过程基本类似，前一种是在初始化时调用on_modify指针函数。后两种在处理了参数后，调用zend_alter_ini_entry_ex函数，触发on_modify函数。于是，管理超时机制的所有操作最终都汇集到OnUpdateTimeout函数。在此函数中，通过zend_set_timeout重新设置脚本的超时时间。

启动

在调用每个模块的模块初始化前，会有一个初始化的过程，它包括：

• 初始化若干全局变量

这里的初始化全局变量大多数情况下是将其设置为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文件）。
2. 如果没有php_ini_path_override，判断php_ini_ignore是否为非空（忽略php.ini配置，这里也就CLI模式下有用，使用-n参数）。
3. 如果不忽略ini配置，则开始处理php_ini_search_path（查找ini文件的路径），这些路径包括CWD(当前路径，不过这种不适用CLI模式)、执行脚本所在目录、环境变量PATH和PHPRC和配置文件中的PHP_CONFIG_FILE_PATH的值。
4. 在准备完查找路径后，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页面。
2. 执行所有可用的__destruct函数。这里的析构函数包括在对象池（EG(objects_store）中的所有对象的析构函数以及EG(symbol_table)中各个元素的析构方法。
3. 将所有的输出刷出去。
4. 发送HTTP应答头。这也是一个输出字符串的过程，只是这个字符串可能符合某些规范。
5. 遍历每个模块的关闭请求方法，执行模块的请求关闭操作，这就是我们在图中看到的Call each extension’s RSHUTDOWN。
6. 销毁全局变量表（PG(http_globals)）的变量。
7. 通过zend_deactivate函数，关闭词法分析器、语法分析器和中间代码执行器。
8. 调用每个扩展的post-RSHUTDOWN函数。只是基本每个扩展的post_deactivate_func函数指针都是NULL。
9. 关闭SAPI，通过sapi_deactivate销毁SG(sapi_headers)、SG(request_info)等的内容。
10. 关闭流的包装器、关闭流的过滤器。
11. 关闭内存管理。
12. 重新设置最大执行时间

结束

最终到了要收尾的地方了。

• 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函数。

PS: 最近有同学问到TIPI项目的进度问题，主编说:在七月份会有一次版本发布，更多的内容可以查看项目的github。

而在PHP5.4之后，我们可以在不添加扩展的情况下，从session数据中获取了文件上传的进度。uploadprogress扩展和PHP5.4的session扩展都能获取上传的进度，其是否有相同的地方呢？

我们先来看uploadprogress扩展，下载源码包，解圧，直接打开文件，我们可以在example中找到一个简单的示例。在info.php文件中，uploadprogress_get_info函数用来获取上传文件进度。upploadprogress.c文件存储了扩展的实现过程。uploadprogress扩展实现的关键在于其模块寝化函数：

PHP_MINIT_FUNCTION(uploadprogress)
{
	REGISTER_INI_ENTRIES();
	php_rfc1867_callback = uploadprogress_php_rfc1867_file;
 
	return SUCCESS;
}

此函数的核心就是设置php_rfc1867_callback为uploadprogress_php_rfc1867_file。
设置这个函数指针有什么用呢？
在前面的文章PHP内核中文件上传类型的获取过程中我们了解到PHP处理POST请求的函数是SAPI_POST_HANDLER_FUNC(rfc1867_post_handler)(main/rfc1867.c)。在这里， 我们发现了若干个php_rfc1867_callback的调用，从调用的第一个参数来看，它可以分为六个事件，或者说有六个回调更新点。

如果此时我们查看PHP5.4的的session扩展的实现文件session.c时，搜索php_rfc1867_callback，你会发现在模块初始化函数中也有与扩展类似的赋值操作：

	php_rfc1867_callback = php_session_rfc1867_callback;

同样，在php_session_rfc1867_callback函数中有与uploadprogress同样的六个事件的处理，这六个事件相当于六个钩子程序，分别对应POST请求的处理的六个不同的位置，在PHP5.4中他们的作用分别是：

• 1、MULTIPART_EVENT_START 在处理所有的请求实体之前，初始化上传进度信息，比用于记录上传进度相关信息的progress结构体信息（如content-length）
• 2、MULTIPART_EVENT_FORMDATA 对于每个multipart包含的控制，执行此步初始化操作，以此之前会解析Content-Disposition相关属性，并初始化progress的其它信息，如session_id,以及整个上传活动的key，这里表示整个上传进度准备好了。
• 3、MULTIPART_EVENT_FILE_START 开始处理上传的文件信息，如果progress的data不存在，则会创建此结构，并初始化session中存储的对于此次文件上传的start_time、content_length、bytes_processed、files等信息。然后处理单个文件的上传属性，如field_name、tmp_name等。对于tmp_name等字段这里是执行初始化操作。这一步的时候获取session 的值才会开始有上传进度的相关信息。
• 4、MULTIPART_EVENT_FILE_DATA 更新上传文件的长度，在一堆的文件相关信息检测和临时文件写入之前，也是在将数据写入到$_FILES之前。
• 5、MULTIPART_EVENT_FILE_END 单个文件上传结束，此时会更新这个文件相关的一些信息，比如error, tmp_name，tmp_name字段在start时是null。当然这里还有针对当前文件的done字段的更新。
• 6、MULTIPART_EVENT_END 更新session数组的最后的一些结信息 比如done字段 并清空progress的信息，

这里的六个事件是相同的，而uploadprogress扩展和PHP5.4的session扩展在事件处理过程中中间存储结构和最后的返回内容与方式上存在一些差异。uploadprogress扩展的存储结构为一个按照扩展制定的规则生成的临时文件，最后是通过扩展函数uploadprogress_get_info返回上传进度的数组。PHP5.4的存储结构为SESSION的存储方式，或者是文件，或者是memcache，这个按session的设置来，其最终是通过$_SESSION返回相关数组。

除了uploadprogress扩展外，APC也以设置php_rfc1867_callback = apc_rfc1867_progress，提供了类似的解决方案，启动此功能需要在php.ini中设置apc.rfc1867项为启用，并且在表单中加一个隐藏域 APC_UPLOAD_PROGRESS，这个域的值可以随机生成一个hash，以确定此次上传操作的唯一性。通过Ajax调用服务端显示进度的接口，在接口中通过apc_fetch函数获取APC缓存的文件上传进度。比如print_r(apc_fetch(“upload_$_POST[APC_UPLOAD_PROGRESS]“));可以得到如下结果：

Array
(
    [total] => 1142543
    [current] => 1142543
    [rate] => 1828068.8
    [filename] => test
    [name] => file
    [temp_filename] => /tmp/php8F
    [cancel_upload] => 0
    [done] => 1
)

apc.rfc1867相关更加详细的内容猛击 APC Runtime Configuration

在我们使用VLD扩展查看PHP生成的中间代码时，经常会看到有这样一项：compiled vars: !0 = $a，或者如果使用更加详细的 -dvld.verbosity=3参数，会看到IS_CV，IS_VAR等类型。这里所说的Compiled vars和IS_CV都与今天我们所要了解的CV类型有莫大的关系。

CV者，Compiled variable也。
CV类型是PHP编译过程中产生的一种变量类型，以类似于缓存的方式，提高某些变量的存储速度。
与CV类型同一级别的类型还有：

	#define IS_CONST (1<<0)
	#define IS_TMP_VAR (1<<1)
	#define IS_VAR (1<<2)
	#define IS_UNUSED (1<<3) /* Unused variable */
	#define IS_CV (1<<4) /* Compiled variable */

比如最常见的赋值语句：$a = 10;

以php -dvld.active=1 -dvld.verbosity=3 test.php(这段代码在放在test.php文件中)查看。

 
	function name:  (null)
	number of ops:  3
	compiled vars:  !0 = $a
	line     # *  op            return  operands
	----------------------------------------------
	   2     0  >   EXT_STMT       RES[  IS_UNUSED  ]         OP1[  IS_UNUSED  ] OP2[  IS_UNUSED  ]
		 1      ASSIGN                 OP1[IS_CV !0 ] OP2[ ,  IS_CONST (0) 10 ]
	  13     2    > RETURN                 OP1[IS_CONST (0) 1 ]

如上我们可以知道10的类型为IS_CONST，$a的类型为IS_CV。

这里的CV类型在代码运行时存储在哪呢？在什么时候能起到性能优化的作用？

我们知道PHP中间代码运行的数据大部分都放在全局变量execute_data中，对于这个变量我们通常以EX(element)的方式调用，如EX(CVs)、EX(opline)等等。通过对execute_data所有字段的查阅我们可以大概知道CV类型变量存放在EX(CVs)中。

如何判别呢？
同样，以上面的简单赋值语句为例，依据其中间代码(ZEND_ASSIGN)，操作数的类型(IS_CV和IS_CONST)，可以得出其中间代码最终执行的函数为：ZEND_ASSIGN_SPEC_CV_CONST_HANDLE。在此函数中，对于操作数据处理：

	zval *value = &opline->op2.u.constant;
	zval **variable_ptr_ptr = _get_zval_ptr_ptr_cv(&opline->op1, EX(Ts), BP_VAR_W TSRMLS_CC);

op2为右值，op1为左值，左值的查找处理是_get_zval_ptr_ptr_cv。如下：

	static zend_always_inline zval **_get_zval_ptr_ptr_cv(const znode *node, const temp_variable *Ts, int type TSRMLS_DC)
	{
		zval ***ptr = &CV_OF(node->u.var);
 
		if (UNEXPECTED(*ptr == NULL)) {
			return _get_zval_cv_lookup(ptr, node->u.var, type TSRMLS_CC);
		}
		return *ptr;
	}
 
	// 函数中的CV_OF宏定义
	#define CV_OF(i)     (EG(current_execute_data)->CVs[i])

上面的函数和宏定义道出了CV这个类缓存机制的实现过程和CV类型的存储位置。

在函数中，程序会先判断变量是否存在于EX(CVs) – 这就是存储位置，如果存在则直接返回，否则调用_get_zval_cv_lookup，通过HashTable操作在EG(active_symbol_table)表中查找变量。虽然HashTable的查找操作已经比较快了，但是与原始的数组操作相比还是不在一个数量级。这就是CV类型变量的性能优化点所在。

以上是变量的赋值操作，也是变量的创建过程，与此对应，在变量销毁时PHP内核应该会对此种类型的变量执行清除HashTable和数组两个操作，以unset操作为例，针对IS_CV类型的变量，其中间代码最终会执行ZEND_UNSET_VAR_SPEC_CV_HANDLER。在此函数中不管是ZEND_QUICK_SET类型的操作，还是常规的unset操作，都会对HashTable（EG(active_symbol_table)或target_symbol_table）和数组（EX(CVs)和ex->CVs）执行清除操作。

$var = 10;
$str = "test string begin " . $var . " end";
 
//或
$var = 10;
$str = "test string begin $var end";

这二者有什么区别呢？

以VLD扩展直接查看这两段代码生成的中间代码：
点号连接：

number of ops:  7
compiled vars:  !0 = $var, !1 = $str
line     # *  op         ext  return  operands
------------------------------------------------
   2     0  >   EXT_STMT
         1      ASSIGN                  !0, 10
   3     2      EXT_STMT
         3      CONCAT          ~1      'test+string+begin+', !0
         4      CONCAT          ~2      ~1, '+end'
         5      ASSIGN                  !1, ~2
         6    > RETURN                  1

直接在字符串中插入变量：

number of ops:  8
compiled vars:  !0 = $var, !1 = $str
line     # *  op             ext  return  operands
----------------------------------------------------
   2     0  >   EXT_STMT
         1      ASSIGN                      !0, 10
   3     2      EXT_STMT
         3      ADD_STRING          ~1      'test+string+begin+'
         4      ADD_VAR             ~1      ~1, !0
         5      ADD_STRING          ~1      ~1, '+end'
         6      ASSIGN                      !1, ~1
         7    > RETURN                      1

对比这段生成的中间码，其原理完全不一样：

点号是典型的连接操作（当然，它本来就是连接操作），
当使用多个点号是，每两个点号的结果都会使用一个临时变量存储起来，并作为下一个操作的一个操作数。如在我们的示例中，首先是执行第一个连接操作，将“test string begin ”和$var连接起来，得到“test string begin 10”，然后再执行第二个连接操作，将上一个操作得到的结果“test string begin 10”和” end”连接起来，并将结果存储在另一个临时变量，最后将第二个连接操作的结果赋值给$str。

连接操作对应的opcode为ZEND_CONCAT，对于所给的两个操作数，其最终通过concat_function函数将两个字符串连接起来，如果所给的变量的类型不是字符串，则会通过zend_make_printable_zval将其转换成字符串。concat_function函数会根据两个字符串的长度重新分配内存，并执行两次拷贝操作，将两个字符串拷贝到新的内存空间。
这里针对两个字符串相同的情况有一个特殊处理。
如下：

if (result==op1) {	/* special case, perform operations on result */
	uint res_len = Z_STRLEN_P(op1) + Z_STRLEN_P(op2);
 
	Z_STRVAL_P(result) = erealloc(Z_STRVAL_P(result), res_len+1);
 
	memcpy(Z_STRVAL_P(result)+Z_STRLEN_P(result), Z_STRVAL_P(op2), Z_STRLEN_P(op2));
	Z_STRVAL_P(result)[res_len]=0;
	Z_STRLEN_P(result) = res_len;
} else {
	Z_STRLEN_P(result) = Z_STRLEN_P(op1) + Z_STRLEN_P(op2);
	Z_STRVAL_P(result) = (char *) emalloc(Z_STRLEN_P(result) + 1);
	memcpy(Z_STRVAL_P(result), Z_STRVAL_P(op1), Z_STRLEN_P(op1));
	memcpy(Z_STRVAL_P(result)+Z_STRLEN_P(op1), Z_STRVAL_P(op2), Z_STRLEN_P(op2));
	Z_STRVAL_P(result)[Z_STRLEN_P(result)] = 0;
	Z_TYPE_P(result) = IS_STRING;
}

示例执行了两次连接操作，则执行了两次内存分配操作和四次拷贝操作。

而直接在字符串中插入变量，其所有的操作都是添加操作，将字符串添加到返回值，将变量添加到返回值，
所有的结果返回都是在一个临时变量中，如我们的示例，首先会将”test string begin “添加到临时变量，然后将临时变量和$var变量添加到临时变量，之后将临时变量和” end”添加到临时变量，最后将此此时变量赋值给$str。这里添加将字符串添加到临时变量，其对应的opcode为ZEND_ADD_STRING，将变量添加到临时变量，其对应的opcode为ZEND_ADD_VAR，虽然这两个操作的opcode不同，但其最终调用都是add_string_to_string，他们所不同的调用此函数的第三个参数，一个是操作码存储的ZVAL变量，一个是通过变更列表获取的ZVAL变量。
其调用结构如下：

// 添加字符串
zval *str = &EX_T(opline->result.u.var).tmp_var;
add_string_to_string(str, str, &opline->op2.u.constant);
 
//添加变量
zval *str = &EX_T(opline->result.u.var).tmp_var;
zval *var = _get_zval_ptr_tmp(&opline->op2, EX(Ts), &free_op2 TSRMLS_CC);
add_string_to_string(str, str, var);

在添加变量时，如果添加的变量不是字符串，会通过zend_make_printable_zval将变量转换成字符串输出，如数组会转换成Array。
add_string_to_string的实现在Zend/zend_operators.c文件中：

/* must support result==op1 */
ZEND_API int add_string_to_string(zval *result, const zval *op1, const zval *op2) /* {{{ */
{
	int length = Z_STRLEN_P(op1) + Z_STRLEN_P(op2);
 
	Z_STRVAL_P(result) = (char *) erealloc(Z_STRVAL_P(op1), length+1);
	memcpy(Z_STRVAL_P(result)+Z_STRLEN_P(op1), Z_STRVAL_P(op2), Z_STRLEN_P(op2));
	Z_STRVAL_P(result)[length] = 0;
	Z_STRLEN_P(result) = length;
	Z_TYPE_P(result) = IS_STRING;
	return SUCCESS;
}
/* }}} */

add_string_to_string函数的实现过程是针对即将生成的字符串的大小重新通过PHP内核的内存管理扩展内存空间（如果当前空间后续的内存够用，则天下太平，如果空间不够，则重新分配空间并执行拷贝操作），并将新的字符串复制到原始字串后面内存空间的过程。
我们的示例执行了三次添加操作，也就执行了三次内存扩展操作和三次拷贝操作。

与过程相比，过程中的数据会更加重要，那么在执行过程中的核心数据结构有哪些呢？ 在Zend/zend_vm_execute.h文件中的execute函数实现中，zend_execute_data类型的execute_data变量贯穿整个中间代码的执行过程， 其在调用时并没有直接使用execute_data，而是使用EX宏代替，其定义在Zend/zend_compile.h文件中，如下：

#define EX(element) execute_data.element

因此我们在execute函数或在opcode的实现函数中会看到EX(fbc)，EX(object)等宏调用， 它们是调用函数局部变量execute_data的元素：execute_data.fbc和execute_data.object。 execute_data不仅仅只有fbc、object等元素，它包含了执行过程中的中间代码，上一次执行的函数，函数执行的当前作用域，类等信息。 其结构如下：

typedef struct _zend_execute_data zend_execute_data;
 
struct _zend_execute_data {
    struct _zend_op *opline;
    zend_function_state function_state;
    zend_function *fbc; /* Function Being Called */
    zend_class_entry *called_scope; 
    zend_op_array *op_array;  /* 当前执行的中间代码 */
    zval *object;
    union _temp_variable *Ts;
    zval ***CVs;
    HashTable *symbol_table; /* 符号表 */
    struct _zend_execute_data *prev_execute_data;   /* 前一条中间代码执行的环境*/
    zval *old_error_reporting;
    zend_bool nested;
    zval **original_return_value; /* */
    zend_class_entry *current_scope;
    zend_class_entry *current_called_scope;
    zval *current_this;
    zval *current_object;
    struct _zend_op *call_opline;
};

在前面的中间代码执行过程中有介绍：中间代码的执行最终是通过EX(opline)->handler(execute_data TSRMLS_CC)来调用最终的中间代码程序。 在这里会将主管中间代码执行的execute函数中初始化好的execture_data传递给执行程序。

zend_execute_data结构体部分字段说明如下：

• opline字段：struct _zend_op类型，当前执行的中间代码
• op_array字段： zend_op_array类型，当前执行的中间代码队列
• fbc字段：zend_function类型，已调用的函数
  called_scope字段：zend_class_entry类型，当前调用对象作用域，常用操作是EX(called_scope) = Z_OBJCE_P(EX(object))， 即将刚刚调用的对象赋值给它。
• symbol_table字段： 符号表，存放局部变量，这在前面的<< 第六节 变量的生命周期 » 变量的作用域 >>有过说明。 在execute_data初始时，EX(symbol_table) = EG(active_symbol_table);
• prev_execute_data字段：前一条中间代码执行的中间数据，用于函数调用等操作的运行环境恢复。
  在execute函数中初始化时，会调用zend_vm_stack_alloc函数分配内存。 这是一个栈的分配操作，对于一段PHP代码的上下文环境，它存在于这样一个分配的空间作放置中间数据用，并作为栈顶元素。 当有其它上下文环境的切换（如函数调用），此时会有一个新的元素生成，上一个上下文环境会被新的元素压下去， 新的上下文环境所在的元素作为栈顶元素存在。

在zend_vm_stack_alloc函数中我们可以看到一些PHP内核中的优化。 比如在分配时，这里会存在一个最小分配单元，在zend_vm_stack_extend函数中， 分配的最小单位是ZEND_VM_STACK_PAGE_SIZE((64 * 1024) – 64)，这样可以在一定范围内控制内存碎片的大小。 又比如判断栈元素是否为空，在PHP5.3.1之前版本(如5.3.0)是通过第四个元素elelments与top的位置比较来实现， 而从PHP5.3.1版本开始，struct _zend_vm_stack结构就没有第四个元素，直接通过在当前地址上增加整个结构体的长度与top的地址比较实现。 两个版本结构代码及比较代码如下：

// PHP5.3.0
struct _zend_vm_stack {
    void **top;
    void **end;
    zend_vm_stack prev;
    void *elements[1];
};
 
if (UNEXPECTED(EG(argument_stack)->top == EG(argument_stack)->elements)) {
}
 
//  PHP5.3.1
struct _zend_vm_stack {
    void **top;
    void **end;
    zend_vm_stack prev;
};
 
if (UNEXPECTED(EG(argument_stack)->top == ZEND_VM_STACK_ELEMETS(EG(argument_stack)))) {
}
 
#define ZEND_VM_STACK_ELEMETS(stack) \
((void**)(((char*)(stack)) + ZEND_MM_ALIGNED_SIZE(sizeof(struct _zend_vm_stack))))

当一个上下文环境结束其生命周期后，如果回收这段内存呢？ 还是以函数为例，我们在前面的函数章节中<< 函数的返回 >>中我们知道每个函数都会有一个函数返回， 即使没有在函数的实现中定义，也会默认返回一个NULL。以ZEND_RETURN_SPEC_CONST_HANDLER实现为例， 在函数的返回最后都会调用一个函数zend_leave_helper_SPEC。

在zend_leave_helper_SPEC函数中，对于执行过程中的函数处理有几个关键点：

• 上下文环境的切换：这里的关键代码是：EG(current_execute_data) = EX(prev_execute_data);。 EX(prev_execute_data)用于保留当前函数调用前的上下文环境，从而达到恢复和切换的目的。
• 当前上下文环境所占用内存空间的释放：这里的关键代码是：zend_vm_stack_free(execute_data TSRMLS_CC);。 zend_vm_stack_free函数的实现存在于Zend/zend_execute.h文件，它的作用就是释放栈元素所占用的内存。
• 返回到之前的中间代码执行路径中：这里的关键代码是：ZEND_VM_LEAVE();。 我们从zend_vm_execute.h文件的开始部分就知道ZEND_VM_LEAVE宏的效果是返回3。 在执行中间代码的while循环当中，当ret=3时，这个执行过程就会恢复之前上下文环境，继续执行。

更多内容请请移步TIPI项目