目錄

0. 摘要

1. nginx內存結構設計

2. nginx內存數據結構

3. nginx內存管理原理

4. 一個簡單的內存模型

5. 小結

6. 參考資料

0. 摘要

內存管理，是指軟件運行時對計算機內存資源的分配和使用的技術。其最主要的目的是如何高效，快速的分配，并且在適當的時候釋放和回收內存資源。

在講解nginx內存管理之前，先思考以下幾個問題。（在小結中會一一回答）

（1）nginx為什么要進行內存管理？

（2）nginx如何進行內存管理？

（3）nginx的內存管理解決了哪些問題？

1. nginx內存結構設計

圖1.1 nginx內存結構設計圖（1）

nginx采用內存池的結構設計來管理內存。內存池是由若干固定大小的內存塊組成的單向鏈表。每個內存塊的設計圖如圖1.1。一個簡單的內存池如圖1.2

圖1.2 nginx內存結構設計圖（2）

從圖1.2中可以看出，內存池的頭結點維護著內存池的總體信息，從頭結點開始，可以訪問內存池的小塊內存（單向鏈表，由ngx_pool_data_t維護），大塊內存（單向鏈表，由ngx_pool_large_t維護），以及抽象內存數據（單向鏈表，由ngx_pool_chain_t維護）。內存池結構涉及的具體數據結構在第2節講解，內存池的管理包括初始化、創建、分配、銷毀四部分，在第3節講解。

2. nginx內存數據結構

2.1 內存池基礎數據結構

（1）內存池?ngx_pool_t：負責整個內存池的管理。

