与使用的％相比，堆大小意外很大
有一个内存分配问题，我希望得到你的帮助。 我们已经分析了一些顶级的服务，我们注意到它们的RES值约为1.8GB，据我了解，这意味着他们当时只能保持1.8GB的内存。 如果我们刚刚开始它们（它们实质上是从缓存中读取数据，处理数据并推送到另一个缓存），但是看到我们在CPU密集型处理完成后仍然可以看到这一点，我们就会好奇它是否会意味着某些事情没有按照我们的预期进行GC'ed。
我们使用以下参数运行程序： -Xms256m -Xmx3096m据我了解，这意味着初始堆大小为256，最大堆大小为3096。
现在我期望看到的是堆最初需要增长，然后随着内存释放而缩小（尽管这可能是我的第一个错误）。 我们用jvisualvm实际看到的是以下内容：
我的问题是，为什么我的堆没有缩小，因为我可能预期它会？ 这不是盗取了有价值内存的Linux盒子上的其他进程，如果是的话，我该如何解决它？ 我们确实有时会发现内存不足的错误，并且这些进程被分配了最“意外”的内存大小，我认为最好从它们开始。
干杯，戴夫。
（〜请原谅可能对JVM内存调整缺乏了解！）
您可能想看到有关调整堆扩展和缩小的答案。 默认情况下，JVM对于缩小堆不太积极。 此外，如果堆有足够的可用空间很长一段时间它不会触发GC，我相信是唯一的时间被认为是缩小它。
理想情况下，您可以将最大值配置为在满负载下为应用程序提供足够空间的值，但如果它始终处于使用状态，则可以为操作系统性能所接受。 为了可预测性和潜在的更好性能，将最小值设置为最大值并不罕见（我没有任何可供参考的参考）。
我没有一个完整的答案，但之前出现过类似的问题。 在之前的讨论中，您应该研究-XX:MaxHeapFreeRatio=作为您的调整参数，以强制堆释放回操作系统。 这里有文档，我相信默认值允许有大量未使用的堆保持由JVM拥有。
那么，GC并不总是在你想的时候运行，它并不总是收集什么是合格的。 如果它几乎用完了堆空间，那么它可能只会开始从旧的gen空间收集对象（因为从旧gen收集通常会涉及GC试图避免的停止世界收集，直到它真的需要做它）。
链接地址: http://www.djcxy.com/p/81425.html