伪共享是多核cpu缓存一致性导致的性能问题：当两线程修改同一64字节缓存行内不同字段时，引发频繁缓存行无效化与重载；在c#中表现为高并发下计数器吞吐低、concurrentqueue压测缓存未命中飙升等，需通过字段对齐填充（如byte[56]）或隔离分配避免。
什么是伪共享（False Sharing）在C#中的表现
伪共享不是C#语言特性，而是多核CPU缓存一致性协议引发的性能问题：当两个线程分别修改同一缓存行（通常64字节）中不同字段时，由于缓存行是CPU间同步的最小单位，会导致该缓存行在核心间反复无效化与重载，显著拖慢写操作。在C#中，它常出现在高并发场景下——比如多个Thread或Task频繁更新同一个对象的相邻字段，或使用数组/结构体密集存储状态时。
常见错误现象包括：
-
interlocked.Increment或SpinLock保护下的计数器吞吐量远低于预期 -
ConcurrentQueue<t></t>自定义实现中，头尾指针字段紧挨着定义，压测时CPU缓存未命中率飙升 - 使用
Unsafe.AsRef或Span<t></t>直接操作内存块时，字段对齐不当放大竞争
C#中避免伪共享的三种实操手段
核心思路是让可能被不同线程修改的字段不落在同一缓存行内。C#没有内置伪共享检测工具，需主动设计：
- 使用
[StructLayout(LayoutKind.Explicit)]+[FieldOffset]手动控制字段位置，确保敏感字段间隔至少64字节（如：在字段前后各填充32字节byte[32]） - 对于类中字段，用
[MarshalAs(UnmanagedType.ByValArray, SizeConst = 64)]或私有byte[64]数组做填充（注意：.NET 6+ 中System.Runtime.CompilerServices.Unsafe提供了更安全的偏移计算方式） - 避免在
struct中将多个long或int计数器连续声明；改用class封装单个计数器，或每个计数器独立分配（如用new long[1]而非long[] counters = new long[4]）
示例：一个易伪共享的结构体
struct CounterPair { public long A; public long B; }A和B极可能落入同一缓存行；应改为：
struct CounterPair { public long A; private byte pad1[56]; public long B; }.NET运行时与JIT对伪共享的影响
.NET本身不消除伪共享，但某些行为会掩盖或加剧它：
-
ValueTuple和自动布局struct的字段排布由JIT决定，不可控，不适合高频并发写入场景 - .NET 5+ 的
RuntimeHelpers.PrepareConstrainedRegions不影响缓存行对齐，不能用于解决伪共享 -
volatile关键字只保证内存可见性和禁止重排序，不改变字段物理位置，无法缓解伪共享 - 使用
Memory<t></t>或ArrayPool<t>.Shared.Rent</t>分配的数组，若复用同一段内存存放多个线程独占数据，仍需手动对齐首地址（可用Marshal.AllocHGlobal+IntPtr对齐计算）
最易被忽略的是：即使你用了[StructLayout(LayoutKind.Sequential, Pack = 1)]，也不能防止伪共享——Pack只是控制填充密度，不保证跨缓存行边界。
验证伪共享是否真实存在
不能仅凭直觉或“感觉慢”判断。可靠方法只有两种：
- 使用Intel VTune或Perf（linux）采集
L1D.REPLACEMENT、MEM_LOAD_RETIRED.L3_MISS等事件，观察线程间缓存行争用指标 - 在目标字段前后插入
byte[64]填充后，对比相同负载下的吞吐量变化；若提升明显（如+30%以上），大概率是伪共享
注意：dotnet-trace 和 dotnet-counters 无法捕获缓存级行为，它们只能看到GC、JIT、线程调度等更高层指标。
伪共享的修复成本不高，但定位困难；一旦怀疑，优先检查字段布局和内存分配模式，而不是加锁或换并发集合。