blocks|key|2524368|text|我的主要原因是确保JVM内存使用量适合可用RAM。假设我有3个tomcat实例在8g内存的机器上运行。对于每个虚拟机，我可能会将mX设置为2g左右，而对于os和其他虚拟机，我可能会设置为2g。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2524369|如果强制JVM进行交换，那么当垃圾收集器在对象树中导航时，可能会产生巨大的性能问题。|2524370|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

My main reason would be to insure that JVM memory usage fits in the available RAM. Say I had 3 tomcat instances running on machine with 8g of ram. I would probably set the mX to around 2g for each vm and allow 2g for os and other.

If the JVM is forced into swap it can give huge performance problems as the garbage collector navigates the object tree.

blocks|key|23526|text|我相信如果内存更大，那么需要GC的频率就会更低，而且会有很多垃圾，因为GC可以轻松地拥有这么大的空间。然而，GC必须占用更多的内存，这反过来可能会使GC变慢。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|23527|JVM堆大小决定了VM收集垃圾的频率和时间。垃圾收集的可接受速率是特定于应用程序的，应该在分析垃圾收集的实际时间和频率之后进行调整。如果设置了较大的堆大小，则完全垃圾回收会较慢，但发生的频率较低。如果根据内存需求设置堆大小，则完全垃圾回收速度更快，但发生的频率更高。|23528|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I believe if the memoru is larger then less frequently it needs to be GC-ed and there can be lots of garbage as GC can relax with that much of room. However, the GC has to work on more memory ,which in turn might make the GC slower.

The JVM heap size determines how often and how long the VM spends collecting garbage. An acceptable rate for garbage collection is application-specific and should be adjusted after analyzing the actual time and frequency of garbage collections. If you set a large heap size, full garbage collection is slower, but it occurs less frequently. If you set your heap size in accordance with your memory needs, full garbage collection is faster, but occurs more frequently.

blocks|key|612818|text|不需要将-XMX-Parameter设置为低。只需将其设置为应用程序所需的值即可。但需要注意的是，使用较高的XMX值时，GC时间将会增加，因此您的应用程序可能不会响应(取决于您使用的收集器)。从个人经验来看，1G并不是很高。我有4G、8G或16G的JVM，它们运行得很好|type|unstyled|depth|inlineStyleRanges|entityRanges|data|612819|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There is no need to set the -XMX-Parameter low. Just set it to the value you need for your application. But it's important to notice, that with higher -XMX-Value the GC-Time will increase and therefore it can happen that your application will not respond (depending on what collector you use). Out of personal experience 1G is not very high. I've JVMs with 4G, 8G or 16G and they are running fine

blocks|key|2524380|text|-Xms和-Xmx参数分别定义最小和最大堆大小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2524381|由于GC是在代填满时发生的，因此吞吐量与可用内存量成反比。|2524382|缺省情况下，JVM在每个GC处增大或缩小堆，以尝试将每个集合中的活动对象的空闲空间比例保持在特定范围内。此范围由参数-XX:MinHeapFreeRatio=minimum和-XX:MaxHeapFreeRatio=maximum设置为百分比；总大小由-Xms和-Xmx限定。|2524383|oracle站点上提供了一些关于Java堆大小调整的指导原则，用于glassfish调优，但对于任何JVM都应该适用。|2524384|http://docs.oracle.com/cd/E18930_01/html/821-2431/abeic.html#abeij|offset|length|2524385|IBM的故障排除指南建议将特定于应用程序的堆使用率目标定为最低堆使用率约为40%25，最大堆使用率约为70%25|2524386|http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%252Fcom.ibm.java.doc.igaa%252F_1vg000139b8b453-11951f1e7ff-8000_1001.html|2524387|如果最大值较低，虚拟机是否会更有效地管理内存？|style|BOLD|2524388|也许，不过度分配堆大小的对象将更正确地‘填充’到正确的内存世代，因为具有较大的堆大小将执行较少的GC，这意味着更多的对象在年轻的世代中停留更长时间，这提供了更快的垃圾收集，但代价是内存使用量翻倍。|2524389|然而，我不认为有任何额外的开销是导致您的应用程序内存耗尽的原因，最有可能的原因是内存中存储了大对象，或者应用程序中的某个地方存在内存泄漏，这是比堆管理更紧迫的问题。|2524390|http://docs.oracle.com/javame/config/cdc/cdc-opt-impl/ojmeec/1.1/custom/html/tuning.htm|2524391|entityMap|0|LINK|mutability|MUTABLE|url|1|http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%252Fcom.ibm.java.doc.igaa%252F_1vg000139b8b453-11951f1e7ff-8000_1001.html|2^0|0|0|0|0|0|1U|0|0|0|0|3X|1|0|8|F|0|0|0|0|2F|2|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1A|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1B|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1C|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1D|8|@]|9|@$J|1E|K|1F|1|1G]]|A|$]]|$1|L|3|M|5|6|7|1H|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1I|8|@]|9|@$J|1J|K|1K|1|1L]]|A|$]]|$1|P|3|Q|5|6|7|1M|8|@$J|1N|K|1O|R|S]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1R|8|@]|9|@$J|1S|K|1T|1|1U]]|A|$]]|$1|Z|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|I]]|16|$5|12|13|14|A|$15|17]]|18|$5|12|13|14|A|$15|Y]]]]

