Java基本功之Reference详解

有这样一种说法,如今争锋于IT战场的两大势力,MS一族偏重于底层实现,Java一族偏重于系统架构。说法根据无从考证,但从两大势力各自的社区力量和图书市场已有佳作不难看出,此说法不虚。于是,事情的另一面让人忽略了。偏巧,我是一个喜欢探究底层实现的Java程序员,虽然我的喜好并非纯正咖啡,剑走偏锋却别是一番风味。
  
  Reference Java世界泰山北斗级大作《Thinking In Java》切入Java就提出“Everything is Object”。在Java这个充满Object的世界中,reference是一切谜题的根源,所有的故事都是从这里开始的。
  
  Reference是什么?
  
  如果你和我一样在进入Java世界之前曾经浪迹于C/C++世界,就一定不会对指针陌生。谈到指针,往日种种不堪回首的经历一下子涌上心头,这里不是抱怨的地方,让我们暂时忘记指针的痛苦,回忆一下最初接触指针的甜蜜吧!
  
  还记得你看过的教科书中,如何讲解指针吗?留在我印象中的一种说法是,指针就是地址,如同门牌号码一样,有了地址,你可以轻而易举找到一个人家,而不必费尽心力的大海捞针。C++登上历史舞台,reference也随之而来,容我问个小问题,指针和reference区别何在?我的答案来自于在C++世界享誉盛名的《More Effective C++》。
  
  没有null reference,reference必须有初值。
  
  使用reference要比使用指针效率高。因为reference不需要测试其有效性。指针可以重新赋值,而reference总是指向它最初获得的对象。
  
  设计选择:
  
  当你指向你需要指向的某个东西,而且绝不会改指向其它东西,或是当你实作一个运算符而其语法需要无法有指针达成,你就应该选择reference。其它任何时候,请采用指针。
  
  这和Java有什么关系?
  
  初学Java,鉴于reference的名称,我毫不犹豫的将它和C++中的reference等同起来。不过,我错了。在Java中,reference 可以随心所欲的赋值置空,对比一下上面列出的差异,就不难发现,Java的reference如果要与C/C++对应,它不过是一个穿着 reference外衣的指针而已。于是,所有关于C中关于指针的理解方式,可以照搬到Java中,简而言之,reference就是一个地址。我们可以把它想象成一个把手,抓住它,就抓住了我们想要操纵的数据。如同掌握C的关键在于掌握指针,探索Java的钥匙就是reference。
  
  一段小程序
  
  我知道,太多的文字总是令人犯困,那就来段代码吧!
  
  public class ReferenceTricks
  {
  public static void main(String[] args)
  {
  ReferenceTricks r = new ReferenceTricks();
  // reset integer
  r.i = 0;
  System.out.println
  ("Before changeInteger:" + r.i);
  changeInteger(r);
  System.out.println
  ("After changeInteger:" + r.i);
  
  // just for format
  System.out.println();
  
  // reset integer
  r.i = 0;
  System.out.println
  ("Before changeReference:" + r.i);
  changeReference(r);
  System.out.println
  ("After changeReference:" + r.i);
  }
  
  private static void
  changeReference(ReferenceTricks r)
  {
  r = new ReferenceTricks();
  r.i = 5;
  System.out.println
  ("In changeReference: " + r.i);
  }
  
  private static void
  changeInteger(ReferenceTricks r)
  {
  r.i = 5;
  System.out.println
  ("In changeInteger:" + r.i);
  }
  
  public int i;
  }
  
  我知道,把一个字段设成public是一种不好的编码习惯,这里只是为了说明问题。如果你有兴趣自己运行一下这个程序。你已经运行过了吗?结果如何?是否如你预期?下面是我在自己的机器上运行的结果:
  
  Before changeInteger:0
  In changeInteger:5
  After changeInteger:5
  
  Before changeReference:0
  In changeReference: 5
  After changeReference:0
  
  这里,我们关注的是两个change,changeReference和changeInteger。从输出的内容中,我们可以看出,两个方法在调用前和调用中完全一样,差异出现在调用后的结果。
  
  糊涂的讲解
  
  先让我们来分析一下changeInteger的行为。
  
  前面说过了,Java中的reference就是一个地址,它指向了一个内存空间,这个空间存放着一个对象的相关信息。这里我们暂时不去关心这个内存具体如何排布,只要知道,通过地址,我们可以找到r这个对象的i字段,然后我们给它赋成5。
  
  既然这个字段的内容得到了修改,从函数中返回之后,它自然就是改动后的结果了,所以调用之后,r对象的i字段依然是5。下图展示了changeInteger调用前后内存变化。
  
  让我们把目光转向changeReference。从代码上,我们可以看出,同changeInteger之间的差别仅仅在于多了这么一句:
  
  r = new ReferenceTricks();
  
  这条语句的作用是分配一块新的内存,然后将r指向它。执行完这条语句,r就不再是原来的r,但它依然是一个ReferenceTricks的对象,所以我们依然可以对这个r的i字段赋值。到此为止,一切都是那么自然。
  
  顺着这个思路继续下去的话,执行完changeReference,输出的r的i字段,那么应该是应该是新内存中的i,所以应该是5。至于那块被我们抛弃的内存,Java的GC功能自然会替我们善后的。
  
  事与愿违。
  
  实际的结果我们已经看到了,输出的是0。肯定哪个地方错了,究竟是哪个地方呢?
  
  参数传递的秘密
  
  知道方法参数如何传递吗?
  
  记得刚开始学编程那会儿,老师教导,所谓参数,有形式参数和实际参数之分,参数列表中写的那些东西都叫形式参数,在实际调用的时候,它们会被实际参数所替代。
  
  编译程序不可能知道每次调用的实际参数都是什么,于是写编译器的高手就出个办法,让实际参数按照一定顺序放到一个大家都可以找得到的地方,以此作为方法调用的一种约定。所谓“没有规矩,不成方圆”,有了这个规矩,大家协作起来就容易多了。这个公共数据区,现在编译器的选择通常是“栈”,而所谓的顺序就是形式参数声明的顺序。
  
  显然,程序运行的过程中,作为实际参数的变量可能遍布于内存的各个位置,而并不一定要老老实实的呆在栈里。为了守“规矩”,程序只好将变量复制一份到栈中,也就是通常所说的将参数压入栈中。
  
  我刚才说什么来着?将变量复制一份到栈中,没错,“复制”!
  
  这就是所谓的值传递。
  
  C语言的旷世经典《The C Programming Language》开篇的第一章中,谈到实际参数时说,“在C中,所有函数的实际参数都是传‘值’的”。
  
  马上会有人站出来,“错了,还有传地址,比如以指针传递就是传地址”。不错,传指针就是传地址。在把指针视为地址的时候,是否考虑过这样一个问题,它也是一个变量。前面的讨论中说过了,参数传递必须要把参数压入栈中,作为地址的指针也不例外。所以,必须把这个指针也复制一份。函数中对于指针操作实际上是对于这个指针副本的操作。
  
  Java的reference等于C的指针。所以,在Java的方法调用中,reference也要复制一份压入堆栈。在方法中对reference的操作就是对这个reference副本的操作。
  
  谜底揭晓
  
  好,让我们回到最初的问题上。在changeReference中对于reference的赋值实际上是对这个reference的副本进行赋值,而对于reference的本尊没有产生丝毫的影响。
  
  回到调用点,本尊醒来,它并不知道自己睡去的这段时间内发生过什么,所以只好当作什么都没发生过一般。就这样,副本消失了,在方法中对它的修改也就烟消云散了。
  
  也许你会问出这样的问题,“听了你的解释,我反而对changeInteger感到迷惑了,既然是对于副本的操作,为什么changeInteger可以运作正常?”这是很有趣的现象。
  
  好,那我就用前面的说法解释一下changeInteger的运作。所谓复制,其结果必然是副本完全等同于本尊。reference复制的结果必然是两个reference指向同一块内存空间。
  
  虽然在方法中对于副本的操作并不会影响到本尊,但对内存空间的修改确实实实在在的,回到调用点,虽然本尊依然不知道曾经发生过的一切,但它按照原来的方式访问内存的时候,取到的确是经过方法修改之后的内容。于是方法可以把自己的影响扩展到方法之外。
  
  多说几句
  
  这个问题起源于我对C/C++中同样问题的思考。同C/C++相比,在changeReference中对reference赋值可能并不会造成什么很严重的后果,而在C/C++中,这么做却会造成臭名昭著的“内存泄漏”,根本的原因在于Java拥有了可爱的GC功能。即便这样,我仍不推荐使用这种的手法,毕竟GC已经很忙了,我们怎么好意思再麻烦人家。
  
  在C/C++中,这个问题还可以继续引申。既然在函数中对于指针直接赋值行不通,那么如何在函数中修改指针呢?答案很简单,指针的指针,也就是把原来的指针看作一个普通的数据,把一个指向它的指针传到函数中就可以了。
  
  同样的问题到了Java中就没有那么美妙的解决方案了,因为Java中可没有reference的reference这样的语法。可能的变通就是将reference进行封装成类。至于值不值,公道自在人心。

 

