我有一个程序可以生成线程 (~5-150) 来执行一堆任务。最初，我使用FixedThreadPool，因为this similar question 建议它们更适合寿命更长的任务，并且由于我对多线程的了解非常有限，我认为线程的平均寿命（几分钟）“寿命长 em>”。
但是，我最近添加了生成额外线程的功能，这样做使我超出了我设置的线程限制。在这种情况下，最好是猜测并增加我可以允许的线程数还是切换到CachedThreadPool 这样我就不会浪费线程了？
初步试用它们，似乎没有区别，所以我倾向于使用CachedThreadPool，以避免浪费。但是，线程的寿命是否意味着我应该选择FixedThreadPool 并只处理未使用的线程？ This question 让人觉得这些额外的线程并没有被浪费，但我希望能得到澄清。
【问题讨论】：
标签： java multithreading threadpool executorservice java.util.concurrent
CachedThreadPool 似乎适合您的情况，因为直接将其用于长时间运行的线程不会产生负面影响。 java 文档中关于 CachedThreadPools 适用于短任务的评论只是表明它们特别适用于这种情况，而不是它们不能用于长时间运行的任务。
CachedThreadPool 的主要问题是它会创建多达Integer.MAX_VALUE 个线程，因为如果缓存中不存在未使用的线程，它总是会生成一个新线程。因此，如果您有长时间运行的任务，那么您更有可能增加并发线程的数量超过您的预期，因为这种类型的线程池不会限制有多少并发执行本身。如上所述，对于您的用例而言，这似乎不是问题，但需要注意。
为了进一步详细说明 CachedThreadPool 和 FixedThreadPool 之间的区别，Executors.newCachedThreadPool 和 Executors.newFixedThreadPool 都通过 @987654328 的实例由相同的线程池实现（至少在开放的 JDK 中）支持@，只是参数不同。区别只是它们的线程最小值、最大值、线程终止时间和队列类型。
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
FixedThreadPool 确实有其优势，当您实际上想要使用固定数量的线程时，您可以将任意数量的任务提交给执行器服务，同时知道线程数将保持在您指定的级别。如果您明确想要增加线程数，那么这不是合适的选择。
然而，这确实意味着CachedThreadPool 可能遇到的一个问题是关于限制并发运行的线程数。 CachedThreadPool 不会为您限制它们，因此您可能需要编写自己的代码以确保不会运行太多线程，您可以通过使用所需的行为特征实例化自己的 ThreadPoolExecutor 来相对轻松地做到这一点。这实际上取决于您的应用程序的设计以及如何将任务提交给执行器服务。
【讨论】：
ThreadPoolExecutor，比如ThreadPoolExecutor(0, maximumPoolSize, 60L, TimeUnit.SECONDS, SynchronousQueue())？
FixedThreadPool 和 CachedThreadPool 在高负载应用程序中都是邪恶的。
CachedThreadPool 比FixedThreadPool 更危险
如果您的应用程序负载高且需要低延迟，最好摆脱这两种选择，因为有以下缺点
CachedThreadPool 无法控制线程创建既然你知道两者都是邪恶的，那么较小的邪恶就没有任何好处。首选ThreadPoolExecutor，它提供对许多参数的精细控制。
beforeExecute(Thread, Runnable) 和 afterExecute(Runnable, Throwable)
【讨论】：
所以我有一个程序可以生成线程（~5-150）来执行一堆任务。
您确定您了解您选择的操作系统和硬件实际上是如何处理线程的吗？ Java 如何将线程映射到 OS 线程，如何将线程映射到 CPU 线程等？我问是因为在一个 JRE 中创建 150 个线程只有在下面有大量 CPU 内核/线程时才有意义，而这很可能不是这种情况。根据所使用的操作系统和 RAM，创建超过 n 个线程甚至可能导致 JRE 由于 OOM 错误而终止。所以你应该真正区分线程和这些线程要做的工作，你甚至能够处理多少工作等等。
这就是 CachedThreadPool 的问题：在实际上无法运行的线程中排队长时间运行的工作是没有意义的，因为您只有 2 个 CPU 内核能够处理这些线程。如果最终有 150 个调度线程，则可能会为 Java 和操作系统中使用的调度程序同时处理它们创建大量不必要的开销。如果您只有 2 个 CPU 内核，这根本是不可能的，除非您的线程一直在等待 I/O 等。但即使在那种情况下，很多线程也会创建大量 I/O...
FixedThreadPool 不会出现这个问题，它是用例如创建的。 2+n 个线程，其中 n 当然是合理的低，因为使用硬件和操作系统资源，管理无论如何都无法运行的线程的开销要少得多。
【讨论】：