很多人似乎都告诉你不要这样做。我不同意。如果在加载关卡等大型加载过程后，你认为:

您有很多不可访问的对象，可能还没有被gc - ed。而且 您认为此时用户可以忍受轻微的减速

调用System.gc()没有害处。我把它看作c/c++的内联关键字。这只是对gc的一个提示，即您(开发人员)已经决定时间/性能不像通常那样重要，其中一些时间/性能可以用于回收内存。

建议不要依赖它做任何事情是正确的。不要依赖于它的工作，但给一个提示，现在是一个可以接受的时间收集是完全可以的。我宁愿把时间浪费在代码中无关紧要的地方(加载屏幕)，也不愿浪费在用户与程序积极互动的时候(比如在游戏关卡中)。

有一次，我将强制收集:当试图找出是一个特定的对象泄漏(本机代码或大型，复杂的回调交互。哦，还有任何UI组件，哪怕只是瞥了一眼Matlab。)在产品代码中不应该使用这种方法。

Since objects are dynamically allocated by using the new operator, you might be wondering how such objects are destroyed and their memory released for later reallocation. In some languages, such as C++, dynamically allocated objects must be manually released by use of a delete operator. Java takes a different approach; it handles deallocation for you automatically. The technique that accomplishes this is called garbage collection. It works like this: when no references to an object exist, that object is assumed to be no longer needed, and the memory occupied by the object can be reclaimed. There is no explicit need to destroy objects as in C++. Garbage collection only occurs sporadically (if at all) during the execution of your program. It will not occur simply because one or more objects exist that are no longer used. Furthermore, different Java run-time implementations will take varying approaches to garbage collection, but for the most part, you should not have to think about it while writing your programs.

每个人总是说要避免System.gc()的原因是，它是一个很好的指示器，显示出从根本上坏掉的代码。任何依赖于它的正确性的代码肯定是坏的;任何依赖于它的性能都很可能是坏的。

您不知道您正在哪种垃圾收集器下运行。当然，有一些jvm并没有像您断言的那样“停止世界”，但是有些jvm并没有那么聪明，或者由于各种原因(也许它们在电话上?)没有做到这一点。你不知道它会做什么。

而且，它不能保证做任何事情。JVM可能会完全忽略您的请求。

“你不知道它会做什么”，“你甚至不知道它是否有用”，以及“你无论如何都不需要调用它”，这就是为什么人们如此强烈地说，一般来说你不应该调用它。我认为这是一个“如果你需要问你是否应该使用这个，你不应该”的案例

EDIT来解决其他线程的一些问题:

在阅读了你链接的帖子后，还有一些事情我想指出来。 首先，有人建议调用gc()可能会向系统返回内存。这当然不一定是正确的——Java堆本身的增长独立于Java分配。

例如，JVM将保留内存(几十兆字节)，并根据需要增加堆。即使在释放Java对象时，它也不一定会将内存返回给系统;保留已分配的内存以供将来的Java分配使用是完全自由的。

为了显示System.gc()可能什么也不做，请查看 JDK bug 6668279 特别是有一个-XX:DisableExplicitGC VM选项:

默认情况下，对System.gc()的调用是启用的(-XX:-DisableExplicitGC)。使用-XX:+DisableExplicitGC禁用对System.gc()的调用。请注意，JVM在必要时仍然执行垃圾收集。

很多人似乎都告诉你不要这样做。我不同意。如果在加载关卡等大型加载过程后，你认为:

您有很多不可访问的对象，可能还没有被gc - ed。而且 您认为此时用户可以忍受轻微的减速

调用System.gc()没有害处。我把它看作c/c++的内联关键字。这只是对gc的一个提示，即您(开发人员)已经决定时间/性能不像通常那样重要，其中一些时间/性能可以用于回收内存。

建议不要依赖它做任何事情是正确的。不要依赖于它的工作，但给一个提示，现在是一个可以接受的时间收集是完全可以的。我宁愿把时间浪费在代码中无关紧要的地方(加载屏幕)，也不愿浪费在用户与程序积极互动的时候(比如在游戏关卡中)。

有一次，我将强制收集:当试图找出是一个特定的对象泄漏(本机代码或大型，复杂的回调交互。哦，还有任何UI组件，哪怕只是瞥了一眼Matlab。)在产品代码中不应该使用这种方法。

人们已经很好地解释了为什么不使用它，所以我将告诉你一些你应该使用它的情况:

(下面的评论适用于在带有CMS收集器的Linux上运行的Hotspot，在这里我有信心地说System.gc()实际上总是调用完整的垃圾收集)。

