機能に戻って調べてみServlet-3.xました。私が間違っていなければ、Servlet-3.x より前はリクエストごとのスレッド モデルであり、大量の受信トラフィックのためにプール内のスレッドが不足していました。
したがって、Servlet-3.x では、非同期であり、スレッドをブロックしたままにせず、すぐにスレッドを解放しますが、タスクだけが委任されます。
以下、私の解釈ですが、
サーバースレッドプールに2つのスレッドがあると考えてください
新しい非同期サーブレット リクエストR1の場合、スレッドがありますT1。これT1により、タスクが委譲され、クライアントにすぐに応答しますT2。T1
質問:T2サーバーのスレッドプールから作成されますか? もしそうなら、私はポイントを取得しません。
ケース 1: 古い同期サーブレット リクエスト
T1が I/O タスクの実行でビジーだった場合、ケース 2: 非同期サーブレット呼び出しの場合
T2は、実行中の I/O タスクでビジーです。どちらの場合も、どちらかがビジーです。
アプリ サーバーのサンプル Async サーブレットで同じことを確認しようとしましたopenliberty。以下は、サンプル デモ サーブレットから取得したサンプル ログです。
Entering doGet() == thread name is = Default Executor-thread-116
Exiting doGet() == thread name is = Default Executor-thread-116
=== Long running task started ===
Thread executing @start of long running task = Default Executor-thread-54
Thread executing @end of long running task = Default Executor-thread-54
=== Long running task ended ===
上記のように、Default Executor-thread-116はすぐに解放され、実行時間の長いタスクが に委任されますがDefault Executor-thread-54、それらが App Server スレッド プールからのものかどうかはわかりません。もしそうなら、Default Executor-thread-116委任の代わりにタスクを実行できないのはなぜですか?
誰かがJavaEEのサーブレットのこの非同期動作に光を当てることができますか