FixedThreadPool与CachedThreadPool：两害相权取其轻

Question

我有一个程序，它产生执行一系列任务的线程(~5-150)。最初，我使用fixedthreadpool，因为这个类似的问题表明它们更适合更长时间的任务，而且由于我对多线程的知识非常有限，我认为线程的平均寿命（几分钟）是“长寿命”的。

但是，我最近添加了生成额外线程的功能，这样做使我超过了我设置的线程限制。在这种情况下，是猜测并增加我可以允许的线程数，还是切换到cachedthreadpool，这样就不会浪费线程？

初步尝试了这两种方法，似乎没有什么不同，所以我倾向于使用CachedThreadPool，以避免浪费。但是，线程的生命周期是否意味着我应该选择fixedthreadpool并只处理未使用的线程？这个问题使它似乎那些额外的线程没有浪费，但我希望澄清。

Answer 1

cachedthreadpool似乎适合您的情况，因为直接对长时间运行的线程使用cachedthreadpool不会产生负面影响。java文档中关于CachedThreadPools适合于短任务的注释只是表明它们特别适合于这种情况，而不是说它们不能用于长时间运行的任务。

cachedthreadpool的主要问题是，它将创建最多integer.max_value线程数，因为如果缓存中不存在未使用的线程，它将始终生成一个新线程。因此，如果您有长时间运行的任务，那么更有可能增加比您期望的更多的并发线程数量，因为这种类型的线程池本身不会限制并发执行的线程数量。正如所描述的，这对于您的用例来说似乎不是一个问题，但这是需要注意的。

为了进一步说明cachedthreadpool和fixedthreadpool之间的区别，executors.newcachedthreadpool和executors.newfixedthreadpool都通过threadpoolexecutor的实例由相同的线程池实现（至少在开放的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确实有它的优点，因为当您确实想要使用固定数量的线程时，您可以向executor服务提交任意数量的任务，同时知道线程数量将保持在您指定的级别。如果您显式地希望增加线程数，那么这不是合适的选择。

但是，这确实意味着CachedThreadPool可能遇到的一个问题是限制并发运行的线程数量。CachedThreadPool不会对它们进行限制，因此您可能需要编写自己的代码以确保不会运行太多线程，通过使用所需的行为特征实例化自己的ThreadPoolExecutor可以相对轻松地实现这一点。这实际上取决于应用程序的设计以及如何将任务提交给executor服务。