伪共享是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 指标，再动手填。