volatile仅解决可见性，不保证原子性或互斥；只能用于字段，支持bool/int/引用等类型，禁用long/double/DateTime/decimal；适用单写多读哨兵场景，多数情况应优先用Interlocked或lock。
volatile 关键字在 C# 中不能替代线程同步，它只解决可见性问题，不保证原子性、不提供互斥、也不构成完整的 happens-before 关系。绝大多数多线程场景下，你应该优先用 Interlocked、lock 或 Monitor，而不是 volatile。
哪些类型能标 volatile？哪些不能？
只能用于类或结构的字段（field），不能用于局部变量、参数、返回值或属性。支持的类型包括：
-
bool、int、uint、short、byte、char、float等基础值类型（但long和double不行——因为它们在 32 位平台上的读写不是原子的） - 所有引用类型（
string、object、自定义类等） - 指针类型（仅限
unsafe上下文，如int*），但注意：volatile int*表示“指针本身是易失的”，不是“指针指向的内容是易失的” - 基于
int、byte等的enum类型 -
IntPtr、UIntPtr、已知为引用类型的泛型参数（如T where T : class）
常见错误：给 long 字段加 volatile ——编译器会允许，但行为不可靠；给 DateTime 或 decimal 加 volatile ——直接编译失败。
volatile 能做什么？不能做什么？
它只做两件事：禁止编译器/运行时对该字段的读写进行重排序，并插入轻量级内存屏障（acquire-release 语义）。这意味着：
- ✅ 线程 A 写入
volatile bool _isReady = true;后，线程 B 读到true时，能保证看到 A 在此之前对其他非 volatile 字段的写入（部分有序性） - ❌ 它不阻止两个线程同时执行
_counter++（这不是原子操作，即使_counter是volatile int） - ❌ 它不防止指令重排影响其他变量的逻辑顺序（例如：先写
volatile标志再初始化对象，仍可能被重排成先赋值标志后构造对象） - ❌ 在 .NET 6+ 的跨处理器系统中，它不保证“立即全局可见”——只是比普通字段更及时，但不是强一致性
典型误用：用 volatile bool _shouldStop 控制循环，却在循环体内访问未加保护的共享集合——_shouldStop 可见，但集合操作仍可能引发 InvalidOperationException。
什么时候真该用 volatile？
极少数低延迟、无锁且逻辑极其简单的协作场景，比如：
- 单写多读的哨兵标志（如启动/停止信号），且写入后不依赖其他复杂状态
- 与硬件或底层驱动交互时，映射寄存器地址的字段（需配合
unsafe） - 实现简单自旋等待（spin-wait）逻辑，且确认没有更高级同步原语可用
示例：
public class Worker
{
private volatile bool _isRunning;
<pre class="brush:php;toolbar:false;">public void Start() => _isRunning = true;
public void Stop() => _isRunning = false;
public void DoWork()
{
while (_isRunning) // 每次读都从内存取最新值
{
// 注意：这里不能修改共享资源，除非另有同步
Thread.Sleep(10);
}
}}
但若 DoWork 中要更新一个计数器，就得换成 Interlocked.Increment(ref _count)，而不是 _count++。
为什么官方文档总说“优先用 Interlocked 或 lock”？
因为 volatile 的语义太弱，容易让人误以为“加了就线程安全”。而现实是：
-
Interlocked.CompareExchange提供原子读-改-写，且带 full memory barrier，比volatile更强也更明确 -
lock自动包含进入/退出的内存屏障，并天然防止重入和竞态，可保护任意代码块 - .NET 运行时对
Interlocked有深度优化（如 x86/x64 上常编译为单条lock xadd指令），性能未必比volatile差
真正棘手的地方在于：volatile 看似简单，却要求你精确理解内存模型、重排序边界、以及 CPU cache coherency 协议——而这些细节在不同 .NET 版本、不同 CPU 架构上表现不一。大多数业务代码根本不需要碰这个层级。
