Question

我正在研究一个java应用程序。我们正在使用Spring，应用程序运行WebSphere应用程序服务器。在整个应用程序中，我们使用Spring维护在应用程序中创建的多个线程池。如下所示，到目前为止，我们对此没有任何问题。

<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
        <property name="maxPoolSize" value="100"/>
        <property name="corePoolSize" value="10"/>
</bean>

但我正在阅读Spring框架参考文档，其中我看到了以下段落，

34.3.3 TaskScheduler实施

与Spring的TaskExecutor抽象一样，主要的好处是   TaskScheduler是不依赖于调度行为的代码   耦合到特定的调度程序实现。这种灵活性   在Application中运行时，提供特别相关   不应直接创建线程的服务器环境   应用程序本身。对于这种情况，Spring提供了一个   委托给CommonJ TimerManager的TimerManagerTaskScheduler   实例，通常配置有JNDI查找。

REF。   https://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html

所以我的问题是，如果我不关心访问Java EE上下文信息，还有其他什么原因可以使用托管线程池？我基本上想知道什么是最好的做法，如果有应用程序管理线程是完全不可接受的。

Answer 1

通常，WebSphere等企业服务器上的线程池（以及JDBC连接）不应由应用程序管理，而应由服务器本身管理。 Spring仅在应用程序和服务器的线程池模型之间提供接口。

在服务器端配置线程池的主要好处是效率：在过去，通常会将多个应用程序部署到同一服务器。使用共享线程池，可以利用服务器的所有资源。如今，在同一个Java服务器上保留多个应用程序被认为是不好的做法（根据微服务架构）。因此，只需将此类线程池视为传统技术堆栈的一部分。

Java应用程序线程创建

1 个答案: