java finalize方法可能带来的后果,finalize java作用

  java finalize方法可能带来的后果,finalize java作用

  00-1010对象的销毁finalize方法对象的GC回收在finalize方法中,是否要为自己重新指定一个引用以避免被GC回收?如果finalze方法中有一个无限循环会发生什么?如果在这样的无限循环中创建对象,会不会导致对象被破坏,导致内存溢出?摘要

  00-1010 C中的destroy方法用于释放资源并销毁对象本身。

  在Java中,由于GC的存在,我们不需要手动回收内存,大大减少了工作量,提高了程序的安全性。但是Java确实有一个类似于c中的析构函数。

  00-1010当类被GC回收时,重载此方法以执行某些操作。

  下面是实现finalize的类的示例。

  AO类有一个int和一个String属性,重载toString,在构造中打印对象及其创建时间,在finalize中打印对象和调用时间。

  Aoo类

  public class Aoo { private int id私有字符串名称;public Aoo(){ this(0,null);} public Aoo(int id,String name){ this . id=id;this.name=namesystem . out . println(this . tostring()现在创建: system . current time millis());}/* *省略get/set/tostring */protected void finalize()throw table { super . finalize();system . out . println(this . tostring() now finalize : system . current time millis());}}首先,简单的测试

  main方法

  public class finalize test { public static void main(String[]args)抛出异常{ Aoo a=new Aoo(1, a );a=空;system . GC()thread . sleep(2000);system . exit(0);}}打印结果:

  id:1名称:a现在创建:149754723036

  00-1010这里手动调用GC清理内存,如果注释掉system . GC();打印结果是这样的:

  id:1 name:a现在创建了33361497

  也就是说,在没有刻意调用GC的情况下,finalize方法根本没有被调用,也就是说这个对象根本没有被主动回收。

  与想象中不同的是,GC的运行模式是懒惰的,也就是说,没有内存的时候,GC不会主动回收对象。为了验证这个想法,我创建了一个不断消耗内存并且不主动调用GC的线程。

  ThreadA类

  公共类ThreadA实现Runnable { public void run(){ list integer list=new ArrayListInteger();int I=0;while(true){ list . add(I);我;} } }main方法

  英语字母表中第十六个字母

  ublic class FinalizeTest {       public static void main(String[] args) throws Exception {              Aoo a = new Aoo(1, "a");              a = null;              ThreadA ta = new ThreadA();              Thread t = new Thread(ta);              t.start();              Thread.sleep(2000);              System.exit(0);       }}打印结果:

  

id:1 name:a now create:1497548135268id:1 name:anow finalize:1497548135386

 

  

这一次尽管没有手动调用GC,但是finalize方法仍然运行了,也就是说,只有在内存被消耗、需要GC出面清理内存的时候,GC才会运行。

 

  这样的finalize方法确实不靠谱,连能不能被调用都不一定,更不用说完成什么特定的操作了,如果需要关流等回收资源,不如手动调用一个方法,或者在final块中统一释放资源。

  

 

  

在finalize方法中,是否重新给自己指定一个引用来避免被GC回收?

尝试在finalize方法中重新引用来让GC无法回收

 

  修改后的Aoo如下

  

public class Aoo {       public static Aoo SAVE = null;       private int id;       private String name;       public Aoo(){              this(0, null);       }       public Aoo(int id, String name){              this.id = id;              this.name = name;              System.out.println(this.toString() + " now create:" + System.currentTimeMillis());       }         /*        * 省略get/set/toString        */       protected void finalize() throws Throwable{              super.finalize();              System.out.println(this.toString() + "now finalize:" + System.currentTimeMillis());              SAVE = this;       }}

main方法

 

  

public class FinalizeTest {       public static void main(String[] args) throws Exception {              Aoo.SAVE = new Aoo(1, "a");              Aoo.SAVE = null;              System.gc();              Thread.sleep(500);              System.out.println(Aoo.SAVE == null? "a is dead" : "a is alive" );                            System.exit(0);                    }}

打印结果:

 

  

id:1 name:a now create:1497551409195id:1 name:anow finalize:1497551409201a is alive

 

  

这里看出,Aoo.SAVE对象确实复活了,不过这样的操作是有限制的,如果故技重施不会再一次复活该对象。

 

  main方法

  

public class FinalizeTest {       public static void main(String[] args) throws Exception {              Aoo.SAVE = new Aoo(1, "a");              Aoo.SAVE = null;              System.gc();              Thread.sleep(500);              System.out.println(Aoo.SAVE == null? "a is dead" : "a is alive" );              Aoo.SAVE = null;              System.gc();              Thread.sleep(500);              System.out.println(Aoo.SAVE == null? "a is dead" : "a is alive" );              System.exit(0);                 }}

打印结果:

 

  

id:1 name:a now create:1497551587715id:1 name:anow finalize:1497551587721a is alivea is dead

 

  

这里注意到,两次的操作是相同的,而finalize方法只会被系统调用一次。

 

  

 

  

如果finalze方法中出现死循环会发生什么?

Aoo类

 

  

public class Aoo {       private int id;       private String name;       public Aoo(){              this(0, null);       }       public Aoo(int id, String name){              this.id = id;              this.name = name;              System.out.println(this.toString() + " now create:" + System.currentTimeMillis());       }       /*        * 省略get/set/toString        */       protected void finalize() throws Throwable{              super.finalize();              while(true){                     System.out.println(this.toString() + "now finalize:" + System.currentTimeMillis());                     Thread.sleep(100);              }       }}

