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

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

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

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

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

(下面的评论适用于在带有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.

GC效率依赖于许多启发式方法。例如，一个常见的启发是，对对象的写访问通常发生在不久前创建的对象上。另一个原因是许多对象的寿命非常短(有些对象会使用很长时间，但许多对象在创建后几微秒就会被丢弃)。

调用System.gc()就像踢掉GC。它的意思是:“所有那些精心调整的参数，那些聪明的组织，所有你投入到分配和管理对象上的努力，让事情顺利进行，好吧，放弃所有这些，从头开始”。它可以提高性能，但大多数时候它只会降低性能。

要可靠地(*)使用System.gc()，您需要了解GC的所有细节。如果使用其他供应商的JVM，或者使用同一供应商的下一个版本，或者使用相同JVM但命令行选项略有不同，那么这些细节可能会发生很大变化。因此，这很少是一个好主意，除非你想解决一个你控制所有这些参数的特定问题。因此就有了“坏做法”的概念:这并没有被禁止，方法是存在的，但它很少有回报。

我在这里谈论的是效率。System.gc()永远不会破坏正确的Java程序。它既不会产生JVM无法获得的额外内存:在抛出OutOfMemoryError之前，JVM会执行System.gc()的工作，即使是作为最后的手段。

也许我写的代码很糟糕，但我已经意识到在eclipse和netbeans ide上点击垃圾桶图标是一个“好的实践”。

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

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

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

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

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

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

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

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

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