伪共享是CPU缓存行冲突导致的性能问题，C#程序因JIT生成机器码访问相邻内存而触发；需通过结构体填充、显式布局或硬件查询确保变量间隔≥64字节以避免。
伪共享（False Sharing）在 C# 中不是语言特性，而是 CPU 缓存层面对多线程程序造成的隐形性能杀手——多个线程修改逻辑上无关、但物理上落在同一缓存行（Cache Line）的变量时，会因 MESI 协议频繁使其他核心缓存失效，导致严重性能下降。
为什么 C# 程序也会遇到伪共享？
C# 运行在 .NET Runtime 上，最终生成的是托管代码 + JIT 编译后的本地机器码。只要这些机器码访问内存的方式让两个 int、long 或对象字段被 CPU 加载到同一个 64 字节缓存行中，且被不同核心上的线程高频写入，伪共享就发生了。
- 常见于：计数器数组（如
long[] counters）、并发状态标志组、自定义高性能队列/环形缓冲区（类似 Disruptor 风格） - 典型症状：多线程吞吐量不随核数线性增长，甚至 2 核比 1 核还慢；perf 或 VTune 显示高比例的
L2_RQSTS.RETRY或MEM_LOAD_RETIRED.L1_MISS - 关键点：C# 没有
alignas，也没有标准库直接暴露缓存行大小，但可通过[StructLayout]+ 填充 +FieldOffset或System.Runtime.Intrinsics辅助控制布局
C# 中避免伪共享的三种实操方式
核心思路只有一个：确保每个会被不同线程独占写入的变量（或结构体字段），彼此间隔 ≥ 64 字节（主流 x86-64 缓存行大小）。
-
手动填充结构体（最常用、最可控）：
用[StructLayout(LayoutKind.Sequential, Pack = 1)]禁用默认对齐优化，再用byte数组填充至 64 字节：
[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct PaddedCounter
{
public long Value;
private byte _padding0; // 1
private byte _padding1; // 2
// ... 填满到 64 字节（Value 占 8 → 还需 56 字节）
private byte _padding55; // 56
}⚠️ 注意：Pack = 1 是必须的，否则编译器可能按自然对齐（如 8 字节）重排，使填充失效；JIT 一般不会优化掉带名字的私有字段。
-
使用
[StructLayout(LayoutKind.Explicit)]+[FieldOffset]精确控制位置：
适合需要严格首地址对齐的场景（如与 native 内存交互）：
[StructLayout(LayoutKind.Explicit)]
public struct AlignedCounter
{
[FieldOffset(0)] public long Value;
[FieldOffset(64)] private byte _guard; // 强制下一个实例从 64 字节后开始
}-
借助
System.Runtime.Intrinsics.X86获取硬件信息（C# 9+）：
虽然不能直接控制对齐，但可用CacheLineSize辅助判断目标平台（注意：该值是运行时查询，非编译时常量）：
if (X86Base.IsSupported)
Console.WriteLine($"Cache line size: {X86Base.CacheLineSize}"); // 通常是 64? 实际项目中建议硬编码为 64，除非你明确支持 ARM64（某些芯片是 128），且已做跨平台验证。
数组和集合场景下的坑与绕过技巧
伪共享最常发生在 long[] counters 这类“看似独立、实则紧挨”的数组中——线程 0 写 counters[0]，线程 1 写 counters[1]，但它们大概率落在同一缓存行。
- ❌ 错误做法：只给结构体加填充，但数组本身未对齐（
new PaddedCounter[4]中相邻元素仍可能跨缓存行边界） - ✅ 正确做法：确保数组起始地址也对齐到 64 字节，并保证每个元素大小 ≥ 64 —— 即使用上面定义的
PaddedCounter类型，再配合Marshal.AllocHGlobal手动分配对齐内存（适用于高性能固定大小缓冲区） - ✅ 更轻量替代：改用“稀疏索引”——让线程写
counters[i * 16]而非counters[i]，利用步长避开同缓存行（简单但浪费空间，适合原型验证）
⚠️ 特别注意：.NET 的 Span 和 ArrayPool 分配的内存**不保证缓存行对齐**，不能直接用于防伪共享场景。
容易被忽略的细节和兼容性提醒
伪共享问题隐蔽，修复后若没压测对比，很容易以为“已经好了”。以下几点务必检查：
- 填充字段必须参与实际内存布局：不要用
private readonly int _unused = 0;—— JIT 可能完全优化掉；要用命名的、非 readonly、非常量的字段（如上面的_padding0） - 泛型类型（如
PaddedCounter）中填充需谨慎：类型参数可能影响字段偏移，建议避免泛型化填充结构体 - .NET 6+ 的
MemoryMarshal.AsBytes可辅助验证布局是否符合预期（例如读取前 8 字节是否确实是Value） - ARM64 平台缓存行可能是 128 字节，若目标部署环境含 Windows on ARM，请用
X86Base.CacheLineSize动态判断，或统一按 128 填充（更安全但略浪费）
真正难的从来不是加几个 byte 字段，而是意识到“我的线程明明没共享数据，为什么性能崩了？”——一旦怀疑伪共享，优先用 dotnet-trace + PerfView 查看 CPU Cache Miss 指标，再动手填。
