c# - 使用哪个 C# 多线程选项

Question

全部-

更多的方法问题。我有一个 Web 服务，我需要从客户端机器对其进行性能测试。所以本质上我正在编写一个快速的 WPF 多线程应用程序(其中有一个仪表/速度计)来直观地指示请求/响应时间。事件驱动——所以当我点击一个按钮时——应用程序将开始发出请求。我只关心请求/响应花费了多少时间，而不关心响应值本身(目前)。

这是我目前的思考过程:

1) 我需要创建尽可能多的线程(我的客户端机器可以处理)并测量性能。我可以考虑 2 个选项——创建一个新的线程机制(这样我就可以完全控制线程)或使用后台 worker 机制(这样我就可以将该值从后台处理传递回 UI)。假设 - 将必须循环遍历线程创建代码 - 因此可以继续为这两种方法创建多个线程。

2) 不需要任何进度报告，因此这不是选择多线程方法的标准

3) 确实需要一个回调方法——因为它应该传回值(请求/响应网络服务所花费的时间)

4) 当我用一个值更新变量时 - 将利用任何一种可用的同步方法。

5) 还没有真正使用 4.0 框架中的任务 API - 但这是我应该考虑的事情。

上述方法看起来不错——还是我遗漏了什么？

非常感谢任何帮助!!!

Answer 1

很多人都推荐了 Tasks，我认为这是个好主意。我自己也不介意使用裸线程，至于你应该使用哪一个，两者都可以。要警惕的主要事情是异常处理行为，这在两者之间有所不同。如果您在一个典型的线程中有一个未处理的异常，它会降低您的进程，所以您可能想要这样的东西(只是不要过于简单 ;)):

int errorCount = 0;

void Run()
{
    Thread t = new Thread(delegate()
    {
        try
        {
            // your code
        }
        catch (Exception )
        {
            Interlocked.Increment(ref errorCount);
        }
    });
}

另一方面，任务有一种更可控的方式来处理错误——它们将错误包裹在 AggregateException 中。当您调用 Task.Wait 函数时。

我正在特别考虑您的案例的异常(exception)情况，因为我假设您在压力测试期间最终会遇到超时错误。

Parallel.ForEach 可能也值得一看，但老实说，由于您正在尝试压力测试而不是真实场景，我可能会避免使用它来确定有多少线程我立即运行 - 我相信 PLINQ 的东西在客户端做了一些负载平衡。

回调方法对于所有这些方法来说都很容易。我只是使用方法调用，而不是传递回调，但这是一个实现细节。

我会远离 BackgroundWorker，因为它实际上是用于与 UI 相关的异步操作，并且在这个特定的上下文中可能有点臃肿。