finalize()是对JVM的一个提示，建议在未指定的时间执行代码。当您希望代码莫名其妙地无法运行时，这是很好的方法。

在终结器中做任何重要的事情(基本上除了日志)在三种情况下也很好:

您希望打赌其他已完成的对象仍然处于程序其余部分认为有效的状态。 您希望向所有具有终结器的类的所有方法添加大量检查代码，以确保它们在终结后行为正确。 您希望意外地复活已完成的对象，并花费大量时间试图弄清楚为什么它们不起作用，和/或为什么它们在最终释放时没有最终完成。

If you think you need finalize(), sometimes what you really want is a phantom reference (which in the example given could hold a hard reference to a connection used by its referand, and close it after the phantom reference has been queued). This also has the property that it may mysteriously never run, but at least it can't call methods on or resurrect finalized objects. So it's just right for situations where you don't absolutely need to close that connection cleanly, but you'd quite like to, and the clients of your class can't or won't call close themselves (which is actually fair enough - what's the point of having a garbage collector at all if you design interfaces that require a specific action be taken prior to collection? That just puts us back in the days of malloc/free.)

Other times you need the resource you think you're managing to be more robust. For example, why do you need to close that connection? It must ultimately be based on some kind of I/O provided by the system (socket, file, whatever), so why can't you rely on the system to close it for you when the lowest level of resource is gced? If the server at the other end absolutely requires you to close the connection cleanly rather than just dropping the socket, then what's going to happen when someone trips over the power cable of the machine your code is running on, or the intervening network goes out?

免责声明:我以前在JVM实现上工作过。我讨厌终结者。

class MyObject {
    Test main;

    public MyObject(Test t) {    
        main = t; 
    }

    protected void finalize() {
        main.ref = this; // let instance become reachable again
        System.out.println("This is finalize"); //test finalize run only once
    }
}

class Test {
    MyObject ref;

    public static void main(String[] args) {
        Test test = new Test();
        test.ref = new MyObject(test);
        test.ref = null; //MyObject become unreachable，finalize will be invoked
        System.gc(); 
        if (test.ref != null) System.out.println("MyObject still alive!");  
    }
}

====================================

结果:

This is finalize

MyObject still alive!

=====================================

所以你可以在finalize方法中使一个不可达的实例可达。

嗯，我曾经用它来清理没有返回到现有池的对象。

它们经常被转来转去，所以不可能知道什么时候能安全地放回泳池。问题在于，它在垃圾收集过程中带来了巨大的损失，远远超过了使用对象池节省的成本。在我拆除整个池，让所有内容都变得动态并完成之前，它已经投入了大约一个月的时间。

编辑:好吧，这真的不管用。我实现了它，并认为如果它有时失败了，这对我来说是可以的，但它甚至没有调用finalize方法一次。

我不是一个专业的程序员，但在我的程序中，我有一个案例，我认为是一个使用finalize()的好例子，那是一个缓存，在它被销毁之前将其内容写入磁盘。因为它没有必要在每次销毁时都执行，它只会加速我的程序，我希望我没有做错。

@Override
public void finalize()
{
    try {saveCache();} catch (Exception e)  {e.printStackTrace();}
}

public void saveCache() throws FileNotFoundException, IOException
{
    ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("temp/cache.tmp"));
    out.writeObject(cache);
}

就我个人而言，除了在一种罕见的情况下，我几乎从不使用finalize():我创建了一个自定义泛型类型集合，并编写了一个自定义finalize()方法，它执行以下操作:

public void finalize() throws Throwable {
    super.finalize();
    if (destructiveFinalize) {
        T item;
        for (int i = 0, l = length(); i < l; i++) {
            item = get(i);
            if (item == null) {
                continue;
            }
            if (item instanceof Window) {
                ((Window) get(i)).dispose();
            }
            if (item instanceof CompleteObject) {
                ((CompleteObject) get(i)).finalize();
            }
            set(i, null);
        }
    }
}

(CompleteObject是我做的一个接口，让你指定你已经实现了很少实现的对象方法，如#finalize()， #hashCode()和#clone()))

因此，使用姐妹方法# setdestructivelyfinalizer(布尔值)，使用我的集合的程序可以(帮助)确保销毁对该集合的引用也会销毁对其内容的引用，并处理可能在无意中保持JVM活动的任何窗口。我也考虑过停止任何线程，但这打开了一个全新的蠕虫罐头。

finalize()是对JVM的一个提示，建议在未指定的时间执行代码。当您希望代码莫名其妙地无法运行时，这是很好的方法。

在终结器中做任何重要的事情(基本上除了日志)在三种情况下也很好:

您希望打赌其他已完成的对象仍然处于程序其余部分认为有效的状态。 您希望向所有具有终结器的类的所有方法添加大量检查代码，以确保它们在终结后行为正确。 您希望意外地复活已完成的对象，并花费大量时间试图弄清楚为什么它们不起作用，和/或为什么它们在最终释放时没有最终完成。

If you think you need finalize(), sometimes what you really want is a phantom reference (which in the example given could hold a hard reference to a connection used by its referand, and close it after the phantom reference has been queued). This also has the property that it may mysteriously never run, but at least it can't call methods on or resurrect finalized objects. So it's just right for situations where you don't absolutely need to close that connection cleanly, but you'd quite like to, and the clients of your class can't or won't call close themselves (which is actually fair enough - what's the point of having a garbage collector at all if you design interfaces that require a specific action be taken prior to collection? That just puts us back in the days of malloc/free.)

Other times you need the resource you think you're managing to be more robust. For example, why do you need to close that connection? It must ultimately be based on some kind of I/O provided by the system (socket, file, whatever), so why can't you rely on the system to close it for you when the lowest level of resource is gced? If the server at the other end absolutely requires you to close the connection cleanly rather than just dropping the socket, then what's going to happen when someone trips over the power cable of the machine your code is running on, or the intervening network goes out?

免责声明:我以前在JVM实现上工作过。我讨厌终结者。