一、 内存

　　在PHP中，填充一个字符串变量相当简单，这只需要一个语句"＜?php $str = 'hello world '; ?＞"即可，并且该字符串能够被自由地修改、拷贝和移动。而在C语言中，尽管你能够编写例如"char *str = "hello world ";"这样的一个简单的静态字符串；但是，却不能修改该字符串，因为它生存于程序空间内。为了创建一个可操纵的字符串，你必须分配一个内存块，并且通过一 个函数（例如strdup()）来复制其内容。

{
　char *str;
　str = strdup("hello world");
　if (!str) {
　　fprintf(stderr， "Unable to allocate memory!");
　}
}

　　由于后面我们将分析的各种原因，传统型内存管理函数（例如malloc()，free()，strdup()，realloc()，calloc()，等等）几乎都不能直接为PHP源代码所使用。

　　二、 释放内存

　　在几乎所有的平台上，内存管理都是通过一种请求和释放模式实现的。首先，一个应用程序请求它下面的层(通常指"操作系统")："我想使用一些内存空间"。如果存在可用的空间，操作系统就会把它提供给该程序并且打上一个标记以便不会再把这部分内存分配给其它程序。
当 应用程序使用完这部分内存，它应该被返回到OS；这样以来，它就能够被继续分配给其它程序。如果该程序不返回这部分内存，那么OS无法知道是否这块内存不 再使用并进而再分配给另一个进程。如果一个内存块没有释放，并且所有者应用程序丢失了它，那么，我们就说此应用程序"存在漏洞"，因为这部分内存无法再为 其它程序可用。

　　在一个典型的客户端应用程序中，较小的不太经常的内存泄漏有时能够为OS所"容忍"，因为在这个进程稍后结束时该泄漏内存会被隐式返回到OS。这并没有什么，因为OS知道它把该内存分配给了哪个程序，并且它能够确信当该程序终止时不再需要该内存。

　　而对于长时间运行的服务器守护程序，包括象Apache这样的web服务器和扩展php模块来说，进程往往被设计为相当长时间一直运行。因为OS不能清理内存使用，所以，任何程序的泄漏-无论是多么小-都将导致重复操作并最终耗尽所有的系统资源。

　　现在，我们不妨考虑用户空间内的stristr()函数；为了使用大小写不敏感的搜索来查找一个字符串，它实际上创建了两个串的各自的一个小型 副本，然后执行一个更传统型的大小写敏感的搜索来查找相对的偏移量。然而，在定位该字符串的偏移量之后，它不再使用这些小写版本的字符串。如果它不释放这 些副本，那么，每一个使用stristr()的脚本在每次调用它时都将泄漏一些内存。最后，web服务器进程将拥有所有的系统内存，但却不能够使用它。

　　你可以理直气壮地说，理想的解决方案就是编写良好、干净的、一致的代码。这当然不错；但是，在一个象PHP解释器这样的环境中，这种观点仅对了一半。

　　三、 错误处理

　　为了实现"跳出"对用户空间脚本及其依赖的扩展函数的一个活动请求，需要使用一种方法来完全"跳出"一个活动请求。这是在Zend引擎内实现的：在一个请求的开始设置一个"跳出"地址，然后在任何die()或exit()调用或在遇到任何关键错误(E_ERROR)时执行一个longjmp()以跳转到该"跳出"地址。

　　尽管这个"跳出"进程能够简化程序执行的流程，但是，在绝大多数情况下，这会意味着将会跳过资源清除代码部分(例如free()调用)并最终导致出现内存漏洞。现在，让我们来考虑下面这个简化版本的处理函数调用的引擎代码：

void call_function(const char *fname， int fname_len TSRMLS_DC){
　zend_function *fe;
　char *lcase_fname;
　/* PHP函数名是大小写不敏感的，
　*为了简化在函数表中对它们的定位，
　*所有函数名都隐含地翻译为小写的
　*/
　lcase_fname = estrndup(fname， fname_len);
　zend_str_tolower(lcase_fname， fname_len);
　if (zend_hash_find(EG(function_table)，lcase_fname， fname_len + 1， (void **)&fe) == FAILURE) {
　　zend_execute(fe-＞op_array TSRMLS_CC);
　} else {
　　php_error_docref(NULL TSRMLS_CC， E_ERROR，"Call to undefined function: %s()"， fname);
　}
　efree(lcase_fname);
}

　　当执行到php_error_docref()这一行时，内部错误处理器就会明白该错误级别是critical，并相应地调用longjmp ()来中断当前程序流程并离开call_function()函数，甚至根本不会执行到efree(lcase_fname)这一行。你可能想把 efree()代码行移动到zend_error()代码行的上面；但是，调用这个call_function()例程的代码行会怎么样呢？fname本 身很可能就是一个分配的字符串，并且，在它被错误消息处理使用完之前，你根本不能释放它。

　　注意，这个php_error_docref()函数是trigger_error()函数的一个内部等价实现。它的第一个参数是一个将被添加 到docref的可选的文档引用。第三个参数可以是任何我们熟悉的E_*家族常量，用于指示错误的严重程度。第四个参数（最后一个）遵循printf() 风格的格式化和变量参数列表式样。

    四、 Zend内存管理器

　　在上面的"跳出"请求期间解决内存泄漏的方案之一是：使用Zend内存管理(ZendMM)层。引擎的这一部分非常类似于操作系统的内存管理行 为-分配内存给调用程序。区别在于，它处于进程空间中非常低的位置而且是"请求感知"的；这样以来，当一个请求结束时，它能够执行与OS在一个进程终止时 相同的行为。也就是说，它会隐式地释放所有的为该请求所占用的内存。图1展示了ZendMM与OS以及PHP进程之间的关系。

    除了提供隐式内存清除功能之外，ZendMM还能够根据php.ini中memory_limit的设置控制每一种内存请求的用法。如果一个脚本试图请求 比系统中可用内存更多的内存，或大于它每次应该请求的最大量，那么，ZendMM将自动地发出一个E_ERROR消息并且启动相应的"跳出"进程。这种方 法的一个额外优点在于，大多数内存分配调用的返回值并不需要检查，因为如果失败的话将会导致立即跳转到引擎的退出部分。

　　把PHP内部代码和OS的实际的内存管理层"钩"在一起的原理并不复杂：所有内部分配的内存都要使用一组特定的可选函数实现。例如，PHP代码 不是使用malloc(16)来分配一个16字节内存块而是使用了emalloc(16)。除