c# - 分析/优化大量多线程应用程序

Question

我正在编写一个性能关键的 .NET 应用程序，它大量使用多线程。

使用 Visual Studio 性能分析器，具有独家示例的顶级函数是:

WaitHandle.WaitAny() - 14.23%

@JIT_MonReliableEnter@8 - 7.76%

Monitor.Enter - 5.09%

基本上，我的前 3 个函数都使用线程原语，并且我相信在某种程度上超出了我的控制范围。相比之下，我的工作/处理例程非常小，我正在努力提高性能。我相信所涉及的算法非常可靠，尽管我经常审查它们。

我的问题是:

• 如果在这些方法中有 14.23% 的 CPU 样本 - 对于大多数这些样本，CPU 是否有效地“空闲”，即只是在等待其他线程？或者线程等待的空闲部分是否未显示为配置文件跟踪的一部分[以及这 3 个中显示的 27.08% 是这些同步方法中所有开销的总和]？ (我猜这大部分是闲置的，但请在回答这个问题后提供一些不错的引用资料)
• 我已经检查了我的锁定方案，但是这些结果是否表明我应该研究一些特定的瓶颈或技术以进一步优化？
• 是WaitAny特别穷？我大量使用它来检查特定队列对象是否可读/可写，但同时也检查中止标志。有更好的方法吗？

Answer 1

当线程处于 WaitHandle.WaitAny 或 Monitor.Enter 时，您的 CPU 不一定空闲。处于等待状态的线程 是空闲的，但可能其他线程正忙于执行。 Monitor.Enter 尤其如此。如果一个线程被锁阻塞，那么人们会希望拥有该锁的线程正在执行代码而不是闲置。

此外，如果您的线程正在使用 WaitAny 从队列中读取数据，那么很可能队列中没有任何内容。这不是消费者代码的性能问题。这只是意味着生产者没有足够快地将东西放入队列。现在，这可能是因为生产者速度慢，或者因为数据传入速度不够快。

如果您处理数据的速度快于数据传入的速度，那么您似乎没有性能问题。当然不是在消费者方面。

就使用 WaitAny 进行排队而言，我建议您使用 BlockingCollection以及采用取消 token 的方法，例如 TryAdd(T, Int32, CancellationToken) .转换为取消 token 确实简化了我的多线程排队代码。