C#中lock死锁实例教程

阿麦

发布时间：2026-10-14| 3人浏览过

原创

C#中的 lock 关键字用于确保同一时刻只有一个线程可以访问特定代码块，通过锁定一个对象来实现互斥。然而，如果使用不当（如锁定公共对象、Type类型或字符串常量），不仅会降低性能，更会直接导致程序进入死锁状态。本文将结合官方文档建议与实际代码场景，深入解析死锁成因及安全最佳实践。

lock的关键字原理与锁对象要求

lock(X) 的原型决定了锁的核心在于对象 X。在C#中，X 必须是引用类型。其工作原理是：当多个线程执行到 lock(X) 时，只有成功获取 X 对象互斥锁的线程才能进入代码块内部执行；其余线程会被迫排队等待。因此，为了实现同步效果，这个 X 必须是所有竞争资源的线程所共有的同一个对象引用。

MSDN指出的三大典型死锁陷阱

微软官方开发中心（MSDN）明确指出，应避免锁定以下三种情况，因为它们属于公开资源或驻留资源：

锁定 this：如果实例可以被公共访问，外部代码可能同样锁定了该实例，从而造成不可控的交叉锁。
锁定 typeof(MyType)：如果类 MyType 被公共访问，全局任何地方都可以锁定该类对象。
锁定字符串：由于CLR的字符串暂留机制（String Interning），内容相同的字符串在内存中只有一份。应用程序域内任何位置锁定相同内容的字符串都会产生冲突。

第1步：分析 lock(this) 导致的相互死锁

这是最常见的死锁场景之一。假设有两个类 A 和 B，并在其中分别持有对方的实例。当两个线程并发调用不同对象的方法时，可能会因为“请求对方持有的锁”而导致僵持。

class A { }
class B { }

假设 a 和 b 分别是这两个类的公共实例。在类 A 的方法中进行如下操作：

// 代码1
lock(this) // 此时this指向a，锁定a
{
    // ...逻辑
    lock(b)   // 尝试获取b的锁
    {
        // ......
    }
}

与此同时，在类 B 的方法中可能存在反向逻辑：

// 代码2
lock(this) // 此时this指向b，锁定b
{
    // ...逻辑
    lock(a)   // 尝试获取a的锁
    {
        // ......
    }
}

死锁发生过程：线程1先执行代码1，获取了锁 a；线程2同时执行代码2，获取了锁 b。随后，线程1在内层尝试获取 b 时发现被占，开始等待；线程2在内层尝试获取 a 时发现也被占，也开始等待。两者陷入永久僵局，即死锁。

第2步：解析 lock(typeof()) 引发的系统级冲突

当对类型本身进行锁定时，锁的范围覆盖整个AppDomain内的该类所有实例。

int a;
float b;

如果在不同代码块中对变量所属的类型进行嵌套锁定，也会出现上述的对向请求问题：

// 代码3
lock(typeof(int)) // 锁定System.Int32类型对象
{
    lock(typeof(float)) { /* ... */ } 
}

// 代码4
lock(typeof(float)) // 锁定System.Single类型对象
{
    lock(typeof(int)) { /* ... */ }
}

若有两个进程或线程同时进入外层 lock，它们将分别持有 System.Type 的不同实例锁，然后立刻尝试获取对方持有的类型锁。这种跨类型的相互占有同样是致命的死锁触发器。

第3步：警惕字符串锁定的隐式危险

C#具有字符串驻留机制，这意味着程序中所有内容为 "abc" 的字符串变量实际上指向内存中的同一个对象引用。如果两个不同的类分别使用了相同的字符串作为锁：

// Class A定义
private string a = "abc";
private string b = "def";

// Class C定义
private string c = "abc"; // 注意：c和a引用的是同一个对象
private string d = "def"; // 注意：d和b引用的是同一个对象

如果在A中先锁 b("def")再锁 a("abc")，而另一个地方先锁 c("abc")再锁 d("def")，结果将与 this 锁定的错误一模一样，只是这次是因为CLR的资源复用特性导致的意外碰撞。因此，**千万不要在 lock 中使用字符串常量。**

最佳实践及其局限性：Private对象的正确用法

为了规避上述公共访问带来的风险，MSDN建议最佳做法是：定义 private 对象来锁定，或使用 private static (shared) 对象变量来保护共享数据。

虽然限制访问范围大大降低了外部干扰的可能，但这并不能绝对保证不死锁。如果我们自己编写的代码内部存在加锁顺序不一致的情况，依然会发生死锁。

第4步：验证私有锁的死锁可能性

即便锁对象是完全私有的，如果在类的不同方法中以相反的顺序获取同一个私有锁集合，仍然极其危险。

class A 
{ 
    private Object a = new Object(); 
    private Object b = new Object(); 

    public void x() 
    { 
        lock(a) // 先锁定a
        { 
            // .....
            lock(b) // 后锁定b
            { 
                // ....
            } 
        } 
    } 

    public void y() 
    { 
        lock(b) // 先锁定b！顺序反了！
        { 
            // .....
            lock(a) // 后锁定a
            { 
                // ....
            } 
        } 
    } 
}

分析：如果线程1调用 x()，线程2调用 y() 且二者并发执行。线程1拿到 a 去求 b，线程2拿到 b 去求 a。尽管 a 和 b 都是 private 的，但在多线程高并发下，这依然是必死的死结。