最可靠方式是读取/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size，x86-64通常为64字节，arm64可能为64或128；lscpu中cache line sizes的min值才是对齐依据；结构体须整体按缓存行对齐（如alignas(64)），而非单字段。
直接查 /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
Linux 内核从 2.6.32 起，把每个 cache level 的缓存行大小（即 coherency line size）暴露在 sysfs 中。这是最可靠、无需 root 权限、不依赖外部工具的方式。
实际执行命令：
cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
多数 x86-64 系统返回 64（单位是字节），ARM64 可能是 64 或 128，取决于具体微架构。
- 用
cpu0即可，多核系统中所有逻辑 CPU 的 L1 数据缓存行大小一致 -
index0指 L1 data cache；index1是 L1 instruction cache（通常相同）；L2/L3 行大小一般也相同，但严格来说应查对应 index - 如果路径不存在（如某些嵌入式或老内核），说明该接口未启用，需换方法
用 lscpu 查看并交叉验证
lscpu 输出中的 Cache line sizes: 行给出的是“min / max”，实际运行时对齐应以最小值为准——因为硬件一致性协议按最小行粒度操作。
执行：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
lscpu | grep "Cache line"
典型输出：Cache line sizes: linesize is 64 bytes 或 Cache line sizes: min: 64 bytes, max: 64 bytes。
- 注意：有些 ARM 平台（如某些 Cavium/ThunderX）会显示
min: 64, max: 128，这时必须按64对齐，否则仍可能触发 false sharing -
lscpu读取的是内核缓存的拓扑信息，比实时 sysfs 略滞后，建议优先信/sys/...路径 - 若
lscpu不可用（如容器里没安装 util-linux），别硬依赖它
代码中做缓存行对齐：用 alignas 或 __attribute__((aligned))
结构体或全局变量若被多个线程高频读写，必须避免跨缓存行布局——否则引发 false sharing，性能掉 2–5 倍很常见。
例如，一个计数器结构：
struct alignas(64) counter_t {
uint64_t hits;
uint64_t misses;
};
或者 GCC/Clang 风格：
struct counter_t {
uint64_t hits;
uint64_t misses;
} __attribute__((aligned(64)));
- 对齐值必须是 2 的幂，且 ≥ 实际缓存行大小；填
64最安全（即使实际是 128，也兼容） - 不要只对单个字段对齐（如
uint64_t hits __attribute__((aligned(64)))），这无效——false sharing 发生在整个缓存行被多核争抢时 - 动态分配时用
aligned_alloc(64, sizeof(counter_t))，注意 glibc ≥ 2.16；旧版本用posix_memalign
容易被忽略的陷阱：伪共享常发生在 padding 不足或编译器重排
即使你写了 alignas(64)，如果结构体本身太小（比如只有两个 int），编译器可能把多个实例紧凑排布在同一个缓存行里——这正是 false sharing 的根源。
- 检查实际内存布局：用
offsetof或打印地址，确认相邻对象地址差 ≥ 64 - 结构体内字段顺序影响填充：把频繁修改的字段放一起，冷字段放后面，减少因 padding 导致的浪费
- 某些编译器（如 ICC）默认启用结构体重排（
-frecord-gcc-switches不影响），加-fno-ipa-icf或显式packed要谨慎——可能破坏对齐 - NUMA 节点间缓存同步开销更大，此时缓存行对齐 + 绑核（
pthread_setaffinity_np）才真正起效
perf stat -e cache-misses,cache-references）验证是否降低了缓存冲突。对齐不是银弹——如果访问模式本身是随机的，对齐也救不了性能。
