这个问题是关于使用 SingleThreadExecutor (JDK 1.6) 的后果。相关问题之前已在本论坛中提出并回答过，但我相信我面临的情况有点不同。
应用程序的各个组件(我们称之为组件 C1、C2、C3 等)生成(出站)消息，主要是为了响应从其他组件接收的消息(入站)。这些出站消息保存在通常是 ArrayBlockingQueue 实例的队列中 - 也许是相当标准的做法。但是，出站消息必须按照添加顺序处理。我想使用 SingleThreadExector 是这里显而易见的答案。我们最终会遇到 1:1 的情况 - 一个 SingleThreadExecutor 对应 一个 队列(专用于从 一个 组件发出的消息)。
现在，在给定时刻组件的数量(C1、C2、C3...)是未知的。它们将根据用户的需要而存在(并且最终也会被丢弃)。我们讨论的是峰值负载时有 200-300 个这样的组件。按照上述 1:1 设计原则，我们将安排 200 个 SingleThreadExecutor。这是我在这里查询的来源。
我对必须创建这么多 SingleThreadExecutor 的想法感到不舒服。我宁愿尝试使用 SingleThreadExecutor 池，如果这有意义并且合理的话(任何现成的、之前见过的类/模式？)。我在这里阅读了许多关于建议使用 SingleThreadExecutor 的文章，但是相同的池怎么样？
这里有学识的女性和男性怎么想？我希望得到指导、纠正或简单的警告:-)。
最佳答案
如果您的要求是按照消息发布的顺序处理消息，那么您只需要一个 SingleThreadExecutor。如果您有多个执行程序，则消息将在执行程序集中无序处理。
如果消息只需按照单个生产者接收消息的顺序进行处理，那么每个生产者有一个执行器是有意义的。如果您尝试池化执行器，那么您将不得不投入大量工作来确保生产者和执行器之间的亲和性。
由于您表明您的生产者将定义生命周期，因此您必须确保的一件事是在执行程序完成后正确关闭它们。
关于java - 给定应用程序的多个 SingleThreadExecutor...是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1943788/