线程安全，说白了就是：多个线程同时调用你的代码，结果和单线程跑出来一模一样，变量不会“算丢”、数据不会“写串”、状态不会“变错”。它不是某种开关或属性，而是你对共享资源访问方式的设计结果。
lock
是最常用也最容易出错的线程安全手段
很多人以为加个
lock就万事大吉，其实关键在锁什么、锁多大范围、谁在用这个锁。
lock(this)或
lock(typeof(MyClass))是高危写法——外部代码也能锁住同一个对象，可能引发死锁或意外阻塞 推荐用私有只读字段：
private readonly object _lockObj = new object();，确保锁对象不被外界干扰 锁的代码块越小越好，比如只包
_counter++，别把
Thread.Sleep(1000)或网络请求也塞进去 如果锁的是集合（如
List<t></t>），那所有增删查改都得走同一把锁；漏掉一个
Add或
Count，立刻线程不安全
Interlocked
适合简单数值操作，性能碾压 lock
当你只做“加1”“取最大值”“原子替换”这类单指令操作时，
Interlocked是更优解——它靠 CPU 硬件指令保证原子性，不抢锁、不挂起线程。
Interlocked.Increment(ref _count)比
lock(_lock) { _count++; } 快 3–5 倍（尤其高并发场景）
它只支持 int、
long、
IntPtr、引用类型等有限类型，不能用于复杂对象赋值或多步逻辑
Interlocked.CompareExchange是实现无锁状态机的核心，比如“仅当当前是空闲态才切换为运行中”
private int _state; // 0=空闲, 1=运行中
public bool TryStart()
{
return Interlocked.CompareExchange(ref _state, 1, 0) == 0;
}
别自己造轮子：优先用 ConcurrentDictionary
而不是 Dictionary
+ lock
.NET 提供的并发集合类（
ConcurrentQueue、
ConcurrentStack、
ConcurrentDictionary）不是“加了锁的普通集合”，而是内部采用分段锁、无锁算法等优化设计，吞吐量更高、更可靠。
ConcurrentDictionary.TryAdd(key, value)是原子的，不用额外加锁 但注意：它的
Count属性不是实时精确值（为性能牺牲一致性），需要精确计数请用
Interlocked单独维护 不要试图用
ConcurrentDictionary替代业务逻辑锁——比如“扣库存”这种需校验+修改两步的操作，仍要自己加锁或用数据库事务
真正难的从来不是“怎么加锁”，而是判断“哪里需要加锁”。静态字段、单例实例、缓存字典、全局计数器……这些地方只要被多个线程读写，就默认不安全。而方法参数、局部变量、
string字面量本身天然线程安全——它们在线程栈上各自有一份，互不干扰。
