c# lock(new object()) 和 lock(static_object) 的区别_技术教程

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 的等价写法——前者太细（实例级），后者太粗（进程级+副作用多）