请参考下面的链接，它解释了为什么锁(这)不是一个好主意。

https://learn.microsoft.com/en-us/dotnet/standard/threading/managed-threading-best-practices

所以解决方案是添加一个私有对象，例如，lockObject到类中，并将代码区域放在lock语句中，如下所示:

lock (lockObject)
{
...
}

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

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

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

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

关于它有一篇非常好的文章http://bytes.com/topic/c-sharp/answers/249277-dont-lock-type-objects，作者是Rico Mariani，他是Microsoft®.NET运行时的性能架构师

摘录:

这里的基本问题是您不拥有类型对象，而您 不知道还有谁能拿到。总的来说，这是一个非常糟糕的主意 依赖于锁定一个不是你创建的对象，也不知道还有谁 可能是存取。这样做会导致僵局。最安全的方法是 只锁定私有对象。

看看MSDN主题线程同步(c#编程指南)

Generally, it is best to avoid locking on a public type, or on object instances beyond the control of your application. For example, lock(this) can be problematic if the instance can be accessed publicly, because code beyond your control may lock on the object as well. This could create deadlock situations where two or more threads wait for the release of the same object. Locking on a public data type, as opposed to an object, can cause problems for the same reason. Locking on literal strings is especially risky because literal strings are interned by the common language runtime (CLR). This means that there is one instance of any given string literal for the entire program, the exact same object represents the literal in all running application domains, on all threads. As a result, a lock placed on a string with the same contents anywhere in the application process locks all instances of that string in the application. As a result, it is best to lock a private or protected member that is not interned. Some classes provide members specifically for locking. The Array type, for example, provides SyncRoot. Many collection types provide a SyncRoot member as well.

以下是不建议使用的原因。

短版: 考虑下面的代码片段:

object foo = new Object(); 
object bar = foo; 

lock(foo)
{
  lock(bar){}
}  

这里，foo和bar引用的是导致死锁的同一个对象实例。这是现实中可能发生的事情的简化版本。

长版: 为了根据下面的代码片段更详细地解释它，假设您编写了一个类(在本例中为SomeClass)，并且类的使用者(名为“John”的编码器)希望获得类实例(在本例中为someObject)上的锁。他遇到死锁是因为他在实例someObject上获得了一个锁，在这个锁中他调用了该实例的一个方法(SomeMethod())，该方法在内部获得了同一个实例上的锁。

I could have written the following example with or without Task/Thread and the gist of deadlock still remains the same. To prevent bizarre situation where the main Thread finishes while its children are still running, I used .Wait(). However, in long-running-tasks or situation where a code-snippet executes more frequently, you would definitely see the same behavior. Although John applied a bad practice of using an instance of a class as a lock-object, but we (as the developer of a classlibrary SomeClass) should deter such situation simple by not using this as a lock-object in our class. Instead, we should declare a simple private field and use that as our lock-object. using System; using System.Threading; using System.Threading.Tasks; class SomeClass { public void SomeMethod() { //NOTE: Locks over an object that is already locked by the caller. // Hence, the following code-block never executes. lock (this) { Console.WriteLine("Hi"); } } } public class Program { public static void Main() { SomeClass o = new SomeClass(); lock (o) { Task.Run(() => o.SomeMethod()).Wait(); } Console.WriteLine("Finish"); } }

请参考下面的链接，它解释了为什么锁(这)不是一个好主意。

https://learn.microsoft.com/en-us/dotnet/standard/threading/managed-threading-best-practices

所以解决方案是添加一个私有对象，例如，lockObject到类中，并将代码区域放在lock语句中，如下所示:

lock (lockObject)
{
...
}