JavaのステートレスBeanは、クライアントからの2つの呼び出しの間で状態を保持しません。つまり、一言で言えば、それらをビジネスメソッドを持つオブジェクトと見なすことができます。各メソッドはパラメーターを受け取り、結果を返します。メソッドが呼び出されると、いくつかのローカル変数が実行スタックに作成されます。メソッドが戻ると、ローカルはスタックから削除され、一時オブジェクトが割り当てられている場合は、とにかくガベージコレクションされます。
私の見解では、同じ単一インスタンスのメソッドを別々のスレッドで呼び出すのと同じです。では、なぜコンテナは、多数のBeanをプールする代わりに、Beanの1つのインスタンスを使用できないのでしょうか。
プーリングはいくつかのことを行います。
1 つ目は、インスタンスごとに 1 つの Bean を持つことで、スレッド セーフであることが保証されます (たとえば、サーブレットはスレッド セーフではありません)。
2 つ目は、Bean の潜在的な起動時間を短縮することです。セッション Bean は「ステートレス」ですが、クライアントに関してのみステートレスである必要があります。たとえば、EJB では、複数のサーバー リソースをセッション Bean に注入できます。その状態は Bean に対してプライベートですが、呼び出しから呼び出しまで保持できない理由はありません。したがって、Bean をプールすることで、これらのルックアップを Bean の作成時にのみ発生するように減らすことができます。
3 つ目は、トラフィックを調整する手段として Bean プールを使用できることです。プールに 10 個の Bean しかない場合、同時に処理できるリクエストは最大で 10 個だけで、残りはキューに入れられます。
プーリングはパフォーマンスを向上させます。
すべてのリクエスト/スレッドを処理する単一のインスタンスは、多くの競合とブロッキングにつながります。
どのインスタンスが使用されるかわからないため（複数のスレッドが単一のインスタンスを同時に使用する可能性があるため）、Beanはスレッドセーフである必要があります。
コンテナは、実際のアクティビティに基づいてプールサイズを管理できます。
Java EE モデルのトランザクション性は、スレッド コンテキストを使用してトランザクションのライフサイクルを管理します。
この簡略化は、UserTransaction オブジェクトと直接やり取りするために特定のインターフェイスを実装する必要がないようにするために存在します。トランザクションが InitialContext から取得される (またはセッション Bean に注入される) と、再利用のためにスレッド ローカル変数にバインドされます (たとえば、ステートレス セッション Bean のメソッドが、注入されたトランザクションも使用する別のステートレス セッション Bean を呼び出す場合)。 )
ステートレス セッション Bean のライフ サイクルは、Doesnot exist、Passive および MethodReady (Passive または Inactive) 状態です。コンテナー コールバック - ejbActivate() および ejbPassivate() は、Bean プールを管理することによってそこにあります。
スリーナット
メソッドは本質的にスレッド セーフです (静的を含む)。なんで？メソッド内のすべての変数がスタックメモリに作成されるため、単純です。つまり、メソッド内で使用されるすべての変数は、呼び出しごとに作成されます (共有されません)。ただし、パラメーターはスタックの一部ではありません。
ただし、安全でない変数を使用する場合、メソッドは安全ではありません。
a) 静的フィールドまたは変数を呼び出す。ただし、すべてのケースで発生します。
b) 共有されているリソースを呼び出す。EntityManager など。
c) 安全でないパラメータを渡す。