java - 为什么通过 newCachedThreadPool 创建的 ExecutorService 是邪恶的？

Question

保罗·泰玛 presentation有这一行:

Executors.newCacheThreadPool evil, die die die

为什么它是邪恶的？

我会大胆猜测:是不是因为线程数量会无限增长。因此，如果达到 JVM 的最大线程数，已被斜线标记的服务器可能会挂掉？

Answer 1

(这是保罗)

幻灯片的目的是(除了有滑稽的措辞)，正如您提到的，线程池在不受限制地创建新线程的情况下增长。

线程池本质上代表系统内的队列和工作传输点。也就是说，有些事情正在为它提供工作(并且它也可能正在为其他地方提供工作)。如果线程池开始增长，那是因为它跟不上需求。

一般来说，这很好，因为计算机资源是有限的，而且该队列是为处理突发工作而构建的。但是，该线程池无法让您控制是否能够插入瓶颈向前发展。

例如，在服务器场景中，一些线程可能正在接受套接字并将线程池交给客户端进行处理。如果那个线程池开始失去控制——系统应该停止接受新的客户端(事实上，“接受者”线程然后经常跳入线程池以帮助处理客户端)。

如果您使用具有无界输入队列的固定线程池，效果是相似的。每当您考虑队列填充失控的情况时 - 您就会意识到这个问题。

IIRC，Matt Welsh 开创性的 SEDA 服务器(异步)创建了线程池，线程池根据服务器特性修改其大小。

停止接受新客户的想法听起来很糟糕，直到您意识到替代方案是一个不处理任何客户的瘫痪系统。 (同样，理解计算机是有限的——即使是优化调整的系统也有限制)

顺便说一句，JVM 将线程限制为 16k(通常)或 32k，具体取决于 JVM。但是，如果您受 CPU 限制，则该限制不是很重要 - 在受 CPU 限制的系统上启动另一个线程会适得其反。

我很乐意以 4 或 5000 个线程运行系统。但接近 16k 限制时，即使不受 CPU 限制，事情也会陷入困境(JVM 强制执行此限制 - 我们在 linux C++ 中有更多线程)。