PHP工作模型与运行机制

 

文章来自：http://www.nowamagic.net/librarys/veda/detail/350，欢迎访问原出处。

 

PHP的工作模型非常特殊。从某种程度上说，PHP和ASP、ASP.NET、JSP/Servlet等流行的Web技术，有着本质上的区别。

 

以Java为例，Java在Web应用领域，有两种技术：Java Servlet和JSP（Java Server Page）。Java Servlet是一种特殊类型的Java程序，它通过实现相关接口，处理Web服务器发送过来的请求，完成相应的工作。JSP在形式上是一种类似于PHP的脚本，但是事实上，它最后也被编译成Servlet。也就是说，在Java解决方案中，JSP和Servlet是作为独立的Java应用程序执行的，它们在初始化之后就驻留内存，通过特定的接口和Web服务器通信，完成相应工作。除非被显式地重启，否则它们不会终止。因此，可以在JSP和Servlet中使用各种缓存技术，例如数据库连接池。

 

ASP.NET的机制与此类似。至于ASP，虽然也是一种解释型语言，但是仍然提供了Application对象来存放应用程序级的全局变量，它依托于ASP解释器在IIS中驻留的进程，在整个应用程序的生命期有效。

 

 

PHP是一种纯解释型在服务端执行的可以内嵌HTML的脚本语言，尤其适合开发Web应用程序。请求一个 PHP 脚本时，PHP 会读取该脚本，并将其编译为 Zend 操作码，这是要执行的代码的一种二进制表示形式。随后，此操作码由 PHP 执行并丢弃。 PHP脚本在每次被解释时进行初始化，在解释完毕后终止运行。这种运行是互相独立的，每一次请求都会创建一个单独的进程或线程，来解释相应的页面文件。页面创建的变量和其他对象，都只在当前的页面内部可见，无法跨越页面访问。在终止运行后，页面中申请的、没有被代码显式释放的外部资源，包括内存、数据库连接、文件句柄、Socket连接等，都会被强行释放。也就是说，PHP无法在语言级别上实现直接访问跨越页面的变量，也无法创建驻留内存的对象。

"; 
TestStaticVar(); 
>

 

在这个例子中，定义了一个名为StaticVarTester的类，它仅有一个公共的静态成员$StaticVar，并被初始化为0。然后，在TestStaticVar()函数中，对StaticVarTester :: $StaticVar进行累加操作，并将它打印输出。

 

熟悉Java或C++的开发者对这个例子应该并不陌生。$StaticVar作为StaticVarTester类的一个静态成员，只在类被装载时进行初始化，无论StaticVarTester类被实例化多少次，$StaticVar都只存在一个实例，而且不会被多次初始化。因此，当第一次调用TestStaticVar()函数时，$StaticVar进行了累加操作，值为1，并被保存。第二次调用TestStaticVar()函数，$StaticVar的值为2。

 

   

打印出来的结果和我们预料的一样：

StaticVarTester :: StaticVar = 1 
StaticVarTester :: StaticVar = 2

   

 

但是，当浏览器刷新页面，再次执行这段代码时，不同的情况出现了。在Java或C++里面，$StaticVar的值会被保存并一直累加下去，我们将会看到如下的结果：

StaticVarTester :: StaticVar = 3 
StaticVarTester :: StaticVar = 4 
…

 

但是在PHP中，由于上文叙及的机制，当前页面每次都解释时，都会执行一次程序初始化和终止的过程。也就是说，每次访问时，StaticVarTester都会被重新装载，而下列这行语句 public static $StaticVar = 0; 也会被重复执行。当页面执行完成后，所有的内存空间都会被回收，$StaticVar这个变量(连同整个StaticVarTester类)也就不复存在。因此，无论刷新页面多少次，$StaticVar变量都会回到起点：先被初始化为0，然后在TestStaticVar()函数调用中被累加。所以，我们看到的结果永远是这个：

StaticVarTester :: StaticVar = 1 
StaticVarTester :: StaticVar = 2

 

PHP这种独特的工作模型的优势在于，基本上解决了令人头疼的资源泄漏问题。Web应用的特点是大量的、短时间的并发处理，对各种资源的申请和释放工作非常频繁，很容易导致泄漏甚至崩溃。PHP的运行机制决定它不存在常规的崩溃问题（顶多连接超时脚本停止执行），可以说PHP是较稳定的Web应用。但是，这种机制的缺点也非常明显。最直接的后果是，PHP在语言级别无法实现跨页面的缓冲机制。这种缓冲机制缺失造成的影响，可以分成两个方面：

一是对象的缓冲。众所周知，很多设计模式都依赖于对象的缓冲机制，创建和销毁对象是很费时间的，因为创建一个对象要获取内存资源或者其它更多资源，对于需要频繁应付大量并发的服务端软件更是如此。因此，对象缓冲的缺失，理论上会极大地降低速度。应尽可能减少创建和销毁对象的次数来提高服务程序的效率，由于 PHP目前还不支持多线程，也就无法像Java一样通过线程池调度来弥补这一缺陷；但可以使用第三方软件如Memcachd来实现PHP的对象缓冲机制，达到减少对象创建和销毁的时间来提高服务程序的效率。Memcachd将PHP编译后的 操作码缓存并在内存中保存这个操作码，并在下一次调用该页面时重用它，这会节省很多时间。比较常用的缓存还有有 eAccelerator，另一种流行的 eAccelerator 替代工具是 Alternative PHP Cache(APC)。

   

二是数据库连接的缓冲。对于MySQL，PHP提供了一种内置的数据库缓冲机制，即用mysql_pconnect()代替mysql_connect() 来打开数据库而已。PHP会自动回收被废弃的数据库连接，以供重复使用。在实际应用中，这种持久性数据库连接往往会导致数据库连接的伪泄漏现象：在某个时间，并发的数据库连接过多，超过了MySQL的最大连接数，从而导致新的进程无法连接数据库。但是过一段时间，当并发数减少时，PHP会释放掉一些连接，网站又会恢复正常。出现这种现象的原因是，当使用pconnect时，Apache 的httpd进程会不释放connect，而当Apache的httpd进程数超过了mysql的最大连接数时，就会出现无法连接的情况。因此，需要小心地调整Apache和Mysql的配置，以使Apache的httpd进程数不会超出MySQL的最大连接数。笔者经过实践，在PHP5和 Oracle10g的连接中，由于频于数据库连接，有时候还会出现数据库丢失连接的情况(Oracle官方有针对PHP的增强包，不知是否可以解决此问题，笔者未试)。

PHP的工作模型即是缺点也是优势，从本质上说，这就是PHP 的独特之处。

若以FastCGI模式运行php,解析php.ini、载入全部扩展并重初始化全部数据结构这些都只在进程启动时发生一次。一个额外的好处是，持续数据库连接可以工作。Nginx+PHP(FastCGI)是个不错的选择。