【问题标题】:why virtual memory allocation is far higher than resident memory allocation for interpreted languages为什么虚拟内存分配远高于解释语言的常驻内存分配
【发布时间】:2013-05-28 13:53:37
【问题描述】:

我在许多语言中都注意到了这一点,包括

  • C#
  • Java
  • Python
  • JS

以及由某些解释器(通常具有垃圾收集器)解释的许多其他语言。

当我检查系统(unix)上的内存使用情况时 - 任何系统(我在许多不同的服务器上尝试过)。我可以看到分配的虚拟内存和常驻内存(实际被吃掉的真实物理内存)之间的巨大差异。

这不是 c 或 c++ 等语言的情况。

例如,使用 30mb 常驻内存的 java 应用程序可以使用 2gb 的虚拟内存,这也适用于其他解释语言。当然,这种情况并非每次都会发生(并非在所有情况下差异都很大),但在大多数情况下会相当大。

或样本(这实际上是真实数据) 使用 136MB 常驻内存但 1661MB 虚拟内存的 c# 应用程序 MonoDevelop

强大的 c++ 应用程序也有例外,例如 firefox 似乎也有同样的问题,据我所知,它也使用垃圾收集器

这对于每个基于虚拟内存限制内存的系统来说都是一个问题(这实际上是一种正确的方法,因为操作系统应该保证分配给进程的虚拟内存量实际上可用于该进程) .

这是为什么呢?

【问题讨论】:

  • 除其他外,这取决于拉入了多少库代码。

标签: memory


【解决方案1】:

您将 30 MB 虚拟转换为 2 GB 虚拟的引用并不是普遍规律。

我习惯于部署到 Java EE 容器(例如 JBOSS)的 Java 应用程序。容器本身就是一个应用程序。它将大量 JAR 加载到堆外的驻留内存中。整个 JAR 被加载,而不仅仅是所需的几个类。所有这些都有助于总驻留内存。

还有其他对总驻留内存的贡献。例如,每个创建的线程都会为其线程堆栈获取约 1 MB 的内存。因此,多线程代码会占用更多内存。

大多数 C/C++ 应用程序都编译为 .exe 并在操作系统控制下自行运行。没有虚拟机需要考虑,所以这总是对他们有利。您引用的所有基于 VM 的语言都是如此。

也许它们是多线程的不太常见,因此它们缺少这种贡献。链接共享库不同于加载 JAR。

我认为所有这些因素都可以解释这种差异。

【讨论】:

  • 是的,你是对的,这不是 /every/ 进程的情况,但它们中的大多数,确实比常驻内存吃更多的 vmem...
  • 我会说总驻留内存>堆内存根据定义。这并不奇怪。超出堆的数量因应用而异。
猜你喜欢
  • 1970-01-01
  • 2011-03-08
  • 2015-12-17
  • 2011-09-26
  • 2020-07-18
  • 1970-01-01
  • 1970-01-01
  • 2012-03-13
  • 2012-09-02
相关资源
最近更新 更多