动态重新大小的线程池

Question

我的应用程序中有以下工作流:用户(通常是5-10个同时)需要搜索系统中的内容(每个请求在一个单独的线程中处理)可以发出X个请求。

每个搜索都可以并行处理(我目前正在实现)。线程/ CPU的使用并不是真正的问题，因为这些任务不是CPU密集型的。数据库是瓶颈。

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

每个请求(线程)将产生一个单独的线程池(在这个池中，每个线程将处理给定用户搜索的一部分)。如果10个用户同时按下"search“按钮，那么将这个线程池的大小设置为固定大小(例如4)是否真的是个问题，因为它会生成10个线程池，每个线程=40个线程，池中只有10个db连接？我想有些线程可能只是空闲的，其余的线程会争相获得池的连接，但这真的是一个大问题吗？

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

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

编辑：谢谢你所有的评论/答案。为了说明为什么我希望每个请求都有一个线程池--这样一个用户就不会耗尽整个线程池。流程完全是这样的:当用户点击“搜索”时，会生成一个对象列表(这个列表可以从1项到数千项不等)，然后对每个项执行DB查找。现在这一切都是按顺序执行的。在我的更改之后，每个任务都处理一个查找(因为DB上的搜索非常慢，这给了我很大的推动力--我知道我可以尝试做一些DB微调，但我不负责)。

问题是，如果我User1来执行一个真正通用的搜索X，000生成的项目，它可能需要几分钟(或更多)。这样，我就可以在执行器中从一个用户中得到数千个任务。然后，如果我有一个共享线程池，比如最多10个线程(与连接池相同的数目)，这个请求将被放入线程池的队列中。现在，如果User2来执行他的搜索，他将不得不等待User2 1的搜索完成，因为他的搜索将被放到相同的队列中。对于每个请求的线程池，我都希望避免这种情况。

我并不担心上下文切换，因为每一次计算都需要几秒钟的时间，所以它们不会经常发生。

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

我在这种方法中看到的问题是，我需要以某种方式通知“父线程”(即用户请求)，它的所有任务都由管理器处理，并以某种方式发送结果。

Answer 1

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

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

• 如果每个请求都有一个线程池，则必须在每次获得新请求时创建并销毁该线程池。
• 不管你有多少个有100000美元预算的线程和超级计算机，只有10个线程在做有用的工作。

现在，您的直觉应该告诉您，问题在于您希望为每个请求建立一个线程池，而理想的解决方案是在请求之间有一个共享线程池，其线程数等于您的连接池大小。这将最大限度地重新使用线程.

如果您还希望避免使用所有计算能力的单个请求，您可能需要添加一个层来决定谁有权安排额外的工作。对于每个请求解决方案中的线程池，您都在考虑让调度器为您执行这些操作，这不是一个好主意，因为您不控制算法。

相反，您可以实现您自己的“公平算法”--例如，通过一个PriorityBlockingQueue，其中具有较低数量的项到达顶部，或者使用一个ConcurrentHashMap，在它中为每个用户存储要调度的作业列表和已经返回的作业列表等等。