Charlie Hunt は、彼のプレゼンテーションで、ラージ オブジェクトは JVM GC にとって悪いと述べています。なぜなら:
大きなオブジェクトは、割り当てと初期化にコストがかかります。
サイズの異なる大きなオブジェクトは、Java ヒープの断片化を引き起こす可能性があります。
ラージオブジェクトを定義するには? オブジェクトがラージ オブジェクトかどうかはどうすればわかりますか? ありがとう
Charlie Hunt は、彼のプレゼンテーションで、ラージ オブジェクトは JVM GC にとって悪いと述べています。なぜなら:
大きなオブジェクトは、割り当てと初期化にコストがかかります。
サイズの異なる大きなオブジェクトは、Java ヒープの断片化を引き起こす可能性があります。
ラージオブジェクトを定義するには? オブジェクトがラージ オブジェクトかどうかはどうすればわかりますか? ありがとう
定義は、プラットフォーム、JVM、および JVM 構成によって異なります。たとえば、Michael Kopp による 3 つの大きな JVM ブログ投稿でのガベージ コレクションの違いからの抜粋を次に示します。
大きなオブジェクトと小さなオブジェクト
JRockit は、割り当て時に大きいオブジェクトと小さいオブジェクトを区別します。オブジェクトが大きいと見なされる場合の制限は、JVM のバージョン、ヒープ サイズ、ガベージ コレクションの戦略、および使用するプラットフォームによって異なります。(イタリック体の鉱山 - DL.) 通常は 2 ~ 128 KB です。ラージオブジェクトは、古い世代に直接生成される世代ヒープの場合、スレッドローカル領域の外に割り当てられます。これは、考え始めると非常に理にかなっています。若い世代はコピー ccollection を使用します。ある時点で、オブジェクトのコピーは、これまでのガベージ コレクションでオブジェクトをトラバースするよりもコストがかかります。
2 番目の質問に対して、そのしきい値を取得する方法がわかりませんが、具体的には HotSpot で設定できます。
-XX:PretenureSizeThreshold=2m
このオプションおよびその他の多くのオプションの詳細については、Alexey Ragozin によるHotSpot JVM ガベージ コレクション オプション チート シートを参照してください-XX
。
そのサイズに関する理論的な定義はありませんが、これは JVM 構成に依存します。たとえば、若い世代が小さい場合、小さなクラスでもスワップ (GC) が多すぎます。オブジェクトがJVMヒープに対して十分に大きい場合、GCはそれらをヒープから割り当てて要求するためにさらに多くの作業を行う必要があります。これにより、「世界を止める」問題がより頻繁に発生します。
GC の観点から見た一般的なラージ オブジェクトとは、次のことを意味します。
例: サイズ 10000 の arraylist。