java system.gc不会立即执行_java - 为什么调用System.gc（）是不好的做法？

这是一个非常麻烦的问题，尽管语言有多么有用，但我觉得很多人反对Java。

事实上，你不能相信“System.gc”做任何事情是令人难以置信的令人生畏的，并且可以很容易地用语言来唤起“恐惧，不确定，怀疑”的感觉。

在许多情况下，处理在重要事件发生之前故意导致的内存峰值是很好的，这会导致用户认为您的程序设计糟糕/没有响应。

能够控制垃圾收集将是一个非常好的教育工具，反过来提高人们对垃圾收集如何工作的理解以及如何使程序利用它的默认行为以及受控行为。

让我来看看这个主题的论点。

效率低下：

通常，程序可能没有做任何事情，而且你知道它没有做任何事情，因为它的设计方式。 例如，它可能正在使用大型等待消息框进行某种长时间的等待，并且最后它还可以添加一个收集垃圾的调用，因为运行它的时间将花费很少的时间。 漫长的等待，但将避免gc在更重要的操作中起作用。

这总是一种不好的做法，并表示代码损坏。

我不同意，你有什么垃圾收集器并不重要。 它的工作是跟踪垃圾并清理垃圾。

通过在使用不太重要的时候调用gc，当你的生活依赖于正在运行的特定代码但是它决定收集垃圾时，你会减少它运行的几率。

当然，它可能不会按照您想要或期望的方式运行，但是当您确实想要调用它时，您就不知道发生了什么，并且用户愿意忍受缓慢/停机。 如果System.gc有效，那太好了！ 如果没有，至少你试过了。 除非垃圾收集器具有固有的副作用，如果垃圾收集器在手动调用时假设如何表现，并且这本身会导致不信任。

这不是一个常见的用例：

这是一个无法可靠实现的用例，但如果系统是这样设计的话。 这就像制作一个交通信号灯并使其成为一些/所有交通信号灯的按钮不做任何事情，它让你质疑为什么按钮在那里开始，javascript没有垃圾收集功能所以我们不要 不要仔细审查它。

规范说System.gc()是一个提示，GC应该运行，VM可以自由忽略它。

什么是“暗示”？ 什么是“忽略”？ 计算机不能简单地提示或忽略某些东西，它有一些严格的行为路径，它们可能是动态的，由系统的意图引导。 一个正确的答案将包括垃圾收集器在实现级别实际执行的操作，这会导致它在您请求时不执行收集。 这个功能只是一个小窍门吗？ 我必须遇到某种条件吗？ 这些条件是什么？

就目前而言，Java的GC通常看起来像一个你不相信的怪物。 你不知道它什么时候会发生或结束，你不知道它将要做什么，它将如何做。 我可以想象一些专家更好地了解他们的垃圾收集如何在每个指令的基础上工作，但绝大多数人只是希望它“只是工作”，并且不得不相信一个看似不透明的算法为你工作是令人沮丧的。

阅读某些内容或被教授内容之间存在很大的差距，实际上看到它的实现，跨系统的差异，以及能够在不必查看源代码的情况下使用它。 这创造了掌握/理解/控制的信心和感觉。

总而言之，答案存在一个固有的问题“这个功能可能没有做任何事情，我不会详细说明如何判断它什么时候做什么，什么时候不做以及为什么它不会或将会， 通常意味着试图去做它只是违背哲学，即使其背后的意图是合理的“。

Java GC可能会以它的方式运行，也可能没有，但要了解它，很难真正遵循哪个方向来全面了解GC可以信任的内容以及 不要这么做，所以简单地不信任语言就太容易了，因为语言的目的是在哲学范围内控制行为(程序员很容易，尤其是新手从某些系统/语言行为陷入存在危机)你 能够容忍(如果你不能，你就不会在必要之前使用这种语言)，而且你无法控制的更多事情，因为你无法控制它们，这本身就是有害的。