垃圾收集算法,垃圾收集器_为什么我不能关闭垃圾收集器？

垃圾收集算法,垃圾收集器

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

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

首先，你们中的某些人可能还记得我们90年代后期使用的Java 1.1。那时，您实际上就有可能关闭GC。至少在Solaris中，Sun提供的JVM版本提供了将-noasyncgc选项添加到JVM启动参数的可能性。为了向后兼容，直到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博客上获得。