The -Xms and -Xmx parameters define the minimum and maximum heap sizes, respectively. 

Since GC occurs when the generations fill up, throughput is inversely proportional to the amount of the memory available.

By default, the JVM grows or shrinks the heap at each GC to try to keep the proportion of free space to the living objects at each collection within a specific range. This range is set as a percentage by the parameters -XX:MinHeapFreeRatio=minimum and -XX:MaxHeapFreeRatio=maximum; and the total size bounded by -Xms and -Xmx.

There is some guidelines for Java Heap Sizing available on the oracle site for glassfish tuning but should hold true for any JVM.

<a href="http://docs.oracle.com/cd/E18930_01/html/821-2431/abeic.html#abeij" rel="nofollow">http://docs.oracle.com/cd/E18930_01/html/821-2431/abeic.html#abeij</a>

A troubleshooting guide from IBM recommends aiming for an application specific heap usage of a minimum heap usage of around 40% and a maximum heap usage of around 70%

<a href="http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%2Fcom.ibm.java.doc.igaa%2F_1vg000139b8b453-11951f1e7ff-8000_1001.html" rel="nofollow">http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%2Fcom.ibm.java.doc.igaa%2F_1vg000139b8b453-11951f1e7ff-8000_1001.html</a>

Does VM manage the memory more efficiently if the maximal value is lower?

Possibly, not over allocating the heap size objects will more correctly 'fill-out' to the correct memory generations since having a large heap size less GC will be performed meaning more objects sitting in the young generation for longer which provides faster garbage collection at the price of doubling the memory usage.

I would not see any additional overhead however being the cause of the your application running out of memory with a high maximum memory allocation as being the cause and its most likely there are large objects being stored in memory or there is a memory leak somewhere in the application that is the more pressing concern than heap management.

<a href="http://docs.oracle.com/javame/config/cdc/cdc-opt-impl/ojmeec/1.1/custom/html/tuning.htm" rel="nofollow">http://docs.oracle.com/javame/config/cdc/cdc-opt-impl/ojmeec/1.1/custom/html/tuning.htm</a>

We can set the maximal possible memory for a java heap space for our java VM with -Xmx, eg. -Xmx1g.

Why would one want to set -Xmx lower than some value if the priority is that java OutOfMemoryError heap space would not occur? Does VM manage the memory more efficiently if the maximal value is lower?

I constantly run into OutOfMemoryError and I have set -Xmx very high. The problem is that eventually I run out of physical memory too - so high Xmx alone is not sufficient. My current solution is to shut down my memory hungry applications which is very inconvenient as it slows down the development and testing.

What is the advantage of setting low Xmx for java heap space?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我们可以使用-Xmx为我们的java虚拟机设置java堆空间的最大可能内存，例如。-Xmx1g。如果优先级是不会出现java OutOfMemoryError堆空间，为什么要将-Xmx设置为低于某个值？如果最大值较低，虚拟机是否会更有效地管理内存？我经常遇到OutOfMemoryError，并且我将-Xmx设置得非常高。问题是，最终我也耗尽了物理内存-因此仅有高Xmx是不够的。我目前的解决方案是关

问为java堆空间设置较低的Xmx有什么好处？
EN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为java堆空间设置较低的Xmx有什么好处？EN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为java堆空间设置较低的Xmx有什么好处？
EN