Nginx内存池高局部性源于指针生命周期的严格约束：地址流线性推进、结构体16字节对齐、current指向首个可用池头、small/large内存分离映射、销毁时批量归零指针。
要真正看清 Nginx 内存池在底层的高局部性指针映射全貌，关键不是泛读结构体定义，而是顺着内存生命周期，把指针如何诞生、如何跳转、如何复用、如何失效这一整条“地址流”串起来。Nginx 的局部性不是靠缓存预取实现的，而是靠数据结构紧邻 + 分配路径极短 + 指针只在固定范围内游走这三点硬约束出来的。
指针布局严格对齐，确保 CPU cache line 高命中
Nginx 所有内存池块都按 16 字节对齐（NGX_POOL_ALIGNMENT），且首块内存池的起始地址就是 ngx_pool_t 结构体本身所在位置。这意味着：
-
p（即ngx_pool_t*）直接指向一块连续内存的开头； -
p->d.last紧跟在sizeof(ngx_pool_t)之后，即结构体末尾紧接着就是可用小内存区； -
p->d.end是这块内存的物理边界，与p起始地址差值恒为申请 size； - 所有指针（
last、end、next）都在同一 cache line 或相邻 line 内，一次内存加载即可覆盖核心元数据。
current 指针不指向“当前池”，而指向“下一个可用池头”
很多人误以为 pool->current 指向正在使用的内存池，其实它是一个快速查找入口指针：它始终指向链表中第一个 failed < 4 的池（即尚未被标记为“分配失败过多”的池）。这个设计让小内存分配几乎总能落在最近刚用过的 pool 上：
- 新分配时优先查
current->d.last是否够用，够就直接 bump last，零额外跳转； - 不够则遍历
current->d.next链表，但链表节点本身是连续 malloc 出来的，物理地址接近； - 一旦某个 pool
failed++达到 4 次，current就跳过它——避免反复访问已退化的冷内存区。
small/large 内存分离映射，消除跨页随机访问
Nginx 把内存分两类处理，本质是两种指针寻址模式：
-
Small 分配（≤ max，默认 4095B）：只动
last/end，指针在 pool 内部线性推进，完全不触发新系统调用，地址绝对局部； -
Large 分配（> max）：调
malloc或mmap单独申请，然后把新地址挂到pool->large链表上——这个链表本身很小（通常仅几项），且large结构体（含void *alloc）就嵌在 pool 头部附近，访问开销可控。
这种分离让 hot path（小内存）全程停留在 L1 cache 可覆盖的 pool head + data 区域内，large 则作为稀疏旁路存在，不污染局部性。
销毁时指针批量归零，而非逐字节释放
ngx_destroy_pool 不遍历每个 small 块，而是：
- 从
pool开始，顺着d.next链表依次 free 整个 pool 块； - 遍历
large链表，对每个alloc地址调free； - 最后清空
cleanup链表并执行回调——所有指针操作都是顺序访存，无跳表、无哈希、无树遍历。
这意味着整个生命周期里，绝大多数指针操作都是单向线性递进或单层链表遍历，没有深度嵌套跳转，CPU 分支预测和 prefetcher 都能高效工作。
