ThreadLocal 変数は Thread Local 割り当てバッファーまたは TLAB に割り当てられていると思いますが、そうですか?
一部のクラスを TLAB に格納する正確な理由を示すドキュメントを見つけることができませんでした。いくつか知っている場合は、リンクを投稿してください。
ThreadLocal 変数は Thread Local 割り当てバッファーまたは TLAB に割り当てられていると思いますが、そうですか?
一部のクラスを TLAB に格納する正確な理由を示すドキュメントを見つけることができませんでした。いくつか知っている場合は、リンクを投稿してください。
一部のクラスを TLAB に格納する正確な理由を示すドキュメントを見つけることができませんでした。いくつか知っている場合は、リンクを投稿してください。
実際、リンク先のブログ投稿に説明があります。
スレッド ローカル割り当てバッファー (TLAB) は、単一のスレッドによる割り当てに使用される Eden の領域です。これにより、スレッドは、スレッド ローカルのトップ ポインターとリミット ポインターを使用してオブジェクトの割り当てを実行できます。これは、スレッド間で共有されるトップ ポインターでアトミック操作を実行するよりも高速です。
すべてのスレッドは、ヒープの「ジェネレーション 0」部分である Eden の独自のチャンクからメモリを割り当てます。ほとんどすべてのものは一定期間 TLAB に保存されますが (おそらくあなたThreadLocal
の s も)、gen0 ガベージ コレクションの後にそこから移動されます。TLAB は、他のスレッドからメモリにアクセスできないようにするためではなく、割り当てを高速化するために存在します。リンク先の同じブログからのよりアクセスしやすい説明は、A little thread privacy, pleaseです。
いいえ。これがその方法です。1.4 の時点で、Java の各スレッドにはthreadLocals
、マップが保持される場所と呼ばれるフィールドがあります。各 threadLocal には構造体へのインデックスがあるため、hashCode() は使用しません。配列を想像してみてください。各 ThreadLocal はスロット インデックスを保持します。
スレッドが終了し、スレッドへの参照がなくなると、ThreadLocals が GC されます。とてもシンプルなアイデアです。
Thread を拡張し、参照を保持するフィールドを追加することで、独自の ThreaLocal を実装できます。次に、スレッドを独自のクラスにキャストし、データを取得します。
したがって、これは TLAB ではなく、他のオブジェクトと同様にヒープです。
歴史的に、データへのアクセスが非常に遅い静的な WeakHashMap を使用した実装がありました。
小規模から中規模のすべてのオブジェクトのオブジェクト割り当てに TLAB が使用されていることを理解しています。ThreadLocal が別の方法で割り当てられることはありません。
これは JVM 実装者の裁量に任されていると確信しています。必要に応じてデータを TLAB に配置することも、スレッド ID をキーとするグローバル テーブルに配置することもできます。Java 言語仕様は、JVM 作成者が Java をできるだけ多くの多様なプラットフォームにデプロイできるように、この種の問題について沈黙する傾向があります。
データ自体は他のメモリ領域に存在しますが、それへのポインタだけだと思います。http://blogs.oracle.com/jonthecollector/entry/the_real_thingおよびhttp://wikis.sun.com/display/MaxineVM/Threads#Threads-Threadlocalvariablesを参照してください。