lock 在 IL 中会自动生成 try-finally 包裹
直接说结论：
lock(obj) { ... } 编译后，IL 中**必然生成 try块 +
finally块**，其中
Monitor.Exit被强制放在
finally里；而手写
Monitor.Enter/
Monitor.Exit若不手动加
try-finally，就**完全没保障**——一旦
Enter后、执行业务逻辑前抛异常（比如线程被中止、OOM、StackOverflow），
Exit就永远不会执行，锁永久泄露。
lock的 IL 等效于：
Monitor.Enter(obj);
try {
// your code
}
finally {
Monitor.Exit(obj);
}
手写 Monitor.Enter/
Monitor.Exit的常见错误写法（危险！）：
Monitor.Enter(obj); DoSomething(); // ← 这里崩了？锁就卡死了 Monitor.Exit(obj); // ← 永远不会执行C# 4.0+ 提供了更安全的手写方式：
Monitor.Enter(obj, ref lockTaken)，配合
if (lockTaken) Monitor.Exit(obj)，但依然要你自己写
try-finally才算完整
lock 只支持引用类型，Monitor.Enter 可“误用”值类型
lock语法强制要求锁对象是引用类型，编译器会报错：
CS0185: 'lock' statement operand must be of a reference type。而
Monitor.Enter接收
object参数，传入值类型（如
int、
struct）会触发装箱——每次调用都产生**新对象实例**，导致锁失效（因为不是同一个对象）。 下面这段代码**根本不同步**：
int locker = 42; Monitor.Enter(locker); // ← 装箱成新 object // ... 业务逻辑 Monitor.Exit(locker); // ← 再次装箱，是另一个 object！
lock(42)直接编译失败，反而帮你避开了这个坑 真正安全的锁对象必须是**同一个引用**：静态
readonly object、私有字段、
typeof(MyClass)（慎用，有跨程序集风险）
Monitor 提供 lock 没有的超时和等待通知能力
lock是纯阻塞式互斥，要么拿到锁立刻进，要么一直等。而
Monitor类暴露了更底层的能力：
Monitor.TryEnter(obj, timeoutMs)：带超时获取锁，避免死等 ——
lock完全不支持
Monitor.Wait(obj)+
Monitor.Pulse(obj)/
PulseAll：实现线程间条件等待（比如生产者-消费者），
lock语法无法表达这种协作语义 这些方法**必须在已持有该对象锁的前提下调用**，否则抛
SynchronizationLockException
容易被忽略的细节：lock 对象的可见性与生命周期
无论用
lock还是
Monitor，锁失效往往不是语法问题，而是对象本身出错了： 锁对象被设为
null→
NullReferenceException（
lock(null)编译期不报错，运行时报） 锁对象是局部变量或每次 new 出来的 → 每次锁的都不是同一个东西，形同虚设 用
lock(this)或
lock(typeof(...))→ 外部代码可能也锁它，引发意外争用或死锁 锁对象被 GC 回收（极少见，但若锁对象无强引用且被弱引用持有，可能触发 Finalize 并发问题）
真正难的从来不是“怎么写 lock”，而是“锁谁”和“锁多久”。Monitor 的裸 API 把这些责任全摊开给你，lock 则帮你盖住了一层——但盖不住设计缺陷。
