Java垃圾回收机制、finalize()

一.谁在做Garbage Collection。

 

　　在C++里，是系统在做垃圾回收;而在Java里，是Java自身在做。

 

　　在C++里，释放内存是手动处理的，要用delete运算符来释放分配的内存。这是流行的说法。确切地说，是应用认为不需要某实体时，就需用delete 告诉系统，可以回收这块空间了。这个要求，对编码者来说，是件很麻烦、很难做到的事。随便上哪个BBS，在C/C++版块里总是有一大堆关于内存泄漏的话题。

 

　　Java采用一种不同的，很方便的方法：Garbage Collection。垃圾回收机制放在JVM里。JVM完全负责垃圾回收事宜，应用只在需要时申请空间，而在抛弃对象时不必关心空间回收问题。

 

二.对象在啥时被丢弃。

 

　　在C++里，当对象离开其作用域时，该对象即被应用抛弃。

 

　　在Java里，对象的生命期不再与其作用域有关，而仅仅与引用有关。一个对象，可以有一个或多个引用变量指向它。当一个对象不再有任何一个引用变量指向它时，这个对象就被应用抛弃了。或者说，这个对象可以被垃圾回收机制回收了。这就是说，当不存在对某对象的任何引用时，就意味着，应用告诉JVM：我不要这个对象，你可以回收了。

　　JVM的垃圾回收机制对堆空间做实时检测。当发现某对象的引用计数为0时，就将该对象列入待回收列表中。但是，并不是马上予以销毁。

 

三.丢弃不是立即被回收。

 

　　该对象被认定为没有存在的必要了，那么它所占用的内存就可以被释放。被回收的内存可以用于后续的再分配。

 

　　但是，并不是对象被抛弃后当即被回收的。JVM进程做空间回收有较大的系统开销。如果每当某应用进程丢弃一个对象，就立即回收它的空间，势必会使整个系统的运转效率非常低下。前面说过，JVM的垃圾回收机制有多个算法。除了引用计数法是用来判断对象是否已被抛弃外，其它算法是用来确定何时及如何做回收。 JVM的垃圾回收机制要在时间和空间之间做个平衡。

 

　　因此，为了提高系统效率，垃圾回收器通常只在满足两个条件时才运行：即有对象要回收且系统需要回收。切记垃圾回收要占用时间，因此，Java运行时系统只在需要的时候才使用它。因此你无法知道垃圾回收发生的精确时间。

 

四.没有引用变量指向的对象有时也有用。

 

　　前面说了，没挂上引用变量的对象是被应用丢弃的，这意味着，它在堆空间里是个垃圾，随时可能被JVM回收。不过，这里有个不是例外的例外。对于一次性使用的对象(有些书称之为临时对象)，可以不用引用变量指向它。举个最简单也最常见的例子：System.out.println(“I am Java!”);就是创建了一个字符串对象后，直接传递给println()方法。

 

五.应用不能干预垃圾回收。

 

　　许多人对Java的垃圾回收不放心，希望在应用代码里控制JVM的垃圾回收运作。这是不可能的事。对垃圾回收机制来说，应用只有两个途径发消息给JVM。第一个前面已经说了，就是将指向某对象的所有引用变量全部移走。这就相当于向JVM发了一个消息：这个对象不要了。第二个是调用库方法 System.gc()，多数书里说调用它让Java做垃圾回收。

 

　　第一个是一个告知，而调用System.gc()也仅仅是一个请求。JVM接受这个消息后，并不是立即做垃圾回收，而只是对几个垃圾回收算法做了加权，使垃圾回收操作容易发生，或提早发生，或回收较多而已。

 

　　希望JVM及时回收垃圾，是一种需求。其实，还有相反的一种需要：在某段时间内最好不要回收垃圾。要求运行速度最快的实时系统，特别是嵌入式系统，往往希望如此。

 

　　Java的垃圾回收机制是为所有Java应用进程服务的，而不是为某个特定的进程服务的。因此，任何一个进程都不能命令垃圾回收机制做什么、怎么做或做多少。

 

六.对象被回收时要做的事。

 

　　一个对象在运行时，可能会有一些东西与其关连。因此，当对象即将被销毁时，有时需要做一些善后工作。可以把这些操作写在finalize()方法(常称之为终止器)里。

 

　　protected void finalize()

　　{

　　// finalization code here

　　}

 

　　这个终止器的用途类似于C++里的析构函数，而且都是自动调用的。但是，两者的调用时机不一样，使两者的表现行为有重大区别。C++的析构函数总是当对象离开作用域时被调用。这就是说，C++析构函数的调用时机是确定的，且是可被应用判知的。但是，Java终止器却是在对象被销毁时调用。一旦垃圾收集器准备好释放无用对象占用的存储空间，它首先调用那些对象的finalize()方法，然后才真正回收对象的内存。由上所知，被丢弃的对象何时被销毁，应用是无法获知的。而且，对于大多数场合，被丢弃对象在应用终止后仍未销毁。

 

