我们可以使用 -Xmx 为我们的 java VM 设置 Java 堆空间的最大可能内存，例如。-Xmx1g。
如果优先级是不会发生 java OutOfMemoryError 堆空间，为什么要将 -Xmx 设置为低于某个值？如果最大值较低，VM 是否更有效地管理内存？
我经常遇到 OutOfMemoryError 并且我将 -Xmx 设置得非常高。问题是最终我的物理内存也用完了 - 仅靠高 Xmx 是不够的。我目前的解决方案是关闭我需要大量内存的应用程序，这很不方便，因为它会减慢开发和测试速度。
我的主要原因是确保 JVM 内存使用适合可用 RAM。假设我在 8g 内存的机器上运行了 3 个 tomcat 实例。我可能会将每个 vm 的 mX 设置为 2g 左右，并允许 2g 用于 os 和其他。
如果 JVM 被强制进行交换，当垃圾收集器在对象树中导航时，它会带来巨大的性能问题。
-Xms 和 -Xmx 参数分别定义最小和最大堆大小。
由于 GC 在代数填满时发生，因此吞吐量与可用内存量成反比。
默认情况下，JVM 会在每次 GC 时增大或缩小堆，以尝试将每个集合中的可用空间与活动对象的比例保持在特定范围内。该范围由参数 -XX:MinHeapFreeRatio=minimum 和 -XX:MaxHeapFreeRatio=maximum 设置为百分比；以及由 -Xms 和 -Xmx 限定的总大小。
oracle 网站上有一些 Java 堆大小调整指南可用于 glassfish 调优，但应该适用于任何 JVM。
http://docs.oracle.com/cd/E18930_01/html/821-2431/abeic.html#abeij
IBM 的故障排除指南建议针对特定于应用程序的堆使用量，最小堆使用量约为 40%，最大堆使用量约为 70%
如果最大值较低，VM 是否更有效地管理内存？
可能，不过度分配堆大小的对象将更正确地“填充”到正确的内存代，因为具有大的堆大小将执行更少的 GC，这意味着更多的对象在年轻代中停留的时间更长，这提供了更快的垃圾收集内存使用量翻倍的代价。
我不会看到任何额外的开销，但是这是导致您的应用程序用尽最大内存分配的内存不足的原因，并且很可能有大对象存储在内存中，或者内存中的某处存在内存泄漏应用程序是比堆管理更紧迫的问题。
http://docs.oracle.com/javame/config/cdc/cdc-opt-impl/ojmeec/1.1/custom/html/tuning.htm
无需将 -XMX-Parameter 设置为低。只需将其设置为您的应用程序所需的值。但重要的是要注意，随着 -XMX-Value 的增加，GC-Time 会增加，因此您的应用程序可能不会响应（取决于您使用的收集器）。出于个人经验1G不是很高。我有 4G、8G 或 16G 的 JVM，它们运行良好
我相信如果备忘录更大，那么它需要被 GC-ed 的频率更低，并且可能会有很多垃圾，因为 GC 可以放松那么多空间。但是，GC 必须在更多内存上工作，这反过来可能会使 GC 变慢。
JVM 堆大小决定了 VM 收集垃圾的频率和时间。可接受的垃圾收集率是特定于应用程序的，应在分析垃圾收集的实际时间和频率后进行调整。如果设置较大的堆大小，则完全垃圾回收会较慢，但发生的频率较低。如果根据内存需求设置堆大小，则完全垃圾收集会更快，但发生的频率更高。