结构体成员顺序直接影响缓存行利用率，将大对齐成员（如double）放前面、小成员（如char）集中放后面，可减少填充和跨缓存行访问；随意混排易导致伪共享，性能下降超30%。
结构体成员顺序直接影响缓存行利用率
把大对齐成员（double、long long、__m128）放前面，小成员（char、bool、int16_t）集中放后面，能显著减少跨缓存行填充。比如 struct { char a; double b; char c; } 实际占 24 字节，而改成 struct { double b; char a; char c; } 后，sizeof 变成 16 —— 因为 a 和 c 被挤进 b 后面的空隙里，没触发新缓存行。
常见错误现象：结构体里混用 int 和 char 且顺序随意，导致每个实例都跨两个 64 字节缓存行，多线程修改时引发伪共享（False Sharing），性能掉 30% 以上。
- 缓存行大小通常是 64 字节，不是所有平台都一样；可用
std::hardware_destructive_interference_size（C++17）查实际值 - 成员间填充是编译器自动加的，无法绕过，但顺序能控制填充位置和总量
- 用
static_assert(offsetof(S, b) == 8)锁定关键字段偏移，防止重构后意外破坏对齐布局
alignas 不等于 sizeof，但能强制起始地址对齐
alignas(64) 只保证该对象起始地址是 64 的倍数，不改变其内部成员布局，也不直接让 sizeof 变成 64。如果结构体本身只有 12 字节有效数据，加上尾部填充后 sizeof 可能是 64，也可能只是 16（取决于最大成员自然对齐）。
使用场景：需要喂给 SIMD 指令（如 AVX2 的 _mm256_load_ps）或 DMA 引擎的数据块，必须严格满足对齐要求，否则会触发 SIGBUS（ARM/PowerPC）或性能暴跌（x86-64）。
- 对齐值必须是 2 的幂，
alignas(12)直接编译失败 -
new表达式在 C++17+ 中自动调用对齐感知版本，但malloc返回的指针不保证对齐，需用std::aligned_alloc - 栈上变量加
alignas(64)可能导致栈空间浪费，某些嵌入式平台栈空间紧张时要谨慎
避免伪共享的关键是隔离高频写字段
两个线程分别修改同一缓存行里的不同字段（如 struct { int a; int b; }），即使逻辑上无竞争，也会因缓存行在核心间反复失效而卡顿。这不是锁的问题，是硬件层面的带宽争抢。
解决办法不是加锁，而是用填充或对齐把它们隔开：
- 手动插入
char pad[64 - sizeof(int)]把b推到下一个缓存行 - 用
alignas(std::hardware_destructive_interference_size)修饰第二个字段，更跨平台 - 别依赖
#pragma pack(1)—— 它取消填充但不降低对齐要求，反而可能让原本对齐的字段变未对齐，引发硬件异常
运行时分配必须匹配声明时的对齐要求
写了 struct alignas(32) Packet { ... };，不代表 new Packet 一定返回 32 字节对齐地址。C++17 起，new 会转发对齐信息给 operator new(size_t, std::align_val_t)，但前提是标准库实现支持。glibc 2.26+、MSVC 2017+ 支持，老版本或嵌入式 libc 可能不支持。
容易踩的坑：
- 用
malloc分配alignas(32)类型对象 → 地址未对齐 → 行为未定义 - 数组
Packet arr[100]占用内存是100 * sizeof(Packet)，但若sizeof(Packet)不是 32 的倍数，后续元素可能不对齐 - placement new 在预分配内存上构造时，必须确保原始内存地址满足
alignof(Packet)，否则崩溃
真正麻烦的地方在于：对齐问题往往只在特定平台、特定负载下暴露，调试时很难复现，但一旦发生，就是硬崩溃或性能雪崩。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
