1）ThreadLocalをどのように値をリサイクルする、とするとき、回復？
分析の内部型からのThreadLocal：
①
静的 クラスThreadLocalMap { / ** *このハッシュマップのエントリが使用して、弱い参照を拡張 *（常にキーとしてその主REFフィールド * ThreadLocalのオブジェクト）。そのnullキー（すなわちentry.get（）に注意してください * == null）をキーは、もはや参照され、そのことを意味しません *エントリがテーブルから抹消することができます。そのようなエントリが参照される 以下のコードで「古いエントリ」として、*。 * / ... }
ThreadLocalMapは、カスタムハッシュマップはスレッドローカル値を維持するためにのみ適用されています。キーとしてweakreferencesを使用して、ハッシュテーブルエントリの使用の非常に大規模で長期の使用に対処するには。しかし、無参照キューいるので、これだけのテーブルだけで時代遅れのエントリを削除確保するために、スペースが不足し始めたとき。（ソースコードのコメントを）
②
静的 クラスエントリ延び弱い参照<ThreadLocalの<？>> { / ** このThreadLocalの関連付けられた値。* / Object値。 エントリ（ThreadLocalの <？> K、オブジェクトV）{ スーパー（K）。 値 = V; } }
（注記：値が弱参照はない）をキーとしてThreadLocalの弱参照を使用してThreadLocalMap、キーのみ異なるスレッドに分離変数のアクセスを可能にする、ThreadLocalのオブジェクトとすることができます。強い参照を失うThreadLocalの場合は、のみ、次のGCの前にライフサイクルにエントリキーがnullに表示されますThreadLocalMap、この時間を生き残ることができ、現在のスレッドが終了することはできません、null値を入力するためのこれらのキーは常に強い存在します参照は、メモリリークが生じる、チェーン。
ソリューション：
推奨事項は（）を取得するのThreadLocalの呼び出しでプライベート静的ThreadLocal変数として定義され、完全なセット（）メソッドは、手動でのThreadLocalを削除する必要がもはや、（）メソッドを削除呼び出します。
2）ThreadLocalのはなぜダーティデータのでしょうか？
スレッドプールは、わずか1つのマイナス面の二重の利点であるので：
スレッドがスレッドプールから削除され、それが再利用される場合は、最後に前回このスレッドということを確認する必要があり、その関連会社ThreadLocalのは、そうでなければ、次の使用まで育成し、一掃されます。