CPU Cache Line对齐可减少内存访问延迟，避免单次访问跨两行导致额外加载；Nginx中通过NGX_CACHE_LINE_SIZE宏、内存池对齐及结构体强制对齐实现，并需配合CPU亲和性以最大化效果。
利用 CPU Cache Line 对齐能显著减少内存访问延迟，尤其在 Nginx 这类高频处理小数据块（如请求头、连接结构体、哈希表项）的场景中。关键不是“对齐就快”，而是避免单次内存访问跨两个 Cache Line——这会强制 CPU 多取一次缓存行，带来额外延迟和带宽浪费。
理解 Cache Line 对齐的实际影响
现代 x64 CPU 的典型 L1/L2 Cache Line 大小为 64 字节（即 0x40）。若一个结构体起始地址是 0x1005，而它占 32 字节，则它横跨 0x1000–0x103F 和 0x1040–0x107F 两行；哪怕只读其中 4 字节，CPU 也可能需加载两行。Nginx 内部大量使用 ngx_pool_t、ngx_connection_t、ngx_http_request_t 等结构，其字段排布与首地址对齐方式直接影响 cache 行命中率。
Windows x64 下尤其敏感：未对齐访问可能触发硬件异常（0xC0000005），或由内核模拟处理，开销远高于 Linux。
启用并验证 NGX_CACHE_LINE_SIZE 对齐
Nginx 源码中已内置对齐机制，核心是宏 NGX_CACHE_LINE_SIZE（默认通常为 64）。编译时可通过 configure 参数显式指定：
- ./configure --with-cc-opt="-DNGX_CACHE_LINE_SIZE=64"
- 确保 ngx_cacheline_size 在运行时被正确初始化（如通过 ngx_pagesize_init() 或手动赋值）
- 检查关键结构是否按此对齐：例如 ngx_crc32_table16 初始化前会做判断：
if (((uintptr_t) p & ~(ngx_cacheline_size - 1)) == (uintptr_t) p)—— 成立即说明已对齐
对齐内存池分配与指针操作
Nginx 内存池（ngx_pool_t）返回的内存块默认调用 ngx_align_ptr() 做自然对齐，但若需 Cache Line 对齐，应主动使用：
- 分配缓冲区时：
m = ngx_align_ptr(p->d.last, ngx_cacheline_size); - 自定义结构体声明时，在结构体前插入填充字段或用编译器属性（如
__attribute__((aligned(64)))）强制对齐 - 对数组/表（如 hash bucket、connection pool）按 ngx_cacheline_size 分配整块内存，再切分，避免相邻元素跨行
例如，连接池中每个 ngx_connection_t 若大小为 128 字节，且起始地址是 64 字节对齐的，那么每两个连接刚好填满一个 Cache Line，读取连接状态时可批量命中。
配合 CPU 亲和性发挥最大效果
Cache Line 对齐的价值在多核环境下需与 CPU 亲和性协同才能释放：
- 开启 worker_cpu_affinity auto;，让每个 worker 固定在单一核心运行，复用该核的 L1/L2 缓存
- 避免不同 worker 同时写同一 cache line（false sharing）：将频繁更新的字段（如计数器）单独对齐到独立 cache line，或使用 padding 隔离
- 结合 worker_processes auto; 和 worker_rlimit_nofile，保证每个 worker 有足够资源独占缓存局部性
此时，对齐后的内存 + 绑核后的执行流，使热点数据长期驻留于低延迟缓存中，memcpy、crc32、header 解析等操作延时明显下降。
