较小的伊甸园空间是否导致保有权空间不断增加？

Question

首先，我将给出我们创建的对象的一些细节。并会提出一个问题(最后)。

我在linux上使用64-但JVM。

我的jvm选项是：-Xmx6g -Xms3g -XX:MaxPermSize=256m

分析器(jprofiler)表示消耗大量内存的两个地方: 1)在这里，每秒创建大约4个字符串(每个110 on )，并对每个字符串执行StringUtils.replace。还执行了一些其他字符串赋值等，但分析器清楚地表明，StringUtils.replace是存储大部分内存的工具。2)在这里，一个对象(如果3.5MB保持大小)包含4个对象(一个类)，每分钟创建一个对象，并(Re)放置到静态并发图中(因此地图在任何时候只包含一个对象)。父对象所拥有的全部是这4个子对象，而不是其他任何对象。这4个对象中的每一个都包含10K数组、10K日期和其他字符串等。我将显式地分配旧父对象(从map.replace()获得的父对象)为null，并显式清除(ArrayList.clear())在这4个子对象中的ArrayList等。

内存行为是:内存使用量不断增加，并且一度发生了主要的收集(2GB)。小型收集(700 minor )也大约每分钟发生一次。

问题：您认为#1实际上是导致伊甸园空间满的吗?所以JVM正在将#2中的对象推送到保有空间，因此内存使用量一直在增加，直到出现大的选择为止？为了诊断目的，我将#2中的父对象更改为保留了500 of的大小(7倍于Date、ArrayList等的1.4K实例)，而且我仍然看到相同的内存行为。

现在，我将选项更改为-Xmx12g -Xms3g -XX:MaxPermSize=256m -XX:NewSize=8g，我在内存中看到了#2中较小的对象#--我看到保有空间/旧代的增长速度较慢。现在正在快速地收集#2中的那些对象，这是很好的，但是CPU的使用率非常高，因为小的集合现在是巨大的(8G)，并且每2分钟发生一次。

我的目标是快速收集所有对象(因此我没有看到内存使用量不断增加)，但不要使次要的集合太大。

对于我应该采取什么方法，有什么建议吗？

Answer 1

收集伊甸园空间的费用与保留的伊甸园空间中的物体数量成正比。由于费用很高，这意味着很大一部分物体被保留超过2分钟。

当您每两分钟创建大约6GB的对象时( NewSize包含两个幸存者空间)，或者大约每分钟3GB，其中大部分来自于您建议的每分钟只有几MB的大小。

我认为更好地理解3GB的来源和减少它将是有用的，因为它似乎您只需要保持大约10 MB每分钟。

顺便说一句:如果你每分钟要创建10 MB的垃圾，你只能在10小时内创建6 GB的垃圾，在这段时间里你不需要任何次要的或mjor的收集。

如果我跑了

public class GCLikeMad {
    public static void main(String... args) {
        for(Long l = 0L; l < Integer.MAX_VALUE * 10L; l++);
    }
}

关于-XX:NewSize=256m，我看到了

[GC 295664K->240K(2121792K), 0.0011190 secs]
[GC 286832K->240K(2113216K), 0.0011510 secs]
[GC 278384K->240K(2105216K), 0.0012900 secs]
[GC 270256K->240K(2097280K), 0.0010110 secs]
[GC 262448K->240K(2257280K), 0.0013450 secs]

关于-XX:newSize=8g -verbosegc，我看到了

[GC 6291664K->320K(7345408K), 0.0017790 secs]
[GC 6291776K->272K(7345408K), 0.0021570 secs]
[GC 6291728K->272K(7345408K), 0.0014490 secs]
[GC 6291728K->240K(8393600K), 0.0016680 secs]
[GC 8388080K->208K(8393600K), 0.0018730 secs]

此时-XX:NewSize=30g -mx31g -XX:SurvivorRatio=100 -verbosegc使用32位引用，并且只使用一个NUMA内存区域。

[GC 30840864K->256K(31154304K), 0.0014270 secs]
[GC 30840832K->256K(31154304K), 0.0014730 secs]
[GC 30840832K->224K(31154304K), 0.0016500 secs]
[GC 30840800K->272K(31154304K), 0.0015740 secs]
[GC 30840848K->272K(31462336K), 0.0015280 secs]

有了-XX:NewSize=128g -mx130g -XX:SurvivorRatio=100 -verbosegc，它就开始起作用了。注意:此时正在使用多个NUMA内存区域和64位引用。这是每2分钟收集一次。

[GC 131586048K->320K(132907264K), 0.0042360 secs]
[GC 131586368K->1376K(132907264K), 0.0058030 secs]
[GC 131587424K->1440K(132907264K), 0.0034110 secs]

此时，它已经创建了200亿个长对象，只有三个集合。

我认为128 GB的伊甸园空间是巨大的。:D

我的观点是，增加伊甸园的大小并不会增加GC的独处时间。它增加了被保留对象的数量，从而增加了所需的时间。