[번역][php 확장 개발 및 임베디드] 3장 - 메모리 관리

메모리 관리

PHP와 C의 가장 중요한 차이점은 메모리 포인터 제어 여부입니다.

메모리

PHP에서는 문자열 변수 설정이 매우 간단합니다. : < ;?php $str = 'hello world'; ?> C에서는 문자열을 자유롭게 수정, 복사 및 이동할 수 있지만 이는 단순히 정적 문자열로 초기화할 수도 있습니다. = "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가 유출된 메모리를 잘 아는 것은 아니지만 종료된 프로세스에 할당된 메모리는 다시 사용되지 않는다는 것을 알고 있습니다. Apache와 같은 웹 서버를 포함하여 장기간 실행되는 서버 측 데몬의 경우 프로세스는 일반적으로 무기한으로 장기간 실행되도록 설계됩니다. 따라서 OS는 아무리 작더라도 메모리 사용 및 누출 정도를 방해할 수 없습니다. , 시스템 리소스가 고갈될 만큼 충분할 수 있습니다.

대소문자를 구분하지 않고 문자열을 찾기 위해 사용자 공간에서 stristr() 함수를 고려하면 실제로 haystack 및 needle에 대한 소문자 복사본이 생성됩니다. , 그런 다음 일반 관련 오프셋을 찾기 위해 대소문자 구분 검색이 수행됩니다. 문자열 오프셋을 찾은 후에는 haystack 및 needle 문자열의 소문자 버전이 더 이상 사용되지 않습니다. stristr() 스크립트는 호출될 때마다 일부 메모리가 누출됩니다. 결국 웹 서버 프로세스는 전체 시스템 메모리를 차지하지만 사용되지는 않습니다.

완벽한 솔루션은 잘 작성되고 깨끗하며 일관됩니다. 그러나 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() 행이 실행되면 내부 프로세서에 오류가 표시됩니다. 레벨이 중요하므로 longjmp()를 호출하여 현재 프로그램 흐름을 중단하고 call_function()을 떠나 efree(lcase_fname) 라인에 도달할 수 없도록 합니다. 그런 다음 efree() 라인을 php_error_docref()로 이동할 수 있습니다. 이 call_function() 호출이 첫 번째 조건부 분기에 들어가면(함수 이름이 발견되어 정상적으로 실행됨) 또 다른 점은 fname 자체가 할당된 문자열이고 다 소모되기 전에 오류 메시지에 사용될 수 없다는 것입니다.

php_error_docref() 함수는 Trigger_error()와 동일한 내부 함수입니다. 첫 번째 매개변수는 .root 이후에 php.ini에서 활성화된 경우 docref에 추가되는 선택적 문서 참조입니다. 세 번째 매개변수는 오류의 심각도를 표시하는 E_* 계열 상수일 수 있습니다. 네 번째 및 후속 매개변수는 printf() 스타일을 따르는 형식 문자열 및 변수 매개변수 목록입니다.

Zend 메모리 관리

요청 반송(오류)으로 인한 메모리 누수에 대한 솔루션은 Zend 메모리 관리(ZendMM) 계층입니다. 엔진의 이 부분은 일반적으로 운영 체제에서 수행하는 것과 동일한 역할을 수행하여 애플리케이션 호출에 메모리를 할당합니다. 프로세스 공간 요청의 인지적 관점에서 보면 다이를 요청할 때 프로세스가 죽을 때 OS가 수행하는 것과 동일한 작업을 수행할 수 있다는 것입니다. 즉, 암시적으로 소유한 메모리 공간을 해제합니다. 다음 그림은 PHP 프로세스에서 ZendMM과 OS 간의 관계를 보여줍니다.

除了提供隐式的内存清理, ZendMM还通过php.ini的设置memory_limit控制了每个请求的内存使用. 如果脚本尝试请求超过系统允许的, 或超过单进程内存限制剩余量的内存, ZendMM会自动的引发一个E_ERROR消息, 并开始跳出进程. 一个额外的好处是多数时候内存分配的结果不需要检查, 因为如果失败会立即longjmp()跳出到引擎的终止部分.

