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