JVM における TLAB の謎を解明

[[413891]]

この記事はWeChatの公開アカウント「プログラマーの成長」から転載したもので、著者はプログラマーの成長です。この記事を転載する場合は、プログラマーの成長公開アカウントまでご連絡ください。

この記事を始める前に、JVM がオブジェクトを作成し、メモリアドレスを割り当てるプロセスを理解しており、JVM のメモリ分割も知っていることを前提とします。人道的な観点から、参考までに写真を投稿します。

JVM メモリ構造

ヒープメモリパーティション構造

ヒープ領域にメモリを割り当てるときに、マルチスレッドの安全性の問題はありますか?

A: 存在するかもしれません。

新しいオブジェクト();

上記の操作では、最終的にはヒープメモリ内にメモリ領域の一部を開く必要があることは誰もが知っています。そこで、この質問について考えてみましょう。ヒープ領域はすべてのスレッドによって共有されます。では、JVM が頻繁にオブジェクトを作成する場合、同時実行時にヒープメモリのスペースを空けるとセキュリティ上の問題が発生するのでしょうか?

この問題を解決するために、まず考えられるのはロックですが、ロックにはパフォーマンスに影響を与えるという問題があります。

TLAB が表示されます (スレッドローカル割り当てバッファ)

上記の問題に基づいて、TLAB が導入されます。強制変換はスレッドローカル割り当てバッファです。まず、写真を見てみましょう

ステートメント: ヒープメモリにスペースを割り当てるときは、古い世代に直接割り当てられるのではなく、最初に Eden 領域に割り当てられます。メモリ割り当てが完了した後、GC が実行されるたびに、オブジェクトがリサイクルされない場合は、その生存カウントが +1 になります。この回数が 15 回に達すると、オブジェクトは古い世代に昇格されます。

オブジェクトの割り当てはまず eden 領域で実行されることがわかったので、上の図を理解するのは難しくありません。私たちはエデンエリア内の領域を分割し、これを TLAB と呼びます。各 TLAB はプライベートなので、オブジェクトを同時に作成する場合、実際にはロックなどの操作を実行する必要がなく、セキュリティの問題が解決されます。

割り当てられた TLAB スペースが使い果たされた場合、またはオブジェクトに必要なメモリスペースが TLAB が提供できるスペースよりも大きい場合、メモリスペースはパブリックエデン領域または古い世代にのみ割り当てることができます。