抱歉，伙计们，我不同意锁定这个可能会导致僵局的说法。你混淆了两件事:僵局和饥饿。

如果不中断其中一个线程，就无法取消死锁，因此进入死锁后就无法退出 饥饿将在其中一个线程完成其工作后自动结束

这里有一张图可以说明两者的区别。

结论 如果线程饥饿对您来说不是问题，您仍然可以安全地使用lock(this)。你仍然需要记住，当线程使用lock(this)饿死线程时，它将以锁定对象的锁结束，它最终将以永远饥饿结束;)

以下是一些更容易遵循的示例代码(IMO):(将在LinqPad中工作，参考以下名称空间:System。Net和System.Threading.Tasks)

需要记住的一点是，lock(x)基本上是语法糖，它所做的就是使用Monitor。输入，然后使用try、catch和finally块调用Monitor.Exit。参见:https://learn.microsoft.com/en-us/dotnet/api/system.threading.monitor.enter(备注部分)

或者使用c#锁语句(Visual Basic中的SyncLock语句)， 它将Enter和Exit方法包装在一个try…finally块中。

void Main()
{
    //demonstrates why locking on THIS is BADD! (you should never lock on something that is publicly accessible)
    ClassTest test = new ClassTest();
    lock(test) //locking on the instance of ClassTest
    {
        Console.WriteLine($"CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        Parallel.Invoke(new Action[]
        {
            () => {
                //this is there to just use up the current main thread. 
                Console.WriteLine($"CurrentThread {Thread.CurrentThread.ManagedThreadId}");
                },
            //none of these will enter the lock section.
            () => test.DoWorkUsingThisLock(1),//this will dead lock as lock(x) uses Monitor.Enter
            () => test.DoWorkUsingMonitor(2), //this will not dead lock as it uses Montory.TryEnter
        });
    }
}

public class ClassTest
{
    public void DoWorkUsingThisLock(int i)
    {
        Console.WriteLine($"Start ClassTest.DoWorkUsingThisLock {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        lock(this) //this can be bad if someone has locked on this already, as it will cause it to be deadlocked!
        {
            Console.WriteLine($"Running: ClassTest.DoWorkUsingThisLock {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
            Thread.Sleep(1000);
        }
        Console.WriteLine($"End ClassTest.DoWorkUsingThisLock Done {i}  CurrentThread {Thread.CurrentThread.ManagedThreadId}");
    }

    public void DoWorkUsingMonitor(int i)
    {
        Console.WriteLine($"Start ClassTest.DoWorkUsingMonitor {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        if (Monitor.TryEnter(this))
        {
            Console.WriteLine($"Running: ClassTest.DoWorkUsingMonitor {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
            Thread.Sleep(1000);
            Monitor.Exit(this);
        }
        else
        {
            Console.WriteLine($"Skipped lock section!  {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        }

        Console.WriteLine($"End ClassTest.DoWorkUsingMonitor Done {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        Console.WriteLine();
    }
}

输出

CurrentThread 15
CurrentThread 15
Start ClassTest.DoWorkUsingMonitor 2 CurrentThread 13
Start ClassTest.DoWorkUsingThisLock 1 CurrentThread 12
Skipped lock section!  2 CurrentThread 13
End ClassTest.DoWorkUsingMonitor Done 2 CurrentThread 13

注意线程#12永远不会因为死锁而结束。

我知道这是一个旧线程，但因为人们仍然可以查找并依赖它，因此有必要指出lock(typeof(SomeObject))明显比lock(this)差。话虽如此;对Alan指出lock(typeof(SomeObject))是不好的做法表示由衷的赞扬。

System的一个实例。Type是最通用的粗粒度对象之一。至少是System的一个实例。Type对于AppDomain是全局的，. net可以在一个AppDomain中运行多个程序。这意味着，如果两个完全不同的应用程序都试图在System.Type的同一个全局实例上获得同步锁，那么它们可能会对彼此造成潜在的干扰，甚至产生死锁。

因此，lock(这)并不是特别健壮的形式，可能会导致问题，并且由于所引用的所有原因应该总是令人惊讶。然而，像log4net这样广泛使用、相对受人尊敬且明显稳定的代码广泛使用锁(此)模式，尽管我个人更希望看到这种模式发生变化。

但是lock(typeof(SomeObject))打开了一个全新的增强的蠕虫容器。

不管怎样。

因为任何可以看到类实例的代码块也可以锁定该引用。您希望隐藏(封装)锁定对象，以便只有需要引用它的代码才能引用它。关键字this指向当前类实例，因此任何数量的东西都可以引用它，并可以使用它来进行线程同步。

需要明确的是，这很糟糕，因为其他一些代码块可能会使用类实例来锁定，并且可能会阻止您的代码获得及时的锁定，或者可能会产生其他线程同步问题。最好的情况是:没有其他方法使用对您的类的引用来锁定。中间情况:某些东西使用对你的类的引用来锁，这导致了性能问题。最坏的情况:某些东西使用你的类的引用来进行锁，这会导致非常糟糕、非常微妙、非常难以调试的问题。

这里有一个更简单的例子(来自这里的问题34)，为什么锁(this)是不好的，并且当你的类的消费者也试图锁定对象时可能会导致死锁。 下面，三个线程中只有一个线程可以继续，其他两个线程处于死锁状态。

class SomeClass { public void SomeMethod(int id) { **lock(this)** { while(true) { Console.WriteLine("SomeClass.SomeMethod #" + id); } } } } class Program { static void Main(string[] args) { SomeClass o = new SomeClass(); lock(o) { for (int threadId = 0; threadId < 3; threadId++) { Thread t = new Thread(() => { o.SomeMethod(threadId); }); t.Start(); } Console.WriteLine(); }

为了解决这个问题，这家伙使用了Thread。TryMonitor(带超时)而不是lock:

班长。TryEnter(temp, millisecondsTimeout, ref lockWasTaken); 如果(lockWasTaken) ｛ doAction (); ｝ 其他的 ｛ 抛出新的异常(" cannot get lock"); ｝

https://blogs.appbeat.io/post/c-how-to-lock-without-deadlocks

这里也有一些关于这个的很好的讨论:这是互斥锁的正确使用吗?