使用线程池有什么缺点吗?

7

我知道线程池是一件好事情,因为它可以重复使用线程,从而节省创建新线程的成本。但我的问题是,使用线程池有没有缺点?在哪种情况下使用线程池不如仅使用单个线程?

7个回答

8
在什么情况下使用线程池不如使用单个线程更好?
我只能想到一种情况,那就是当您有一个单线程仅需要在程序的生命周期内执行单个任务时。例如,与永久缓存相关的后台线程。那大概是我直接派生线程而不使用 ExecutorService 的唯一时候了。即使这样,使用 Executor.newSingleThreadExecutor() 也可以。线程池本身的开销可能是一些逻辑和一些内存,但很难看到紧迫的缺点。
肯定在任何需要多个线程执行任务的情况下,都需要使用线程池。ExecutorService 代码所做的是减少您需要编写以管理线程的代码量。可读性和代码可维护性的改进是巨大的胜利。

5

Threadpool 只适合用于完成时间较短的操作。Threadpool 线程不适合进行长时间运行的操作,否则容易导致线程饥饿现象。

如果您需要一个特定优先级的线程,则 threadpool 线程不适合。

如果您有一些任务需要使线程长时间阻塞,则线程池中的大量被阻塞的线程可能会防止任务启动,因为线程池有最大线程数的限制。


4
你得到了许多不同的答案。我认为其中一个原因是问题不完整。你正在问“使用线程池的缺点”,但你没有说相比于什么的缺点?
线程池解决了一个特定的问题。还有其他一些问题,其中“线程”是解决方案的一部分,但“线程池”不是。当问题是如何在多处理器系统上实现许多短暂的CPU密集型任务的并行执行时,“线程池”通常是答案。
即使在单处理器上,线程也有其他用途。例如,对于任何长时间运行的线程,我首先问的问题是“它等待什么”。线程是组织必须等待不同类型事件的程序的优秀工具。但你不会用线程池来做这件事。

2

除了Gray的回答之外。

另一个用例是,如果您正在使用线程本地变量或将线程用作某种哈希表或有状态自定义线程实现的键。在这种情况下,即使任务失败,您也必须关心在特定任务使用线程时清除状态。否则,可能会出现一些意外情况:下一个使用具有某些状态的线程的任务可能会开始运行错误。


2

如果在有限大小的线程池中运行的任务通过阻塞队列交换信息,那么这可能会导致线程饥饿:什么是饥饿?。一个好的规则是永远不要在线程池中运行的任务中使用阻塞操作。


1

如果您不打算停止使用线程,那么线程是更好的选择,例如在无限循环中。当执行许多不同时发生的任务时,线程池是最好的选择。特别是当任务很短时,使用相同线程的开销和清晰度更大。


0

这取决于您要如何利用线程池。例如,如果您的系统不需要并行执行任务,则线程池将毫无用处。它会保持准备好永远不会到来的工作的不必要的线程。在这种情况下,您仍然可以使用SingleThreadExecutor。如果您还没有,请查看此链接,它可能会为您澄清:线程池模式


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接