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

Question

我正在阅读"通过C#CLR",似乎在这个例子中,最初分配给'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();
}

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

Answer 1

请注意，仅仅因为可以收集对象，并不意味着它实际上会在任何给定点被收集 - 因此您的方法可能会给出漏报。如果任何对象的finalize方法被调用，你肯定可以说它是不可访问的，但如果没有调用该方法，你就不能从逻辑上推断出任何东西。与大多数与 GC 相关的问题一样，垃圾收集器的不确定性使得很难对其具体功能进行测试/保证。

关于可达性/可收集性主题，JLS 表示 (12.6.1)：

可到达对象是可以在任何潜在的持续计算中从任何活动线程访问的任何对象。可以设计程序的优化转换，将可到达的对象数量减少到比天真地认为可到达的对象数量少。例如，编译器或代码生成器可以选择将不再使用的变量或参数设置为空，以使此类对象的存储可以更快地回收。

这或多或少正是您所期望的 - 我认为上面的段落与“一个对象无法访问，如果您绝对不会再使用它”是同构的。

回到原来的情况，您能想到在第 1 行之后被视为无法访问的对象与第 2 行之后被视为无法访问的对象之间有什么实际影响吗？我最初的反应是没有，如果你设法找到这种情况，那很可能是错误/扭曲的代码导致虚拟机陷入困境，而不是语言固有的弱点。

尽管我对反驳持开放态度。

编辑：感谢您提供有趣的例子。

我同意您的评估并看看您要去哪里，尽管问题可能更多是调试模式正在巧妙地改变代码的语义。

在编写的代码中，您将 分配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 密集型任务的计时器会计时更多次 - 两种结果都没有错误，因为接口不提供这种保证。）

此时，我请您回到这个答案的第一句话。:)