Java Eclipse将堆释放回系统

我将Eclipse3.6与Linux上最新的Sun Java 6（64位）一起用于大量大型项目。在某些特殊情况下（例如SVN更新），Eclipse需要高达1GB的堆。但大多数时候它只需要350MB。当我启用“堆状态”面板时，大多数情况下都会看到：

350米，878米

我使用以下设置启动Eclipse：-Xms128m-Xmx1024m

因此，在大多数情况下，大量的MB只是被浪费了，而且在内存使用量达到峰值的时间很短时很少被使用。我一点也不喜欢这样，我希望Eclipse将内存释放回系统，以便我可以将其用于其他程序

当Eclipse需要更多的内存，而没有足够的可用RAM，Linux无法替换其他正在运行的程序时，我可以接受这一点。我听说有一个-XX:MaxHeapFreeRatio选项。但我从来没有弄清楚我必须使用什么样的价值观，这样它才能起作用。我尝试过的任何价值都没有改变

---

那么，我如何告诉Eclipse（或Java）释放未使用的堆呢？

您可以转到

首选项->常规

并检查

显示堆状态

。这将在Eclipse的角落中激活堆的良好视图。大概是这样的：

---

如果单击垃圾箱，它将尝试运行垃圾收集并返回内存。

Java的堆不过是JVM进程堆空间中管理的大数据结构。这两个堆在逻辑上是独立的实体，即使它们占用相同的内存

JVM受制于主机系统的

malloc（）

实现，它使用

brk（）

从系统分配内存。在Linux系统（Solaris也是如此）上，分配给进程堆的内存几乎永远不会返回，这主要是因为它变得支离破碎，堆必须是连续的。这意味着分配给进程的内存将单调地增加，而保持较小大小的唯一方法是不首先分配内存

-Xms

和

-Xmx

告诉JVM如何提前调整Java堆的大小，从而使其分配进程内存。Java可以进行垃圾收集，直到太阳熄灭，但这种清理是JVM内部的，支持它的进程内存不会返回

---

根据以下评论进行详细阐述：

用C编写的程序（尤其是运行Eclipse的JVM）分配内存的标准方法是调用

malloc（3）

，它使用操作系统提供的机制为进程分配内存，然后在这些分配中管理各个分配。有关

malloc（）

和

free（）

如何工作的详细信息是特定于实现的

---

在大多数风格的Unix上，进程只获得一个数据段，这是一个连续的内存区域，具有指向开始和结束的指针。进程可以通过调用

brk（2）

并增加结束指针以分配更多内存或减少结束指针以将其返回系统来调整此段的大小。只有末端可以调整。这意味着，如果

malloc（）

的实现放大了数据段，则

free（）

的相应实现无法缩小数据段，除非它确定末尾有未使用的空间。实际上，使用

malloc（）

分配的巨大内存块在

free（）

释放时很少在数据段的最末端结束，这就是进程趋向于单调增长的原因。

找到了解决方案。我将Java转换为使用G1垃圾收集器，现在HeapFreeRatio参数按预期工作。因此，我在eclipse.ini中使用以下选项：

-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:MinHeapFreeRatio=5
-XX:MaxHeapFreeRatio=25

---

现在，当Eclipse为一个复杂的操作占用超过1GB的RAM，并在垃圾收集后切换回300MB时，内存实际上会释放回操作系统。

您是否使用Xms Xmx设置尝试过这个Eclipse.ini（）？我知道这个状态显示（甚至在我的问题中提到过它）我知道这个垃圾按钮，但它只运行垃圾收集器，不向系统返回任何内存。因此，如果Eclipse的内存使用峰值很短，为1 GB，那么堆大小将永远保持在1 GB（直到我重新启动Eclipse），即使实际使用的堆只有300 MB。这是否意味着这是操作系统问题，并且内存在Windows上正确返回到系统？有没有官方消息来源表明它在Linux上不起作用？这不是操作系统的问题。在您的例子中，它是JVM为Java堆分配了多少进程内存、如何释放以及JVM使用的分配器（通常是libc的

malloc（）

）如何处理进程内存的组合。我在最初的回答中对此做了更多的阐述。任何关于特定实现行为的“官方声明”都将是该实现的来源。