クライアント要求をリスンするスレッドが10個あるTomcatサーバーがあるとします。応答に5秒かかるエンドポイントを呼び出すクライアントがある場合、そのクライアントはそのスレッドを5秒間保持します。いくつかの同時クライアントを追加すると、それらの5秒間にすぐにスレッドが使い果たされます。
これらの5秒間のほとんどのリクエストでほとんどI/Oが実行されているため、状況がさらに悪くなります。つまり、待機するだけでスレッドをブロックするだけです。
したがって、Callable、CompletableFuture、またはListenableFutureをコントローラの戻り値の型として使用するSpringの能力は、プログラマがこの種の問題をある程度まで克服できるようにすることです。
基本的に、これらのタイプのうちの1つを返すだけで、Webサーバスレッドが解放され、別のクライアントが使用できるようになります。同じ時間内に多くのクライアントに出席することになりますが、それだけでは非ブロッキングIO（別名NIO）APIを実装するには不十分かもしれません。
これらの機能のほとんどは、Servlet APIとServlet Async IOが提供するコア機能から来ています。これはSpringがおそらくボンネットの下で使用するはずです。
これらの動画は、サーブレットの背後にある考え方を説明する：あなたは私が地面からこれを理解する助け以下面白い動画を見てみたいことがあり非同期I/OとNIO Webアプリケーションの実装の最終的な目標です。
ここでは、スレッドプール内のスレッドが何らかのI/Oが発生するのを待ってブロックされることのないようにすることをお勧めします。彼らはいくつかのCPUバインド作業を行っているか、スレッドプールに戻ってきて、他のクライアントがそれらを使用することができます。 I/Oを実行するときは、待ってはいけません。結果がいつ出てくるかを知らせるコールバックを登録し、その間に貴重なCPUコアを使用して他の作業を行うことができます。それを考えると、Callable、CompletableFuture、またはListenableFutureは、Springインフラストラクチャがその機能を呼び出して別のスレッドの要求に参加するコールバックオブジェクトのようなものです。
貴重なCPUリソースの使用を最適化するだけで、より多くのクライアントに同時に参加することができるため、スループットが向上します.NIOの場合は、想像すると、 （有益なTomcatスレッドを解放しているので）有益ですが、まだブロックしているので、問題を別のスレッドプールに移動するだけです。
この基本的な原則は、このタイプの機能を活用するために、APIで非同期プログラミングを導入する必要があるため、現在、Springチームが現在行っている作業のかなりの部分であると考えています。やりにくいです。
これはフレームワークの拡散の理由でもあり、Netty,RxJava,Reactive Streams InitiativeおよびProject Reactorのようなものです。彼らはすべてこのタイプの最適化とプログラミングモデルを促進しようとしています。
この強力な機能を活用し、その領域内の限られた機能を持つSpringと競合または補完する新しいフレームワークの興味深い動きもあります。私はVert.xとRatpackのような興味深いプロジェクトについて話しています。そして今、私たちはそれをしています。この機能は、Node.jsの主要なセールスポイントの1つです。
あなたのリクエストを処理しているスレッドは、応答が処理されている間は待機しますが、CallableまたはCompletableFutureを返すと、そのスレッドはトレッドプールに戻され、その間に他のクライアントに参加してスループットを向上させます。 –
時間のかかるリクエストが発生した場合は、2番目のオプションが役立ちます。たとえば、所得要求にはdb選択の遅さや外部APIへの追加リクエストが必要です。高負荷のWebアプリケーションでは、通常、すべての要求が非同期モードと非ブロックモードで処理されます。場合によっては、追加の水平スケーリングなしに並行性の高いプレッシャーを維持することは唯一の選択肢です。 – rvit34