在分析有一些问题的64位Java应用程序的过程中，我注意到探查器本身(YourKit)使用的内存确实非常大。 YourKit启动脚本中包含以下内容:
JAVA_HEAP_LIMIT="-Xmx3072m -XX:PermSize=256m -XX:MaxPermSize=768m"
天真地假设一些开销，这会让我猜测YourKit将使用最多4 GB的内存。但是，我在PS中实际看到的是:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
dmoles 31379 4.4 68.2 14440032 8321396 ? Sl 11:47 10:42 java -Xmx3072m -XX:PermSize=256m -XX:MaxPermSize=768m -XX:+HeapDumpOnOutOfMemoryError -Dyjp.probe.table.length.limit=20000 -Xbootclasspath/a:/home/dmoles/Applications/yjp-9.5.6/bin/../lib/tools.jar -jar /home/dmoles/Applications/yjp-9.5.6/bin/../lib/yjp.jar
虚拟大小接近14 GB，常驻大小接近8 GB，几乎是Java堆的3倍。
现在，我的开发箱上有足够的内存来运行此内存，但回到我试图诊断的原始内存问题:我怎么知道必须使用多少Java堆？
显然，如果客户拥有16 GB的物理RAM，那么告诉他们将
-Xmx设置为16 GB对我来说不是一个好主意。那么合理的数字是多少？ 12 GB？ 8 GB？
我怎么估计呢？
最佳答案
如果客户在他/她的机器上没有其他重要的操作，那么将堆大小设置为16G不一定是个坏主意。这取决于应用程序在做什么。
理想的数量应该是“JVM最大堆+ JVM非堆开销+ OS +其他 Activity 应用程序的工作集+缓冲区高速缓存工作集”加到物理内存量上。但是问题在于，如果没有在客户计算机上进行详细的测量，则无法固定这些组件(除了最大堆大小之外)……而当应用程序运行于实际问题上时。
底线是你不能。您能做的最好的就是猜测……并保持保守。
一种替代方法是估计应用程序实际要解决的问题实际需要多少堆。然后再添加50％或100％，以使GC的空间有效地工作。 (然后调谐...)