After the initial work of starting up your application, you may be a terrible state of memory usage. Half your tenured generation could be full of garbage, meaning that you are that much closer to your first CMS. In applications where that matters, it is not a bad idea to call System.gc() to "reset" your heap to the starting state of live data. Along the same lines as #1, if you monitor your heap usage closely, you want to have an accurate reading of what your baseline memory usage is. If the first 2 minutes of your application's uptime is all initialization, your data is going to be messed up unless you force (ahem... "suggest") the full gc up front. You may have an application that is designed to never promote anything to the tenured generation while it is running. But maybe you need to initialize some data up-front that is not-so-huge as to automatically get moved to the tenured generation. Unless you call System.gc() after everything is set up, your data could sit in the new generation until the time comes for it to get promoted. All of a sudden your super-duper low-latency, low-GC application gets hit with a HUGE (relatively speaking, of course) latency penalty for promoting those objects during normal operations. It is sometimes useful to have a System.gc call available in a production application for verifying the existence of a memory leak. If you know that the set of live data at time X should exist in a certain ratio to the set of live data at time Y, then it could be useful to call System.gc() a time X and time Y and compare memory usage.

这是一个非常麻烦的问题，我觉得这是许多人反对Java的原因，尽管它是一种多么有用的语言。

你不能相信"系统"gc”来做任何事情都令人难以置信地令人生畏，并且很容易调用“恐惧，不确定，怀疑”的语言感觉。

在许多情况下，在重要事件发生之前处理您故意引起的内存峰值是很好的，这将导致用户认为您的程序设计很糟糕/反应迟钝。

拥有控制垃圾收集的能力将是一个非常好的教育工具，进而提高人们对垃圾收集如何工作以及如何使程序利用其默认行为和受控行为的理解。

让我回顾一下这篇文章的论点。

效率低下:

通常情况下，程序可能什么都不做，而您知道它什么都不做是因为它的设计方式。例如，它可能正在使用一个大的等待消息框进行某种长时间的等待，最后它可能会添加一个调用来收集垃圾，因为运行它的时间只占长等待时间的一小部分，但可以避免gc在更重要的操作中间发生故障。

这是一种不好的做法，表明代码有问题。

我不同意，不管你有什么垃圾收集器。它的工作是追踪垃圾并清理垃圾。

通过在使用不那么关键的时候调用gc，当您的生命依赖于正在运行的特定代码，但它却决定收集垃圾时，您可以减少gc运行的几率。

当然，它的行为可能不是您想要或期望的方式，但当您确实想要调用它时，您知道什么都没有发生，并且用户愿意容忍缓慢/停机。如果系统。Gc工作，太棒了!如果没有，至少你试过了。没有任何缺点，除非垃圾收集器具有固有的副作用，会对手动调用垃圾收集器的行为产生可怕的意想不到的影响，而这本身就会引起不信任。

这不是一个常见的用例:

这是一个不能可靠地实现的用例，但如果系统以这种方式设计，则可以实现。这就像做一个交通灯，让它的一些/所有的交通灯的按钮不做任何事情，这让你质疑为什么按钮在那里开始，javascript没有垃圾收集功能，所以我们没有仔细检查它。

规范说System.gc()提示GC应该运行，VM可以忽略它。

什么是“暗示”?什么是“忽略”?计算机不能简单地接受暗示或忽略某些东西，它所采取的严格行为路径可能是动态的，由系统的意图指导。一个正确的答案应该包括垃圾收集器在实现级别上实际做了什么，导致它在您请求它时不执行收集。这个功能只是一个nop吗?有什么条件是必须满足的吗?这些条件是什么?

就目前的情况而言，Java的GC通常看起来像一个不值得信任的怪物。你不知道它什么时候来，什么时候走，你不知道它会做什么，它会怎么做。我可以想象一些专家对他们的垃圾收集如何在每条指令的基础上工作有更好的想法，但绝大多数人只是希望它“只是工作”，不得不相信一个看起来不透明的算法为你工作是令人沮丧的。

阅读一些东西或学习一些东西，与实际看到它的实现，不同系统之间的差异，以及能够在不查看源代码的情况下使用它之间有很大的差距。这会创造自信和掌控/理解/控制的感觉。

总而言之，“这个功能可能不会做任何事情，我不会详细说明它什么时候会做什么事情，什么时候不会做，为什么不会或会做，这通常意味着尝试这样做是违反哲学的，即使背后的意图是合理的”，这是一个固有的问题。

It might be okay for Java GC to behave the way it does, or it might not, but to understand it, it is difficult to truly follow in which direction to go to get a comprehensive overview of what you can trust the GC to do and not to do, so it's too easy simply distrust the language, because the purpose of a language is to have controlled behavior up to philosophical extent(it's easy for a programmer, especially novices to fall into existential crisis from certain system/language behaviors) you are capable of tolerating(and if you can't, you just won't use the language until you have to), and more things you can't control for no known reason why you can't control them is inherently harmful.