Javaアプリケーションスレッドの作成

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フレームワークリファレンスドキュメント、SpringののTaskExecutor抽象化の主な利点と同様に

34.3.3 TaskScheduler実装

を読んでいました TaskSchedulerは、スケジューリング動作に依存するコードが特定のスケジューラの実装に結合された である必要はないということです。この の柔軟性は、アプリケーション内で実行する場合に特に関係します アプリケーション自体によって によってスレッドが直接作成されるべきでないサーバー環境。そのような場合、SpringはCommonY TimerManager インスタンスに委譲するTimerManagerTaskSchedulerを提供します。通常はJNDIルックアップで構成されます。

ref。私は、Java EEコンテキスト情報にアクセスすることを気にしない場合 https://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html

ので、私の質問は、マネージスレッドプールを使用するために、他のどのような理由があり、あるのでしょうか？ 私は基本的に、そこにあるベストプラクティスと、アプリケーション管理のスレッドが全く受け入れられないと思っています。

Answer 1

通常、WebSphereなどのエンタープライズ・サーバー上のスレッド・プール（およびJDBC接続）は、アプリケーションによって管理されるのではなく、サーバー自体によって管理される必要があります。 Springは、アプリケーションとサーバーのスレッドプールモデルの間のインターフェイスのみを提供します。

サーバー側でスレッドプールを構成する主な利点は、効率的です。古いアプリケーションでは、通常、複数のアプリケーションが同じサーバーに展開されていました。共有スレッドプールでは、サーバのすべてのリソースを利用することができます。今日、いくつかのアプリケーションを同じJavaサーバーに保つことは、（マイクロサービスアーキテクチャの観点から）悪い習慣とみなされています。そのようなスレッドプールは、従来の技術スタックの一部として考えてください。