17370845950

lock(new object())几乎没用，因为每次新建对象实例导致线程锁不同对象，无法实现互斥；正确做法是用private static readonly object _syncLock = new object()确保共享同一引用。

lock(new object()) 为什么几乎没用

它每次执行都新建一个 object 实例，而 lock 的作用是让多个线程在**同一个对象实例**上排队。新对象彼此不共享，等于每个线程锁的都是“自己的门”，根本互斥不了。

常见错误现象：
— 多线程修改共享字段仍出现竞态（如计数器不准）
— 单元测试偶尔通过、压测必崩
— 看似加了锁，实际等效于没加

• 永远不要在 lock 表达式里用 new object()、new object[] { } 或任何每次求值都产生新引用的表达式
• 如果只是想“防止这段代码被并发执行”，必须确保所

  

  有调用路径锁的是**同一个引用**
• 编译器不会报错，运行时也无异常，这是典型的静默失效

lock(static_object) 是正确做法，但要注意初始化时机

静态字段保证生命周期和可见性，但必须确保它在首次访问前已就绪。推荐显式声明并初始化，避免依赖静态构造函数的隐式行为。

private static readonly object _syncLock = new object();

// ✅ 安全：字段只读 + 显式初始化
public void DoWork()
{
    lock (_syncLock)
    {
        // 临界区
    }
}

• 用 private static readonly 而非 static object，防止意外重新赋值
• 不要在静态构造函数里延迟初始化 _syncLock，除非有特殊理由——多数场景直接内联初始化最清晰
• 若需延迟加载（比如依赖外部配置），可用 Lazy，但要确认 Value 是线程安全的

lock(this) 和 lock(typeof(XXX)) 的典型误用

这两类写法看似“复用同一对象”，实则隐患明显，常被当成 static object 的替代方案，但语义和风险完全不同。

• lock(this)：锁的是当前实例，对实例方法有效；但若类被大量 new，或暴露给外部调用者，可能引发外部死锁或锁粒度失控
• lock(typeof(MyClass))：锁的是类型对象，全局唯一，但会与反射、序列化、甚至某些框架（如 ASP.NET Core 的类型扫描）产生意外交互，且难以追踪
• 它们都不是 static object 的等价写法——前者太细（实例级），后者太粗（进程级+副作用多）

真正需要区分的是锁的粒度，而不是“new 还是 static”

关键不在关键字，而在你锁的对象是否对应你要保护的资源范围。比如：

• 保护整个类的静态状态 → 用 private static readonly object
• 保护某个实例字段 → 用该实例的私有 readonly object 字段（非 this）
• 保护字典中某个 key 对应的值 → 用 ConcurrentDictionary 配合 GetOrAdd，而非全局锁

很多人卡在“怎么选锁对象”，其实更该先问：“我要保护什么？谁会并发访问它？最小必要范围是多大？”——锁对象只是这个判断的结果，不是起点。