是否有 .Net StyleCop 规则警告 lock(this)、lock(typeof、lock(<string obj> 等？答案

【问题标题】：Is there a .Net StyleCop rule which warns about lock(this), lock(typeof, lock(<string obj>, etc.?是否有 .Net StyleCop 规则警告 lock(this)、lock(typeof、lock(<string obj> 等？
【发布时间】：2011-02-26 02:38:57
【问题描述】：

这 3 种类型的锁显然不好。还有什么其他类型的锁定不好？是否有 Stylecop / FxCop 规则可以捕捉到这一点？如果没有，那么您能帮我实现自定义规则吗？它们的所有代码都必须相似，对吧？

谢谢。

【问题讨论】：

StyleCop 只检查编码风格而不是行为。如果您需要为此制定规则，FxCop 就是解决此问题的工具。
愚蠢的问题：当我在 VS2010 中右键单击 C# 项目并选择“运行代码分析”时...是 FxCop 还是其他工具？另外：如果我想检测一个案例异常被重新抛出并且堆栈跟踪已被切断 - 这也是 FxCop 的工作吗？
奇怪，您一直在寻求无法胜过编辑器查找功能的工具。
:) Hans，工具的好处在团队环境中增加了 20 倍。
右键->代码分析就是FXCop，嗯，内置的FXCop。

标签： .net locking fxcop stylecop

【解决方案1】：

John Robbins 的Debugging Microsoft .NET Applications 书中的samples（您可能需要在浏览器中允许弹出窗口）包含此类 FxCop 规则（DoNotLockOnPublicFields、DoNotLockOnThisOrMe、DoNotLockOnTypes 等）的来源。看起来它们最初是为 FxCop 1.35 制作的，而 VS 2008 中的版本和最新的独立版本是 1.36（更不用说 VS2010）。所以他们可能需要一些调整，YMMV。

还有一条规则CA2002（不要锁定具有弱标识的对象），它检查lock(typeof(...))之类的东西，但不检查lock(this)

【讨论】：

【解决方案2】：

基本上，您不应该锁定任何外部对象，除非这是一个专门的锁定对象（例如非泛型 ICollection 上的 SyncRoot 属性设计用于）。这样做会带来引用的其他“用户”也锁定它的风险，从而导致不必要的锁定甚至死锁。

显然，this 和 typeof() 是根据定义的外部对象。字符串是不可变的，字符串字面量都是 intern 的，因此即使您直接在对象中分配了相同的引用，它也可以在不同的地方处于 unse 状态。

我不知道针对这些情况的 StyleCop 规则，但我对 StyleCop 或 FxCop 可用的内容没有一个很好的概述，因此很可能有一些东西可以在野外检查这些情况。我只检查不是字符串且不直接在任何属性或方法中返回的私有成员的同步。

【讨论】：

顺便说一句，字符串是不可变的，但 CLR 也永远不会生成多个具有相同值的字面常量，例如：const string l1 = "lock"; 和 const string l2 = "lock"; 在 l1 和l2 都在 lock 语句中使用。
而且字符串甚至可以在 AppDomain 之间共享，进一步增加了死锁的机会。
很好，Steven ... .Net 的lock 功能似乎可以以一种对新手更友好的方式设计（事后看来）。我希望其他人能指出lock更常见的危险用法。