在回答了有关如何使用强制释放Java中的对象（那个家伙正在清除1.5GB的HashMap）的问题后System.gc()，有人告诉我System.gc()手动调用是一种不好的做法，但是注释并不完全令人信服。此外，似乎没有人敢于赞成，也没有反对我的答案。
System.gc()
有人告诉我这是一种不好的做法，但是后来我又被告知，垃圾收集器的运行不再系统地停止世界，而且它也可以有效地被JVM用作提示，所以我有点不知所措。
我确实知道，JVM在需要回收内存时通常比你了解更多。我也了解担心数千字节的数据是愚蠢的。我也了解到，即使是数百万字节的数据也已不是几年前的样子。但还是1.5 GB？而且你知道内存中大约有1.5 GB的数据悬空。这不像是在黑暗中拍摄。是System.gc()系统上的问题，还是在某种程度上可以解决？
因此，问题实际上是双重的：
每个人都总是要避免的原因System.gc()是，这从根本上破坏了代码。依靠它来确保正确性的任何代码肯定会损坏；任何依靠它来提高性能的方法都很可能被破坏了。
你不知道要运行哪种垃圾收集器。当然，有些JVM不能像你所说的那样“停止运行”，但是某些JVM并不那么聪明，或者由于各种原因（也许它们在电话上？）没有做到这一点。你不知道该怎么办。
另外，也不保证会做任何事情。JVM可能会完全忽略你的请求。
人们通常这么大胆地说：“你不知道它会做什么，”“你甚至不知道它是否会帮助”，以及“你无论如何都不必称呼它”。你不应该这样称呼它。我认为这是“如果你需要询问是否应该使用此功能，则不应该使用”的情况
编辑以解决其他线程的一些问题：
阅读了你链接的线程后，我还要指出几件事。首先，有人建议调用gc()可以将内存返回给系统。这不一定是正确的-Java堆本身独立于Java分配而增长。
与之类似，JVM将保留内存（数十兆字节）并根据需要增加堆。即使释放Java对象，它也不一定会将该内存返回给系统。完全免费地保留已分配的内存以用于将来的Java分配。
已经说明了调用system.gc() 可能无能为力，并且“需要”垃圾收集器运行的任何代码都已损坏。
但是，称其为不好的做法的务实原因System.gc()是效率低下。在最坏的情况下，它效率极低！让我解释。
典型的GC算法通过遍历堆中的所有非垃圾对象来识别垃圾，并推断未访问的任何对象都必须是垃圾。由此，我们可以对垃圾收集的总工作进行建模，其中一个部分与实时数据量成正比，另一部分与垃圾量成正比。即work = (live * W1 + garbage * W2)。
现在，假设您在单线程应用程序中执行以下操作。
System.gc(); System.gc();
（我们预测）第一个调用将(live * W1 + garbage * W2)起作用，并消除未完成的垃圾。
第二个呼叫将(live* W1 + 0 * W2)起作用，并且不回收任何内容。换句话说，我们已经完成了(live * W1)工作，却一无所获。
我们可以将收集器的效率建模为收集一个垃圾单元所需的工作量。即efficiency = (live * W1 + garbage * W2) / garbage。因此，为了使GC尽可能高效，我们需要最大化garbage运行GC时的价值。即等待直到堆满。（而且，使堆尽可能大。但这是一个单独的主题。）
如果应用程序不干扰（通过调用System.gc()），则GC将等待直到堆满为止再运行，从而有效地收集了垃圾1。但是，如果应用程序强制GC运行，则可能是堆不会满，结果是垃圾回收效率低下。而且，应用程序强制使用GC的频率越高，GC的效率就越高。
注意：以上解释掩盖了以下事实：典型的现代GC将堆划分为“空间”，GC可以动态扩展堆，应用程序的非垃圾对象的工作集可能会发生变化等等。即使这样，所有基本垃圾收集器2的基本原理仍然相同。强制GC运行效率低下。
1-这就是“吞吐量”收集器的工作方式。诸如CMS和G1之类的并发收集器使用不同的标准来决定何时启动垃圾收集器。
2-我还排除了仅使用引用计数的内存管理器，但是当前的Java实现都没有使用该方法…是有充分理由的。
