Java堆：什么限制了旧一代的最大容量？
我正在调查EE应用程序上的性能问题，这些问题可能是由于垃圾收集器的优化程度不高造成的。
在查看在重载下收集的jstat日志时，我偶然发现了以下发现：
S0 S1 E O P
7.39 0.00 41.81 88.89 53.93
NGCMN NGCMX NGC S0C S1C
131072.0 301056.0 301056.0 30080.0 30080.0
EC OGCMN OGCMX OGC
240896.0 1441792.0 2058240.0 2058240.0
按照这里的官方jstat留档，我们可以看到当前的旧代大小（OGC）已经达到了最大旧代大小（OGCMX）。然而，第一行告诉我们，“旧空间利用率占空间当前容量的百分比”（O）“仅”为88%。
我的问题是：
- 什么机制在jstat输出中将旧的生成限制设置为OGCMX？
- 是什么阻止了旧空间的增长和使用剩余堆的12%？
我们有JVM参数，用于设置总堆、新空间和perm空间的最小/最大值（-Xms-Xmx-XX:NewSize-XX:MaxNewSize-XX:PermSize-XX:MaxPermSize）。但对旧空间没有限制（我不知道这些参数是否存在）。
关于NewRatio的编辑：
这是我的理解，也在这里提到，JVM不强制执行新旧空间之间的比率，特别是如果使用了MaxNewSize参数。并且接受MaxNewSize参数，因为上面的值（301056.0KB）实际上正是我们为MaxNewSize指定的294MB。此外，NewRatio的默认值为2（参见此处），根本不是jstat列出的上述任何值之间的比率。
共有1个答案
我觉得这个问题很重要。我在寻找完全相同的答案。我的情况更糟。我们有6GB的Xmx，gccapacity选项的输出显示它使用了几乎100%的内存：
[ec2-user@ip ~]$ sudo jstat -gccapacity 2416
OGCMX: 6121088.0
OGC: 6084776.0
以及gcutil选项的输出：
[ec2-user@ip ~]$ sudo jstat -gcutil 2416
S0 S1 E O P YGC
0.00 100.00 26.01 58.81 59.90 8555
这意味着它应该只使用老一代的59%左右。我不明白。这意味着JVM正在占用全部容量，即使它没有使用它。。。
-
问题内容： 我有两台linux机器（都是VM），一台有12GB内存，另一台有8GB内存。 我试图在两台机器上启动相同的Java程序，并且最大可能的最大堆大小（使用-Xmx标志）。以下是我得到的结果。 12GB机器：9460MB 8GB机器：4790MB 如果我指定的最大堆大小超出了限制，我将得到以下错误。 我检查了两个系统中的可用内存（使用命令），然后得到关注。 12GB机器：大约3GB可用空间。
-
我有两台Linux机器（都是虚拟机），一台有12GB内存，另一台有8GB内存。 我尝试在两台机器上启动相同的java程序，并尽可能地使用最大堆大小（使用-Xmx标志）。以下是我得到的结果。 12GB 机器容量： 9460MB 8GB 机器容量： 4790MB 如果我指定的最大堆大小超出了上述限制，我会得到以下错误。 我检查了两个系统中的空闲内存(使用< code>free命令)，得到如下结果。 <
-
问题内容： 这是 不是 增加Java的堆的最大尺寸的虚拟机启动后。技术原因是什么？垃圾回收算法是否取决于要使用固定数量的内存？还是出于安全原因，通过消耗所有可用内存来防止Java应用程序从DOS的系统中移至其他应用程序？ 问题答案： 最后我知道在Sun的JVM中，必须在连续的地址空间中分配整个堆。我想对于大堆值，很难在启动后将其添加到您的地址空间中，同时又要确保它保持连续。您可能需要在启动时获取它
-
如果我逃跑 在铬33上，我得到 为什么？
-
问题内容： 我想限制a的最大大小，以对正在实现的各种哈希算法进行度量。我在的一个重载构造函数中查看了loadfactor 。 我尝试在构造函数中将loadFactor设置为0.0f（这意味着我不希望HashMap的大小从EVER增大），但将此无效： 还有另一种方法来限制它的大小，使其永远不会增长吗？ 问题答案： 有时越简单越好。