3.1 内存管理

在PHP里，我们可以定义字符串变量，比如 <?php $str="hello";?>，$str 这个字符串变量可以被自由的修改与复制等。这一切在 C 语言里看起来都是不可能的事情，我们用 char *p = "hello"; 来定义一个字符串，但它是常量，是不能被修改的，如果你用 p[1]='c'; 来修改这个字符串会引发段错误（Gcc,c99），为了修改 C 语言里的字符串常量，我们往往需要定义字符串数组。为了得到一个能够让我们自由修改的字符串，我们往往需要用strdup函数来复制一个字符串出来。

{
    char *p = "hello world";
    // p[0] = 'a'; 如果这么做，就等着运行时段错误吧。
    char *str;
    str = strdup(p);
    str[0] = 'a'; //这时就能自由修改了。
}       

在 PHP 内核中，大多数情况下都不应该直接使用 C 语言中自带着 malloc、free、strdup、realloc、calloc 等操作内存的函数，而应使用内核提供的操作内存的函数，这样可以由内核整体统一的来管理内存。

Free the Mallocs

每个平台操作内存的方式都是差不多的有两个方面，一负责申请，二负责释放。如果应用程序向系统申请内存，系统便会在内存中寻找还没有被使用的地方，如果有合适的，便分配给这个程序，并标记下来，不再给其它的程序了。如果一个内存块没有释放，而所有者应用程序也永远不再使用它了。

那么，我们就称其为"内存泄漏"，那么这部分内存就无法再为其它程序所用了。
在一个典型的客户端应用程序中，偶尔的小量的内存泄漏是可以被操作系统容忍的，因为在进程结束后该泄漏内存会被返回给 OS。这并没有什么高科技含量，因为OS知道它把该内存分配给了哪个程序，并且它能够在一个程序结束后把这些内存给回收回来。

但是，世界总是不缺乏特例！对于一些需要长时间运行的程序，比如像 Apache 这样的 web 服务器以及它的 php 模块来说，都是伴随着操作系统长时间运行的，所以OS在很长一段时间内不能主动的回收内存，从而导致这个程序的每一个内存泄漏都会促进量变到质变的进化，最终引起严重的内存泄漏错误，使系统的资源消耗殆尽。

现在，我们来在C语言中故意错误的模拟一下 PHP 的 stristr() 函数为例，为了使用大小写不敏感的方式来搜索一个字符串，我们需要创建两个辅助的字符串，它们分别是被查找字符串和待查找字符串的小写化副本，然后由这两个副本来帮助我们来完成这次搜索。如果我们在执行这个函数后不释放这些副本占用的资源，那么每一次stristr函数都将是对内存的一次永远的侵占，最终导致这个函数占用了所有的系统内存，而没有实际意义！

大多数人提出来的理想的解决方案是：书写优秀，整洁并且风格一致的代码，这当然是毫无疑问的。但是在PHP扩展开发这样的底层环境中，这并不能解决全部的问题。比如，你需要自己保证在层层嵌套调用中对某块内存的使用都是正确的，且会及时释放的。

错误处理

为了实现从用户端（PHP 语言中）跳出，需要使用一种方法来完全 跳出 一个活动请求。这个功能是在内核中实现的：在一个请求的开始设置一个 跳出 地址，然后在任何 die() 或 exit() 调用或在遇到任何关键错误（E_ERROR）时执行一个 longjmp() 以跳转到该 跳出 地址。

