[Traduction][développement d'extensions php et embarquées] Chapitre 3 - Gestion de la mémoire

Gestion de la mémoire

La différence la plus importante entre PHP et C est de savoir s'il faut contrôler le pointeur de mémoire.

Mémoire

En PHP, définir une variable de chaîne est très simple : < ;?php $str = 'hello world'; ?>, les chaînes peuvent être librement modifiées, copiées et déplacées. En C, c'est une autre façon, bien que vous puissiez simplement l'initialiser avec une chaîne statique : char * str. = "hello world"; Mais cette chaîne ne peut pas être modifiée car elle existe dans le segment de code. Pour créer une chaîne maintenable, vous devez allouer une mémoire et utiliser une fonction comme strdup() pour copier le contenu dans Parmi eux.

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

Les fonctions traditionnelles de gestion de la mémoire (malloc(), free(), strdup(), realloc(), calloc(), etc.) ne seront pas utilisées directement par le code source PHP. Ce chapitre expliquera le. raison de cela.

Libérer la mémoire allouée

La gestion de la mémoire était gérée de manière demande/libération sur toutes les plates-formes précédentes. L'application dit à sa couche supérieure (généralement le système d'exploitation) "Je veux". une certaine utilisation de la mémoire", si l'espace le permet, le système d'exploitation la fournit au programme et conserve une trace de la mémoire fournie.

Une fois que l'application a utilisé la mémoire, elle doit restituer la mémoire au système d'exploitation pour la rendre Elle peut être allouée ailleurs. Si le programme ne renvoie pas la mémoire, le système d'exploitation n'a aucun moyen de savoir que la mémoire n'est plus utilisée, elle ne peut donc pas être allouée à d'autres processus si un morceau de mémoire n'est pas libéré. l'application qui le possède en perd l'accès. Son handle, nous l'appelons "fuite", car personne ne peut l'obtenir directement.

Dans les applications clientes typiques, des fuites petites et peu fréquentes sont généralement tolérées car le processus sera se terminer après un certain temps, de sorte que la mémoire divulguée soit récupérée par le système d'exploitation. Ce n'est pas que le système d'exploitation connaît très bien la mémoire divulguée, mais il sait que la mémoire allouée au processus terminé ne sera plus utilisée.

Pour les démons côté serveur de longue durée, y compris les serveurs Web comme Apache, le processus est conçu pour s'exécuter pendant une longue période, généralement indéfiniment. Par conséquent, le système d'exploitation ne peut pas interférer avec l'utilisation de la mémoire ni avec aucun degré de fuite. peu importe la taille possible. Accumulé suffisamment pour provoquer l'épuisement des ressources système

Considérez la fonction stristr() dans l'espace utilisateur afin de trouver des chaînes sans tenir compte de la casse, elle crée en fait une copie en minuscules pour chaque botte de foin ; et aiguille, puis effectuez une recherche ordinaire sensible à la casse pour trouver le décalage approprié. Une fois le décalage de chaîne localisé, les versions minuscules des chaînes de botte de foin et d'aiguille ne sont plus utilisées. Si ces copies ne sont pas publiées, alors chaque script A. l'utilisation de stristr() entraînera une perte de mémoire à chaque appel. Finalement, le processus du serveur Web occupera toute la mémoire du système, mais il ne sera pas utilisé

La solution parfaite est bien écrite, propre et cohérente. code, garanti absolument correct. Mais dans un environnement comme l'interpréteur PHP, ce n'est que la moitié de la solution

Gestion des erreurs

Pour permettre l'activation à partir des scripts utilisateur La possibilité de sortir de. la requête et la fonction d'extension où elle se trouve nécessitent une méthode pour sortir de l'intégralité de la requête d'activation. La façon dont elle est gérée dans le moteur Zend est de définir une adresse de saut au début de la requête, après tout die()/. exit() appelle, ou en cas d'erreurs critiques (E_ERROR), longjmp() est exécuté pour rediriger vers l'adresse de saut prédéfinie.

Bien que ce type de traitement de saut simplifie le déroulement du programme, il présente un problème : Le code de nettoyage des ressources (tel que les appels free()) sera ignoré, ce qui entraînera des fuites. Considérez le code d'appel de fonction de traitement du moteur simplifié suivant :

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);  
}

Lorsque la ligne php_error_docref() est exécutée, la ligne php_error_docref() est exécutée. traitement interne Lorsque le processeur voit que le niveau d'erreur est critique, il appelle longjmp() pour interrompre le flux du programme en cours et quitter call_function(), afin que la ligne efree(lcase_fname) ne puisse pas être atteinte. Vous souhaiterez peut-être alors déplacer l'efree. () à php_error_docref () ci-dessus, mais que se passe-t-il si cet appel call_function() entre dans la première branche conditionnelle (le nom de la fonction est trouvé et exécuté normalement) Un autre point est que fname lui-même est une chaîne allouée et qu'elle est utilisée dans le fichier ? message d'erreur, vous ne pouvez pas le publier tant que vous n'avez pas fini de l'utiliser.

La fonction php_error_docref() est un équivalent interne de trigger_error(). Le premier paramètre est une référence de document facultative, qui sera utilisée si elle est activée dans. php.ini Ajouté à docref.root. Le troisième paramètre peut être n'importe quelle constante de la famille E_* pour marquer la gravité de l'erreur. Le quatrième paramètre et les suivants sont des chaînes de format et des listes de paramètres variables conformes au style printf().

Zend Memory Management

La solution aux fuites de mémoire dues aux rebonds de requêtes (défauts) est la couche Zend Memory Management (ZendMM). Cette partie du moteur joue un rôle équivalent à celui habituellement joué par l'opérateur. système, Allouer de la mémoire à l'application appelante. La différence est que du point de vue cognitif des demandes d'espace de processus, lors de la demande de mort, il peut effectuer la même chose que le système d'exploitation lorsque le processus meurt. En d'autres termes, cela libérera implicitement l'espace mémoire détenu par toutes les requêtes. La figure suivante montre la relation entre ZendMM et le système d'exploitation dans le processus php :

.

除了提供隐式的内存清理, 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）！