.net - 多线程调试技术

Question

我想知道是否有人知道对多线程应用程序的调试技术进行了很好的调查。理想情况下，我正在寻找基于案例的分析:死锁、饥饿、损坏的共享状态，......

.Net 特定的或通用的。

Answer 1

我不知道有一篇文章或书籍可以解决您正在寻找的内容，因此这是我从 12 年的 Windows(非托管和托管)多线程调试中获得的“经验教训”。

正如我在评论中所说，我的大部分“多线程调试”实际上是通过手动代码审查完成的，寻找这些问题。

死锁和损坏的共享状态

文件 lock hierarchies (它们保护的顺序和共享状态)，并确保它们是一致的。这解决了大多数死锁问题和损坏的共享状态问题。

(注意:上面的“锁层次结构”链接指的是 Herb Sutter 的 Dobbs 博士的文章；他写了一系列我强烈推荐的 Effective Concurrency 文章)。

更多关于死锁

使用RAII for all synchronization .这确保了在遇到异常时释放锁。更喜欢“锁定”语句来尝试/最终。

(请注意，.NET 中的 RAII 取决于 IDisposable，而不是 Finalize，并假设客户端代码将正确使用 using block )。

饥饿

删除线程优先级的任何修改。正确的优先级实际上有点反直觉:最好给工作最多的线程做较低的优先级，而给 I/O 绑定(bind)的线程(包括 UI 线程)较高的优先级。由于 Windows 会自动执行此操作(请参阅 Windows Internals )，因此根本没有理由让代码参与其中。

一般

删除所有内部编写的无锁代码。它几乎肯定包含细微的错误。将其替换为 .NET 4 lock-free collections和 synchronization objects ，或将代码更改为基于锁的。

使用更高级别的概念进行同步。 Task Parallel Library和 unified cancellation在 .NET 4 中，几乎不需要直接使用 ManualResetEvent , Monitor , Semaphore ， ETC。

使用更高级别的概念进行并行化。 TPL and PLINQ在 .NET 4 中具有内置的自平衡算法，具有智能分区和工作窃取队列，可自动提供最佳并行化。对于自动并行化次优的少数罕见情况，TPL 和 PLINQ 都公开了大量可调整的旋钮(自定义分区方案、长时间运行的操作标志等)。

我发现还有一种技术对任何其方法被不同线程调用的类很有用:记录哪些方法在哪些线程上运行。通常，这会作为注释添加到方法的顶部。确保每个方法仅在已知线程上下文中运行(例如，“在 UI 线程上”或“在 ThreadPool 线程上”或“在专用后台线程上”)。除非您正在编写同步类，否则任何方法都不应该说“在任何线程上”(如果您正在编写同步类，请问问自己是否真的应该这样做)。

最后，命名你的线程。这有助于在使用 VS 调试器时轻松区分它们。 .NET 通过 Thread.Name 支持此功能属性(property)。