I know there is no "right" heap size, but which heap size do you use in your applications (application type, jdk, os)?
The JVM Options -Xms (initial/minimum) and -Xmx (maximum) allow for controlling the heap size. What settings make sense under which circumstances? When are the defaults appropriate?
您必须尝试您的应用程序并查看它的性能。例如，我以前总是开箱即用地运行 IDEA，直到我得到这份新工作，我在这个庞大的单体项目上工作。在编译整个项目时，IDEA 运行非常缓慢并且经常抛出内存错误。
我做的第一件事是将堆增加到 1 gig。这摆脱了内存不足的问题，但它仍然很慢。我还注意到 IDEA 经常冻结 10 秒左右，之后使用的内存被减半，然后再次增加，这引发了垃圾收集的想法。我现在将它与 -Xms512m、-Xmx768m 一起使用，但我还添加了 -Xincgc，以激活增量垃圾收集
结果，我的旧 IDEA 又回来了：它运行平稳，不再冻结，并且从不使用超过 600m 的堆。
对于您的应用程序，您必须使用类似的方法。尝试确定典型的内存使用情况并调整堆以使应用程序在这些条件下运行良好。但也让高级用户调整设置，以解决不寻常的数据负载。
这取决于应用程序类型。桌面应用程序与 Web 应用程序有很大不同。应用程序服务器与独立应用程序有很大不同。
它还取决于您使用的 JVM。JDK5 和更高版本 6 包含有助于了解如何调整应用程序的增强功能。
堆大小很重要，但了解它如何与垃圾收集器一起使用也很重要。
Actually I always considered it very strange that Java limits the heap size. A native application can usually use as much heap as it wants, until it runs out of virtual address space. The only reason to limit the heap in Java seems the garbage collector, which has a certain kind of "laziness" and may not garbage collect objects, unless there is a necessity to do so. That means if you choose the heap too big, your app constantly uses more memory than is really necessary.
However, Sun has improved the GC a lot over the years and to emulate the behavior of a native C app, I would set the initial heap size to 32 MB (for small programs) or 64 MB (for bigger ones) and the maximum to something between 1-2 GB. If your app really needs over a 1 GB of memory, it is most likely broken (unless you deal with data objects that large), but I see no reason why your app should be killed, just because it goes over a certain heap size.
Of course, this is referring to normal PCs. If you create Java code for mobile phones or other limited devices, you should probably adopt the initial and maximum heap size to the limitations of that device.
Typically i try not to use heaps which are larger than 1GB. It will cost you on major garbage collections.
Sometime it is better to split your application to a few JVM on the same machine and not you large heap sizes.
Major collection with a large heap size can take >10 mintues (on unoptimized GC applications).
This is entirely dependent on your application and any hardware limitations you may have. There is no one size fits all.
jmap can be used to have a look at what heap you are actually using and is a good starting point for right-sizing the heap.
您需要在 JConsole 或 visualvm 中花费相当长的时间才能清楚地了解高原内存使用情况。等到一切都稳定了，你就会看到堆内存使用的特征锯齿曲线。峰值应该是您的 70-80% 堆，具体取决于您使用的垃圾收集器。
当堆使用量达到一定百分比时，大多数垃圾收集器都会触发完整的 GC。这个百分比是最大堆的 60% 到 80%，具体取决于所涉及的策略。
1.3Gb 用于重型 GUI 应用程序。
不幸的是，在 Linux 上，JVM 似乎在这种情况下预先请求了 1.3G 的虚拟内存，即使不需要，这看起来也很糟糕（并且会引起用户的很多困惑的抱怨）
在我最占用内存的应用程序上：
-Xms250M -Xmx1500M -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC