Java垃圾回收机制GC

JAVA中的内存管理其实就是对象的管理,其中包括对象的分配和释放,分配对象使用new关键字,释放对象只要给对象赋值为null.

if(对象==null){
        对象"不可达";
    }else{
        对象"可达";
    }

GC回收的就是”不可达”对象

对于GC来说，当程序员创建对象时，GC就开始监控这个对象的地址、大小以及使用情况。通常，GC采用有向图的方式记录和管理堆(heap)中的所有对 象，通过这种方式确定哪些对象是”可达的”，哪些对象是”不可达的”。当GC确定一些对象为”不可达”时，GC就有责任回收这些内存空间。但是，为了保证 GC能够区别平台实现的问题，Java规范标准对GC的很多行为都没有进行严格的规定。例如，对于采用什么类型的回收算法、什么时候进行回收等重要问题都 没有明确的规定。因此，不同的JVM的实现者往往有不同的实现算法。这也给Java程序员的开发带来很多不确定性。本文研究了几个和GC工作相关的问题， 努力减少这种不确定性给Java程序带来的负面影响。

1.增量式GC

GC在JVM中是一个线程或一组线程来实现,它本身也和应用程序一样占用堆(heap)的空间,运行时也占用CPU,当GC运行时,应用程序停止,所以GC运行较长时间的时候,用户能感觉到应用程序的停顿,这大大影响了用户体验.如果GC运行的时间较短,则可能对象回收率就比较低,有很多”不可达”对象没有被回收,继续占用着内存,因此，在设计GC的时候，就必须在停顿时间和回收率之间进行权衡.

增量式GC就是通过一定的回收算法，把一个长时间的中断，划分为很多个小的中断，通过这种方式减少GC对用户程序的影响。虽然，增量式GC在整体性能上可能不如普通GC的效率高，但是它能够减少程序的最长停顿时间.

Sun JDK提供的HotSpot JVM就能支持增量式GC。HotSpot JVM缺省GC方式为不使用增量GC，为了启动增量GC，我们必须在运行Java程序时增加-Xincgc的参数。HotSpot JVM增量式GC，实现是采用Train GC算法，它的基本想法：将堆中的所有对象按照创建和使用情况进行分组(分层)，将使用频繁和具有相关性的对象放在一队中，随着程序的运行，不断对组进行调整，当GC运行时，它总是先回收最老的(最近很少访问的)对象，如果整组都为可回收对象，GC将整组回收，这样，每次GC运行只回收一定比例的不可达对 象，保证程序的顺畅运行。

finalize( )函数

finalize是位于Object类的一个方法，该方法的访问修符为 protected，由于所有类为Object的子类，因此用户类很容 易访问到这个方法。由于，finalize函数没有自动实现链式调用，我们必须手动实现，因此finalize函数的最后一个语句通常是 super.finalize()。通过这种方式，我们可以实现从下到上实现finalize的调用，即先释放自己的资源，然后再释放父类的资源

JAVA语言标准规范中规定了,JVM保证finalize()调用之前,对象是”不可达”的,但是，JVM不保证这个函数一定会被调用,也规定finalize()函数*最多执行一次.….

使用finalize()并不是一种好的方式,
1.GC为了支持finalize(),要对覆盖这个方法的对象做很多附加的工作.
2.GC在使用finalize()后,对象可能变成’可达’的,GC还要再检查一次对象是否是”可达的”,这降低了GC运行的性能.
3.由于GC调用finalize()的时间是不确定的，因 此通过这种方式释放资源也是不确定的

通常，finalize()用于一些不容易控制，并且非常重要资源的释放，例如一些I/O操作、数据连接等，这些资源的释放对整个应用程序是非常关键的。在这 种情况下，程序员应该以通过程序本身管理(包括释放)这些资源为主，以finalize()函数释放资源方式为辅，形成一种双保险的管理机制，而不应该仅仅依 靠finalize()来释放资源。