http://www.iteye.com/topic/12961

 

 

  在 jdk 1.2 及其以后,引入了强引用、软引用、弱引用、虚引用这四个概念。网上很多关于这四个概念的解释,但大多是概念性的泛泛而谈,今天我结合着代码分析了一下,首先我们先来看定义与大概解释(引用类型在包 java.lang.ref 里)。
  1、强引用(StrongReference)
    强引用不会被GC回收,并且在java.lang.ref里也没有实际的对应类型。举个例子来说:
    Object obj = new Object();
    这里的obj引用便是一个强引用,不会被GC回收。
  2、软引用(SoftReference)
    软引用在JVM报告内存不足的时候才会被GC回收,否则不会回收,正是由于这种特性软引用在caching和pooling中用处广泛。软引用的用法:
1     Object obj = new Object(); 
2     WeakReference<Object> softRef = new WeakReference(obj); 
3     // 使用 softRef.get() 获取软引用所引用的对象 
4     Object objg = softRef.get();
  3、弱引用(WeakReference)
    当GC一但发现了弱引用对象,将会释放WeakReference所引用的对象。弱引用使用方法与软引用类似,但回收策略不同。
  4、虚引用(PhantomReference)
    当GC一但发现了虚引用对象,将会将PhantomReference对象插入ReferenceQueue队列,而此时PhantomReference所指向的对象并没有被GC回收,而是要等到ReferenceQueue被你真正的处理后才会被回收。虚引用的用法:
