ngx_pool_cleanup_add使用-原理

痛定思痛。 2022-08-14 03:42 151阅读 0赞

参考：

[http://www.cnblogs.com/jzhlin/archive/2012/06/07/ngx\_palloc.html][http_www.cnblogs.com_jzhlin_archive_2012_06_07_ngx_palloc.html]

上一篇已经通过对 ngx\_palloc这个内存池（pool）管理的核心函数\--内存分配函数进行解析，我们窥探到了Nginx内存管理的主体方法还有对于大内存需求的解决之道，同时也对管理内存池的数据结构有了更深一步的认识，通过这些认识我们可以得到以下这样一张数据结构的示意图：

![Center][]

图3 Nginx内存管理数据结构示意图

做说明下，这里示意的是有需求大内存分配时的结构示意图，为了图示的方便，我们将 large\_t特殊话到了和 large所在的同一个pool单元里面，其实实际运行中并非一定在同一个pool单元中。如果没有大内存需求时 large\_t 也并不存在。

分析完了，内存分配函数 ngx\_palloc，可以说nginx内存分配机制的解析我们已经完成了一半，对于 ngx\_palloc的变种函数如：ngx\_pcalloc、ngx\_pnalloc等就不一一详细说明了，和 ngx\_palloc结构类似或者只是添加了少许功能（比如，初始化内存数据为0等）。我们再来分析内存池的其他函数

**1、创建内存池**

ngx\_pool\_t\*ngx\_create\_pool(size\_t size, ngx\_log\_t \*log)

此函数结构简明，是对 ngx\_pool\_t按照 size的大小进行些必要的初始化，并返回一个指针。

**2、释放内存池**

内存池pool的注销函数 ngx\_destroy\_pool

分析这个函数，首先得分析Nginx内存池的注销机制。我知道在需求内存时很可能用到一些数据结构，注销时需要特别的对它进行释放，否则可能发生内存泄漏。对这样的情况，Nginx内存管理中，采用了一个有特点的结构体来应对\--ngx\_pool\_cleanup\_t，对应的就是pool单元中的 cleanup。

struct ngx_pool_cleanup_s {

ngx_pool_cleanup_pt   handler;

void                 *data;

ngx_pool_cleanup_t   *next;

};

一个看显然就明白是个链表，不过，ngx\_pool\_cleanup\_pt是什么呢？请看下面这个定义

typedef void (*ngx_pool_cleanup_pt)(void *data);

很明白了，原来是一个函数指针。这一下问题就显然解决了，在内存管理中遇到这样的特殊的数据结构，只要编写它相应的释放函数，用函数指针加载到pool单元上，在注销pool内存池时调用即可。**特别说明下是，ngx\_pool\_cleanup\_t 数据结构中的data存储的是 handler 指向的函数可能需要用到的参数。**看起来很有C++中类的析构函数的味道，可以有多个这样的函数用 ngx\_pool\_cleanup\_t链表的形式保存。回到，Nginx内存管理的源代码里，我们可以找到 ngx\_pool\_cleanup\_add这样的一个函数，和预想的一样，它就是分配释放函数的内存，并返回地址。附上源码：

ngx\_pool\_cleanup\_t \*ngx\_pool\_cleanup\_add(ngx\_pool\_t\*p, size\_t size)

\#if (NGX\_PCHECK)  
ngx\_pool\_cleanup\_t \*  
\_ngx\_pool\_cleanup\_add(ngx\_pool\_t \*p, size\_t size,  
char \*name, char \*file, char \*func, ngx\_int\_t line)  
\#else  
ngx\_pool\_cleanup\_t \*  
ngx\_pool\_cleanup\_add(ngx\_pool\_t \*p, size\_t size)  
\#endif  
\{   
    ngx\_pool\_cleanup\_t  \*c;  
  
  
\#if (NGX\_PCHECK)  
    c = \_ngx\_palloc(p, sizeof(ngx\_pool\_cleanup\_t),  
name, file, func, line);  
\#else  
    c = ngx\_palloc(p, sizeof(ngx\_pool\_cleanup\_t));  
\#endif  
if (c == NULL) \{   
        return NULL;  
    \}  
  
  
    if (size) \{   
\#if (NGX\_PCHECK)  
c->data = \_ngx\_palloc(p, size, name, file, func, line);  
\#else  
        c->data = ngx\_palloc(p, size);  
\#endif  
        if (c->data == NULL) \{   
            return NULL;  
        \}  
  
  
    \} else \{   
        c->data = NULL;  
    \}  
  
  
    c->handler = NULL;  
    c->next = p->cleanup;  
  
  
    p->cleanup = c;  
  
  
    ngx\_log\_debug1(NGX\_LOG\_DEBUG\_ALLOC, p->log, 0, "add cleanup: %p", c);  
  
  
    return c;  
\}

好了，理解了释放特殊结构体后，我们再来看 ngx\_destroy\_pool就比较简单了。

**内存池的建设过程，先建pool单元，如果有大内存需求再建large。**

**内存池注销正好相反，首先处理 ngx\_pool\_cleanup\_t 的特殊需求，如果有的话然后释放分配large，最后释放pool。**其中如果配置了要写的DEBUG日志的，就还对DEBUG日志进行记录。附上源码：

void

ngx\_destroy\_pool(ngx\_pool\_t \*pool)

ngx\_pool\_t          \*p, \*n;

ngx\_pool\_large\_t    \*l;

ngx\_pool\_cleanup\_t  \*c;

/\*

处理 ngx\_pool\_cleanup\_t的特殊需求

\*/

**for (c =pool->cleanup; c; c = c->next) \{**

**        if(c->handler) \{**

**           ngx\_log\_debug1(NGX\_LOG\_DEBUG\_ALLOC, pool->log, 0,**

**                          "run cleanup: %p", c);**

**           c->handler(c->data);**

**        \}**

**    \}**

/\*

释放分配large

\*/

for (l =pool->large; l; l = l->next) \{

ngx\_log\_debug1(NGX\_LOG\_DEBUG\_ALLOC, pool->log, 0, "free:%p", l->alloc);

if(l->alloc) \{

ngx\_free(l->alloc);

\#if (NGX\_DEBUG)

/\*

\* we couldallocate the pool->log from this pool

\* so we cannot usethis log while free()ing the pool

\*/

for (p = pool, n =pool->d.next; /\* void \*/; p = n, n = n->d.next) \{

ngx\_log\_debug2(NGX\_LOG\_DEBUG\_ALLOC, pool->log, 0,

"free: %p, unused: %uz", p, p->d.end - p->d.last);

if (n == NULL)\{

break;

\#endif

/\*

释放pool

\*/

for (p = pool, n =pool->d.next; /\* void \*/; p = n, n = n->d.next) \{

ngx\_free(p);

if (n == NULL)\{

break;

大家或许有点疑惑，内存真的没有泄漏了么？ngx\_pool\_cleanup\_t 所占的内存，释放了么?答案当然是肯定的！如果有这样的疑惑，请仔细看 ngx\_pool\_cleanup\_add函数他给 ngx\_pool\_cleanup\_t 分配的内存空间也是pool单元中的内存(同样的 ngx\_pool\_large\_t )，释放pool的时候一并释放出来。

分析到这里，Nginx内存管理机制源码的分析就基本上结束了。感慨到Nginx内存池的设计确实精美，pool单元数据结构的设计（实用）、内存分配机制（大内存特殊处理，大内存信息的结构体也在内存池中）、内存释放机制（经典的函数指针用法，很巧妙的防止内存泄漏），很多地方都可以借鉴！

**3、worker进程退出时候会释放cycle->pool**

通过函数ngx\_worker\_process\_cycle可以看出，由于进入for(;;)之前执行了ngx\_worker\_process\_init(cycle,worker)即会调用每个模块的init\_process指向的函数，退出for(;;)后执行ngx\_worker\_process\_exit(cycle)即会调用ngx\_destroy\_pool(cycle->pool);

**我们可以在每个模块的init\_process指向的函数中从cycle->pool中申请内存并且调用cln = ngx\_pool\_cleanup\_add(pool,0)设置清理函数cln->handler**，当worker进程退出时候释放cycle->pool之前则会调用每个模块注册的cln->handler。

**4、实验**

我们在  ngx\_palloc添加上一条 printf("call ngx\_palloc\\n")其他函数也添加上类似的语句，编写如下main代码：

void fun(void *p)

{

printf("call fun\n");

}

int ngx_cdecl

main(int argc, char *const *argv)

{

ngx_pool_t    *t;

ngx_pool_cleanup_t *clt;

void *p1,*p2,*p3;

t=ngx_create_pool(512,NULL); /*创建pool*/

printf("\n");

p1=ngx_palloc(t,416); /*分配内存，在可分配内*/

printf("\n");

p2=ngx_palloc(t,216);/*分配内存，在可分配内，但pool中没有足够的内存空间*/

printf("\n");

p3=ngx_palloc(t,624);/*分配大内存*/

printf("\n");

clt=ngx_pool_cleanup_add(t, sizeof(void *));/*添加释放特殊结构体的函数*/

clt->handler=&fun;

ngx_destroy_pool(t);/*pool池注销*/

printf("\n");

return 0;

}

实验结果，截图如下：

![Image 1][]![Center 1][]

图4 Nginx内存管理机制实验截图

实验结果简单说明下：

call ngx\_create\_pool //创建了pool池

call ngx\_palloc  //分配内存，在可分配内

call ngx\_palloc //分配内存，在可分配内，但pool中没有足够的内存空间

call ngx\_palloc\_block //分配新的pool单元

callngx\_palloc  //分配大内存  
call ngx\_palloc\_large  //调用大内存分配函数  
call ngx\_palloc  //分配 ngx\_pool\_large\_t结构体空间

call ngx\_pool\_cleanup\_add //添加释放特殊结构体的函数

callngx\_palloc  //分配ngx\_pool\_cleanup\_t 的空间  
call ngx\_palloc  //分配函数参数的空间  
call ngx\_destroy\_pool  //内存池pool池注销

call fun  //调用释放特殊结构体的函数释放

以上实验结果，完全符合我们分析Nginx内存分配机制，Nginx内存池(pool)的分析到此处就结束了。经典的内存池管理机制！

[http_www.cnblogs.com_jzhlin_archive_2012_06_07_ngx_palloc.html]: http://www.cnblogs.com/jzhlin/archive/2012/06/07/ngx_palloc.html
[Center]: /images/20220810/7dbcf83c71754f41a8581307739eaf52.png
[Image 1]: 
[Center 1]: /images/20220810/7124298f47304cdfb002f47082ce2d43.png