用于查找竞争条件/死锁的 C#/.NET 分析工具答案

【问题标题】：C#/.NET analysis tool to find race conditions/deadlocks用于查找竞争条件/死锁的 C#/.NET 分析工具
【发布时间】：2011-01-23 16:33:39
【问题描述】：

是否有分析 .NET 代码并查找竞争条件的工具？

我有一段代码有一个公共静态属性，可以获取或创建一个私有静态字段。它还有一个公共静态方法，可将此字段设置为 null（...是的，我知道！..）

由于这两种方法中的任何一种都没有锁定，因此可以肯定的是，将来事情会变得非常糟糕。我需要一个工具，它可以递归地遍历调用这些方法中的任何一个，并查看是否在另一个线程上产生了任何东西。

我正在寻找一个工具或者可能是一个 nDepend SQL 脚本（如果可能的话）。

【问题讨论】：

【解决方案1】：

您可能想查看CHESS。

【讨论】：

【解决方案2】：

您可能正在寻找其中之一：

注意：此答案来自 2010 年。与所有建议答案一样，建议往往会随着时间而变化。现在可能还有其他产品，微软研究实验室项目的 CHESS 可能已经演变成最终产品或完全废弃。请对这个答案持保留态度，并对现在适合哪些产品进行新的研究。

【讨论】：

感谢 Lasse，我听说过 CHESS，但没有听说过 TypeMock Racer。我真的在寻找一种对代码进行静态分析的工具。我正在使用 ReSharper 5，它有一个很好的功能，可以检查代码并显示特定方法的所有调用者并递归地深入研究它们。我需要的是将方法标记为在工作线程上实例化的东西。我将更多地研究 CQL 方法，因为我知道有一个上游调用者脚本，所以我确信有一种方法可以找出是否有任何方法是线程调用调用的结果。
这个fork of chess 似乎是最新的并且工作正常。

【解决方案3】：

Jinx 将在运行时（不是静态地）执行此操作，但可能值得一看。

【讨论】：

不错。运行时分析远远优于对并发问题的静态分析。静态分析仪的运行时约定太多，无法产生良好的信噪比。
看起来 Jinx 是吐司。
维基百科：Jinx 是一种并发调试器，可确定性地控制跨处理器内核的工作负载交错，专注于共享内存交互。使用这种确定性方法，Jinx 旨在增加难以捉摸的共享内存错误（有时称为 Heisenbugs）的发生频率。 Jinx 不再可用。开发 Jinx 的公司 Corensic 被 F5 Networks 收购，Jinx 项目被取消。

【解决方案4】：

你看过Red-Gate Ants吗？我不确定它是否能满足您的所有需求，但它是一个很好的产品：

【讨论】：

【解决方案5】：

在此处查看答案：What static analysis tools are available for C#?

一些静态分析工具可以进行死锁检测。

另外，试试微软的FxCop。

【讨论】：

【解决方案6】：

我一直在尝试如何轻松跟踪这些内容。我一直在努力跟踪一些死锁，特别是在使用许多不同锁语句的情况下。

我的目标是在死锁发生之前检测它们，例如如果您有两个资源，您知道您必须始终以相同的顺序使用它们，否则可能会出现死锁。

lock (lockObj1) 
lock (lockObj2) 
{ 
    // some code
}

...应用程序中的其他位置...

lock (lockObj2) 
lock (lockObj1) // <- I expect some "possible deadlock" detection here 
{ 
    // some code
}

在这种情况下，我在一个地方使用 lockObj1 然后 lockObj2 并在另一个地方以相反的顺序使用它们，这是您希望在应用程序中避免的事情当然，lock 语句不需要像示例中那样一个接一个地使用，您的复杂应用程序可能有多个复杂对象相互交互

我在这里上传了带有测试用例的代码 https://github.com/glmnet/LockTracer

【讨论】：

这是一个非常有趣的想法。受您的代码启发，我写了一些类似的东西，为每个锁分配一个“优先级编号”，然后检查每当我获得多个锁时，我是否按“优先级顺序”获得它们。果然，这立即表明我的程序中有一个地方违反了我自己关于锁获取顺序的规则，并修复了我的死锁漏洞。
这看起来更简单，但很有效！可以分享到 GitHub 上吗？如果您没有投票，请不要忘记投票。谢谢！