void call_function(const char *fname, int fname_len TSRMLS_DC)
{
    zend_function *fe;
    char *lcase_fname;
    /* php函数的名字是大小写不敏感的
     * 我们可以在function tables里找到他们
     * 保存的所有函数名都是小写的。
     */
    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) == SUCCESS)
    {
        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 这个函数被调用的时候，便会触发内核中的错误处理机制，根据错误级别来决定是否调用 longjmp 来终止当前请求并退出 call_function 函数，从而 efree 函数便永远不会被执行了。

其实 php_error_docref() 函数就相当于 php 语言里的 trigger_error() 函数。它的第一个参数是一个将被添加到docref的可选的文档引用第三个参数可以是任何我们熟悉的 E_* 家族常量，用于指示错误的严重程度。后面的两个参数就像 printf() 风格的格式化和变量参数列表式样。

Zend 内存管理器

在上面的"跳出"请求期间解决内存泄漏的方案之一是：使用 Zend 内存管理（Zend Memory Manager，简称 ZendMM、ZMM）层。内核的这一部分非常类似于操作系统的内存管理功能——分配内存给调用程序。区别在于，它处于进程空间中非常低的位置而且是 请求感知 的；这样一来，当一个请求结束时，它能够执行与 OS 在一个进程终止时相同的行为。也就是说，它会隐式地释放所有的为该请求所占用的内存。

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

把 PHP 内核代码和 OS 的实际的内存管理层 钩 在一起的原理并不复杂：所有内部分配的内存都要使用一组特定的可选函数实现。例如，PHP 内核代码不是使用 malloc(16) 来分配一个 16 字节内存块而是使用了 emalloc(16)。除了实现实际的内存分配任务外，ZendMM 还会使用相应的绑定请求类型来标志该内存块；这样以来，当一个请求 跳出 时，ZendMM 可以隐式地释放它。

有些时候，某次申请的内存需要在一个请求结束后仍然存活一段时间，也就是持续性存在于各个请求之间。这种类型的分配（因其在一次请求结束之后仍然存在而被称为 永久性分配），可以使用传统型内存分配器来实现，因为这些分配并不会添加 ZendMM 使用的那些额外的相应于每种请求的信息。

然而有时，我们必须在程序运行时根据某个数据的具体值或者状态才能确定是否需要进行永久性分配，因此 ZendMM 定义了一组帮助宏，其行为类似于其它的内存分配函数，但是使用最后一个额外参数来指示是否为永久性分配。

如果你确实想实现一个永久性分配，那么这个参数应该被设置为 1；在这种情况下，请求是通过传统型 malloc() 分配器家族进行传递的。然而，如果运行时刻逻辑认为这个块不需要永久性分配；那么，这个参数可以被设置为零，并且调用将会被调整到针对每种请求的内存分配器函数。
例如，pemalloc(buffer_len，1) 将映射到 malloc(buffer_len)，而 pemalloc(buffer_len，0) 将被使用下列语句映射到 emalloc(buffer_len)：

//define in Zend/zend_alloc.h:
#define pemalloc(size, persistent) ((persistent)?malloc(size): emalloc(size))

所有这些在ZendMM中提供的内存管理函数都能够从下表中找到其在C语言中的函数。

你可能会注意到，即使是 pefree() 函数也要求使用永久性标志。这是因为在调用 pefree() 时，它实际上并不知道是否 ptr 是一种永久性分配。

需要注意的是，如果针对一个 ZendMM 申请的非永久性内存直接调用 free() 能够导致双倍的空间释放，而针对一种永久性分配调用 efree() 有可能会导致一个段错误，因为 ZendMM 需要去查找并不存在的管理信息。因此，你的代码需要记住它申请的内存是否是永久性的，从而选择不同的内存函数，free() 或者 efree()。

除了上述内存管理函数外，还存在其它一些非常方便的 ZendMM 函数，例如：

void *estrndup(void *ptr，int len);  

该函数能够分配 len+1 个字节的内存并且从 ptr 处复制 len 个字节到最新分配的块。这个 estrndup() 函数的行为可以大致描述如下：

ZEND_API char *_estrndup(const char *s, uint length ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)
{
    char *p;

    p = (char *) _emalloc(length+1 ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
    if (UNEXPECTED(p == NULL))
    {
        return p;
    }
    memcpy(p, s, length);
    p[length] = 0;
    return p;
}

在此，被隐式放置在缓冲区最后的0可以确保任何使用 estrndup() 实现字符串复制操作的函数都不需要担心会把结果缓冲区传递给一个例如 printf() 这样的希望以为 NULL 为结束符的函数。当使用 estrndup() 来复制非字符串数据时，最后一个字节实质上浪费了，但其中的利明显大于弊。

void *safe_emalloc(size_t size, size_t count, size_t addtl);
void *safe_pemalloc(size_t size, size_t count, size_t addtl, char persistent);

这些函数分配的内存空间最终大小都是 (size*count)+addtl。

你可以会问：为什么还要提供额外函数呢？为什么不使用一个 emalloc/pemalloc 呢？。

原因很简单：为了安全，以防万一。尽管有时候可能性相当小，但是，正是这一 可能性相当小 的结果导致宿主平台的内存溢出。

这可能会导致分配负数个数的字节空间，或更有甚者，会导致分配一个小于调用程序要求大小的字节空间。

而 safe_emalloc() 能够避免这种类型的陷井-通过检查整数溢出并且在发生这样的溢出时显式地预以结束。

注意，并不是所有的内存分配例程都有一个相应的 p* 对等实现。例如，不存在 pestrndup()，并且在 PHP 5.1 版本前也不存在 safe_pemalloc()。