在 Java 中为线程池提供单独的微服务是否有意义？答案

【问题标题】：Does it make sense to have a separate microservice for thread pool in Java?在 Java 中为线程池提供单独的微服务是否有意义？
【发布时间】：2025-12-03 05:05:01
【问题描述】：

我想知道您是否可以帮助我解决这个问题，拥有一个单独的微服务来负责管理线程、特定应用程序的线程池是否有意义？此微服务管理的线程必须在其他应用程序代码中执行。..

所以这意味着线程池微服务存在于不同的 JVM 中，而应用程序代码存在于另一个 JVM 中？

这意味着更多线程由 JVM 1 创建并在 JVM 2 中为不同的应用程序执行..

谢谢。

【问题讨论】：

一个线程不能由一个JVM创建，然后由另一个JVM执行。线程是一个固有的本地概念，而不是分布式的东西。所以我倾向于说“不，这没有意义”。您的用例是什么？为什么要远程进程为本地进程创建线程？
感谢您的回答，我们有一个单体应用程序，目前无法分离到不同的微服务，在这个应用程序中，我们有许多类，每个类都有自己的线程管理/池，所以我想知道如果我们可以将它们分组到一个池中，在应用程序资源之外进行管理。
在规划如何将大型应用拆分为更小的微服务时，您通常会尝试为不同的业务领域识别有界上下文，然后逐一提取服务。 “线程”不是业务问题，而是实现细节。您也不会将“多态性”提取到单独的服务器
说得好，不应该关心业务，那我只能选择将应用程序本身分解为不同的微服务，以便扩展。问题在于，处理现有的单体应用程序不同于从一开始就以正确的方式构建新事物。再次感谢您

标签： java microservices threadpool

【解决方案1】：

第一印象：坏主意。

不是硬性规定，但各个微服务应该解耦。

线程管理是操作系统的工作。因此，实际上，这个 Thread Manager 微服务将成为您架构的非官方操作系统。因此，这种架构将改为分层架构，线程管理器位于底层。

您的微服务应该在问题域中工作，这意味着它们应该获取一个输入单元（例如：购物清单）并返回一个输出单元（例如：从购物清单中购买的商品） .通过让微服务返回线程，你打破了抽象。

【讨论】：

完全有道理，差点忘了这个概念，就是我们应用程序中使用的线程数量很多，我想盲目提取它们而不考虑故事的抽象方面，感谢您回答。
您仍然可以在您的应用程序中集中线程管理，方法是创建一个处理应用程序线程管理的类/依赖项。这可以在不将其移动到远程微服务的情况下完成。（Java已经在这个方向提供了很多类，比如ExecutorService的实现）
好点，我的下一个问题是，它是每个类/类组一个线程池吗？还是 1 个线程池用于更大尺寸的所有内容？
这取决于您的要求和架构。没有涵盖所有情况的单一答案
@user1201957：正确答案需要测量。您可以从一个基本实现开始并围绕该实现运行测试，以查看它的运行情况以及是否存在任何热点或主要瓶颈。然后进行相应的调整。