volatile 在 C# 里到底管什么？
它只做两件事：确保变量的最新值对所有线程可见，并插入内存屏障防止读写指令被重排序。它不保证原子性，也不提供互斥——换句话说，
volatile不是锁，不能替代
lock、
Interlocked或
Monitor。
什么时候必须用 volatile？
典型场景是轻量级线程间“通知”或“状态广播”，比如控制循环启停、标记初始化完成、开关调试模式等。只要满足两个条件就适合：单次读或写操作本身是原子的（如
bool、
int、引用类型赋值），且不需要复合操作的同步保障（例如
count++就不行）。
_shouldStop = true是安全的 volatile 写入
if (_shouldStop) return;是安全的 volatile 读取
_counter++即使加了
volatile仍是竞态操作，结果不可靠 多个 volatile 字段之间无顺序保证，比如
a = 1; b = 2;不能靠 volatile 确保其他线程先看到
a后看到
b
常见误用和坑
最典型的错误是以为加了
volatile就能避免锁。实际中，一旦涉及“检查后赋值”（check-then-act）、“读-改-写”（read-modify-write）或多字段协同，
volatile就失效了。 ❌
if (!_isInitialized) _isInitialized = true;—— 两个线程可能同时通过
if判断，导致重复初始化 ✅ 正确做法：用
Interlocked.CompareExchange或
Lazy<t></t>❌ 把
volatile加在
double或
long上（在 32 位平台）——它们的读写不是原子的，volatile 无法修复这个问题 ✅ 若需跨平台原子读写，优先用
Interlocked.Read/Write
C# volatile 和 C 的 volatile 本质不同
C 里的
volatile主要是防编译器优化（比如寄存器缓存），而 C# 的
volatile是语言规范强制要求的内存模型语义：它既影响 JIT 编译器，也插入硬件级内存屏障（如
mfence），真正解决多核 CPU 下的可见性和重排问题。这意味着你在 .NET 中用
volatile，不是“提醒编译器别乱动”，而是“告诉运行时：这里必须同步到主内存”。
public class Worker
{
private volatile bool _shouldStop = false;
<pre class='brush:php;toolbar:false;'>public void RequestStop() => _shouldStop = true;
public void DoWork()
{
while (!_shouldStop)
{
// 做工作...
}
}}
去掉
volatile后，在某些 CPU 架构（如 ARM64）或高优化等级下，
DoWork可能永远看不到
_shouldStop的变化——因为 JIT 把读取优化成了常量或缓存副本。
真正难的是判断“这个变量要不要 volatile”。它不是性能优化手段，也不是同步兜底方案；它是为数不多几个必须精确理解内存模型才能用对的关键字之一。