1 Object obj = new Object(); 
2 ReferenceQueue<Object> refQueue = new ReferenceQueue<Object>(); 
3 PhantomReference<Object> phanRef = new PhantomReference<Object>(obj, refQueue); 
4 // 调用phanRef.get()不管在什么情况下会一直返回null 
5 Object objg = phanRef.get(); 
6 // 如果obj被置为null,当GC发现了虚引用,GC会将phanRef插入进我们之前创建时传入的refQueue队列 
7 // 注意,此时phanRef所引用的obj对象,并没有被GC回收,在我们显式地调用refQueue.poll返回phanRef之后 
8 // 当GC第二次发现虚引用,而此时JVM将phanRef插入到refQueue会插入失败,此时GC才会对obj进行回收 
9 Reference<? extends Object> phanRefP = refQueue.poll();
看了简单的定义之后,我们结合着代码来测试一下,强引用就不用说了,软引用的描述也很清楚,关键是 “弱引用” 与 “虚引用”。
弱引用:
01 public static void main(String[] args) throws InterruptedException { 
02     Object obj = new Object(); 
03     ReferenceQueue<Object> refQueue = new ReferenceQueue<Object>(); 
04     WeakReference<Object> weakRef = new WeakReference<Object>(obj, refQueue); 
05     System.out.println(weakRef.get()); 
06     System.out.println(refQueue.poll()); 
07     obj = null; 
08     System.gc(); 
09     System.out.println(weakRef.get()); 
10     System.out.println(refQueue.poll()); 
11 }
由于System.gc()是告诉JVM这是一个执行GC的好时机,但具体执不执行由JVM决定,因此当JVM决定执行GC,得到的结果便是(事实上这段代码一般都会执行GC):
  java.lang.Object@de6ced
  null
  null
  java.lang.ref.WeakReference@1fb8ee3
