什么时候不应该在.Net中使用ThreadPool？

我应该什么时候不使用.NET中的线程池？

看起来最好的选择是使用ThreadPool,在这种情况下,为什么它不是唯一的选择？

你有什么经历？

1> Derek Park..：

---

@Eric,我将不得不同意Dean.线程很贵.你不能假设你的程序是唯一运行的程序.当每个人都对资源贪婪时,问题就会成倍增加.

我更喜欢手动创建我的线程并自己控制它们.它使代码非常容易理解.

在适当的时候这很好.但是,如果您需要一堆工作线程,那么您所做的就是让代码更复杂.现在你必须编写代码来管理它们.如果您刚刚使用了线程池,那么您将免费获得所有线程管理.并且语言提供的线程池很可能比你为自己滚动的更强大,更高效,更少错误.

Thread t = new Thread(new ThreadStart(DoSomething));  
t.Start();  
t.Join();  

我希望你通常会之间都存在一些额外的代码Start()和Join().否则,额外的线程是无用的,你无缘无故地浪费资源.

人们太害怕线程使用的资源.我从未见过创建和启动一个线程花费超过一毫秒.您可以创建的线程数没有硬性限制.RAM使用率极低.一旦你有几百个线程,由于上下文切换,CPU就成了一个问题,所以在这一点上你可能想要对你的设计感兴趣.

在现代硬件上,毫秒是很长一段时间.这是3GHz机器上的300万次循环.而且,你不是唯一一个创建线程的人.您的线程与每个其他程序的线程竞争CPU.如果你使用的线程不是太多,那么另一个程序也是如此,那么你就会使用过多的线程.

说真的,不要让生活变得比它需要的更复杂.除非您需要一些非常具体的东西,否则不要使用线程池.

确实.不要让生活变得更复杂.如果您的程序需要多个工作线程,请不要重新发明轮子.使用线程池.这就是为什么它在那里.你会推出自己的字符串类吗？

---

有些人在char的数组上滚动自己的包装,并像字符串一样使用..所以它可能......而且也很可悲.

2> 小智..：

---

我不想使用ThreadPool廉价多线程的唯一原因是我需要......

与运行方法相互影响(例如,杀死它)

在STA线程上运行代码(这发生在我身上)

我的应用程序死后(ThreadPool线程是后台线程)保持线程处于活动状态

以防我需要更改Thread的优先级.我们无法在ThreadPool中更改线程的优先级,默认情况下为Normal.

PS: MSDN文章"托管线程池"包含标题为"何时不使用线程池线程"的部分,其中包含一个非常相似但略微更完整的不使用线程池的可能原因列表.

你需要跳过它有很多原因ThreadPool,但是如果你不了解它们,那么它ThreadPool应该足够好了.

或者,看一下新的Parallel Extensions Framework,它里面有一些可以满足你需求而又不需要使用的东西ThreadPool.

---

@Mou:不幸的是,我说我不知道​​你想说什么.

3> Derek Park..：

---

只要有工作线程的概念,线程池就有意义.任何时候您都可以轻松地将处理分区为较小的作业,每个作业都可以独立处理,工作线程(以及线程池)是有意义的.

当您需要执行完全不同且不相关的操作的线程时,线程池没有意义,这些操作不能被视为"作业"; 例如,一个用于GUI事件处理的线程,另一个用于后端处理.处理形成管道时,线程池也没有意义.

基本上,如果你有启动,处理作业和退出的线程,那么线程池可能就是这样.否则,线程池实际上并没有帮助.

---

你能解释一下"处理形成管道时线程池没有意义"吗？假设我有工作项需要压缩,然后加密,压缩使用10倍的计算作为加密.为什么不使用压缩器与加密器线程比率为10:1的线程池？

---

线程池通常用于程序具有独立的,离散的工作要素.如果工作线程之间存在通信(例如在管道中),那么您实际上没有线程池方案.

4> Dogmang..：

---

对于quarrelsome的回答,我想补充一点,如果你需要保证你的线程立即开始工作,最好不要使用ThreadPool线程.每个appdomain限制运行的线程池线程的最大数量,因此如果它们都忙,您的工作可能需要等待.毕竟,它被称为"队列用户工作项".

当然有两点需要注意:

您可以在运行时更改代码中线程池线程的最大数量,因此没有什么可以阻止您检查当前与最大数量并在需要时提高最大数量.

旋转一个新的线程会带来自己的时间惩罚 - 是否值得你接受命中取决于你的情况.