main方法

 

  

public class FinalizeTest {       public static void main(String[] args) throws Exception {              Aoo a1 = new Aoo(1 , "a1");              Aoo a2 = new Aoo(2 , "a2");              a1 = null;              a2 = null;              ThreadA ta = new ThreadA();              Thread t = new Thread(ta);              t.start();              Thread.sleep(5000);              System.exit(0);       }}

打印结果:

 

  

id:1 name:a1 now create:1497552024252id:2 name:a2 now create:1497552024252id:1 name:a1now finalize:1497552024373id:1 name:a1now finalize:1497552024503id:1 name:a1now finalize:1497552026848id:1 name:a1now finalize:1497552028960id:1 name:a1now finalize:1497552032363

 

  

结果是随机的,有时候是执行的a1的finalize,有的时候执行的是a2的。

 

  这个结果说明了两点:

  1.finalze方法在的线程优先级很低,时间间隔相当的不确定并且明显大于100毫秒。

  2.这个死循环导致了别的对象的finalize方法无法执行。

  

 

  

如果对象的创建出现这种死循环,会不会导致对象无法销毁进而导致内存溢出?

我们大量创建Aoo对象,并且等待GC自己回收内存。

 

  为了直观的观看finalize方法的调用情况,删除掉了Aoo对象初始化的时候的打印代码。

  main方法

  

public class FinalizeTest {       public static void main(String[] args) throws Exception {              int i = 1;              while(true){                     Aoo a = new Aoo(i , "a" + i);                     i++;              }       }}

让程序执行了约两分钟,然后手动终止,查看输出

 

  

1497554225913id:269614 name:a269614now finalize:1497554226151id:269614 name:a269614now finalize:1497554227635id:269614 name:a269614now finalize:1497554227735id:269614 name:a269614now finalize:1497554227836id:269614 name:a269614now finalize:1497554229586id:269614 name:a269614now finalize:1497554229686id:269614 name:a269614now finalize:1497554229951id:269614 name:a269614now finalize:1497554230051id:269614 name:a269614now finalize:1497554230152id:269614 name:a269614now finalize:1497554233699id:269614 name:a269614now finalize:1497554233800id:269614 name:a269614now finalize:1497554233900id:269614 name:a269614now finalize:1497554234308id:269614 name:a269614now finalize:1497554234408id:269614 name:a269614now finalize:1497554234508id:269614 name:a269614now finalize:1497554235053id:269614 name:a269614now finalize:1497554235153id:269614 name:a269614now finalize:1497554235253id:269614 name:a269614now finalize:1497554235823id:269614 name:a269614now finalize:1497554235923id:269614 name:a269614now finalize:1497554236023id:269614 name:a269614now finalize:1497554240324id:269614 name:a269614now finalize:1497554240424id:269614 name:a269614now finalize:1497554240525id:269614 name:a269614now finalize:1497554241146id:269614 name:a269614now finalize:1497554241247id:269614 name:a269614now finalize:1497554241347id:269614 name:a269614now finalize:1497554241448id:269614 name:a269614now finalize:1497554242020id:269614 name:a269614now finalize:1497554242120id:269614 name:a269614now finalize:1497554242220id:269614 name:a269614now finalize:1497554242321id:269614 name:a269614now finalize:1497554242421id:269614 name:a269614now finalize:1497554242521id:269614 name:a269614now finalize:1497554248367id:269614 name:a269614now finalize:1497554248467id:269614 name:a269614now finalize:1497554248567id:269614 name:a269614now finalize:1497554248667id:269614 name:a269614now finalize:1497554249534id:269614 name:a269614now finalize:1497554249634id:269614 name:a269614now finalize:1497554249734id:269614 name:a269614now finalize:1497554249835id:269614 name:a269614now finalize:1497554255954id:269614 name:a269614now finalize:1497554256055id:269614 name:a269614now finalize:1497554256155id:269614 name:a269614now finalize:1497554256255id:269614 name:a269614now finalize:1497554256356id:269614 name:a269614now finalize:1497554257285id:269614 name:a269614now finalize:1497554257386id:269614 name:a269614now finalize:1497554257486id:269614 name:a269614now finalize:1497554257586id:269614 name:a269614now finalize:1497554257686id:269614 name:a269614now finalize:1497554268652id:269614 name:a269614now finalize:1497554268753id:269614 name:a269614now finalize:1497554268853id:269614 name:a269614now finalize:1497554268953id:269614 name:a269614now finalize:1497554269054id:269614 name:a269614now finalize:1497554269154id:269614 name:a269614now finalize:1497554277474id:269614 name:a269614now finalize:1497554292852id:269614 name:a269614now finalize:1497554301062

 

  

可以发现两个情况:

 

  1.只有一个对象的finalize方法被执行了,也就是说这个死循环的finalize方法阻止了其他对象执行finalize方法

  2.程序执行很快的一段时间后,finalize方法就开始执行,但是随着内存消耗的不断增加,finalize方法被执行的次数也就越来越少。至于为什么这样,我不知道= =#

  

 

  

总结

至此,我尝试了finalize方法的一些用法和特殊情况。可以看出,GC调用finalize方法存在巨大的不确定性,确实很不靠谱,不过通过这个方法,了解了一些关于GC的知识,也让我明白,虽然Java语言虽然具有高度的一致性等特点使之很容易上手,但是要做到对Java的精通,路还很远呢~~

 

  以上为个人经验,希望能给大家一个参考,也希望大家多多支持盛行IT。

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: