volatile不能替代锁或原子操作，仅解决内存可见性和指令重排序限制；它不保证复合操作原子性，无法建立跨字段happens-before关系，误用会掩盖并发bug。
volatile 在 C# 中不能替代锁或原子操作，它只解决两个具体问题：变量读写的内存可见性、以及相关指令的重排序限制。用错地方不仅没用，还会掩盖真正的并发 bug。
volatile 为什么不能让 while(flag) 退出？
常见现象是：主线程设 flag = false，但工作线程的 while (flag) 死循环不退出。这不是“没生效”，而是编译器可能把 flag 缓存在寄存器里，循环中只读一次——后续修改根本没被检查。
- 加
volatile后，每次循环都强制从主内存读取flag的最新值 - 但它不阻止其他线程在读-判-跳之间修改
flag，也不保证这个读操作和其他操作构成原子序列 - 如果
flag的修改依赖于其他状态（比如对象初始化完成），仅靠volatile无法建立 happens-before 关系
volatile.Write 和 Volatile.Read 比字段修饰更可控
直接修饰字段（private volatile bool _stopRequested;）作用范围大，但有时你只需要对某次写/读施加语义约束，比如配合非 volatile 字段做发布顺序控制。
-
Volatile.Write(ref _y, 1)确保它之前的写（如_x = 1）不会被重排到它之后 -
Volatile.Read(ref _y)确保它之后的读（如return _x）不会被重排到它之前 - 这对实现无锁模式下的“发布-获取”模式很关键，比如单例双重检查锁定中对实例字段的访问
- 注意：
Volatile.Read不等价于Thread.VolatileRead（后者已过时，不应再用）
什么时候绝对不该用 volatile？
只要涉及复合操作，volatile 就失效。它不是同步机制，只是内存访问约束。
-
i++、list.Add(x)、obj.Property = value—— 这些都不是原子操作，volatile修饰字段也拦不住中间被抢占 - 多个 volatile 字段之间的逻辑依赖（如先写
_data再写_ready），不能靠两个volatile保证另一线程按序看到；必须用Volatile.Write+ 内存屏障语义，或直接上Interlocked - .NET Core 3.0+ 中，
volatile对struct字段的行为更严格，某些嵌套结构体可能使volatile失效，建议改用Unsafe.AsRef配合Volatile.Read/Write
真正容易被忽略的是：volatile 的语义边界非常窄——它只管“这个变量怎么读/写”，不管“这个变量和其他变量什么关系”。一旦逻辑跨字段、跨对象、跨生命周期，就得换工具。别让它出现在你代码审查通过的临界区里。