在php内部代码和OS真实的内存管理层之间hook的完成, 最复杂的是要求所有内部的内存分配要从一组函数中选择. 例如, 分配一个16字节的内存块不是使用malloc(16), php代码应该使用emalloc(16). 除了执行真正的内存分配任务, ZendMM还要标记内存块所绑定请求的相关信息, 以便在请求被故障跳出时, ZendMM可以隐式的释放它(分配的内存).

很多时候内存需要分配, 并使用超过单请求生命周期的时间. 这种分配我们称为持久化分配, 因为它们在请求结束后持久的存在, 可以使用传统的内存分配器执行分配, 因为它们不可以被ZendMM打上每个请求的信息. 有时, 只有在运行时才能知道特定的分配需要持久化还是不需要, 因此ZendMM暴露了一些帮助宏, 由它们来替代其他的内存分配函数, 但是在末尾增加了附加的参数来标记是否持久化.

如果你真的想要持久化的分配, 这个参数应该被设置为1, 这种情况下内存分配的请求将会传递给传统的malloc()族分配器. 如果运行时逻辑确定这个块不需要持久化 则这个参数被设置为0, 调用将会被转向到单请求内存分配器函数.

例如, 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))

传统分配器	php中的分配器
void *malloc(size_t count);	void *emalloc(size_t count);
	void *pemalloc(size_t count, char persistent);
void *calloc(size_t count);	void *ecalloc(size_t count);
	void *pecalloc(size_t count, char persistent);
void *realloc(void *ptr, size_t count);	void *erealloc(void *ptr, size_t count);
	void *perealloc(void *ptr, size_t count, char persistent);
void *strdup(void *ptr);	void *estrdup(void *ptr);
	void *pestrdup(void *ptr, char persistent);
void free(void *ptr);	void efree(void *ptr);
	void pefree(void *ptr, char persistent);

你可能注意到了, pefree要求传递持久化标记. 这是因为在pefree()调用时, 它并不知道ptr是否是持久分配的. 在废持久分配的指针上调用free()可能导致双重的free, 而在持久化的分配上调用efree()通常会导致段错误, 因为内存管理器会尝试查看管理信息, 而它不存在. 你的代码需要记住它分配的数据结构是不是持久化的.

除了核心的分配器外, ZendMM还增加了特殊的函数:

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

它分配len + 1字节的内存, 并从ptr拷贝len个字节到新分配的块中. estrndup()的行为大致如下:

void *estrndup(void *ptr, int len)  
{  
    char *dst = emalloc(len + 1);  
    memcpy(dst, ptr, len);  
    dst[len] = 0;  
    return dst;  
}

终止NULL字节被悄悄的放到了缓冲区末尾, 这样做确保了所有使用estrndup()进行字符串赋值的函数不用担心将结果缓冲区传递给期望NULL终止字符串的函数(比如printf())时产生错误. 在使用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()和safe_pemalloc()在php 5.1之前就不存在. 有时你需要在ZendAPI的这些不足上工作.

引用计数

在php这样长时间运行的多请求进程中谨慎的分配和释放内存非常重要, 但这只是一半工作. 为了让高并发的服务器更加高效, 每个请求需要使用尽可能少的内存, 最小化不需要的数据拷贝. 考虑下面的php代码片段:

<?php  
    $a = &#39;Hello World&#39;;  
    $b = $a;  
    unset($a);  
?>

在第一次调用后, 一个变量被创建, 它被赋予12字节的内存块, 保存了字符串"Hello world"以及结尾的NULL. 现在来看第二句: $b被设置为和$a相同的值, 接着$a被unset(释放)

