JavaRunTime.Max内存不正确?

从文件中,

最大内存() 返回Java虚拟机将尝试使用的最大内存量。

顶部只显示系统分配给进程的(虚拟)内存量——您询问Java在最坏的情况下可以使用多少。

通常,查询JVM和/或系统以获取有关实际使用内存的信息是不可靠的。例如,Top的数字可能包括已分配但未使用或已调出的内存。它还可以包括共享库之类的内容,其中一个10MB库可以计算两个进程的分配,但在内存中只有一个物理副本。(例如)

你想做什么?

该方法的javadocs是错误的,或者至少是非常误导的。这个 Sun bug report 解释。

另一点是,显示为res的156MB是当前的“常驻集”大小,即当前归属于应用程序的物理RAM的数量。根据系统服务/守护程序和计算机上运行的应用程序的虚拟内存需求,此数字可能会增加或减少。JVM打算报告的数字是JVM的虚拟内存分配。

只要说这一切都像泥一样清楚,可能不值得你努力去弄清楚。如果你真的在乎,注意什么 top , vmstat 等等,告诉你,忽略JVM编号。

runtime.getruntime().maxmemory()返回最大堆大小的估计值,而不是整个进程将消耗的内存总量。本机内存、本机库等将影响进程大小,但不会影响maxmemory()。

如果您试图理解为什么top显示的内存消耗比JVM中设置的多。

这是我过去的经验

我们已经看到top和其他类似的实用程序显示消耗的内存比我们最初在jvm参数中设置的要多。

在我们的案例中,环境是: AIX/WebSphere应用程序服务器。

原因是: 我们在类路径中定义了一个共享库,我们在应用程序中使用它。 这个特定的库(pureedgeapi) 实际上跨越另一个进程或进行JNI调用 . (为清晰起见,图书馆很少) 在我们几个不正确的调用之后——我的意思是不通过调用这个objects.destroy()来破坏它,而不仅仅是将它设置为空。我们已经看到在使用2GB(最大设置)的JVM上内存提升到30GB的水平。

从操作系统的角度 因为Java是原始进程——这个JNI调用的所有子实例也被记录为使用它的同一Java父进程。

我没有命令HANDY——但我实际上会看到这个特定过程的树(这可能产生了另一个进程(在Java中)。

谢谢您,