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 的大小，他们确保更多的对象被它收集，因此不会遇到上述任何坏点。也就是说，物体很快就会死去，而且不会让任何人付出任何坏事，所以一切都更快？

此外，您正在阅读的文档有一个更现代的版本，尽管它似乎缺少您的示例： http ://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

于 2012-02-22T00:11:13.500 回答
1

答案就在文章本身。

正如预期的那样，年轻代的大小不会改变在次要收集中幸存的活动对象的数量（每种情况下大约 2.4M 字节），但是次要收集更少，并且收集的成本就次要收集而言暂停时间是可比较的（每行末尾列出的秒的分数）。

这是增加 YoungGen 的直接结果。

于 2012-02-22T00:14:24.840 回答
1

年轻集合的成本与保留的对象数量成正比。年轻的集合越大，这些对象就越有可能不再需要，这意味着您会发现年轻集合的成本不会增加太多超过一定的大小。

对于小的年轻一代来说，它的比例是成比例的，但对于更大的尺寸来说不是那么大。收集频率随大小成比例下降。您可以达到每天收集不到一次的地步。;)

YMMV 取决于您的应用程序的行为方式。

于 2012-02-22T08:02:29.607 回答