当前位置：文江博客话题详情

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

发布于 2024-12-17 13:26:28 字数 98 浏览 0 评论 0原文

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

雨的味道风的声音 2024-12-24 13:26:28

这几乎总是一个坏主意：

任何人都可以从代码中的任何位置锁定类型，因此您无法在不查看所有代码的情况下确保不会陷入死锁。
锁定类型甚至可能导致跨 AppDomain 的死锁。请参阅 Joe Duffy 的文章：不要锁定 marshal-by-bleed 对象.

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

《调试 Microsoft .NET 应用程序》一书包含 FxCop 规则 DoNotLockOnTypes 的源代码，如果您尝试执行此操作，该规则会向您发出警告。（感谢克里斯蒂安.K)

回复收藏 0 原文

妥活 2024-12-24 13:26:28

要了解为什么这是一个坏主意，请查看文章不要锁定类型对象。

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

采用这个签名：

void Foo(object o)

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

当然，可能存在一些超级奇异的情况，人们可能需要锁定一种类型。也许 CLR 在内部执行此操作。

To understand why it is a bad idea in general have a look at the article Don't lock type objects.

It is allowed because the language/framework designers decided to be able to take lock on anything that derives from System.Object. Nobody can prevent it because System.Type derives from System.Object (as every other .NET type).

Take this signature:

void Foo(object o)

How could a compiler enforce that o is no System.Type? You could of course check it at runtime, but this would have a performance impact.

And of course there might be super-exotic situations where one might need to lock on a type. Maybe the CLR does it internally.

回复收藏 0 原文

送舟行 2024-12-24 13:26:28

许多糟糕的想法都进入了编程语言，因为没有语言设计者能够预测未来。人类创造的任何语言都会有缺陷。

一些示例：

Hejlsberg 希望 (原文：编程语言的 AZ：C# - 计算机世界）他向 C# 添加了不可为 null 的类引用。（我希望他也解决了 const 问题。）
C++ 委员会搞砸了 valarray 和导出，还有许多其他或大或小的遗憾。
Java 的模板是一个糟糕的工作（天哪，类型省略！），旨在避免更改 VM，当他们意识到 VM 无论如何都必须更改时，已经来不及进行必要的返工了。
Python 的作用域规则一直令人烦恼，无数改进它的尝试并没有真正起到多大作用（有一点，但不多）。