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

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

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

lock (lockObject)
{
...
}

你可以建立一个规则，规定一个类可以有锁定'this'或类中代码实例化的任何对象的代码。所以只有不遵循这个模式才会有问题。

如果您想保护自己不受不遵循此模式的代码的影响，那么接受的答案是正确的。但如果遵循这个模式，那就不是问题。

锁的优点是效率高。如果你有一个简单的“值对象”，它只包含一个值。它只是一个包装器，它被实例化了数百万次。通过要求仅为锁定而创建一个私有同步对象，基本上使对象的大小增加了一倍，分配的数量也增加了一倍。当性能很重要时，这是一个优势。

当您不关心分配数量或内存占用时，出于其他答案中指出的原因，避免锁定(这)是可取的。

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

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

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

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

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

摘录:

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

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

这里有一个更简单的例子(来自这里的问题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