线程过多 - 影响渲染性能

Question

我有一个应用程序，它从 Web 获取大量信息并将其显示在带有 WPF 的窗口中。信息获取当然是在几个后台线程中完成的；它们中的大多数不应该是非常密集的计算（除了一些文本解析），而是主要依赖于获取网络内容（webclient.Download.. 和类似的）。

因为我必须发送很多请求，所以我启动了很多线程，否则用户将不得不等待数小时才能完成加载所有内容；由于其中许多线程主要等待来自网络的数据和/或开始对 Web 服务的新请求，因此理论上这应该不是问题。然而，在实践中，调度程序的性能通常比没有线程运行时要差得多。

后台线程由 TPL 数据流管道和 Parallel.ForEach 方法的混合创建。我也已经尝试通过指定 MaxThreads 来限制线程的数量，但是由于任何数据流块都可以启动 Parallel.Foreach 块，我认为这不太好用。

有没有其他方法可以提高调度程序的优先级、性能或减少卡顿？

编辑：任务/线程的数量通常在 50-100 之间，在最坏的情况下可能会更多。 weblookup 的一个典型场景是：向 webservice 发送请求，解析响应（

Answer 1

考虑使用异步版本的下载函数，例如WebClient.DownloadDataTaskAsync，而不是启动一个新线程来下载数据。然后你不需要启动一个线程。只需调用

var result = await webClient.DownloadDataTaskAsync

并在await 之后处理结果。这将基本上启动下载操作并返回。下载完成后，将执行该方法的其余部分。最重要的是它不使用任何额外的线程。

Answer 2

由于没有代码示例，并且根据您帖子的语气，在我看来，您可以通过使用基于异步 IO 的模式完全节省使用 TPL Datablock 或 Parallel.ForEach 提供的线程的使用。

如果您的主要目标是下载网络内容，我会尝试基于 Task Asynchronous Pattern 的方法。例如，这是使用HttpClient

public async Task<string> DownloadWebContentAsync(string url)
{
    var client = new HttpClient();
    // Assuming a GET request
    var response = await client.GetAsStringAsync(url);

    // Do some string processing..

    return response;
}

现在，吃吧：

await DownloadWebContentAsync(url);

Answer 3

我不清楚你的后台线程不会像你说的那样造成太多的 CPU 负载。即使平均而言它们造成的负载很小，负载也可能会激增并导致卡顿。

尝试将后台工作放在优先级较低的TaskScheduler 上。 Parallel Extension Extras 有一个支持该功能的 TaskScheduler。

您多久更新一次用户界面？也许是太频繁了。限制更新频率。

我们到底在谈论多少个线程？如果数量达到数百个，请考虑使用异步 IO。异步 IO 操作在运行时不使用线程。甚至没有后台线程。