Joshua Blochによる以下のステートメントに何度も出くわしたとき、私はThreadLocalクラスについて読んでいました。
制御できないコールバックを介した「スリーシング」値：パッケージを呼び出すライブラリメソッドを呼び出す必要がある場合があります。この時点で、ライブラリの欠陥のために自分自身に渡すことができなかったコンテキストが必要です。このまれな状況では、スレッドローカルが命の恩人になる可能性があります。
これを理解するのに苦労しています..誰かが詳しく説明してくれたら幸いです
ありがとう..Heena
私のアプリケーションは、保存されたデータを検索するライブラリを呼び出します。
そのライブラリには、検索の生の結果を必要なデータ形式に変換する方法を指示する実装可能なインターフェイスもあります。
検索結果を必要なオブジェクトに変換する方法の実装には、特定のタイム ゾーンを知ることが含まれます。
したがって、プロセスは、(A) ライブラリ検索メソッドを呼び出し、(B) 検索メソッドが生の結果を自分の形式に変換する別のコードを呼び出し、(C) 変換にはタイムゾーンを知る必要があります。課題は、ポイント A で知っている情報 (タイムゾーン) をポイント C で利用できるようにするにはどうすればよいかということです。
明らかに、ライブラリが提供するメソッドにはタイム ゾーンの受け渡しが含まれていないため、ThreadLocal に貼り付けます。
後でコードにコールバックするサードパーティ関数を呼び出すとします。コールバックでは、いくつかのコンテキストが必要です。つまり、いくつかの変数にアクセスできるようにする必要があります。ただし、サードパーティの関数には、コードを介してオブジェクト参照をコールバックに渡す方法がないという点で欠陥があります。
あなたは何をしますか？
残念ながら、コンテキストを実質的にグローバル変数に格納する以外に選択肢はあまりありません (恐ろしい!)。ThreadLocalこのハックを使用する複数のスレッドが互いに足を踏み入れないという点で、グローバル変数のわずかな改良です。
もちろん、サードパーティ関数を呼び出しているスレッドとは別のスレッドでコールバックが発生した場合、この手法は機能しません。
また、この手法はスケーリングしません。2 つのコールバックを同時に登録する場合は、2 つの異なるコールバック関数と 2 つの異なるグローバル コンテキストが必要になります。