java系统。gc（）仅在隐式设置obj=null时有效？

Question

我在windows 10上使用jdk1.8，我有这个代码片段来测试System.gc（）是如何工作的：

public class testGc{
    static class MyObject{
        @Override
        protected void finalize() throws Throwable{ // not called when System.gc()
            System.out.println("gc: " + toString());
        }
    }

    public static void main(String[] args) throws Exception{
        {
            MyObject obj=new MyObject();
            System.out.println("NOT set to null");
        }
        System.gc(); // obj still exists
        Thread.sleep(500);
    }
}

你可以在我的main（）中看到，代码块结束，obj不再被引用，然后是System.gc（）。我期望这个“obj”被回收。但是这个程序只打印：

NOT set to null

    public static void main(String[] args) throws Exception{
        {
            MyObject obj=new MyObject();
            System.out.println("Set to null");
            obj=null;//need this expression!
        }
        System.gc(); // now it works
        Thread.sleep(500);
    }

现在程序打印：

Set to null
gc: testGc$MyObject@2130772

为什么我需要使用“=null”来创建系统。gc（）工作并调用我的“finalize”函数？代码块之后，“obj”不再有效。

如何理解这一点？谢谢

Answer 1

因为JVM不是这样工作的。

JVM（类文件）级别的局部变量不存在。相反，还有堆栈（类文件是基于堆栈的语言），任何方法都会设置固定数量的未命名“插槽”。局部变量和插槽之间只有轻微的“链接”。例如，此代码：

void example() {
 int a = 5;
 System.out.println(a);
 int b = 10;
 System.out.println(b);
}

最终将只使用一个插槽（或者可能没有任何插槽，将文本直接推到堆栈上，然后println方法将使用它们）。

不能对活动方法中仍由本地“插槽”指向的任何对象进行垃圾收集。插槽不会消失。因此，在您的示例代码中，是的，在java（语言）术语中，obj变量不再存在，但在java（虚拟机）术语中，它确实存在-该方法有一个插槽，第一个插槽指向该对象<代码>javac不会决定添加额外的代码来撤销这一事实，以帮助垃圾收集-这将导致数十亿的内存写入几乎完全无用，并将使收益相形见绌！

相反，当一个方法退出时，它的堆栈空间和那些插槽都会被重用（并被标记为不再以一种更智能的方式阻止垃圾收集，即显式地对其进行写入），对于几乎所有的意图和目的来说，这“足够快”。

这确实意味着在极其罕见的情况下，你会做这样的事情：

void example() {
  {
    List<String> list = ... make some GIGANTIC 1GB+ list ...
    process(list);
  }

  callSomeMethodThatAlsoNeedsTonsOfMemory();
}

您将遇到内存错误，明智的做法是添加一个显式的list=null 在中间。除此之外，这实际上不是真的——更好的方法是将上面写的“块”粘贴到一个方法中，然后用两个调用替换这个方法。现在不需要这样做了——事实上，包含1GB列表的方法（以及进程（列表）调用）在调用内存中的唯一可用的方法（callsomethods）开始之前结束，这意味着它的插槽被正常清除。

更进一步——制作一个巨大的列表，然后处理它，只是在之后立即进行垃圾收集，这可能是不明智的。有意义的算法少得可怕——最有可能的是，你要么想逐个单元处理这些数据（而不是生成100万条目，将它们粘贴在列表中，然后处理列表——在循环中生成1个条目，处理它，然后生成下一个，处理它，等等），或者，嘿，如果需要1GB，如果你扩展得更大一点，可能需要100GB，所以这需要一个磁盘支持的数据库解决方案。

换言之，JVM完全有意在这些特殊情况下在可能的情况下无法GC。

注意：<代码>系统。gc（）只是一个请求；某种暗示。它不能保证垃圾收集会真正发生。然而，它通常是“有效的”，对你所看到的东西的解释与这个系统的事实无关。gc不是保证。