在回答了一个关于如何使用System.gc()在Java中强制释放对象的问题(这个人正在清除1.5GB的HashMap)后，我被告知手动调用System.gc()是一种糟糕的做法，但评论并不完全令人信服。此外，似乎没有人敢对我的回答投赞成票，也没有人敢投反对票。
我在那里被告知这是一种糟糕的做法，但后来我又被告知垃圾收集器的运行不再系统地停止整个世界，而且JVM也只能有效地将其用作提示，所以我有点不知所措。
我知道JVM通常比您更了解何时需要回收内存。我也明白，担心几千字节的数据是愚蠢的。我也明白，即使是兆字节的数据也不如几年前了。但还是1.5 gb ?你知道大概有1.5 GB的数据在内存中;这又不是瞎猜的。System.gc()在系统上是坏的，还是在某个点上变得正常了?
所以这个问题实际上是双重的
Why is or isn't it bad practice to call System.gc()? Is it really merely a hint to the JVM under certain implementations, or is it always a full collection cycle? Are there really garbage collector implementations that can do their work without stopping the world? Please shed some light over the various assertions people have made in the comments to my answer.
Where's the threshold? Is it never a good idea to call System.gc(), or are there times when it's acceptable? If so, what are those times?
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()可能什么都不做，任何“需要”垃圾收集器运行的代码都是坏的。
然而，调用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实现使用这种方法…理由很充分。
很多人似乎都告诉你不要这样做。我不同意。如果在加载关卡等大型加载过程后，你认为:
您有很多不可访问的对象，可能还没有被gc - ed。而且
您认为此时用户可以忍受轻微的减速
调用System.gc()没有害处。我把它看作c/c++的内联关键字。这只是对gc的一个提示，即您(开发人员)已经决定时间/性能不像通常那样重要，其中一些时间/性能可以用于回收内存。
建议不要依赖它做任何事情是正确的。不要依赖于它的工作，但给一个提示，现在是一个可以接受的时间收集是完全可以的。我宁愿把时间浪费在代码中无关紧要的地方(加载屏幕)，也不愿浪费在用户与程序积极互动的时候(比如在游戏关卡中)。
有一次，我将强制收集:当试图找出是一个特定的对象泄漏(本机代码或大型，复杂的回调交互。哦，还有任何UI组件，哪怕只是瞥了一眼Matlab。)在产品代码中不应该使用这种方法。
有时(不是经常!)您确实比运行时更了解过去、当前和将来的内存使用情况。这种情况并不经常发生，而且我敢说，在web应用程序中，当提供正常页面时，这种情况绝不会发生。
很多年前，我在一个报告生成器上工作
只有一根线
从队列中读取“报告请求”
从数据库加载报告所需的数据
生成报告并通过电子邮件发送出去。
没完没了地重复，没有特别的要求就睡去。
它没有在报告之间重复使用任何数据，也没有进行任何兑现。
首先，因为它不是实时的，而且用户希望等待报告，GC运行时的延迟不是问题，但是我们需要以比请求更快的速度生成报告。
看了上面的过程大纲，很明显。
我们知道，在报告通过电子邮件发送出去之后，活动对象会非常少，因为下一个请求还没有开始处理。
众所周知，运行垃圾收集周期的成本取决于活动对象的数量，垃圾的数量对GC运行的成本几乎没有影响。
当队列为空时，没有什么更好的事情可做，然后运行GC。
因此，当请求队列为空时执行GC运行显然是非常值得的;这并没有什么坏处。
在每个报告通过电子邮件发送之后执行GC运行可能是值得的，因为我们知道这是GC运行的好时机。但是，如果计算机有足够的ram，则可以通过延迟GC运行来获得更好的结果。
这种行为是在每个安装基础上配置的，对于一些客户来说，在每个报告之后启用强制GC可以大大加快报告的生成速度。(我认为这是由于他们服务器上的内存较低，并且运行了许多其他进程，因此强制GC减少了分页。)
每次工作队列为空时，我们从未检测到一个安装没有从强制GC运行中获益。
但是，需要明确的是，上述情况并不常见。
现在，我更倾向于在单独的进程中运行每个报告，让操作系统清理内存，而不是使用垃圾收集器，并让自定义队列管理器服务在大型服务器上使用多个工作进程。
