Question

我正在阅读“CLR via C＃”，似乎在这个例子中，最初分配给'obj'的对象在执行第1行后不符合垃圾收集条件，而不是在第2行之后。

void Foo()
{
    Object obj = new Object();
    obj = null;
}

这是因为局部变量生命周期不是由定义它的范围定义的，而是在上次读取时定义的。

所以我的问题是：Java怎么样？我编写了这个程序来检查这种行为，它看起来像对象保持活着。我不认为JVM可以在解释字节码时限制变量的生命周期，因此我尝试使用'java -Xcomp'来运行程序以强制进行方法编译，但无论如何都不会调用'finalize'。看起来对Java来说不是这样，但我希望我能在这里得到更准确的答案。另外，Android的Dalvik VM呢？

class TestProgram {

    public static void main(String[] args) {
        TestProgram ref = new TestProgram();
        System.gc();
    }

    @Override
    protected void finalize() {
        System.out.println("finalized");
    }
}

添加了： Jeffrey Richter在“CLR via C＃”中给出了代码示例，如下所示：

public static void Main (string[] args)
{
    var timer = new Timer(TimerCallback, null, 0, 1000); // call every second
    Console.ReadLine();
}

public static void TimerCallback(Object o)
{
    Console.WriteLine("Callback!");
    GC.Collect();
}

TimerCallback在MS .Net上只调用一次，如果项目目标是'Release'（在GC.Collect（）调用后销毁定时器），并且如果目标是'Debug'则每秒调用一次（变量寿命增加，因为程序员可以尝试访问带调试器的对象）。但是无论你如何编译它，Mono回调都会调用它。看起来Mono的'Timer'实现存储了对线程池中某个实例的引用。 MS实现不会这样做。

Answer 1

请注意，仅仅因为可以被收集，并不意味着它实际上会被收集到任何给定的点 - 所以你的方法可以给出假阴性。如果调用任何对象的finalize方法，你肯定可以说它无法访问，但如果没有调用该方法，则无法在逻辑上推断任何内容。与大多数与GC相关的问题一样，垃圾收集器的非确定性使得很难提出关于它将做什么的测试/保证。

关于可达性/可收集性的主题，JLS说（12.6.1）：

可达对象是任何可以从任何活动线程继续计算中访问的对象。可以设计优化程序的转换，以减少可达到的对象的数量，使其少于可以被认为可达的对象的数量。例如，编译器或代码生成器可以选择设置一个不再用于null的变量或参数，以使这种对象的存储可以更快地回收。

这或多或少正是你所期望的 - 我认为上面的段落是同形的＆＃34;如果你肯定不再使用它，那么对象就无法达到＆＃34;。< / p>

回到原来的情况，你能想到在第1行之后被认为无法访问的对象与第2行之间的任何实际后果吗？我最初的反应是没有，如果你以某种方式设法找到这样的情况，它可能是一个坏/扭曲代码的标志，导致VM挣扎而不是语言中固有的弱点。

虽然我可以接受反驳。

编辑：感谢有趣的例子。

我同意您的评估并了解您的目标，但问题可能更多的是调试模式正巧妙地改变您的代码的语义。

在编写的代码中，将Timer分配给本地变量，该变量随后在其范围内读取。即使是最琐碎的逃逸分析也可以揭示timer变量在main方法中的任何其他位置都没有使用过，因此可以省略。因此，我认为你的第一行可以被认为完全等同于直接调用构造函数：

public static void Main (string[] args)
{
    new Timer(TimerCallback, null, 0, 1000); // call every second
    ...

在后一种情况下，很明显新构建的Timer对象在构建后不能立即到达（假设它没有做任何偷偷摸摸的事情，比如将自己添加到静态字段中在其构造函数中）;因此，一旦GC到达它就会收集它。

现在在调试的情况下，事情略有不同，因为你提到的原因是开发人员可能希望稍后在方法中检查局部变量的状态。因此，编译器（和JIT编译器）无法优化这些;它就像在方法结束时访问变量一样，防止收集到那一点。

即便如此，我也不认为这实际上改变了语义。 GC的本质是很少保证集合（至少在Java中，唯一可以保证的是，如果抛出OutOfMemoryError，那么所有被认为无法访问的东西都会事先得到GC）。实际上，假设您有足够的堆空间来容纳在运行时生命周期内创建的每个对象，那么无操作GC实现是完全有效的。因此，虽然您可能会观察到Timer滴答次数的行为变化，但这很好，因为根据您调用它的方式无法保证您所看到的内容。（这在概念上类似于在整个CPU密集型任务中运行的计时器如何在系统处于负载状态时打勾更多次 - 结果都不正确，因为接口不能提供这种保证。）

此时我再回答你在这个答案中的第一句话。：）

Answer 2

一般来说，Java的行为是，如果对象在作用域中可以访问（对它的引用不是垃圾），那么该对象不是垃圾。这是递归的，因此如果a是对引用b的对象的引用，则对象b引用的不是垃圾。

在您仍然到达 ref引用的对象的范围内，（您可以添加行System.out.println(ref.toString())），ref不是垃圾

但是，根据this old source from Sun's site，大多数取决于JVM的具体实现。

Java与.Net中的对象生命周期

2 个答案: