什么时候锁定类型是个好主意？答案

【问题标题】：When is locking on types a good idea?什么时候锁定类型是个好主意？
【发布时间】：2011-11-21 08:48:27
【问题描述】：

从其他问题我可以看出锁定类型是一个坏主意。但是有可能这样做，所以我想知道这样做是否是一件坏事，为什么允许这样做？我假设它的目的必须有很好的用例，所以有人可以让我知道它们是什么吗？

【问题讨论】：

【解决方案1】：

这几乎总是一个坏主意：

任何人都可以从代码中的任何位置锁定类型，因此如果不查看所有代码，就无法确保不会出现死锁。
锁定一个类型甚至会导致跨 AppDomain 的死锁。参见 Joe Duffy 的文章：Don't lock on marshal-by-bleed objects.

这是允许的，因为对于您可以用作锁定对象的对象几乎没有任何限制。换句话说，它没有被明确允许——只是 .NET 框架中没有任何代码不允许它。

“调试 Microsoft .NET 应用程序”一书包含 FxCop 规则 DoNotLockOnTypes 的源代码，如果您尝试这样做，该规则会向您发出警告。 (thanks to Christian.K)

【讨论】：

【解决方案2】：

要了解为什么一般来说这是一个坏主意，请查看文章Don't lock type objects。

这是允许的，因为语言/框架设计者决定能够锁定源自System.Object 的任何内容。没有人能阻止它，因为 System.Type 派生自 System.Object（与其他所有 .NET 类型一样）。

签下这个签名：

void Foo(object o)

编译器如何强制o 不是System.Type？您当然可以在运行时检查它，但这会对性能产生影响。

当然，在某些情况下，可能需要锁定一种类型。也许 CLR 会在内部进行。

【讨论】：

【解决方案3】：

许多糟糕的想法在编程语言中找到了自己的方式，因为没有语言设计者可以预测未来。人类创造的任何语言都会有缺陷。

一些例子：

Hejlsberg wished（原始文章：The A-Z of Programming Languages: C# - Computerworld）他为 C# 添加了不可为空的类引用。（我希望他也能解决 const 问题。）
C++ 委员会搞砸了 valarray 和 export 以及其他许多次要和主要的遗憾。
Java 的模板是一项拙劣的工作（OMG，类型省略！），旨在避免更改 VM，当他们意识到无论如何都必须更改 VM 时，进行必要的返工已经太晚了。
Python 的范围规则一直是个麻烦事，许多改进它的尝试并没有太大帮助（有点，但不大）。

【讨论】：