可动态调整大小的线程池

Question

我的应用程序中有如下工作流：可以有X个用户请求（通常同时有5-10个），他们希望在系统中搜索某些东西（每个请求在单独的线程中处理）。

每个搜索都可以并行处理（我目前正在实现）。线程/CPU使用实际上不是这里的问题，因为这些任务不需要占用CPU。数据库是瓶颈。

目前，我只为搜索机制设置了一个单独的DB连接池-最大池大小设置为10。我知道这不多，但我不能把它设置得更高。现在我试图弄清楚如何为每个搜索（每个用户）设置线程池。

每个请求（线程）将产生一个单独的线程池（在这个池中，每个线程将处理给定用户搜索的一部分）。如果有10个用户同时点击“Search”按钮，那么将线程池的大小设置为固定的大小（比方说4个）真的会有问题吗？因为它会生成10个线程池，其中4个线程每个=40个线程，并且池中只有10个db连接？我猜有些线程将会是空闲的，而其余的线程将会为池争相获得连接，但这真的会是一个巨大的问题吗？

如果是，那么最好的行动方针是什么：

1. 在创建一个新的线程池时检查已经有多少个线程池，并相应地调整它（这个新池的）最大线程池大小（假设已经有2个池，每个池有4个线程，那么创建新的线程池时，将最大线程设置为2，甚至更新的线程池，假设只有1个最大线程）。这意味着每个下一个用户的搜索速度将大大降低。
2. 创建具有相同最大线程池大小（即4个）的线程池，但实现我自己的线程池，它将动态检查应用程序中有多少个线程，并相应地调整maxThreadPoolSize的大小（例如，在本例中，所有线程池（两个旧线程池和一个新线程池）将被缩小为3个线程）。这将要求每个线程池访问某个包含应用程序中所有线程池信息的共享对象。
3. 其他吗？

编辑：感谢所有的评论/回答。为了澄清为什么我希望每个请求都有一个线程池--这样做是为了一个用户不会用完整个线程池。流程是这样的：当用户点击“搜索”时，会生成一个对象列表（该列表可以从1个项目到数千个项目不等），然后对每个项目执行DB查找。现在全部按顺序执行。更改后，每个任务都处理一次查找（因为在DB上的搜索非常慢，这给了我很大的帮助--我知道我可以尝试做一些DB微调，但我不负责）。

问题是，如果我User1来并对X,000个生成的项目执行真正通用的搜索，它可能需要几分钟（或更长时间）。因此我可以在执行器中拥有来自单个用户的数千个任务。然后，如果我有一个共享线程池，假设最多有10个线程（与连接池的数量相同），那么这个请求将被放入线程池的队列中。现在，如果User2来执行他的搜索，他将不得不等待user1的搜索完成，因为他的搜索将被放入相同的队列中。这是我希望在使用每个请求的线程池时避免的情况。

我并不是真的那么害怕上下文切换，因为每次计算都需要几秒钟的时间，所以它们不会经常发生。

目前，我正在考虑一个共享线程池和一个管理器，每个用户线程都将其数据发送到该管理器，然后每当有空闲线程时，该管理器将其发送到线程池。通过这种方式，我可以实现它（manager）来发送来自不同用户的任务（即，没有一个用户不支配线程池）。

我认为这种方法的问题是，我需要以某种方式通知“父线程”（意味着用户请求）它的所有任务都由manager处理，并以某种方式将结果发送给它。

Answer 1

现代处理器能够轻松地处理数百个线程，没有任何问题，但是正如@PeterLawrey所指出的，您的设计有些奇怪。如您所说，如果操作在计算上并不昂贵，那么具有非常高数量的线程将导致大量昂贵的上下文切换，从而导致性能下降。

额外的复杂性来自这样一个事实,即您希望为每个请求拥有一个线程池,而连接池是每个应用程序的：

• 如果每个请求都有一个线程池，则必须创建它，并在每次获得新请求时销毁它
• 无论您将拥有几万亿的线程和10万美元预算的超级计算机，都不会有超过10个线程在做有用的工作。

现在，您的直觉告诉我们，问题是您希望每个请求都有一个线程池，而理想的解决方案是在请求之间有一个共享的线程池，线程数等于您的连接池大小。这将最大化线程重用。

如果您还想避免一个请求占用您的全部计算能力，您可能希望添加一个层来决定谁有权安排额外的工作。对于每个请求的线程池解决方案，您正在考虑让调度程序为您做这件事，这不是一个好主意，因为您不控制算法。

相反，您可以实现自己的“公平算法”，例如通过PriorityBlockingQueue（其中chunck数较低的项会排到顶部），或者通过ConcurrentHashMap（其中为每个用户存储要调度的作业列表和已经返回的作业列表）等等。