Java 我们可以显式地调用垃圾收集器吗？

我的应用程序有很多迭代。到现在为止，我还没有遇到任何记忆问题。但从代码级别上看，我可以怀疑很少有地方会导致内存泄漏和内存不足问题。我正在考虑手动调用垃圾收集器。手动调用垃圾收集器是一种好做法吗？

您可以使用以下方法调用垃圾收集器：

System.gc();

但这并不意味着它将立即执行。JVM决定何时执行它。通常，如果JVM即将抛出一个

OutOfMemoryError

，调用

System.gc（）

不会阻止它。最好调查一下你为什么会泄漏这么多内存，并一路上把它清理干净

JavaDoc：

调用gc方法意味着Java虚拟机需要 努力回收未使用的对象，以使内存 它们目前可用于快速重用。当控件返回时 从方法调用来看，Java虚拟机已经尽了最大的努力 从所有丢弃的对象中回收空间

手动调用垃圾收集器是一种好的做法吗

不，这绝对不是好的做法

您可以使用

System.gc（）

。请注意，这并不能保证调用垃圾收集器——它只向系统提示执行垃圾收集可能是个好主意

Oracle的JVM中的垃圾收集器包含许多复杂的逻辑，用于确定何时以及清理什么。调整it需要了解有关其工作原理的详细信息。仅仅在程序中的某个地方放置一个

System.gc（）

，可能不会有多大帮助，事实上，它甚至会使情况变得更糟

---

有关如何使用Java SE 6优化垃圾回收的详细信息，请参阅。

无论您是否可以手动触发垃圾回收器（以及不同的收集级别），也不管这对性能有何影响（实际上是这样），它都不会防止OutOfMemoryErrors，因为当JVM即将耗尽内存时，无论如何，它做了最彻底的收集。只有在收集之后没有足够的内存可用时，才会出错。即使您自己更早地触发收集，结果（回收的内存量）也是一样的

内存泄漏无法通过更频繁地运行垃圾收集来修复

它们必须在您的程序中修复（停止引用您以前不再需要的内容），或者在JVM或运行库本身中修复（最坏的情况是，如果它是“真正的”泄漏）（但经过这么多年的服务，真正的内存管理错误应该不再存在）。

调用System.gc（）不能保证任何gc。如果确实需要内存，则会收集垃圾。
您可以在这里查看不同的垃圾收集器。

---

您可以根据需要在命令行参数中包含这些GC中的任何一个。

您可以显式调用垃圾收集器，但JVM决定是否处理该调用。 理想情况下，您不应该编写依赖于对垃圾收集器的调用的代码。

---

JVM内部使用一些算法来决定何时进行此调用。当您使用System.gc（）进行调用时，它只是对JVM的一个请求，JVM可以随时决定忽略它。

是的，您可以使用

System.gc();

但实际情况是，您不能命令JVM立即执行垃圾收集。JVM自行决定何时进行垃圾收集，因此手动调用它不是一个好主意

此外，关于

OutOfMemoryException

执行手动垃圾收集并不能帮助您防止异常，因为JVM在回收其所能回收的所有内存后会抛出此异常。它有一些非常复杂的算法来确定何时以及如何执行垃圾收集。

---

因此，我的建议是，如果您从MemoryException中获得

，那么请重新检查您的程序，使其更高效或增加堆空间。
在我看来，这个问题已经被讨论过了：+1我还想添加调用系统。gc实际上会降低应用程序的性能。我想最好有一个案例列表其中调用
System.gc（）
非常有用。一种情况是试图在调试/开发（而非生产）期间估计内存使用量。另一种情况是在开发过程中调用终结器以分析内存泄漏的不可靠尝试。@Thomas，终结器/类垃圾是主要原因，系统资源的终结器（如DirectBuffers/文件描述符）是重要原因。另外，jmap w/live选项调用垃圾收集。有几个-XX选项可以影响显式调用过程中发生的事情（包括完全没有）。还有一些其他情况可能会对压缩永久堆产生积极影响（如果压缩和永久堆实际上是与所选收集器相关的选项）@ThomasMueller有这样一个问题。大多数答案就像“没有意义”，所以。@maaartinus是的，有意义。不，这绝对不是好的做法。我不同意，如果你知道你为什么叫它，这是一个好交易。不过，这也适用于某些监控代码。我将给出一个名为MappedByteBuffer.map的示例，您需要最终确定它，并且唯一的非黑客选项确实涉及GC。@bestsss-我将“良好实践”解释为“通常是一件好事”，手动调用GC肯定不是你通常应该做的事情——只有当你真的知道自己在做什么，并且你可以向自己证明它是有益的时候，才应该这样做。当然，无缘无故地调用GC是个坏主意。顺便说一句，前面的评论中有一个输入错误：MappedByteBuffer。取消映射