根据我的经验，使用System.gc()实际上是一种平台特定形式的优化(其中“平台”是硬件架构、OS、JVM版本和可能的更多运行时参数(如可用的RAM)的组合)，因为它的行为虽然在特定平台上大致可预测，但在不同平台之间可能(也将)有很大差异。

是的，在某些情况下System.gc()将提高(可感知的)性能。举个例子，如果延迟在你的应用的某些部分是可以容忍的，但在其他部分却不能(就像上文所提到的游戏例子，你希望GC发生在关卡开始时，而不是在关卡进行时)。

然而，它是帮助还是伤害(或什么都不做)在很大程度上取决于平台(如上所定义)。

所以我认为这是针对特定平台的最后一种优化方法(即如果其他性能优化还不够的话)。但是，您绝不应该仅仅因为相信它可能有帮助(没有特定的基准)就调用它，因为它很可能没有帮助。

每个人总是说要避免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在必要时仍然执行垃圾收集。

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

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

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

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

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

首先，规范和现实之间是有区别的。规范说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偶尔发出的调用也会对性能造成破坏。

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

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

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

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

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

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

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

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

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

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

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

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