メソッドを使ってさらに2つのスレッドを生成している。クラスは、固定数のスレッドを再利用するスレッドプールを作成する。このスレッドプールのスレッドは、長さに制限のないタスクキューを共有している。示すスレッド数が、同時にアクティブとなるスレッドの最大数である。スレッドがすべてアクティブな時に追加のタスクが登録された場合、スレッドが利用可能になるまで、それらのタスクはキュー内で待機状態となる。スレッドが再利用されるとき、スレッドローカル変数の状態は保持されたままである。以下の表では、起こりうるタスクの順序を示している。値)は月曜日になっていることが期待される。実行時の曜日は金曜日になってしまっている。(スレッドプールサイズの増加)以下の違反コード例では、前述の問題の対策として、スレッドプールのサイズを2から3に変更している。...}スレッドプールのサイズを増加させることにより前述の問題は解決する。多くのタスクがプールにサブミットされる場合には、この変更では不十分となり、スケーラビリティに優れた解決方法とはいえない。ブロックで囲んでいる。オブジェクトから実行中のスレッドが加えた変更を取り除き、オブジェクトを初期化する。上記の解決方法では、スレッドローカル変数の操作に関する責任がクライアント側(DiaryPool)に移されている。クラスの修正が不可能な場合にはよい解決策である。メソッドをオーバーライドしている。タスクが実行される前に呼び出される。実行される前に、スレッドローカル変数を再初期化する。オブジェクトを再度初期化する必要はない。その値を変更する必要はないだろう。データを持つオブジェクトが、再初期化を行わずにスレッドプールの異なるタスクで実行されると、スレッドの再利用によって予期せぬ状態になることがありうる。Variables翻訳元これは以下のページを翻訳したものです。有このページは役に立ちましたか?javascriptを有効にすると、ご回答いただけます。その他のご意見はPCサイトにて入力願います。