C#的多线程开发中，lock语句是最常用的同步手段，但很多初学者会写出lock(new object())这样的代码，看起来加了锁，实际上完全没有起到任何同步作用，甚至可能引发难以排查的并发bug。本文将深入分析lock(new object())与lock(静态对象)的本质区别，并给出正确使用锁对象的实践建议。
一、lock语句的底层原理：锁的是对象引用
要理解两者的区别，首先要明白lock到底锁住了什么。C#中的lock语句在编译后会被展开为对System.Threading.Monitor类的调用，大致等价于下面的代码：
object obj = lockObject;
bool lockTaken = false;
try
{
Monitor.Enter(obj, ref lockTaken);
// 临界区代码
}
finally
{
if (lockTaken) Monitor.Exit(obj);
}Monitor.Enter方法接收的是一个object类型的引用。.NET运行时会在这个对象的对象头中关联一个同步块索引，用来记录当前哪个线程持有锁、有多少线程在等待。也就是说，锁的互斥语义完全依赖于"所有竞争线程引用的是同一个对象实例"。如果两个线程传入的是两个不同的对象实例，那么它们各自锁定的是两把不同的锁，彼此之间毫无干扰，可以同时进入临界区。
理解了这一点，lock(new object())的问题就显而易见了：每次执行到这一行时，new object()都会在堆上创建一个全新的对象，每次拿到的锁都是新的，锁的互斥性自然无从谈起。
二、lock(new object())为什么完全无效
先看一段典型的错误代码：
private int _count = 0;
public void Add()
{
for (int i = 0; i < 10000; i++)
{
lock (new object()) // 错误写法：每次都是新锁
{
_count++;
}
}
}假设两个线程同时调用Add方法，每次循环进入lock时都执行new object()，线程A和线程B拿到的是两个完全不同的锁对象。Monitor.Enter发现各自要的锁都是空闲的，于是两个线程同时进入临界区，_count++这个非原子操作就会发生竞争，最终结果大概率小于20000，出现数据丢失。
除了无法互斥之外，这种写法还有额外的性能损耗：new object()每次都要在托管堆上分配内存，虽然单个对象很小，但在高频调用的场景下会加重GC压力。可以说lock(new object())是"花了加锁的代价，却得到不加锁的结果"，是最糟糕的组合。
一些开发者误以为编译器会把new object()提升到循环外或者缓存起来，实际上不会。C#规范明确规定lock的表达式按原样求值，编译器不会做任何去重优化，因此每次执行到lock语句就是每次新建对象。
三、lock静态对象：真正意义上的全局互斥
正确的做法是让所有竞争线程锁定同一个对象，最常见的就是声明一个私有的静态只读锁对象：
public class Counter
{
private static readonly object _lock = new object();
private static int _count = 0;
public void Add()
{
for (int i = 0; i < 10000; i++)
{
lock (_lock) // 正确写法：所有线程竞争同一把锁
{
_count++;
}
}
}
}这里的关键点有三个：static保证了锁对象在所有实例之间共享，即使创建多个Counter实例，它们竞争的也是同一把锁；readonly防止锁对象被意外替换，一旦锁引用被修改，不同线程可能锁到不同对象上，互斥立即失效；private则避免了外部代码拿到你的锁对象去锁定，造成死锁或意外的锁竞争。
需要注意的是，静态锁的粒度是"整个类所有实例共享"。如果被保护的共享资源本身就是静态的，这是正确选择；但如果每个实例有各自独立的数据，用静态锁会导致不必要的串行化，降低并发性能。此时应该使用实例字段的锁对象：
public class Item
{
private readonly object _lock = new object(); // 实例锁，各实例互不影响
private int _data = 0;
public void Update()
{
lock (_lock)
{
_data++;
}
}
}四、其他常见的锁对象选择与陷阱
除了上述两种写法，实际开发中还有一些常见的锁对象选择，各有优劣。用this做锁对象是最危险的做法之一：this是公开可访问的引用，任何外部代码都可以lock你的实例，导致你无法掌控锁的竞争情况，极易造成死锁。锁定Type对象（如typeof(Counter)）同样危险，因为类型对象在AppDomain范围内是全局共享的，跨程序集的代码也可能锁定它。
锁定字符串也是常见陷阱。由于.NET的字符串驻留机制，代码中相同内容的字符串字面量会引用同一个实例，这意味着你在自己类里锁定的"myLock"，可能与完全不相关的第三方代码锁定的"myLock"是同一个对象，形成隐藏的锁竞争甚至死锁。因此锁对象一定要用你自己独占的、私有的object实例。
在高并发场景下，还可以考虑更专业的同步原语，例如Interlocked类适合简单的原子操作，SpinLock适合临界区极短的场景，SemaphoreSlim适合控制并发数量，async/await场景下则应使用SemaphoreSlim或AsyncLock替代lock，因为lock块内不能包含await。
五、总结：锁对象选择的最佳实践
回到核心问题：lock(new object())每次都创建新锁，完全无法提供互斥保护，还会带来额外的GC开销，属于必须杜绝的错误写法；lock(静态对象)让所有线程竞争同一把锁，能真正保护静态共享资源。选择锁对象时遵循以下原则即可避免绝大多数问题：锁对象必须是私有、只读的object实例；保护静态数据用static readonly字段，保护实例数据用实例readonly字段；永远不要锁定this、Type或字符串。掌握"锁的本质是对象引用的同一性"这一原理，你就能够在任何多线程场景中正确地设计同步方案。