C#内存模型是一套定义线程之间如何通过内存交互的规范，它规定了当一个线程写入某个变量后，这个修改在什么条件下能被其他线程观察到，以及编译器和CPU在多大程度上可以重排指令。很多看似诡异的并发Bug——比如一个线程已经把标志位设为true，另一个线程的死循环却始终读不到这个变化——本质上都是对内存模型的误解造成的。本文将从底层原理到实际代码，系统讲清楚这个问题。
为什么多线程下会出现内存可见性问题
要理解内存可见性问题，先要知道现代计算机的执行模型。CPU的速度远快于内存，为了弥补这个差距，硬件引入了多级缓存：每个核心都有自己的L1、L2缓存，多个核心共享L3缓存。当一个线程修改了某个变量，这个修改很可能只是发生在当前核心的缓存里，并没有立即写回主内存，其他核心自然看不到这个新值。
除了缓存，还有两个因素会加剧问题。第一是编译器和CPU的指令重排：只要不改变单线程语义，编译器和CPU都有权调整指令的执行顺序以提升性能。在单线程视角下无害的重排，在多线程交错执行时可能产生完全不同的结果。第二是编译器的优化策略，比如一个循环里反复读取某个没有被当前线程修改的字段，JIT编译器可能把它优化成只读一次并放到寄存器中。
看一个经典例子：
bool stopped = false;
// 线程A
new Thread(() =>
{
bool local = false;
while (!local)
{
local = stopped; // JIT可能只读一次，缓存在寄存器里
}
}).Start();
// 线程B
stopped = true; // 线程A的循环可能永远不结束
这段代码在某些配置下（尤其开启了优化之后）确实可能永不终止。这不是.NET的Bug，而是程序没有遵守内存模型的规则。内存模型存在的意义，就是明确告诉开发者：哪些行为是有保证的，哪些是未定义的，你需要用什么手段来建立跨线程的可见性保证。
可见性、有序性与原子性是三件不同的事
讨论内存模型时最容易混淆的三个概念是可见性、有序性和原子性。可见性指一个线程的写操作何时对其他线程可见；有序性指程序指令的实际执行顺序是否与你写的顺序一致；原子性指一个操作是否不可分割，执行过程中不会被其他线程观察到中间状态。
先说原子性。对于int、bool、byte这类不超过32位的内置类型，读写操作天然是原子的，不会出现读到半个值的情况。但long和double在32位平台上是64位，读写可能被拆成两条32位指令，理论上存在撕裂的可能。注意原子性不等于可见性：一个int写入是原子的，但其他线程可能依然长时间读到旧值，因为新值还停留在写线程所在核心的缓存中。
再说有序性。内存模型定义了不同强度的事件顺序关系，粗略来说，普通读写可以被重排；volatile读写之间以及带屏障语义的操作之间存在顺序约束。一个经典的重排陷阱是“先设置数据，再设置就绪标志”的发布模式：
int data = 0;
bool ready = false;
// 生产者线程
data = 42; // 第一步：写数据
ready = true; // 第二步：发布标志
// 消费者线程
if (ready) // 看到ready为true
{
Console.WriteLine(data); // 可能读到0！
}
如果没有内存屏障介入，CPU或编译器可能把两个写操作重排，消费者看到了ready等于true，data却还是0。这就是为什么发布数据时必须使用带屏障语义的机制，而不是依赖普通字段的书写顺序。
.NET提供的同步手段：volatile、Interlocked与内存屏障
C#提供了几个层次的原语来建立内存可见性保证。最直接的是volatile关键字。被标记为volatile的字段，读操作具有获取语义，写操作具有释放语义，这意味着volatile读不能与其后的操作重排，volatile写不能与其前的操作重排。同时CLR保证volatile字段不会被缓存到限制可见性的寄存器中。需要强调的是，volatile只解决可见性和一部分有序性问题，不提供原子性保证，volatile int i; i++这样的复合操作依然存在竞态。
第二层是System.Threading.Interlocked类，它提供CompareExchange、Increment、Exchange等方法，底层对应CPU的原子指令（如x86上的lock前缀指令），在保证原子性的同时自带全屏障语义，是计数器、无锁算法的首选：
int count = 0; // 线程安全的自增，等价于原子性的 ++count Interlocked.Increment(ref count); // 无锁更新：仅当当前值等于expected时才写入newValue int original = Interlocked.CompareExchange(ref count, newValue, expected);
第三层是显式内存屏障，通过Thread.MemoryBarrier()插入全屏障，阻止屏障前后的读写操作互相穿越。它最典型的用途是修正前面的发布模式：
// 生产者
data = 42;
Thread.MemoryBarrier(); // 保证data的写入先于ready的写入完成
ready = true;
// 消费者
if (ready)
{
Thread.MemoryBarrier(); // 保证data的读取发生在ready判断之后
Console.WriteLine(data); // 现在能稳定读到42
}
日常开发中还有一个自动携带屏障语义的机制是lock语句。进入监视器有获取语义，退出监视器有释放语义，因此lock块内对外部状态的全部修改在释放锁后对后续获取同一把锁的线程立即可见。这也是大多数业务代码不需要手动关心内存模型的原因：标准同步原语已经顺带解决了可见性问题。
实战：正确实现双重检查锁定单例
内存模型知识最经典的落地场景就是双重检查锁定。先看一个错误写法：
public sealed class Singleton
{
private static Singleton instance;
private Singleton() { }
public static Singleton GetInstance()
{
if (instance == null) // 第一次检查，无屏障
{
lock (typeof(Singleton))
{
if (instance == null) // 第二次检查
{
instance = new Singleton(); // 危险！
}
}
}
return instance;
}
}
问题出在instance = new Singleton()这行。它并非原子操作，大致分为分配内存、执行构造函数、把引用赋给字段三步。在没有额外屏障的情况下，这三步可能被重排为“分配、赋值、构造”。此时另一个线程在第一次检查处看到一个非null的instance就直接返回，拿到的却是一个尚未构造完成的对象，访问其字段可能得到错误数据。
修复方式很简单，把字段声明为volatile：
public sealed class Singleton
{
private static volatile Singleton instance; // volatile提供释放语义
private Singleton() { }
public static Singleton GetInstance()
{
if (instance == null)
{
lock (typeof(Singleton))
{
if (instance == null)
{
instance = new Singleton(); // volatile写保证构造完成先于发布
}
}
}
return instance;
}
}
当然，如果不需要延迟初始化，直接用静态字段初始化或者Lazy<T>会更省心，它们由运行时保证线程安全，代码也更清晰。选择建议是：能用高层的lock、Lazy、ConcurrentDictionary解决问题就不要碰volatile和MemoryBarrier，只有在对性能极度敏感的热路径上，才值得用底层原语换取开销的降低，并且要配上详细的注释说明同步逻辑。
总结与实践建议
C#内存模型回答的核心问题是：一个线程的写入，在什么条件下对另一个线程可见。普通字段读写没有任何跨线程时效保证，编译器缓存、CPU缓存和指令重排都可能导致旧值被长期读取。开发者需要掌握的工具按层次划分：volatile解决可见性与发布顺序，Interlocked提供原子复合操作，Thread.MemoryBarrier允许精确控制屏障位置，而lock及更高层的同步结构在完成互斥的同时自动附带完整的内存语义。
实践中有几条经验值得遵守。第一，不要因为“看起来能跑”就依赖普通字段的跨线程读写，这类问题在调试模式下往往不复现，上线后才爆雷。第二，尽量把共享状态的修改收敛到同步块或不可变数据结构中，从设计上消灭竞态而不是修补它。第三，确实需要无锁编程时，优先使用Interlocked和框架提供的并发集合，手写volatile逻辑前务必确认你理解获取和释放语义的方向。把这些规则内化之后，内存模型就不再是黑盒，而是你排查并发问题、评估代码正确性的有力工具。