lock是C#最常用线程同步机制，但需正确选用锁对象（私有、专用、不可变），仅在多线程读写共享非原子数据时使用，不可在lock内await，.NET 9+推荐用System.Threading.Lock替代。
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>添加元素（内部数组扩容+索引更新，非线程安全） - ❌ 不必加：只读访问
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 本身，而在共享状态的设计粒度和生命周期管理上。
