C#的lock关键字如何实现线程同步？-C#.Net教程-PHP中文网

lock关键字通过monitor类实现排他锁，确保多线程下共享资源访问的线程安全；2. 使用私有只读object字段作为锁对象是最佳实践，避免锁定this、typeof、字符串字面量或值类型以防死锁或同步失效；3. lock不支持超时、无公平性保证、无法控制并发数且不区分读写，复杂场景应选用semaphoreslim或readerwriterlockslim。

C#的lock关键字如何实现线程同步？

C#中的

lock

登录后复制

关键字，本质上就是为了解决多线程环境下共享资源访问冲突的问题。它确保在任何给定时刻，只有一个线程能够执行被

lock

登录后复制

保护的代码块，从而有效地避免了数据竞争和不一致性。

lock

登录后复制

关键字是C#提供的一个同步原语，它背后的实现机制是基于.NET框架中的

Monitor

登录后复制

类。当你写下

lock (someObject)

登录后复制

时，编译器会将其转换为对

Monitor.Enter

登录后复制

和

Monitor.Exit

登录后复制

方法的调用，并且非常关键的是，

Monitor.Exit

登录后复制

被放置在一个

try-finally

登录后复制

块中，以确保无论代码块中是否发生异常，锁都能被正确释放。

这个

someObject

登录后复制

，也就是我们通常称之为“锁对象”的东西，扮演着一个关键的“门卫”角色。当一个线程尝试进入

lock

登录后复制

代码块时，它会试图获取这个

someObject

登录后复制

的独占锁。如果锁已经被其他线程持有，那么当前线程就会被阻塞，直到锁被释放。一旦线程成功获取锁，它就可以安全地执行临界区代码。代码执行完毕，或者抛出异常退出

try

登录后复制

块时，

finally

登录后复制

块会确保锁被释放，允许其他等待的线程有机会获取它。

lock

登录后复制

关键字内部究竟是怎样运作的？

深入一点看，

lock

登录后复制

实际上是对

System.Threading.Monitor

登录后复制

类方法的语法糖。当你写

lock (myLockObject)

登录后复制

时，它大致等同于：

bool lockTaken = false;
try
{
    Monitor.Enter(myLockObject, ref lockTaken);
    // 这里是你的临界区代码
}
finally
{
    if (lockTaken)
    {
        Monitor.Exit(myLockObject);
    }
}

登录后复制

这里需要注意

Monitor.Enter

登录后复制

的重载版本，它带有一个

bool lockTaken

登录后复制

参数。这个参数在

Monitor.Enter

登录后复制

成功获取锁后会被设置为

true

登录后复制

，即使在获取锁的过程中发生异常（比如线程被中断），

lockTaken

登录后复制

也可能仍然是

false

登录后复制

，从而避免在未成功获取锁的情况下调用

Monitor.Exit

登录后复制

。这是一种非常健壮的设计，确保了锁的正确性。

Monitor

登录后复制

类在内部维护着一个等待队列和一个就绪队列。当一个线程调用

Monitor.Enter

登录后复制

并发现锁已被占用时，它会被放入等待队列并阻塞。当持有锁的线程调用

Monitor.Exit

登录后复制

释放锁时，

Monitor

登录后复制

会从等待队列中选择一个线程（具体选择哪个线程，CLR没有明确规定，通常是先进先出，但并非绝对公平）并将其移到就绪队列，使其有机会重新调度并获取锁。

Monitor

登录后复制

还支持锁的重入性（reentrancy）。这意味着，如果一个线程已经持有了某个对象的锁，那么它可以在不阻塞自己的情况下，再次进入使用同一个锁对象的

lock

登录后复制

代码块。

Monitor

登录后复制

会为每个锁维护一个计数器，每次重入就增加计数，每次退出就减少计数，直到计数为零时，锁才真正被释放。

选择

lock

登录后复制

对象时有哪些常见的陷阱和最佳实践？

选择一个合适的锁对象至关重要，否则可能导致意想不到的死锁、性能瓶颈，甚至无法达到同步的目的。

常见陷阱：

锁定
```
this
```
登录后复制
实例：
```
public class MyClass
{
    public void DoSomething()
    {
        lock (this) // 陷阱！
        {
            // ...
        }
    }
}
```
登录后复制
当你锁定
```
this
```
登录后复制
时，你实际上是锁定了当前
```
MyClass
```
登录后复制
的实例。如果这个实例可以被外部代码访问，并且外部代码也尝试对这个实例进行锁定（例如，为了同步对
```
MyClass
```
登录后复制
实例的某个公共方法的访问），那么就可能出现死锁。更糟糕的是，这使得你的内部同步机制暴露给了外部，失去了封装性。
锁定
```
typeof(MyClass)
```
登录后复制
：
```
public class MyClass
{
    public static void DoSomethingStatic()
    {
        lock (typeof(MyClass)) // 陷阱！
        {
            // ...
        }
    }
}
```
登录后复制
锁定
```
typeof(MyClass)
```
登录后复制
会锁定
```
MyClass
```
登录后复制
的
```
Type
```
登录后复制
对象。这个
```
Type
```
登录后复制
对象是应用程序域内唯一的。这意味着，如果你在不同的类或不同的静态方法中也锁定
```
typeof(MyClass)
```
登录后复制
，它们之间会互相阻塞。这通常会导致过度粗粒度的锁定，降低并发性，并且同样暴露了内部同步细节。
锁定字符串字面量：
```
public void DoSomething()
{
    lock ("myLockString") // 陷阱！
    {
        // ...
    }
}
```
登录后复制
C#编译器会对字符串字面量进行“字符串驻留”（string interning）。这意味着，即使你在代码的不同地方写了相同的字符串字面量，它们在内存中可能指向同一个唯一的字符串对象。因此，锁定一个字符串字面量可能无意中导致你的锁与应用程序中其他看似不相关的代码共享同一个锁对象，造成难以调试的竞争条件。

