I.背景
ブラザーは最近、管理バックグラウンド処理は、実装プロセスは、ユーザのログイン情報操作を取得する必要があり、小さなドロップDBの需要を記録し作られたが、それに順に、途中で別の会社のAD RPCサービスシステムからログイン情報を必要とするクエリは、両方のユーザーのリーチを決定しますログイン状況が、また、CRUDにログイン情報を使用することができます。私はADサービス検証要求を呼び出すと、Cookie情報を運ぶ、CRUDに要求がコントローラ層の前に到着した、ということを理解リクエストをキャプチャするためにインターセプタを使用して考えることは有効であり、かつに着く「アカウント、UID、その他の基本的な情報、」ユーザー、できるようにするために、基本的な情報を取得するが、サービスを呼び出す再び呼び出すことがない[AD]サービス層は、私は、スレッドと同じようにへのアクセス権を持っているので、ThreadLocalのにユーザーの状態情報を保存することを決定し、時間のかかるプロセスです。、
何の問題を実装しませんが、スレッドが終了した後、弟が突然、考え、スレッド情報は、あなたが存在し続けるユーザーモードに対応し、それが自動的にJVMを回復することになる、すぐにリコールされていない場合、CRUDの多くは、サーバーのメモリには影響しません。そして、実際には「JVM仮想マシンの深い理解」の上にラフに行く前に閲覧するためには、この質問につながりました。「詳細な分析ThreaLoaclメモリ構造」+こと「ThreadLocalのガベージコレクションメカニズムが作ったものです」
二、ThreadLocalの原則
2.1ThreadLocal概要
2.2ThreadLocal構造
2.3ThreadLocal回復戦略
ソースコードを読み取ることにより、我々は明らかにそのガベージコレクションモードを理解することができます。ここでは、ソースコードのドキュメントのドキュメントを見てです
暗黙的な参照は、スレッドローカルのITS Aコピーにそれぞれ保持しているスレッド
@code {}はスレッドが生存していてThreadLocal AS AS *ロング変数を
スレッドAが後に消える、ITSのコピーのすべて;アクセがインスタンス*
*スレッド・ローカルガベージコレクションの対象には、インスタンス（しない限り、他のある
これらのコピーへの*参照が存在する）。
限り、このスレッドがあるように、」非常に明確ではない、とのThreadLocalインスタンスがアクセス可能である、そして、スレッドは、スレッドローカルへの暗黙的な参照を保持しますこのスレッドは（すなわち終了）消えたときには、それは（このバックアップへの他の参照がある場合を除き）thread_localバックアップ」は、ガベージコレクションを入力します保持している
だけでそこに停止した場合、当然のことながら、これを記述する必要はありません記事。なぜそれが以下の分析の下で継続するガベージコレクションスレッドのそれの消失でバックアップすることができます。
（1）参照仮想
https://www.cnblogs.com/mfrank/p/9837070.html
https://www.jianshu.com/p/825cca41d962
ソフト参照、弱参照、ファントム参照 - その機能とアプリケーションのシナリオ
（2）ソフト参照
（3）弱参照
（4）強い参照
参照の種類に関しては、サード
ガベージコレクションのメカニズムに、第四
https://mahl1990.iteye.com/blog/2347932 メモリは、コメントをリーク