“在垃圾回收器准备回收某个对象的内存时，都要先调用finalize方法，然后等下次再回收”这样效率不是很低么？

Question

这段话不知道你在哪里找到的，
Java 是没有析构函数的，甚至连对象销毁的时间都是无法确定的，某个对象不用了以后直接就当成Garbage扔那儿了事，等到虚拟机高兴的时候才gc掉，如果资源比较富裕，可能到有的不用的对象要到虚拟机退出的时候才会销毁。所以java才设置了这么个机制，在销毁垃圾之前调用finalize方法，清理对象构造的时候申请的资源，不然就会有内存泄漏之类的麻烦。gc之前调用finalizer确实很影响效率，更讨厌的是finalizer是用java写的，速度更慢，所以j2me里面sun干脆就把整个finalizer机制取消了，要释放资源自己到本地代码里写去，很痛苦:S, gc是虚拟机的一部分，gc启动两次才回收一块内存的说法我没有看懂，

Answer 1

我的意思是gc发现一个对象要被销毁时，会先调用finalize方法，然后gc再次启动时才会销毁这个对象，我是在TIJ里看的，难道我理解错了吗？

Answer 2

我翻了 TIJ 还真没有看到这句话，可能是翻译的问题，不过有 finalize 的对象的回收好像确实是两步走的，gc 的时候，首先看哪些对象是永远都不会被用到的，其中没有实现 finalize 的对象直接回收掉了，其中实现了 finalize 的对象被标记成准备回收，等合适的时候再回收这些对象。具体原因可能是因为性能的关系，像上面我说的，Finalize是java方法，执行效率要比本地代码慢很多，如果系统正在等内存用，gc的时候又慢吞吞地调用要回收的对象的java代码，确实不能接受，相反，如果gc把没有实现finalize的对象先回收了，然后等虚拟机空闲的时候再慢慢地去回收那些需要执行finalize的对象，显然要高效得多。所以这样分两步回收反而要高效些，而不是楼主担心的低效。

Answer 3

java的垃圾搜集机制可以使程序员不必管理内存的释放。
而且java对垃圾搜集机制:在对象不再使用的时候释放它们，但具体何时释放是不知道的。
垃圾搜集机制以低优先级在后台自动运行，没有必要考虑这个问题。
如果真的很在意效率问题，有第三方专门的工具提供处理内存释放问题。