MSDN文档是这么说的
public class SomeObject
{
public void SomeOperation()
{
lock(this)
{
//Access instance variables
}
}
}
是“如果实例可以公开访问,则会出现问题”。我想知道为什么?这是因为锁持有的时间比需要的时间长吗?还是有更阴险的原因?
MSDN文档是这么说的
public class SomeObject
{
public void SomeOperation()
{
lock(this)
{
//Access instance variables
}
}
}
是“如果实例可以公开访问,则会出现问题”。我想知道为什么?这是因为锁持有的时间比需要的时间长吗?还是有更阴险的原因?
当前回答
想象一下,你的办公室有一位技术娴熟的秘书,这是部门的共享资源。偶尔,你会因为有任务而冲向他们,只希望你的另一个同事还没有认领他们。通常你只需要等很短的一段时间。
因为关心就是分享,你的经理决定顾客也可以直接使用秘书。但这有一个副作用:当您为该客户工作时,客户甚至可能会认领它们,并且您还需要他们执行部分任务。死锁发生,因为声明不再是层次结构。如果从一开始就不允许客户索赔,这完全可以避免。
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();
其他回答
这里也有一些关于这个的很好的讨论:这是互斥锁的正确使用吗?
关于它有一篇非常好的文章http://bytes.com/topic/c-sharp/answers/249277-dont-lock-type-objects,作者是Rico Mariani,他是Microsoft®.NET运行时的性能架构师
摘录:
这里的基本问题是您不拥有类型对象,而您 不知道还有谁能拿到。总的来说,这是一个非常糟糕的主意 依赖于锁定一个不是你创建的对象,也不知道还有谁 可能是存取。这样做会导致僵局。最安全的方法是 只锁定私有对象。
请参考下面的链接,它解释了为什么锁(这)不是一个好主意。
https://learn.microsoft.com/en-us/dotnet/standard/threading/managed-threading-best-practices
所以解决方案是添加一个私有对象,例如,lockObject到类中,并将代码区域放在lock语句中,如下所示:
lock (lockObject)
{
...
}
因为任何可以看到类实例的代码块也可以锁定该引用。您希望隐藏(封装)锁定对象,以便只有需要引用它的代码才能引用它。关键字this指向当前类实例,因此任何数量的东西都可以引用它,并可以使用它来进行线程同步。
需要明确的是,这很糟糕,因为其他一些代码块可能会使用类实例来锁定,并且可能会阻止您的代码获得及时的锁定,或者可能会产生其他线程同步问题。最好的情况是:没有其他方法使用对您的类的引用来锁定。中间情况:某些东西使用对你的类的引用来锁,这导致了性能问题。最坏的情况:某些东西使用你的类的引用来进行锁,这会导致非常糟糕、非常微妙、非常难以调试的问题。
抱歉,伙计们,我不同意锁定这个可能会导致僵局的说法。你混淆了两件事:僵局和饥饿。
如果不中断其中一个线程,就无法取消死锁,因此进入死锁后就无法退出 饥饿将在其中一个线程完成其工作后自动结束
这里有一张图可以说明两者的区别。
结论 如果线程饥饿对您来说不是问题,您仍然可以安全地使用lock(this)。你仍然需要记住,当线程使用lock(this)饿死线程时,它将以锁定对象的锁结束,它最终将以永远饥饿结束;)