在哪种情况下我应该使用不同的.NET线程方法？

概述我一直在研究处理多线程.NET应用程序的不同方法.它变得有点混乱. 新主题 – >当需要一个额外的线程？ ThreadPool – >当你需要多个线程时.使用现有线程并将优化(基于所涉及的工作的数量)留给框架更便宜. 任务 – >当你想要一个额外的线程,并且你碰巧使用.net 4.0或更高版本.这是新线程的API吗？ Parallel.for – >当您有多个任务并希望框架处理优化时,根据CPU核 我一直在研究处理多线程.NET应用程序的不同方法.它变得有点混乱.

新主题 – >当需要一个额外的线程？

ThreadPool – >当你需要多个线程时.使用现有线程并将优化(基于所涉及的工作的数量)留给框架更便宜.

任务 – >当你想要一个额外的线程,并且你碰巧使用.net 4.0或更高版本.这是新线程的API吗？

Parallel.for – >当您有多个任务并希望框架处理优化时,根据cpu核心数分配不同任务的工作.

在MSDN上,它没有声明新的Thread方法已经过时了？

解决方法 您对Threads和ThreadPool使用的基本了解或多或少都是正确的.然而,任务有点复杂.

线程,ThreadPool,任务

首先,Task简单地表示异步 *** 作.它可以在ThreadPool线程上执行(如果您是调度任务的那个,那么通常它会在大多数情况下使用TaskScheduler.Default).它也可以在单独的非线程池线程上执行(当您指定TaskCreationoptions.LongRunning时).它甚至可以在没有线程的情况下执行(想想异步IO *** 作：http://blog.stephencleary.com/2013/11/there-is-no-thread.html).最后,当Task封装多个异步 *** 作时,它可以是上述任何一个的组合.

最终,Task在Thread和ThreadPool上添加了一个抽象层(它在适当时在内部使用,并且在您安排任务时可以对其进行一定程度的控制).在三种线程方法中,由于围绕它构建了语言支持,Task可能应该是您的首选武器.与使用低级线程工具执行相同 *** 作相比,使用Task编写异步 *** 作序列是一件轻而易举的事.

然而,这并不意味着Thread和ThreadPool真的过时 – 仅仅是因为它们不应该是你开发新开发的第一步.撇开它们即使在使用Task时仍被框架使用的事实,请考虑使用Thread或ThreadPool的全功能生产代码的数量,以及在这些类型中的任何一种情况下会发生什么标有ObsoleteAttribute.这将是一个烂摊子.

当然也有其他原因使用它们,即对性能非常敏感的场景(我确信还有更多,但这就是我现在所能想到的).

使用Task调度工作

在安排新任务时,您对何时使用ThreadPool或新线程的考虑仍然适用.这里的指导很简单：

>如果期望任务连续运行(运行整个运行过程的任务将是一个很好的例子),最好在启动时指定TaskCreationoptions.LongRunning标志.这类似于启动新线程.
>如果您想要异步执行某些有限的cpu限制工作,请通过Task.Run将其推送到ThreadPool(它使用默认任务调度程序,恰好是当前实现中的ThreadPoolTask​​Scheduler).这类似于使用ThreadPool.QueueUserWorkItem(WaitCallback).
>如果您的任务大部分时间都在执行异步IO,那么您实际上并不需要担心它的执行位置.

平行

现在让我们来谈谈Parallel类及其成员.首先,你有Parallel.Invoke,这大致相当于并行启动一堆任务,然后在完成时阻塞.这在您处理要并行运行的多个阻塞 *** 作时才非常有用.如果这是你的情况,你不想搞乱多个Task实例,请使用它.

Parallel.For和Parallel.ForEach是一个稍微不同的野兽,主要用于并行处理集合元素的cpu绑定工作(由于它们内置的“负载平衡”工作方式,将它们用于IO工作不是一个好主意,最终产生太多线程,除非你限制并行度).这些方法在概念上与Thread,ThreadPool和Task不同,并且更接近PliNQ.在平行化收集元素处理导致可测量的性能提升的情况下,将它们用于通常使用for或foreach循环的位置.

总结

以上是内存溢出为你收集整理的在哪种情况下我应该使用不同的.NET线程方法？全部内容，希望文章能够帮你解决在哪种情况下我应该使用不同的.NET线程方法？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。