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

首先让我们快速回顾一下我作为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博客上获得。