.NET 4.0 中的多线程和性能

Question

我一直在玩弄 .NET 4.0 中的 Parallel 库。最近，我为我们的大型系统之一必须使用的一些不寻常的读/写操作开发了一个自定义 ORM。这允许我用属性装饰一个对象，并通过反射找出它必须从数据库中提取哪些列，以及它必须在写入时输出哪些 XML。

因为我设想这个包装器可以在许多项目中重用，所以我想尽可能地加快速度。该库主要用于 .NET Web 应用程序。我正在使用一次性控制台应用程序测试框架，以查看我创建的类。

我现在已经吸取了多线程带来的开销的教训。多线程会导致它运行得更慢。从阅读中，对于已经做了很长时间的人来说似乎很直观，但对我来说实际上是违反直觉的:如何将方法运行 30 次 同时比顺序运行 30 次要慢吗？

我认为我不会因为多个线程不得不争夺同一个共享对象而引起问题(尽管我还不够擅长它还不能确定)，所以我认为减速来自开销产生所有这些线程和运行时使它们保持正常。所以:

虽然我主要是作为一个学习练习来做的，但这是悲观吗？对于琐碎的非 IO 任务，多线程是否过大？我的主要目标是速度，而不是 UI 或任何东西的响应能力。

由于线程池中已经创建了线程，在 IIS 中运行相同的多线程代码会导致它加速，而现在我正在使用控制台应用程序，我假设它是单线程的，直到我另有说明？我即将进行一些测试，但我认为我缺少一些基础知识为什么这将是一种或另一种方式。我的控制台应用程序也在我的桌面上运行，具有两个内核，而用于 Web 应用程序的服务器会有更多内核，因此我可能也必须将其用作变量。

Answer 1

线程实际上并非全部同时运行。

在台式机上，我假设您有一个双核 CPU(最多可能是四核)。这意味着只能同时运行 2/4 个线程。

如果您产生了 30 个线程，操作系统将不得不在这 30 个线程之间进行上下文切换以保持它们全部运行。上下文切换非常昂贵，因此速度放缓。

作为一个基本建议，如果您尝试优化计算，我的目标是每个 CPU 1 个线程。除此之外，您并没有真正做任何额外的工作，您只是在同一个 CPU 上交换线程。试着把你的电脑想象成里面有有限数量的 worker ，你不能同时做比你可用的 worker 数量更多的工作。

.net 4.0 并行任务库中的一些新功能允许您执行考虑线程数量可伸缩性的操作。例如，您可以创建一堆任务，任务并行库将在内部计算出您有多少可用 CPU，并优化创建/使用的线程数以免 CPU 过载，因此您可以创建 30 个任务，但在双核机器上，TP 库仍然只会创建 2 个线程，并将 .显然，当您在更大的机器上运行它时，它会很好地扩展。或者你可以使用类似 ThreadPool.QueueUserWorkItem(...)将一堆任务排队，池将自动管理用于执行这些任务的线程数。

是的，线程创建有很多开销，但是如果您使用 .net 线程池(或 4.0 中的并行任务库)，.net 将管理您的线程创建，您实际上可能会发现它创建的线程少于您创建的任务数。它将在可用线程上内部交换您的任务。如果您确实想控制实际线程的显式创建，则需要使用 Thread 类。

[一些 cpu 可以用线程做一些聪明的事情，每个 CPU 可以运行多个线程 - 见 hyperthreading - 但请查看您的任务管理器，如果您在今天的桌面上拥有超过 4-8 个虚拟 CPU，我会感到非常惊讶]