Interlocked 为什么不能直接操作普通变量
因为
Interlocked的所有方法都要求传入
ref int、
ref long等引用类型参数，它底层依赖 CPU 的原子指令（如 x86 的
XCHG、
LOCK XADD），这些指令必须作用在内存地址上。如果你传一个局部值类型变量（比如
int i = 0;），编译器会报错：「无法将“int”类型的值作为 ref 参数传递」——这不是语法限制，而是语义强制：必须确保操作的是同一块可寻址内存。
常见错误写法：
int value = 42; int result = Interlocked.Add(value, 1); // ❌ 编译失败：期望 ref int
正确做法是始终用
ref传变量地址：
int value = 42; int result = Interlocked.Add(ref value, 1); // ✅
CompareExchange 是唯一能做“CAS”的方法
Interlocked.CompareExchange是 C# 中实现无锁编程的核心，它完成「比较并交换」：仅当当前值等于预期值时，才把新值写入，并返回原始值。它不像
Add或
Increment那样只适用于数值，还能用于引用类型（
object、自定义类等）和泛型版本（.NET 6+）。
典型使用场景：
实现线程安全的单例懒加载（不用lock） 构建无锁栈 / 队列的节点链接逻辑 避免重复初始化共享资源
示例：用 CAS 实现简易计数器初始化
private static int _counter = 0;
private static readonly object _initLock = new();
<p>public static int GetCounter()
{
if (_counter == 0)
{
// 可能多个线程同时进这里，只让一个成功写入
Interlocked.CompareExchange(ref _counter, 1, 0);
}
return _counter;
}注意：上面例子中，
CompareExchange返回的是交换前的值，所以你得靠返回值判断是否真正执行了赋值，而不是只看条件
_counter == 0—— 因为判断和交换之间存在竞态窗口。
Read、Add、Increment 在 32/64 位平台上的行为差异
Interlocked.Read是个特例：它只接受
ref long，且在 x64 上被编译为单条
MOV指令，在 x86 上则必须用
LOCK MOV（实际是
LOCK XCHG）来保证 64 位读取的原子性。而
Interlocked.Add(ref long, long)和
Interlocked.Increment(ref long)在 x86 上同样依赖
LOCK前缀指令，性能开销略高于 32 位操作。
关键事实：
int类型的
Interlocked操作在所有平台都是原子的，无需额外同步
long在 x86 上不是自然原子的，必须走
Interlocked，不能直接读/写字段
Interlocked.Read(ref long)是唯一安全读取未对齐或并发更新的
long字段的方式
错误示范（x86 下可能读到撕裂值）：
private long _timestamp; public long GetTimestamp() => _timestamp; // ❌ 可能返回高低 32 位来自不同写入的结果
正确写法：
private long _timestamp; public long GetTimestamp() => Interlocked.Read(ref _timestamp); // ✅
泛型 CompareExchange 在 .NET 6+ 中的适用边界
.NET 6 引入了
Interlocked.CompareExchange<t>(ref T, T, T)</t>，但它有硬性约束：类型
T必须是「不可变的引用类型」或「由编译器保证按位可比的值类型」，实际上目前只安全支持
class、
struct（且不含引用字段）、以及
IntPtr、
UIntPtr等少数类型。你不能对含字符串字段或 List 的类实例做泛型 CAS —— 编译器会允许，但运行时行为未定义。
更隐蔽的问题是内存模型：泛型版本不保证对字段的重新排序屏蔽，所以在复杂对象状态切换中，仍需配合
Volatile.Read/
Volatile.Write或
MemoryBarrier使用。
推荐优先级：
简单标志位 → 用int+
CompareExchange(ref int, 1, 0)对象引用替换 → 用泛型版，但确保
T是纯数据容器（如
Statestruct） 含副作用的状态机 → 别硬套
Interlocked，改用
lock或
SpinLock
真正难的从来不是调哪个方法，而是判断「这个变量的修改是否需要和其他字段的修改保持顺序一致」——这时候
Interlocked自身解决不了，得看整个同步契约。
