2

次の記事を読んでいました: http://java.sun.com/docs/hotspot/gc1.4.2/example.htmlそして、次の行を理解するのに問題があります:

Young generation size is too small

The young generation heap size in this first example is about 4 Mbytes with an overall heap size of about 32 Mbytes.

[GC [DefNew: 4032K->64K(4032K), 0.0429742 secs] 9350K->7748K(32704K), 0.0431096 secs]

[GC [DefNew: 4032K->64K(4032K), 0.0403446 secs] 11716K->10121K(32704K), 0.0404867 secs]

[GC [DefNew: 4032K->64K(4032K), 0.0443969 secs] 14089K->12562K(32704K), 0.0445251 secs]

This output seems reasonable from the point of view of the time spent in garbage collection but note that although the occupancy of the young generation is decreasing (e.g., in the first line from 4032 to 64k by 3968k) the occupancy of the entire heap is decreasing by considerably less (by 1602k from 9350k to 7748k). This indicates that only about 40% objects in the young generation were garbage and the rest survive the collection and are being promoted into the old generation.


Increasing the young generation size to increase the free space after the collection


The young generation heap size in this next run is increased to 8 Mbytes.


[GC [DefNew: 8128K->64K(8128K), 0.0453670 secs] 13000K->7427K(32704K), 0.0454906 secs]

[GC [DefNew: 8128K->64K(8128K), 0.0388632 secs] 15491K->9663K(32704K), 0.0390013 secs]

[GC [DefNew: 8128K->64K(8128K), 0.0388610 secs] 17727K->11829K(32704K), 0.0389919 secs]


With an 8 Mbyte size most of young generation is garbage at the time of the minor collection. In the first line the young generation heap decreases by 8064k from 8128k to 64k and the entire heap decreases by 5573k from 13000k to 7427k meaning about 68% of the young generation was garbage. As would be expected the size of the young generation does not change the amount of live objects that survive the minor collection (about 2.4M bytes in each case) but there are fewer minor collections and the cost of the collections in terms of the minor collection pause times are comparable (fractions of a second listed at the end of each line).

私の質問は、この場合、YoungGen のサイズを大きくするとどのように役立つかということです。アプリケーションが YoungGen に割り当てるオブジェクトの総数は一定です。

4

3 に答える 3

6

YoungGen から何かを昇格させるとコストがかかり、次の原因になります。

  • それはより長く生き、記憶を浪費する
  • 将来のガベージ コレクション (すべてのガベージ コレクションがなくなるまで) のコストが高くなる
  • YoungGen コレクションでは無視され、より貴重なリソースを使い果たすまで待たなければならず、より高価なコレクションを強制する必要があります。

YoungGen のサイズを大きくすることで、YoungGen によってより多くのオブジェクトが収集されるようになり、上記の悪い点に該当しなくなります。つまり、オブジェクトはすぐに消滅し、誰にも何の損害も与えないので、すべてが高速になりますか?

さらに、あなたが読んでいるドキュメントのより新しいバージョンがありますが、例が欠けているようです: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

于 2012-02-22T00:11:13.500 に答える
1

若いコレクションのコストは、保持されるオブジェクトの数に比例します。若いコレクションが大きいほど、それらのオブジェクトが不要になる可能性が高くなります。つまり、若いコレクションのコストが特定のサイズを超えて大幅に増加することはありません。

小さい若い世代のサイズの場合は比例しますが、大きいサイズの場合はそれほど多くありません。収集の頻度は、サイズに比例して低下します。1日1回未満の収集に達することができます。;）

アプリケーションの動作に応じたYMMV。

于 2012-02-22T08:02:29.607 に答える
1

答えは記事自体にあります。

予想されるように、若い世代のサイズは、マイナー コレクション (各ケースで約 2.4M バイト) を生き残るライブ オブジェクトの量を変更しませんが、マイナー コレクションが少なくなり、マイナー コレクションに関してコレクションのコストがかかります。一時停止時間は比較可能です (各行の最後に 1 秒未満でリストされています)。

これは、YoungGen の増加の直接的な結果です。

于 2012-02-22T00:14:24.840 に答える