java - ThreadLocal の実装

Question

私の以前の質問を参照して、もう少し進んで、

1. ローカル変数ではなく ThreadLocals を使用することの欠点は何ですか
2. それらはどのように実装されていますか
3. セッション変数は ThreadLocals ですか
4. 頻繁に使用される ThreadLocals の例は他にもありますか

Answer 1

これを不利と呼ぶかどうかはわかりませんが、明示的に削除されない限り、スレッドが存続している限り、そこに入力したデータはすべてそこにとどまるため、ThreadLocalを適切にクリーンアップする場合は十分に注意する必要があります。これは、スレッドがスレッドプールを使用して再利用される環境では特に厄介であるため、適切にクリーンアップされない限り、一部のガベージデータがスレッドに添付される可能性があります。

ThreadLocalsは実際に多く使用されます。主にフレームワーク開発者は、メソッドのシグネチャを変更せずにユーザーメソッドに「コンテキスト」をアタッチできるためです。たとえば、J2EEでのトランザクション管理は、ThreadLocalsを使用して行われます。現在開いているトランザクションへの参照は常にスレッドに付加されるため、データベースを操作するときに、現在開いているトランザクションを使用して自動的にアクセスします。ThreadLocalがないと、これらの参照をメソッドパラメーターとして渡す必要があります。

そのような使用法の多くの追加の例があります。参照しているセッション変数はわかりませんが、セッションのようなデータがThreadLocalに添付されることがよくあります。

実装について-よくわかりません。今日ではかなり多くのコードが使用しているため、パフォーマンスを非常に高速にするために、JVM内にかなり低いレベルで実装されていることをどこかで読んだと思います。

Answer 2

1. 何と比べてデメリット？
2. -- 実際にはMap<Thread,Value>スレッドに関連付けられたマップですが、スレッドによってキー設定されたマップとして考える方が簡単です
3. いいえ
4. ThreadLocals はほとんど使用されないため、そのままにしておく必要があります

私の意見では、アプリケーション開発者が ThreadLocal を使用する唯一の理由は、(比較的) 構築コストが高いスレッドセーフではないユーティリティ オブジェクト (SimpleDateFormat など) を頻繁に使用する必要がある場合です。それでも、それはトスアップです。

Answer 3

実際の例: AMQPメッセージング プロトコルでは、複数の多重化された論理接続 (チャネルと呼ばれる) が 1 つの TCP/IP 接続などに共存できます。一部の操作は論理接続の状態を変更するため、並行メッセージング操作を並行チャネルでの操作としてモデル化することが望ましいです。並行性モデルがスレッド化されている場合、 ThreadLocal get()でチャネル アクセスをカプセル化し、 initialValue()オーバーライドでチャネルを開くことで、これを非常に簡単に行うことができます。

Springフレームワークのコンテキストでは、適切なターゲット ソースを使用して透過的にスレッド ローカル Bean を使用できます。