　　在编码时，考虑到这一点。譬如，某对象在运作时打开了某个文件，在对象被丢弃时不关闭它，而是把文件关闭语句写在终止器里。这样做对文件操作会造成问题。如果文件是独占打开的，则其它对象将无法访问这个文件。如果文件是共享打开的，则另一访问该文件的对象直至应用终结仍不能读到被丢弃对象写入该文件的新内容。

 

　　至少对于文件操作，编码者应认清Java终止器与C++析构函数之间的差异。

 

　　那么，当应用终止，会不会执行应用中的所有finalize()呢？据Bruce Eckel在Thinking in Java里的观点：“到程序结束的时候，并非所有收尾模块都会得到调用”。这还仅仅是指应用正常终止的场合，非正常终止呢？因此，哪些收尾操作可以放在finalize()里，是需要酌酎的。

 

七.Thinking ing java 一书中也对垃圾回收做了一些小结。

 

　　java垃圾回收，主要是靠一个低优先级的进程负责回收，注意，不是后台的进程。

 

　　优点：边回收，边调整堆使其紧凑。

 

八、主要有以下几种算法。

 1.引用计数。

 

　　该算法在java虚拟机没被使用过，主要是循环引用问题，因为计数并不记录谁指向他，无法发现这些交互自引用对象。

 

　　(1)怎么计数？

　　 当引用连接到对象时，对象计数加1。

　　 当引用离开作用域或被置为null时减1。

 

　　(2)怎么回收？

　　 遍历对象列表，计数为0就释放。

 

　　(3)有什么问题？

　　 循环引用问题。

 2.标记算法。

 

　　标记算法的思想是从堆栈和静态存储区的对象开始，遍历所有引用，标记活得对象。

 

　　对于标记后有两种处理方式：

 

　　(1)停止-复制。

　　   所谓停止，就是停止在运行的程序，进行垃圾回收。
　　   所谓复制，就是将活得对象复制到另外一个堆上，以使内存更紧凑。

　　   优点:当大块内存释放时，有利于整个内存的重分配。

　　   问题:一、停止，干扰程序的正常运行；二，复制，明显耗费大量时间；三，如果程序比较稳定，垃圾比较少，那么每次重新复制量是非常大的，非常不合算。

　　   什么时候启动停止-复制：内存数量较低时，具体多低我也不知道。

 

　　(2)清除，也称标记-清除算法。

　　  将标记为非活得对象释放，也必须暂停程序运行。

　　  优点：在程序比较稳定，垃圾比较少的时候，速度比较快。

　　  问题：很显然停止程序运行是一个问题，只清除也会造成很对内存碎片。

　　(3)为什么这2个算法都要暂停程序运行？

　　   这是因为，如果不暂停，刚才的标记会被运行的程序弄乱。

 

 3、分代收集。

 

　　分代收集是利用程序有大量临时对象的特点，对象每被引用一次，代数就增加，代数小的小型对象会被回收整理，大对象只会代数增加，不会被整理。

　　优点：对于处理大量临时的变量很有帮助。

 

 4、自适应。

 

　　jvm会监测垃圾回收的效率，在1，2算法之间切换。

 

 5.增量收集。

 

　　增量回收的主要算法还是分代(Young Objects 回收)与Train算法(Mature Object回收)，所谓增量回收的关键问题是如何实现有序的增量回收而不会导致混乱(引用及其的增加与减少)，分代可以逐代回收，Train算法可以逐个车厢回收，这样每次一代或每次一厢可以实现短停顿回收。

 

九、注意。

 1、每个对象只能调用finalize(   )方法一次。如果在finalize(   )方法执行时产生异常（exception），则该对象仍可以被垃圾收集器收集。
 
 2、垃圾收集器跟踪每一个对象，收集那些不可触及的对象（即该对象不再被程序引用了），回收其占有的内存空间。但在进行垃圾收集的时候，垃圾收集器会调用该对象的finalize(   )方法（如果有）。如果在finalize()方法中，又使得该对象被程序引用(俗称复活了)，则该对象就变成了可触及的对象，暂时不会被垃圾收集了。但是由于每个对象只能调用一次finalize(   )方法，所以每个对象也只可能 "复活 "一次。
 
 3、Java语言允许程序员为任何方法添加finalize(   )方法，该方法会在垃圾收集器交换回收对象之前被调用。但不要过分依赖该方法对系统资源进行回收和再利用，因为该方法调用后的执行结果是不可预知的。
 
 4、垃圾收集器不可以被强制执行，但程序员可以通过调研System.gc方法来建议执行垃圾收集。记住，只是建议。一般不建议自己写System.gc，因为会加大垃圾收集工作量。