首先，规范和现实之间是有区别的。规范说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()实际上是一种平台特定形式的优化(其中“平台”是硬件架构、OS、JVM版本和可能的更多运行时参数(如可用的RAM)的组合)，因为它的行为虽然在特定平台上大致可预测，但在不同平台之间可能(也将)有很大差异。

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

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

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

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.

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

(下面的评论适用于在带有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()的工作，即使是作为最后的手段。