首先，规范和现实之间是有区别的。规范说System.gc()提示GC应该运行，VM可以忽略它。实际情况是，VM永远不会忽略对System.gc()的调用。

Calling GC comes with a non-trivial overhead to the call and if you do this at some random point in time it's likely you'll see no reward for your efforts. On the other hand, a naturally triggered collection is very likely to recoup the costs of the call. If you have information that indicates that a GC should be run than you can make the call to System.gc() and you should see benefits. However, it's my experience that this happens only in a few edge cases as it's very unlikely that you'll have enough information to understand if and when System.gc() should be called.

这里列出了一个例子，在IDE中敲击垃圾桶。如果你要去开会，为什么不去呢?开销不会影响您，当您返回时，可能会清理堆。在生产系统中执行此操作，频繁调用收集将使其彻底停止!即使是RMI偶尔发出的调用也会对性能造成破坏。

前面已经解释过，调用system.gc()可能什么都不做，任何“需要”垃圾收集器运行的代码都是坏的。

然而，调用System.gc()是一种糟糕的实践，其实际原因是它效率低下。在最坏的情况下，它的效率非常低!让我解释一下。

典型的GC算法通过遍历堆中的所有非垃圾对象来识别垃圾，并推断任何未访问的对象都必须是垃圾。由此，我们可以对垃圾收集的总工作进行建模，其中一部分与活动数据量成正比，另一部分与垃圾量成正比;即工作=(生活* W1 +垃圾* W2)。

现在假设您在单线程应用程序中执行以下操作。

System.gc(); System.gc();

第一个调用将(我们预测)做(活* W1 +垃圾* W2)工作，并摆脱未处理的垃圾。

第二个调用将执行(live* W1 + 0 * W2)工作，并且不回收任何东西。换句话说，我们做了(活的)工作，却一事无成。

我们可以将收集器的效率建模为收集一个单位垃圾所需的工作量;即效率=(活* W1 +垃圾* W2) /垃圾。因此，为了使GC尽可能高效，我们需要在运行GC时最大化垃圾的价值;也就是说，一直等到堆满。(并且，使堆尽可能大。但这是另一个话题。)

如果应用程序不进行干预(通过调用System.gc())， GC将等到堆满才运行，从而有效地收集garbage1。但是，如果应用程序强制GC运行，则堆可能不会满，结果将是垃圾收集效率低下。应用程序强制GC的频率越高，GC的效率就越低。

注意:上面的解释掩盖了一个事实，即典型的现代GC将堆划分为“空间”，GC可能会动态扩展堆，应用程序的非垃圾对象的工作集可能会变化等等。即便如此，同样的基本原则也适用于所有真正的垃圾收集器2。强制GC运行效率很低。

1 -这就是“吞吐量”收集器的工作原理。并发收集器(如CMS和G1)使用不同的标准来决定何时启动垃圾收集器。

2 -我也排除了专门使用引用计数的内存管理器，但目前没有Java实现使用这种方法…理由很充分。

是的，调用System.gc()并不能保证它会运行，它是对JVM的请求，可能会被忽略。从文档中可以看出:

调用gc方法表明Java虚拟机将精力用于回收未使用的对象

调用它几乎总是一个坏主意，因为自动内存管理通常比您更了解何时进行gc。当它的内部空闲内存池很低时，或者当操作系统要求归还一些内存时，它会这样做。

如果知道System.gc()有帮助，调用它可能是可以接受的。我的意思是，您已经在部署平台上对两个场景的行为进行了彻底的测试和测量，并且可以证明这是有帮助的。但是要注意gc是不容易预测的-它可能在一次运行中有帮助，在另一次运行中有伤害。

有时(不是经常!)您确实比运行时更了解过去、当前和将来的内存使用情况。这种情况并不经常发生，而且我敢说，在web应用程序中，当提供正常页面时，这种情况绝不会发生。

很多年前，我在一个报告生成器上工作

只有一根线 从队列中读取“报告请求” 从数据库加载报告所需的数据 生成报告并通过电子邮件发送出去。 没完没了地重复，没有特别的要求就睡去。 它没有在报告之间重复使用任何数据，也没有进行任何兑现。

首先，因为它不是实时的，而且用户希望等待报告，GC运行时的延迟不是问题，但是我们需要以比请求更快的速度生成报告。

看了上面的过程大纲，很明显。

我们知道，在报告通过电子邮件发送出去之后，活动对象会非常少，因为下一个请求还没有开始处理。 众所周知，运行垃圾收集周期的成本取决于活动对象的数量，垃圾的数量对GC运行的成本几乎没有影响。 当队列为空时，没有什么更好的事情可做，然后运行GC。

因此，当请求队列为空时执行GC运行显然是非常值得的;这并没有什么坏处。

在每个报告通过电子邮件发送之后执行GC运行可能是值得的，因为我们知道这是GC运行的好时机。但是，如果计算机有足够的ram，则可以通过延迟GC运行来获得更好的结果。

这种行为是在每个安装基础上配置的，对于一些客户来说，在每个报告之后启用强制GC可以大大加快报告的生成速度。(我认为这是由于他们服务器上的内存较低，并且运行了许多其他进程，因此强制GC减少了分页。)

每次工作队列为空时，我们从未检测到一个安装没有从强制GC运行中获益。

但是，需要明确的是，上述情况并不常见。

现在，我更倾向于在单独的进程中运行每个报告，让操作系统清理内存，而不是使用垃圾收集器，并让自定义队列管理器服务在大型服务器上使用多个工作进程。

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

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

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

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

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

这是一个非常麻烦的问题，我觉得这是许多人反对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.