17370845950

应避免使用 lock(this)，因其会暴露锁对象导致同步失控；正确做法是使用私有只读对象字段（如 private readonly object _syncLock = new object();）作为锁，确保锁范围可控且不被外部访问。

lock(this) 会暴露锁对象给外部代码

当你写 lock(this)，实际是把当前实例（this）作为同步原语的监视器对象。而这个对象只要被公开引用，其他任意代码都能对它调用 Monitor.Enter 或 lock —— 意味着你完全失去了对锁边界的控制。

常见后果包括：

• 外部代码意外持有该锁，导致你的方法长时间阻塞
• 恶意或误用代码在锁内执行耗时操作，拖垮整个对象的并发性能
• 跨类协作时，两个本不相关的模块因共用同一实例锁而产生隐蔽竞争或死锁

lock(this) 在继承和多态场景下更危险

子类可能重写方法、添加新锁逻辑，甚至把 this 传给其他线程或异步回调。一旦发生，lock(this) 的作用域就从“保护本类内部状态”滑向“保护整个对象生命周期中的任意时刻”，这根本不可控。

尤其注意：

• 如果类是 public 且非 sealed，任何继承者都可能破坏你的同步假设
• ASP.NET Core 中的控制器实例、WPF 的 DependencyObject 子类等，常被框架反复复用或跨线程访问，lock(this) 极易引发偶发性卡顿或超时

替代方案：用私有 readonly object 字段

最简单可靠的写法是声明一个私有的、只读的锁对象：

private readonly object _syncLock = new object();

这样锁对象不会被外部访问，也不会随实例状态变化而改变引用。使用时：

• 始终用 lock(_syncLock)，而不是 lock(this)
• 不要把 _syncLock 设为 public 或 internal，避免被反射或友元程序滥用
• 不需要手动 Dispose，object 不实现 IDisposable

如果你需要区分读写场景，应改用 ReaderWriterLockSlim，而不是靠多个 lock(this) 变体硬凑。

特别注意：lock(typeof(T)) 和 lock(字符串) 同样危险

虽然问题焦点是 this，但顺带提醒：用 lock(typeof(MyClass)) 实际锁的是类型对象，在 AppDomain/Assembly 级别全局唯一；而 lock("myLock") 因字符串驻留（string interning）可能意外与其他模块共享锁。这两者都属于“锁范围失控”的同类错误。

真正安全的锁对象，必须满足两个条件：私有 + 不可被外部拿到引用。哪怕是一个 private static readonly object，只要没暴露出去，也比 this 或 typeof(...) 可靠得多。