1 typedef struct ngx_pool_s ngx_pool_t; 2 struct ngx_pool_s { // 內存池的管理分配模塊 3 ngx_pool_data_t d; // 內存池的數據塊 4 size_t max; // 數據塊大小，小塊內存的最大值 5 ngx_pool_t *current; // 指向內存池可用數據塊 6 ngx_chain_t *chain; // 該指針掛接一個ngx_chain_t結構 7 ngx_pool_large_t *large; // 指向大塊內存分配，nginx中，大塊內存分配直接采用標準系統接口malloc 8 ngx_pool_cleanup_t *cleanup; // 析構函數，掛載內存釋放時需要清理資源的一些必要操作 9 ngx_log_t *log; // 內存分配相關的日志記錄 10 };

（2）ngx_pool_data_t：負責內存池小塊數據的管理。

1 typedef struct { // 內存池的數據結構模塊 2 u_char *last; // 當前內存分配結束位置，即下一段可分配內存的起始位置 3 u_char *end; // 內存池的結束位置 4 ngx_pool_t *next; // 鏈接到下一個內存池，內存池的很多塊內存就是通過該指針連成鏈表的 5 ngx_uint_t failed; // 記錄內存分配不能滿足需求的失敗次數，當失敗次數大于指定值時 current 指向下一內存池單元 6 } ngx_pool_data_t; // 結構用來維護內存池的數據塊，供用戶分配小塊內存使用。

（3）ngx_chain_t：負責內存池抽象數據的管理，比如緩存數據，文件數據。

1 typedef struct ngx_buf_s ngx_buf_t; 2 struct ngx_buf_s { 3 u_char *pos; // 當buf所指向的數據在內存里的時候，pos指向的是這段數據開始的位置。 4 u_char *last; // 當buf所指向的數據在內存里的時候，last指向的是這段數據結束的位置。 5 off_t file_pos; // 當buf所指向的數據是在文件里的時候，file_pos指向的是這段數據的開始位置在文件中的偏移量。 6 off_t file_last; // 當buf所指向的數據是在文件里的時候，file_last指向的是這段數據的結束位置在文件中的偏移量。 7 /* 當buf所指向的數據在內存里的時候，這一整塊內存包含的內容可能被包含在多個buf中(比如在某段數據中間插入了其他的數據，這一塊數據就需要被拆分開)。那么這些buf中的start和end都指向這一塊內存的開始地址和結束地址。而pos和last指向本buf所實際包含的數據的開始和結尾。 8 */ 9 u_char *start; 10 // 解釋參考 start 11 u_char *end; /* end of buffer */ 12 ngx_buf_tag_t tag; 13 ngx_file_t *file; // 當buf所包含的內容在文件中是，file字段指向對應的文件對象。 14 /* 當這個buf完整copy了另外一個buf的所有字段的時候，那么這兩個buf指向的實際上是同一塊內存，或者是同一個文件的同一部分，此時這兩個buf的shadow字段都是指向對方的。那么對于這樣的兩個buf，在釋放的時候，就需要使用者特別小心，具體是由哪里釋放，要提前考慮好，如果造成資源的多次釋放，可能會造成程序崩潰！*/ 15 ngx_buf_t *shadow; 16 17 /* the buf's content could be changed */ 18 // 為1時表示該buf所包含的內容是在一個用戶創建的內存塊中，并且可以被在filter處理的過程中進行變更，而不會造成問題。 19 unsigned temporary:1; 20 21 /* 22 * the buf's content is in a memory cache or in a read only memory 23 * and must not be changed 24 */ // 為1時表示該buf所包含的內容是在內存中，但是這些內容確不能被進行處理的filter進行變更。 25 unsigned memory:1; 26 27 /* the buf's content is mmap()ed and must not be changed */ 28 // 為1時表示該buf所包含的內容是在內存中, 是通過mmap使用內存映射從文件中映射到內存中的，這些內容確不能被進行處理的filter進行變更。 29 unsigned mmap:1; 30 31 unsigned recycled:1; 32 unsigned in_file:1; // 為1時表示該buf所包含的內容是在文件中。 33 /* 遇到有flush字段被設置為1的的buf的chain，則該chain的數據即便不是最后結束的數據（last_buf被設置，標志所有要輸出的內容都完了），也會進行輸出，不會受postpone_output配置的限制，但是會受到發送速率等其他條件的限制。 34 */ 35 unsigned flush:1; 36 unsigned sync:1; 37 unsigned last_buf:1; // 數據被以多個chain傳遞給了過濾器，此字段為1表明這是最后一個buf。 38 /* 在當前的chain里面，此buf是最后一個。特別要注意的是last_in_chain的buf不一定是last_buf，但是last_buf的buf一定是last_in_chain的。這是因為數據會被以多個chain傳遞給某個filter模塊。 39 */ 40 unsigned last_in_chain:1; 41 42 unsigned last_shadow:1; 43 unsigned temp_file:1; 44 45 /* STUB */ int num; 46 };

（4）ngx_pool_large_t：負責內存池大塊數據（size>max）的管理，大塊內存直接實時向系統申請。

1 typedef struct ngx_pool_large_s ngx_pool_large_t; 2 struct ngx_pool_large_s { 3 ngx_pool_large_t *next; 4 void *alloc; 5 };

（5）ngx_pool_cleanup_t：負責內存池數據的回收。引用：“cleanup字段管理著一個特殊的鏈表，該鏈表的每一項都記錄著一個特殊的需要釋放的資源。對于這個鏈表中每個節點所包含的資源如何去釋放，是自說明的。這也就提供了非常大的靈活性。意味著，ngx_pool_t不僅僅可以管理內存，通過這個機制，也可以管理任何需要釋放的資源，例如，關閉文件，或者刪除文件等。”從這點來說，本篇文章確切地說，應該是資源管理，而不只是內存管理。

1 typedef void (*ngx_pool_cleanup_pt)(void *data); 2 typedef struct ngx_pool_cleanup_s ngx_pool_cleanup_t; 3 struct ngx_pool_cleanup_s { 4 ngx_pool_cleanup_pt handler; // 函數指針 5 void *data; // 實際數據 6 ngx_pool_cleanup_t *next; 7 };

（6）ngx_log_t：當內存池數據操作出現錯誤（一般是申請失敗）時打印日志。

1 typedef struct ngx_log_s ngx_log_t; 2 struct ngx_log_s { 3 ngx_uint_t log_level; 4 ngx_open_file_t *file; 5 ngx_atomic_uint_t connection; 6 ngx_log_handler_pt handler; 7 void *data; 8 /* 9 * we declare "action" as "char *" because the actions are usually 10 * the static strings and in the "u_char *" case we have to override 11 * their types all the time 12 */ 13 char *action; 14 };

2.2 內存池主要基本操作

（1）創建內存池：ngx_pool_t *ngx_create_pool(size_t size, ngx_log_t *log);分配一個內存頁，并初始化相應字段。?

ngx_pool_t * ngx_create_pool(size_t size, ngx_log_t *log) {ngx_pool_t *p;p = ngx_memalign(NGX_POOL_ALIGNMENT, size, log);if (p == NULL) {return NULL;}p->d.last = (u_char *) p + sizeof(ngx_pool_t);p->d.end = (u_char *) p + size;p->d.next = NULL;p->d.failed = 0;size = size - sizeof(ngx_pool_t);p->max = (size < NGX_MAX_ALLOC_FROM_POOL) ? size : NGX_MAX_ALLOC_FROM_POOL;p->current = p;p->chain = NULL;p->large = NULL;p->cleanup = NULL;p->log = log;return p; }

?（2）分配內存：void * ngx_palloc(ngx_pool_t *pool, size_t size);?根據size大小決定具體行為：a.在當前內存頁分配 b. 在新內存也分配 c. 向系統申請大塊內存

1 // ngx_palloc和ngx_pnalloc都是從內存池里分配size大小內存，至于分得的是小塊內存還是大塊內存，將取決于size的大小； 2 // 他們的不同之處在于，palloc取得的內存是對齊的，pnalloc則否。 3 void * 4 ngx_palloc(ngx_pool_t *pool, size_t size) 5 { 6 u_char *m; 7 ngx_pool_t *p; 8 9 if (size <= pool->max) { 10 p = pool->current; 11 do { 12 m = ngx_align_ptr(p->d.last, NGX_ALIGNMENT); 13 if ((size_t) (p->d.end - m) >= size) { 14 p->d.last = m + size; 15 return m; 16 } 17 p = p->d.next; 18 } while (p); 19 //如果遍歷完整個內存池鏈表均未找到合適大小的內存塊供分配，則執行ngx_palloc_block()來分配。 20 //ngx_palloc_block()函數為該內存池再分配一個block，該block的大小為鏈表中前面每一個block大小的值。 21 //一個內存池是由多個block鏈接起來的。分配成功后，將該block鏈入該poll鏈的最后， 22 //同時，為所要分配的size大小的內存進行分配，并返回分配內存的起始地址。 23 return ngx_palloc_block(pool, size); 24 } 25 return ngx_palloc_large(pool, size); 26 }

（3）銷毀內存池：void ngx_destroy_pool(ngx_pool_t *pool); 分三步走：一，執行cleanup清理；二，釋放大塊內存；三，釋放小塊內存（內存頁）。

1 #define ngx_free free 2 void 3 ngx_destroy_pool(ngx_pool_t *pool) 4 { 5 ngx_pool_t *p, *n; 6 ngx_pool_large_t *l; 7 ngx_pool_cleanup_t *c; 8 9 printf("ngx_destroy_pool::ngx_destroy_pool:%p\n", ngx_destroy_pool); 10 get_systime(buf, 100); 11 // printf("ngx_destroy_pool:%s\n",buf); 12 13 // 執行資源（比如文件關閉，刪除等）清理函數 14 for (c = pool->cleanup; c; c = c->next) { 15 if (c->handler) { 16 ngx_log_debug1(NGX_LOG_DEBUG_ALLOC, pool->log, 0, 17 "run cleanup: %p", c); 18 c->handler(c->data); 19 } 20 } 21 // 釋放大塊內存 22 for (l = pool->large; l; l = l->next) { 23 24 ngx_log_debug1(NGX_LOG_DEBUG_ALLOC, pool->log, 0, "free: %p", l->alloc); 25 26 if (l->alloc) { 27 ngx_free(l->alloc); 28 } 29 } 30 31 // 釋放小塊內存，一個pagesize 32 for (p = pool, n = pool->d.next; /* void */; p = n, n = n->d.next) { 33 ngx_free(p); 34 35 if (n == NULL) { 36 break; 37 } 38 } 39 }

（4）其他：src/core/ngx_palloc.c其他函數說明

1）void ngx_reset_pool(ngx_pool_t *pool);

// 該函數釋放pool中所有大塊內存鏈表上的內存，小塊內存鏈上的內存塊都修改為可用。但不會去處理cleanup鏈表上的項目。 // 這說明重置pool只是要利用小塊內存資源

?2）void * ngx_pnalloc(ngx_pool_t *pool, size_t size);

// ngx_palloc和ngx_pnalloc都是從內存池里分配size大小內存，至于分得的是小塊內存還是大塊內存，將取決于size的大小； // 他們的不同之處在于，palloc取得的內存是對齊的，pnalloc則否。

?3）static void * ngx_palloc_block(ngx_pool_t *pool, size_t size);

// ngx_palloc_block()函數為該內存池再分配一個block，該block的大小為鏈表中前面每一個block大小的值。 // 一個內存池是由多個block鏈接起來的。分配成功后，將該block鏈入該poll鏈的最后， // 同時，為所要分配的size大小的內存進行分配，并返回分配內存的起始地址。

?4）static void * ngx_palloc_large(ngx_pool_t *pool, size_t size);

// 執行ngx_palloc和ngx_pnalloc時，若size>max，則會調用ngx_palloc_large // 新的大塊內存將會被掛接到pool->large上，即加入鏈表頭部

?5）void * ngx_pmemalign(ngx_pool_t *pool, size_t size, size_t alignment);

// ngx_pmemalign將在分配size大小的內存并按alignment對齊，然后掛到large字段下，當做大塊內存處理。 // 內存對齊的好處就是提高了CPU取數據的效率

?6）ngx_int_t ngx_pfree(ngx_pool_t *pool, void *p);?

// 釋放指定大塊內存 // 該函數的實現是順序遍歷large管理的大塊內存鏈表。所以效率比較低下。 // 如果在這個鏈表中找到了這塊內存，則釋放，并返回NGX_OK。否則返回NGX_DECLINED。 // 由于這個操作效率比較低下，除非必要，也就是說這塊內存非常大，確應及時釋放，否則一般不需要調用。

?7）void * ngx_pcalloc(ngx_pool_t *pool, size_t size);

// ngx_pcalloc是直接調用palloc分配好內存，然后進行一次0初始化操作。

?8）ngx_pool_cleanup_t * ngx_pool_cleanup_add(ngx_pool_t *p, size_t size);?

// 這個 size就是要存儲這個data字段所指向的資源的大小。 // 比如我們需要最后刪除一個文件。那我們在調用這個函數的時候，把size指定為存儲文件名的字符串的大小， // 然后調用這個函數給cleanup鏈表中增加一項。該函數會返回新添加的這個節點。我們然后把這個節點中的data字段拷貝為文件名。 // 把hander字段賦值為一個刪除文件的函數（當然該函數的原型要按照void (*ngx_pool_cleanup_pt)(void *data);）。

?9）void ngx_pool_run_cleanup_file(ngx_pool_t *p, ngx_fd_t fd);

// 對內存池進行文件清理操作,即執行handler,此時handler==ngx_pool_cleanup_file

?10）void ngx_pool_cleanup_file(void *data);

// 關閉data指定的文件句柄

?11）void ngx_pool_delete_file(void *data);

// 刪除data指定的文件?

3. nginx內存管理原理

3.1 內存管理初始化

我們知道，在nginx正式進入事件處理流程之前，nginx在主流程中（main函數）會進行一系列的初始化工作，這是為以后的master-worker運行模式準備資源，也為各模塊的運行準備條件。同樣，在創建一個內存池之前，nginx需要知道程序處在什么樣的系統環境中，這些系統變量會影響nginx的內存管理效率。

3.1.1 內存對齊

（1）為什么要內存對齊

? ? ? 內存對齊是操作系統為了快速訪問內存而采取的一種策略。因為處理器讀寫數據，并不是以字節為單位，而是以塊(2,4,8,16字節)為單位進行的，而且由于操作系統的原因，塊的起始地址必須整除塊大小。如果不進行對齊，那么本來只需要一次進行的訪問，可能需要好幾次才能完成，并且還要進行額外的數據分離和合并，導致效率低下。更嚴重地，有的CPU因為不允許訪問unaligned address，就報錯，或者打開調試器或者dump core，比如sun sparc solaris絕對不會容忍你訪問unaligned address，都會以一個core結束你的程序的執行。所以一般編譯器都會在編譯時做相應的優化以保證程序運行時所有數據地址都是在'aligned address'上的，這就是內存對齊的由來。

? ? ? 為了更好理解上面的意思，這里給出一個示例。在32位系統中，假如一個int變量在內存中的地址是0x00ff42c3,因為int是占用4個字節，所以它的尾地址應該是0x00ff42c6，這個時候CPU為了讀取這個int變量的值，就需要先后讀取兩個4字節的塊，分別是0x00ff42c0~0x00ff42c3和0x00ff42c4~0x00ff42c7，然后通過移位等一系列的操作來得到，在這個計算的過程中還有可能引起一些總線數據錯誤的。但是如果編譯器對變量地址進行了對齊，比如放在0x00ff42c0，CPU就只需要一次就可以讀取到，這樣的話就加快讀取效率。

? ? ?綜合，內存對齊的原因有2點：
? ? 1) 平臺原因(移植原因)：不是所有的硬件平臺都能訪問任意地址上的任意數據的；某些硬件平臺只能在某些地址處取某些特定類型的數據，否則拋出硬件異常。
? ? 2) 性能原因：數據結構(尤其是棧)應該盡可能地在自然邊界上對齊。原因在于，為了訪問未對齊的內存，處理器需要至少要兩次內存訪問；而對齊的內存訪問僅需要一次訪問。

（2）在linux上如何內存對齊

內存對齊可以用一句話來概括："數據項只能存儲在地址是數據項大小的整數倍的內存位置上"。

每個特定平臺上的編譯器都有自己的默認“對齊系數”(也叫對齊模數)。程序員可以通過預編譯命令#pragma pack(n)，n=1,2,4,8,16 來改變這一系數，其中的n 就是你要指定的“對齊系數”。
規則1：
數據成員對齊規則：結構(struct)(或聯合(union))的數據成員，第一個數據成員放在offset為0 的地方，以后每個數據成員的對齊按照#pragma pack 指定的數值和這個數據成員自身長度中，比較小的那個進行。
規則2：
結構(或聯合)的整體對齊規則：在數據成員完成各自對齊之后，結構(或聯合)本身也要進行對齊，對齊將按照#pragma pack指定的數值和結構(或聯合)最大數據成員長度中，比較小的那個進行。
規則3：
結合1、2 顆推斷：當#pragma pack 的n值等于或超過所有數據成員長度的時候，這個n值的大小將不產生任何效果。

在這就不展開討論內存對齊的細節了。

（3）nginx為內存對齊做了哪些

#define NGX_POOL_ALIGNMENT 16#ifndef NGX_ALIGNMENT #define NGX_ALIGNMENT sizeof(unsigned long) /* platform word */ #endif // 兩個參數d和a，d代表未對齊內存地址，a代表對齊單位，必須為2的冪。假設a是8，那么用二進制表示就是1000，a-1就是0111. // d + a-1之后在第四位可能進位一次（如果d的前三位不為000，則會進位。反之，則不會）， // ~（a-1)是1111...1000，&之后的結過就自然在4位上對齊了。注意二進制中第四位的單位是8，也就是以8為單位對齊。 // 例如，d=17,a=8,則結果為24.所以該表達式的結果就是對齊了的內存地址 #define ngx_align(d, a) (((d) + (a - 1)) & ~(a - 1)) // 對指針地址進行內存對齊，原理同上 #define ngx_align_ptr(p, a) \(u_char *) (((uintptr_t) (p) + ((uintptr_t) a - 1)) & ~((uintptr_t) a - 1))

3.1.2 內存分頁

本小節主要解釋創建內存池函數中的語句：p->max = (size < NGX_MAX_ALLOC_FROM_POOL) ? size : NGX_MAX_ALLOC_FROM_POOL;該語句限制了內存池可用內存的最大值。也就是說當創建內存池的size>NGX_MAX_ALLOC_FROM_POOL時會造成內存浪費。但nginx為什么會這么做呢？

（1）為什么要內存分頁

? ? ?在存儲器管理中，連續分配方式會形成許多“碎片”，雖然可通過“緊湊”方法將許多碎片拼接成可用的大塊空間，但須為之付出很大開銷。如果允許將一個進程直接分散地裝入到許多不相鄰的分區中，則無須再進行“緊湊”。基于這一思想而產生了離散分配方式。如果離散分配的基本單位是頁，則稱為分頁存儲管理方式。
? ? ?分頁管理器把地址空間劃分成4K大小的頁面（非Intel X86體系與之不同），當進程訪問某個頁面時，操作系統首先在Cache中查找頁面，如果該頁面不在內存中，則產生一個缺頁中斷（Page Fault），進程就會被阻塞，直至要訪問的頁面從外存調入內存中。
? ? ?綜上，內存分頁管理使得進程的地址空間可以為整個物理內存地址空間（如4G）,一個頁面經過映射后在實際物理空間中是連續存儲的。根據程序局部性原理，如果程序的指令在一段時間內訪問的內存都在同一頁面內，則會提高cache命中率，也就提高了訪存的效率。

（2）nginx內存分頁好處

從上可以看出，內存分頁管理使得程序向系統申請一個頁面的內存時，該頁內存地址在物理內存地址空間中是連續分布的，這提高了cache命中率。如果申請的內存大于一個內存頁，則會降低程序指令訪存cache命中率。所以，在nginx內存池小塊內存管理單元中，其有效內存的最大值為一個頁面大小。

3.2 內存池的創建

經過測試，nginx在為每個http連接（connection）創建size為256的pool，為每個請求（request）創建size為4096的pool。當客戶端使用長連接向服務器請求資源時，nginx完成request后會釋放request對應的pool，而不立即釋放connection對應的pool，等超時后再釋放。在一次簡單的會話中（請求首頁），連接建立到關閉期間，至少有30次的內存分配（調用ngx_palloc）。

3.3 內存池的分配

從第二節的函數介紹可以看到，nginx內存分配有種形式，小塊內存分配包括用戶數據、維護內存池鏈表數據結構數據等，大塊數據包括大的資源文件等。

3.3.1 小塊內存分配（size<=max）

圖3.1 nginx小塊內存池分配圖

? ? ?上圖這個內存池模型是由上3個小內存池構成的，由于第一個內存池上剩余的內存不夠分配了，于是就創建了第二個新的內存池，第三個內存池是由于前面兩個內存池的剩余部分都不夠分配，所以創建了第三個內存池來滿足用戶的需求。

? ? ?failed表示的是當前這個內存池的剩余可用內存不能滿足用戶分配請求的次數，即是說：一個分配請求到來后，在這個內存池上分配不到想要的內存，那么就failed就會增加1；這個分配請求將會遞交給下一個內存池去處理，如果下一個內存池也不能滿足，那么它的failed也會加1，然后將請求繼續往下傳遞，直到滿足請求為止（如果沒有現成的內存池來滿足，會再創建一個新的內存池）。
? ? ?current字段會隨著failed的增加而發生改變，如果current指向的內存池的failed達到了4的話，current就指向下一個內存池了。猜測：4這個值應該是Nginx作者的經驗值，或者是一個統計值。

3.3.2 大塊內存分配（size>max）

? ? ?大塊內存的分配請求不會直接在內存池上分配內存來滿足，而是直接向操作系統申請這么一塊內存（就像直接使用malloc分配內存一樣），然后將這塊內存掛到內存池頭部的large字段下。內存池的作用在于解決小塊內存池的頻繁申請問題，對于這種大塊內存，是可以忍受直接申請的。為什么大塊內存分配后是掛在鏈表頭部而不是尾部呢？根據程序局部性原理，最近分配的內存一般經常使用，掛在頭部可以提高查找效率。
? ? ?圖3.2展示了大塊內存分配情況：

圖3.2 nginx大塊內存池分配圖

? ? ?注意每塊大內存都對應有一個頭部結構（next&alloc），這個頭部結構是用來將所有大內存串成一個鏈表用的。這個頭部結構不是直接向操作系統申請的，而是當做小塊內存（頭部結構沒幾個字節）直接在內存池里申請的。這樣的大塊內存在使用完后，可能需要第一時間釋放，節省內存空間，因此nginx提供了接口函數：
? ? ?ngx_int_t ngx_pfree(ngx_pool_t *pool, void *p)；
? ? ?此函數專門用來釋放某個內存池上的某個大塊內存，p就是大內存的地址。ngx_pfree只會釋放大內存，不會釋放其對應的頭部結構，畢竟頭部結構是當做小內存在內存池里申請的；遺留下來的頭部結構會作下一次申請大內存之用。

3.3.3 資源內存分配

? ? ?nginx內存池中除了存放物理內存資源，還存放著其他資源，比如文件、緩存等。每個進程能打開的文件句柄是有限的，所以分配了文件資源后需要及時釋放。nginx定義了chain和cleanup字段來支持靈活的自主資源分配，這樣當連接關閉時，通過銷毀內存池就可以一次性回收這次連接占用的系統資源。
? ? ?圖3.3展示了自定義資源分配情況：

圖3.3 nginx自定義資源分配圖

? ? ?可以看到所有掛載在內存池上的資源將形成一個循環鏈表。
? ? ?由圖可知，每個需要清理的資源都對應有一個頭部結構，這個結構中有一個關鍵的字段handler，handler是一個函數指針，在掛載一個自定義資源到內存池上的時候，同時也會注冊一個清理資源的函數到這個handler上。即是說，內存池在清理cleanup的時候，就是調用這個handler來清理對應的資源。
? ? ?比如：我們可以將一個開打的文件描述符作為資源掛載到內存池上，同時提供一個關閉文件描述的函數注冊到handler上，那么內存池在釋放的時候，就會調用我們提供的關閉文件函數來處理文件描述符資源了。

3.4 內存池的銷毀

? ? ?一個web server總是不停的接受connection和request，所以nginx就將內存池分了不同的等級，有進程級的內存池、connection級的內存池、request級的內存池。也就是說，創建好一個worker進程的時候，同時為這個worker進程創建一個內存池，待有新的連接到來后，就在worker進程的內存池上為該連接創建起一個內存池；連接上到來一個request后，又在連接的內存池上為request創建起一個內存池。這樣，在request被處理完后，就會釋放request的整個內存池，連接斷開后，就會釋放連接的內存池；worker進程退出后就會釋放worker級的內存池。因而，就保證了內存有分配也有釋放。
? ? ?通過內存的分配和釋放可以看出，nginx內存池的主要作用將小塊內存的申請聚集到一起申請，然后一起釋放。避免了頻繁申請小內存，降低內存碎片的產生等問題。

4. 一個簡單的內存模型

學以致用，對源碼的學習不能只停留在閱讀上，而應該去實踐。如果能夠對目前的工作有所幫助那就更好了。為此，本人從nginx源碼中提取內存管理模塊代碼，供以后的工作借鑒，參考。

5. 小結

先回答摘要中的問題

（1）nginx為什么要進行內存管理？

1）nginx作為高性能web服務器，在各個環節都必須考慮如何提高性能的問題。

2）《編程珠璣》中文第2版第9章-“代碼調優”中講了一個典型的故事，主要講Chris Van Wyk花了幾個小時把一個3000行的圖形程序的運行時間減少了一半，而其中的主要優化就是減少不必要的malloc。這說明malloc操作是很耗時的。

3）使用系統的malloc和free面臨幾個問題：web服務器對內存的需求有大有小，系統運行久了會產生大量的內存碎片，最終造成內存操作更加耗時直到無可用內存，導致服務器宕機。

（2）nginx如何進行內存管理？

nginx首先將內存池分級：進程級、連接級、請求級；然后按照內存使用情況的不同分類：小塊內存、大塊內存、自定義資源內存。

進程級內存池通過fork完成創建（fork()創建子進程時，子進程復制了父進程的數據段和堆棧段）；根據web server的特點，客戶端建立連接時創建連接級內存池(在void ngx_event_accept(ngx_event_t *ev);函數中調用)，客戶端請求資源時創建請求級內存池（在 void??ngx_http_init_connection(ngx_connection_t *c)函數中調用）。

進程在處理http請求過程中需要的內存均在該連接對應的內存池中分配，根據需要的內存大小和資源種類進行不同的分配操作。（）

進程在處理完http請求后釋放請求級內存池；當連接超時或斷開時，釋放連接級內存；當進程退出時，銷毀該進程占用的所有內存池資源。

（3）nginx的內存管理解決了哪些問題？

1）簡化了內存操作：程序員不必擔心何時釋放內存，當連接釋放時，就回收該連接對應的內存池。

2）避免了內存碎片：從外部內存碎片來看，采用一次性申請一個內存頁，避免了外部內存碎片；從內部內存碎片來看，對大小內存申請分別管理，提高了內存利用率，避免了內部內存碎片。

3）避免了內存泄露：在同一內存池上進行內存申請和回收，當連接關閉后，不存在沒有回收的內存。

4）提高了內存訪問效率：充分利用程序局部性原理，結合內存對齊和內存分頁機制，有效提高了CPU訪存的cache命中率。

6. 參考資料

網絡博客及nginx-1.4.0源碼。

1. 內存對齊：關于內存對齊問題的一些資料整理? ?內存對齊

2. 內存分頁：基本分頁存儲管理方式??分頁內存和非分頁內存區別

3. nginx內存分配：Nginx源碼剖析之內存池，與內存管理

4. nginx-1.4.0源碼：

?

轉載于:https://www.cnblogs.com/didiaoxiong/p/nginx_memory.html

總結

以上是生活随笔為你收集整理的结合源码看nginx-1.4.0之nginx内存管理详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。