腾讯智影-AI数字人
基于AI数字人能力，实现7*24小时AI数字人直播带货，低成本实现直播业务快速增增，全天智能在线直播

73

查看详情
锁定值类型：
```
int counter = 0;
private void Increment()
{
    lock (counter) // 陷阱！
    {
        counter++;
    }
}
```
登录后复制
```
lock
```
登录后复制
关键字只能用于引用类型。当你尝试锁定一个值类型时，它会被装箱（boxing）成一个新的对象，
```
lock
```
登录后复制
操作实际上是对这个新装箱对象进行锁定。每次
```
lock
```
登录后复制
操作都会创建一个新的装箱对象，所以每次锁定的都是不同的对象，导致同步完全失效。

最佳实践：

使用私有的、只读的
```
object
```
登录后复制
实例作为锁对象：
```
public class MyClass
{
    private readonly object _lockObject = new object(); // 最佳实践！

    public void DoSomething()
    {
        lock (_lockObject)
        {
            // 临界区代码
        }
    }
}
```
登录后复制
对于实例方法，创建一个
```
private readonly object
```
登录后复制
字段作为锁对象是标准的做法。
```
private
```
登录后复制
确保了锁对象不会被外部代码访问和滥用，
```
readonly
```
登录后复制
确保了它在对象生命周期内不会被意外替换。

对于静态方法或静态成员，使用私有的、只读的静态

object

登录后复制

实例：

public class MyClass
{
    private static readonly object _staticLockObject = new object(); // 最佳实践！

    public static void DoSomethingStatic()
    {
        lock (_staticLockObject)
        {
            // 临界区代码
        }
    }
}

登录后复制

这确保了对静态成员的访问同步，并且同样遵循了封装性原则。

保持锁的粒度尽可能小：只锁定真正需要同步的代码块，而不是整个方法或类。过大的锁粒度会限制并发性，导致性能下降。例如，如果一个方法中只有一小部分涉及到共享资源，那么只对这部分代码使用
```
lock
```
登录后复制
，而不是整个方法。

lock

登录后复制

与其它同步机制（如

SemaphoreSlim

登录后复制

、

ReaderWriterLockSlim

登录后复制

）相比，有哪些局限性？

lock

登录后复制

关键字虽然简单易用，但在某些复杂场景下，它的能力会显得不足。

独占性：
```
lock
```
登录后复制
提供的是一个排他锁，这意味着在任何时候，只有一个线程能够进入被保护的代码块。这对于读写操作都需要独占访问的场景很合适。但如果你的场景是“多读少写”，即读操作可以并行发生，而写操作才需要独占，那么
```
lock
```
登录后复制
就会成为性能瓶颈，因为它会阻止所有并行读操作。
无超时机制：使用
```
lock
```
登录后复制
时，如果一个线程尝试获取已经被其他线程持有的锁，它会无限期地等待，直到锁被释放。这意味着它没有提供超时机制。在某些情况下，你可能希望线程在等待一段时间后如果仍未获取到锁，就放弃等待并执行其他逻辑，或者抛出异常。
```
Monitor.TryEnter
```
登录后复制
提供了超时功能，但
```
lock
```
登录后复制
关键字本身不提供。
无公平性保证：
```
lock
```
登录后复制
（以及底层的
```
Monitor
```
登录后复制
）不保证等待线程获取锁的顺序。一个线程释放锁后，CLR可能会选择任何一个等待的线程来获取锁，不一定是等待时间最长的那个。在需要严格按顺序处理请求的场景中，这可能不是你想要的。
无法控制并发数量：
```
lock
```
登录后复制
只能实现“有”或“无”的访问控制（0或1个线程）。它不能像
```
SemaphoreSlim
```
登录后复制
那样，允许指定数量（N个）的线程同时访问某个资源。
```
SemaphoreSlim
```
登录后复制
可以用于限制对某个资源池（如数据库连接池、线程池）的并发访问数量。
无法区分读写操作：对于读多写少的场景，
```
ReaderWriterLockSlim
```
登录后复制
是更优的选择。它允许多个读取者同时访问资源，只有在写入者需要修改资源时才阻塞读取者和其它写入者。这极大地提高了读操作的并发性，而
```
lock
```
登录后复制
无法提供这种读写分离的并发控制。