lock 是 C# 最常用、最直接的线程同步机制，但它不是万能钥匙——用错对象、锁太久、嵌套顺序乱，轻则性能暴跌，重则死锁或数据错乱。
lock 的正确写法和锁对象怎么选
lock 本质是
Monitor.Enter+
Monitor.Exit的语法糖，它只接受引用类型对象，且该对象必须「私有」「专用」「不可变」。 ✅ 推荐：
private static readonly object _lockObj = new object();（保护静态资源）或
private readonly object _instanceLock = new object();（保护实例资源） ❌ 绝对禁止：
lock("myLock")（字符串被 CLR 暂留，跨处共享同一锁）、lock(this)（外部代码可能也锁它）、
lock(typeof(MyClass))（类型对象全局唯一，易被滥用） ❌ 编译不通过：
lock(1)或
lock(new int())（值类型会装箱成新对象，每次 lock 都是不同实例，完全无效）
什么时候必须加 lock？常见误判场景
不是“多线程”就一定需要 lock，而是「多个线程同时读写同一内存地址」且操作非原子时才真正需要。比如：
✅ 必须加：对static int counter执行
counter++（读-改-写三步，非原子） ✅ 必须加：向
static List<string></string>添加元素（内部数组扩容+索引更新，非线程安全） ❌ 不必加：只读访问
static readonly string ConfigValue（只读 + 不可变，天然线程安全） ❌ 别乱加：在 lock 块里调用
File.WriteAllText()或
HttpClient.GetAsync()（I/O 耗时长，会卡住其他线程，应移到 lock 外）
lock 内部能 await 吗？不能，但有替代方案
lock语句块内**不允许使用
await** —— 因为编译器无法保证 finally 中的
Monitor.Exit在异步恢复后执行，会导致锁永远不释放。 ❌ 错误写法：
lock (_lockObj)
{
await Task.Delay(100); // 编译报错：CS4032：“await”不能在“lock”语句中使用
}
✅ 替代方案：
用 SemaphoreSlim.WaitAsync()替代（支持 async/await） 把耗时 I/O 拆出来，只在 lock 中做纯内存操作（如：先计算结果，再 lock 更新状态）
.NET 9+ 推荐用 System.Threading.Lock
替代 object
从 .NET 9 和 C# 13 开始，
System.Threading.Lock是专为锁定设计的 ref struct 类型，比
new object()更轻量、更安全（编译器会警告误转型）。 ✅ 新写法：
private static readonly Lock _lock = new Lock();
// ...
using (_lock.EnterScope())
{
// 临界区代码
}
⚠️ 注意：旧项目若仍用 .NET 6/8，继续用 private static readonly object即可，无需强切；升级前确保所有 lock 使用都已收敛、可测试。
真正难的从来不是「怎么加锁」，而是「哪里要加」「加多细」「加多久」——多数线程问题，根源不在 lock 本身，而在共享状态的设计粒度和生命周期管理上。
