为什么我不能关闭垃圾收集器？

首先让我们快速回顾一下我作为Java开发人员的职业生涯的早期。 我想消除正在进行的测试中的垃圾回收（GC）暂停。 瞧，当我发现无法完成时，我很生气。 那时，我将问题抛在了“设计错误”上，并继续前进。 对James Gosling或对该决定负责的人感到生气。

几天前，我遇到了一种使我想起过去的时代的情况。 幸运的是，过去的岁月在我体内积累了一些关于JVM内部的见解，我认为我会以博客文章的形式分享我的最新想法。

首先，你们中的某些人可能还记得我们在90年代后期使用的Java 1.1。 那时，您实际上就有可能关闭GC。 至少在Solaris（Sun提供的JVM版本）中，可以在您的JVM启动参数中添加-noasyncgc选项。 在向后兼容JDK 1.4之前，仍然支持该选项，但是从JDK 1.2开始，它什么也没做。 除了增加启动脚本的复杂性。

该选项关闭了JVM控制的垃圾收集器。 您仍然可以通过从代码中显式调用System.gc()来收集未使用的对象。 听起来像经验丰富的工程师可以很好地利用灵活性。 那么–为什么要删除此选项？

实际上，考虑以下因素后，此举背后的动机就变得有意义了：

• 通过禁用GC，您实际上声称您知道应用程序在运行时需要多少内存。 但是，如果您错了怎么办？ 堆填满后，禁用GC将导致应用程序终止。
• 调用System.gc()可能根本不执行垃圾回收。 在现代JVM中，仅是向JVM建议“我认为这是运行GC的好地方”。 并且–您的sysadmin可能通过指定-XX:+DisableExplicitGC启动参数完全禁用了System.gc()调用。
• 如果System.gc()实际上是由JVM执行的，则将导致完整的垃圾回收。 对于大堆，这往往非常昂贵，并且会导致较长的暂停时间。
• 通过调用System.gc()仍然无法实现可预测的GC计时，尤其是在多线程应用程序中。

  现在，看一下以上几点，并想象一个可以在没有自动GC的JVM中运行的应用程序。 您可能不想将房子押在房子的行为上。 当我尝试描绘调试会话以跟踪该应用程序的任何性能问题时，我的后背上的头发立即开始冒起。 所以也许先生。 戈斯林毕竟没有犯过设计错误。

  但是，如果我停下来的停顿时间太长了，该怎么办？ 我真的希望关闭GC吗？ 实际上有一些可能性：

  • JVM分配了一部分内存，您可以在其中关闭GC。

  但是，我建议您仅在确定要做什么时才转向这些解决方案。 在99.9％的情况下，垃圾收集器会比您更聪明。
  

  参考： 为什么我不能关闭垃圾收集器？ 由我们的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上获得。

翻译自: https://www.javacodegeeks.com/2012/12/why-cant-i-turn-off-the-garbage-collector.html