サーブレット 3.0 では、startAsync を使用して長い作業を別のスレッドに置くことができるため、サーブレット スレッドを解放できます。
サーブレットスレッドを使用して作業しないのはなぜですか? startAsync によって作成されたスレッドは、どういうわけか安価ですか?
サーブレット 3.0 では、startAsync を使用して長い作業を別のスレッドに置くことができるため、サーブレット スレッドを解放できます。
サーブレットスレッドを使用して作業しないのはなぜですか? startAsync によって作成されたスレッドは、どういうわけか安価ですか?
ほとんどの場合、リクエストを処理するときに、外部のリソース/条件をブロックまたは待機しています。この場合、作業を行わずにスレッドを占有している(したがって大量のメモリを使用している)。
サーブレット3.0を使用すると、使用可能なスレッドよりもはるかに多くの数千の同時接続を処理できます。スループットが制限されたファイルのダウンロードを提供するアプリケーションについて考えてみてください。ほとんどの場合、スレッドは次のデータチャンクの送信を待機しているため、アイドル状態になっています。通常のサーブレットでは、ほとんどの場合、これらのスレッドがアイドル/スリープ状態であっても、HTTPスレッドの数より多くのクライアントにサービスを提供することはできません。
サーブレット3.0では、HTTPスレッドが少ない数千のクライアントを接続できます。私の記事で実際の例を見つけることができます:この質問に触発されたサーブレット3.0非同期処理によるサーバースループットの10倍の増加:サーブレットでのダウンロードファイルの帯域幅/速度を制限する
startAsyncによって作成されたスレッドはどういうわけか安いですか?
startAsync
!によって作成されたスレッドはありません。サーブレットコンテナに通知するだけです。/メソッドは終了しましたがdoGet
、doPost
このリクエストは完了していません。閉じないでください。それが全体のポイントです-非同期リクエストごとに新しいスレッドを作成することはおそらくないでしょう。別の例を次に示します。cometを使用して株価の変更を待っているブラウザが何千もあります。標準のサーブレットでは、これは次のことを意味します。何千ものアイドルスレッドが何らかのイベントを待機しています。
サーブレット3.0を使用すると、すべての非同期リクエストをArrayList
キューまたはキューで待機させることができます。株価変動が発生したら、すべてのクライアントに次々と送信します。このシナリオでは、必要なスレッドは1つだけです。また、すべてのHTTPスレッドは、残りのリソースを自由に処理できます。
サーブレット 3.0 では、すべての非同期リクエストを ArrayList または何らかのキューで待機させることができます 。問題はこれです。リクエストを処理し、リクエストを取得して最終的にレスポンスを送信するには、まだ新しいスレッドが必要です。したがって、http スレッドを解放しますが、リクエストを処理するためのスレッドを作成する必要があります