从执行结果得知,通过调用weakRef.get()我们得到了obj对象,由于没有执行GC,因此refQueue.poll()返回的null,当我们把obj = null;此时没有引用指向堆中的obj对象了,这里JVM执行了一次GC,我们通过weakRef.get()发现返回了null,而refQueue.poll()返回了WeakReference对象,因此JVM在对obj进行了回收之后,才将weakRef插入到refQueue队列中。
虚引用:
01 public static void main(String[] args) throws InterruptedException { 
02     Object obj = new Object(); 
03     ReferenceQueue<Object> refQueue = new ReferenceQueue<Object>(); 
04     PhantomReference<Object> phanRef = new PhantomReference<Object>(obj, refQueue); 
05     System.out.println(phanRef.get()); 
06     System.out.println(refQueue.poll()); 
07     obj = null; 
08     System.gc(); 
09     System.out.println(phanRef.get()); 
10     System.out.println(refQueue.poll()); 
11 }
同样,当JVM执行了GC,得到的结果便是:
  null
  null
  null
  java.lang.ref.PhantomReference@1fb8ee3
从执行结果得知,我们先前说的没有错,phanRef.get()不管在什么情况下,都会返回null,而当JVM执行GC发现虚引用之后,JVM并没有回收obj,而是将PhantomReference对象插入到对应的虚引用队列refQueue中,当调用refQueue.poll()返回PhantomReference对象时,poll方法会先把PhantomReference的持有队列queue(ReferenceQueue<? super T>)置为NULL,NULL对象继承自ReferenceQueue,将enqueue(Reference paramReference)方法覆盖为return false,而此时obj再次被GC发现时,JVM再将PhantomReference插入到NULL队列中便会插入失败返回false,此时GC便会回收obj。事实上通过这段代码我们也的却看不出来obj是否被回收,但通过 PhantomReference 的javadoc注释中有一句是这样写的:
Once the garbage collector decides that an object obj is phantom-reachable, it is being enqueued on the corresponding queue, but its referent is not cleared. That is, the reference queue of the phantom reference must explicitly be processed by some application code.
翻译一下(这句话很简单,我相信很多人应该也看得懂):
一旦GC决定一个“obj”是虚可达的,它(指PhantomReference)将会被入队到对应的队列,但是它的指代并没有被清除。也就是说,虚引用的引用队列一定要明确地被一些应用程序代码所处理。
弱引用与虚引用的用处
  软引用很明显可以用来制作caching和pooling,而弱引用与虚引用呢?其实用处也很大,首先我们来看看弱引用,举个例子:
1 class Registry { 
2     private Set registeredObjects = new HashSet(); 
3  
4     public void register(Object object) { 
5         registeredObjects.add( object ); 
6     } 
7 }
所有我添加进 registeredObjects 中的object永远不会被GC回收,因为这里有个强引用保存在registeredObjects里,另一方面如果我把代码改为如下:
1 class Registry { 
2      private Set registeredObjects = new HashSet(); 
3   
4      public void register(Object object) { 
5          registeredObjects.add( new WeakReference(object) ); 
6      } 
7  }
  现在如果GC想要回收registeredObjects中的object,便能够实现了,同样在使用HashMap如果想实现如上的效果,一种更好的实现是使用WeakHashMap。
而虚引用呢?我们先来看看javadoc的部分说明:
Phantom references are useful for implementing cleanup operations that are necessary before an object gets garbage-collected. They are sometimes more flexible than the finalize() method.
翻译一下:
虚引用在实现一个对象被回收之前必须做清理操作是很有用的。有时候,他们比finalize()方法更灵活。
很明显的,虚引用可以用来做对象被回收之前的清理工作。

 

转自:http://blog.sina.com.cn/s/blog_667ac0360102e9f3.html

没有更多推荐了,返回首页