如果php认为每个变量赋值都需要拷贝变量的内容, 那么在数据拷贝期间就需要额外的12字节拷贝重复的字符串, 以及额外的处理器负载. 在第三行出现的时候, 这种行为看起来就有些可笑了, 原来的变量被卸载使得数据的复制完全不需要. 现在我们更进一步想想当两个变量中被装载的是一个10MB文件的内容时, 会发生什么? 它需要20MB的内存, 然而只要10MB就足够了. 引擎真的会做这种无用功浪费这么多的时间和内存吗?

你知道php是很聪明的.

还记得吗? 在引擎中变量名和它的值是两个不同的概念. 它的值是自身是一个没有名字的zval *. 使用zend_hash_add()将它赋值给变量$a. 那么两个变量名指向相同的值可以吗?

{  
    zval *helloval;  
    MAKE_STD_ZVAL(helloval);  
    ZVAL_STRING(helloval, "Hello World", 1);  
    zend_hash_add(EG(active_symbol_table), "a", sizeof("a"),  
                                           &helloval, sizeof(zval*), NULL);  
    zend_hash_add(EG(active_symbol_table), "b", sizeof("b"),  
                                           &helloval, sizeof(zval*), NULL);  
}

此时, 在你检查$a或$b的时候, 你可以看到, 它们实际都包含了字符串"Hello World". 不幸的是, 接着来了第三行: unset($a);. 这种情况下, unset()并不知道$a指向的数据还被另外一个名字引用, 它只是释放掉内存. 任何后续对$b的访问都将查看已经被释放的内存空间, 这将导致引擎崩溃. 当然, 你并不希望引擎崩溃.

这通过zval的第三个成员: refcount解决. 当一个变量第一次被创建时, 它的refcount被初始化为1, 因为我们认为只有创建时的那个变量指向它. 当你的代码执行到将helloval赋值给$b时, 它需要将refcount增加到2, 因为这个值现在被两个变量"引用"

{  
    zval *helloval;  
    MAKE_STD_ZVAL(helloval);  
    ZVAL_STRING(helloval, "Hello World", 1);  
    zend_hash_add(EG(active_symbol_table), "a", sizeof("a"),  
                                           &helloval, sizeof(zval*), NULL);  
    ZVAL_ADDREF(helloval);  
    zend_hash_add(EG(active_symbol_table), "b", sizeof("b"),  
                                           &helloval, sizeof(zval*), NULL);  
}

现在, 当unset()删除变量的$a拷贝时, 它通过refcount看到还有别人对这个数据感兴趣, 因此它只是将refcount减1, 其他什么事情都不做.

写时复制

通过引用计数节省内存是一个很好的主意, 但是当你只想修改其中一个变量时该怎么办呢? 考虑下面的代码片段:

<?php  
    $a = 1;  
    $b = $a;  
    $b += 5;  
?>

看上面代码的逻辑, 处理完后期望$a仍然等于1, 而$b等于6. 现在你知道, Zend为了最大化节省内存, 在第二行代码执行后$a和$b只想同一个zval, 那么到达第三行代码时会发生什么呢? $b也会被修改吗?

答案是Zend查看refcount, 看到它大于1, 就对它进行了隔离. Zend引擎中的隔离是破坏一个引用对, 它和你刚才看到的处理是对立的:

zval *get_var_and_separate(char *varname, int varname_len TSRMLS_DC)  
{  
    zval **varval, *varcopy;  
    if (zend_hash_find(EG(active_symbol_table),  
                       varname, varname_len + 1, (void**)&varval) == FAILURE) {  
       /* 变量不存在 */  
       return NULL;  
   }  
   if ((*varval)->refcount < 2) {  
       /* 变量名只有一个引用, 不需要隔离 */  
       return *varval;  
   }  
   /* 其他情况, 对zval *做一次浅拷贝 */  
   MAKE_STD_ZVAL(varcopy);  
   varcopy = *varval;  
   /* 对zval *进行一次深拷贝 */  
   zval_copy_ctor(varcopy);  
  
   /* 破坏varname和varval之间的关系, 这一步会将varval的引用计数减小1 */  
   zend_hash_del(EG(active_symbol_table), varname, varname_len + 1);  
  
   /* 初始化新创建的值的引用计数, 并为新创建的值和varname建立关联 */  
   varcopy->refcount = 1;  
   varcopy->is_ref = 0;  
   zend_hash_add(EG(active_symbol_table), varname, varname_len + 1,  
                                        &varcopy, sizeof(zval*), NULL);  
   /* 返回新的zval * */  
   return varcopy;  
}

现在引擎就有了一个只被$b变量引用的zval *, 就可以将它转换为long, 并将它的值按照脚本请求增加5.

写时修改

引用计数的概念还创建了一种新的数据维护方式, 用户空间脚本将这种方式称为"引用". 考虑下面的用户空间代码片段:

<?php  
    $a = 1;  
    $b = &$a;  
    $b += 5;  
?>

凭借你在php方面的经验, 直觉上你可能认识到$a的值现在应该是6, 即便它被初始化为1并没有被(直接)修改过. 发生这种情况是因为在引擎将$b的值增加5的时候, 它注意到$b是$a的一个引用, 它就说"对于我来说不隔离它的值就修改是没有问题的, 因为我原本就想要所有的引用变量都看到变更"

但是引擎怎么知道呢? 很简单, 它查看zval结构的最后一个元素: is_ref. 它只是一个简单的开关, 定义了zval是值还是用户空间中的引用. 在前面的代码片段中, 第一行执行后, 为$a创建的zval, refcount是1, is_ref是0, 因为它仅仅属于一个变量($a), 并没有其他变量的引用指向它. 第二行执行时, 这个zval的refcount增加到2, 但是此时, 因为脚本中增加了一个取地址符(&)标记它是引用传值, 因此将is_ref设置为1.

最后, 在第三行中, 引擎获得$b关联的zval, 检查是否需要隔离. 此时这个zval不会被隔离, 因为在前面我们没有包含的一段代码(如下). 在get_var_and_separate()中检查refcount的地方, 还有另外一个条件:

if ((*varval)->is_ref || (*varval)->refcount < 2) {  
    /* varname只有在真的是引用方式, 或者只被一个变量引用时才会不发生隔离 */  
    return *varval;  
}

此时, 即便refcount为2, 隔离处理也会被短路, 因为这个值是引用传值的. 引擎可以自由的修改它而不用担心引用它的其他变量被意外修改.

隔离的问题

对于这些拷贝和引用, 有一些组合是is_ref和refcount无法很好的处理的. 考虑下面的代码:

<?php  
    $a = 1;  
    $b = $a;  
    $c = &$a;  
?>

这里你有一个值需要被3个不同的变量关联, 两个是写时修改的引用方式, 另外一个是隔离的写时复制上下文. 仅仅使用is_ref和refcount怎样来描述这种关系呢?

答案是: 没有. 这种情况下, 值必须被复制到两个分离的zval *, 虽然两者包含相同的数据. 如下图:

类似的, 下面的代码块将导致相同的冲突, 并强制值隔离到一个拷贝中(如下图)

<?php  
    $a = 1;  
    $b = &$a;  
    $c = $a;  
?>

注意, 这里两种情况下, $b都和原来的zval对象关联, 因为在隔离发生的时候, 引擎不知道操作中涉及的第三个变量的名字.

小结

php是一种托管语言. 从用户空间一侧考虑, 小心的控制资源和内存就意味着更容易的原型涉及和更少的崩溃. 在你深入研究揭开引擎的面纱后, 就不能再有博彩心里, 而是对运行环境完整性的开发和维护负责.

以上就是 [翻译][php扩展开发和嵌入式]第3章-内存管理的内容，更多相关内容请关注PHP中文网（www.php.cn）！