伪共享是CPU缓存行争用导致的多线程性能问题：多个线程写不同变量但同属64字节缓存行，触发频繁失效；C#中因struct/class字段紧密布局且无显式对齐语法而易被忽略。
什么是伪共享，以及为什么它在 C# 多线程中容易被忽略
伪共享不是 C# 语言特性，而是 CPU 缓存行（cache line）层面的性能问题：当多个线程频繁写入**不同变量但位于同一缓存行**（通常是 64 字节）时，会导致缓存一致性协议反复使其他 CPU 核心的对应缓存行失效，从而显著拖慢性能。C# 中尤其隐蔽，因为 struct 成员默认紧密排布，class 实例字段也常被 JIT 编译器紧凑布局，且没有显式内存对齐控制语法（不像 C++ 的 alignas）。
C# 中检测伪共享的实用方法
直接观测缓存行争用需要硬件级指标，但可通过组合手段定位可疑热点：
- 使用 Windows Performance Analyzer（WPA）加载 ETW trace，筛选
Microsoft-Windows-Kernel-Memory提供的CacheLineShared和CacheLineInvalidated事件，重点关注高频率、多核间交叉触发的地址段 - 用
dotnet-trace采集Microsoft-DotNETCore-EventPipe+Microsoft-Windows-Kernel-Memory，再用perfview查看CacheMiss和Interlocked操作的调用栈分布 - 人工排查：若发现多个
volatile字段或Interlocked操作（如Interlocked.Increment）集中在同一个struct或class实例中，且各自被不同线程独占更新，就高度可疑
避免伪共享的 C# 实操策略
核心思路是让易争用字段**跨缓存行隔离**，同时兼顾内存开销与可读性：
- 对高频独立更新的字段，在其前后插入
[StructLayout(LayoutKind.Sequential, Pack = 1)]+ 填充字节数组（如private byte padding0[60];），确保字段间隔 ≥ 64 字节；注意Pack = 1是必须的，否则 JIT 可能重排或压缩填充 - 优先用
struct封装单个计数器（如Counter），每个线程持有一个独立实例，避免共享；比在类中塞多个字段更安全 - 避免在共享对象中定义多个
volatile int字段用于不同逻辑路径；改用ConcurrentDictionary或分拆为多个独立对象引用 - JIT 不保证字段顺序与源码一致，所以不要依赖“把字段写远一点”这种做法；必须用
[FieldOffset]或填充强制布局
[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct PaddedCounter
{
public long Value;
private byte _padding0[56]; // 确保下一个字段不在同一 cache line
}
.NET 6+ 的新选项：HardwareIntrinsics 与缓存行提示
.NET 6 引入了 System.Runtime.Intrinsics.X86，但目前**没有提供直接控制缓存行对齐或预取的 C# API**；_mm_clflush 类指令需通过 unsafe + NativeAOT 输出才能生效，且仅适用于极少数需要手动刷缓存的场景（如零拷贝通信），不解决伪共享本身。
真正可用的是 RuntimeHelpers.PrepareConstrainedRegions 配合 try/finally 确保关键区不被 GC 中断——但这只是辅助，不能替代字段隔离。最稳妥的仍是结构体填充和线程本地化设计。
伪共享的修复往往不体现在代码行数上，而在于你是否愿意为一个 int 字段多分配 63 字节，并接受调试时看到大量 byte[60] 字段。这点空间换性能的权衡，很容易被跳过。
