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

如果可以公开访问实例，就会出现问题，因为可能有其他请求正在使用相同的对象实例。最好使用私有/静态变量。

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

以下是一些更容易遵循的示例代码(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) is bad as we've seen. An outside object might lock on the object and since you don't control who's using the class, anyone can lock on it... Which is the exact example as described above. Again, the solution is to limit exposure of the object. However, if you have a private, protected or internal class you could already control who is locking on your object, because you're sure that you've written your code yourself. So the message here is: don't expose it as public. Also, ensuring that a lock is used in similar scenario's avoids deadlocks.

与此完全相反的是锁定整个应用领域共享的资源——这是最坏的情况。这就像把你的秘书放在外面，让外面的人去认领一样。结果是彻底的混乱——或者就源代码而言:这是一个坏主意;把它扔掉，重新开始。我们怎么做呢?

正如这里大多数人指出的那样，类型在应用领域是共享的。但是我们可以使用更好的东西:字符串。原因是字符串被池化了。换句话说，如果你有两个字符串在一个应用域中有相同的内容，它们有可能有完全相同的指针。由于指针被用作锁键，基本上你得到的是“为未定义的行为做好准备”的同义词。

类似地，你不应该锁定WCF对象HttpContext。目前,线程。当前，单例(一般)等。避免这一切的最简单方法是什么?private [static] object myLock = new object();