Java基本功——Reference

这是一篇一年多之前便已写就的文章，那时，因为很多Java程序员只求追随新生的事物，却连基本的概念都没有，很多讨论中，很明显是基本功不过硬，于是萌生写一个系列文章，讨论Java的基本功，下面便是在这个想法下催生出的第一篇文章。可事实上，真正完成的也只有这一篇。因为未能及时发布，它就被我遗忘在硬盘的角落中。今天，JavaEye上关 于Java传值还是传引用 的论战让我记起了自己曾经写过的这篇文章，愿与大家共享。

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++》。

1. 没有null reference。
2. reference必须有初值。
3. 使用reference要比使用指针效率高。因为reference不需要测试其有效性。
4. 指针可以重新赋值，而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是一种不好的编码习惯，这里只是为了说明问题。
如果你有兴趣自己运行一下这个程序，我等你！

OK，你已经运行过了吗？结果如何？是否如你预期？下面是我在自己的机器上运行的结果：
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调用前后内存变化。

     Reference +--------+                Reference +--------+
    ---------->| i = 0  |               ---------->| i = 5  |
               |--------|                          |--------|
               | Memory |                          | Memory |
               |        |                          |        |
               |        |                          |        |
               +--------+                          +--------+

         调用changeInteger之前              调用changeInteger之后

让我们把目光转向changeReference。
从代码上，我们可以看出，同changeInteger之间的差别仅仅在于多了这么一句。
r = new ReferenceTricks();
这条语句的作用是分配一块新的内存，然后将r指向它。
执行完这条语句，r就不再是原来的r，但它依然是一个ReferenceTricks的对象，所以我们依然可以对这个r的i字段赋值。到此为止，一切都是那么自然。

     Reference +--------+                          +--------+
    ---------->| i = 0  |                          | i = 0  |
               |--------|                          |--------|
               | Memory |                          | Memory |
               |        |                Reference |--------|
               |        |               ---------->| i = 5  |
               +--------+                          +--------+

        调用changeReference之前            调用changeReferenc之后

顺着这个思路继续下去的话，执行完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进行封装成类。至于值不值，公道自在人心。

参考文献
1 《Thinking in Java》
2 《More Effective C++》
3 《The C Programming Language》

日志标题：Java为什么能够支持Reflection 发表时间：2005-5-17 21:12:00        Java为什么能够支持Reflection？答案是Java运行时仍然拥有类型信息，它包含了这个类一切：它有哪些字段、哪些方法，各是何种保护级别等等，还有这个类依赖于哪些类。在Java中，类信息以对象的形式存放，这些对象是一种元对象，它们的类型就是Class。拥有了这些信息，无论是动态创建对象还是调用某些方法都是轻而易举的。在C++中，通过RTTI（运行时类型识别），我们也可以知道类的一些信息，但为什么C++中却没有 Reflection，原因是类型信息不完整。RTTI这个名字本身就告诉我们，C++的类型信息是用来进行类型识别的，因此，它也不需要其它额外的信息。并不是C++无法做到这一点，而是C++不希望给用户增加额外的负担。有所得，必然有所失，因此，C++放弃了元对象。关于这一点，C++之父 Bjarne Stroustrup在他的《C++语言的设计与演化》的14.2.8节中进行了深入的讨论。 元对象是Java Reflection的物质基础，那它的精神基础又是什么呢？Java为什么要支持Reflection？经过上面的讨论，我们把这个问题再进一步，为什么Java要提供元对象？ 讨论这个问题，我们还要拉回到十年前，那时Java刚刚来到正式登上历史的舞台。Java实际上诞生在这之前的数年，那时候还叫Oak，环境所限使得这一划时代的杰作甫一出炉便被束之高阁。当Netscape掀起了为网络大戏的序幕，Java得以凤凰涅槃，这其中很重要的一个原因就是Java是以网络为中心的。 仔细观察，我们会发现，Java的整个基础架构的设计都是为网络服务。首当其冲的便是Java中最著名的跨平台。其实，在Java之前的年代，人们也需要考虑平台之间的可移植性，但这种移植大多数集中在源码一级，这也就是C语言可以流行的原因之一，在单机环境下，平台的差异并不那么明显。网络的出现使平台之间差异凸现出来，因为网络可能会连接各种各样的计算机和设备。没错，还有设备，你也许知道Java最初的开发是和嵌入式设备相关的。一旦应用可以跨平台，程序开发和后期管理维护工作将得到极大的简化，可移植性也从源码级晋升到二进制级（Java字节码）。所以，跨平台实际上也是为了网络打基础。Java中另一个重要的买点——安全性与网络之间的关系更为密切，谁都可以想出几条理由，把二者关联起来。 再来具体看看Java的基础架构如何对网络进行支持的。还记得Java最初是怎么吸引人的吗？没错，Applet。熟悉原理的朋友都知道，Applet的运行是把远程的类文件下载到本地来执行的。相对于本地硬盘，网络给我们的感觉就是一个字————慢。如果Java采用传统可执行文件组织方式，即一个完整的可执行文件，把整个 Applet下载下来的运行，只怕等到花儿也谢了。Java采用的手法是把文件拆开，以类为单位进行组织，这就是我们今天见到的class文件。这样，执行的过程就变成第一个类下载之后就可以运行，大大节省了最初的等待时间。好的设计会把程序分成若干的模块，所以，绝大多数程序不可能写在一个类中。因此，类文件中必须包含它所用到类。对于引导部分，我们可以让它以特定的方式开始执行，比如把我们耳熟能详的main方法放在特定的字节，但对于没有定法的任意方法，是没有办法规定的，而一个类调用另一个类的方法就是这样随意，因此类文件中必须包含这个类方法的信息，进一步字段信息也会加进来，这样几乎一个完整类的信息就出来了，而这些信息对应的恰好是元对象。所以，元对象出现在Java基础架构中。 有了元对象，Reflection也成了一件顺其自然的事情。有了Reflection，Java也就拥有了动态扩展的能力，这样就可以极大的提高程序的灵活性。 关于Java基础结构对网络的支持还可以再说几句。class文件经过了精心的设计，本身相当紧凑，其目的就是为了方便在网络上传输，而JAR文件的出现，其目的也是为了方便网络传输，因为如果每次只传输一个类，大量的时间都被浪费在建立网络连接的过程中，JAR文件使得一次传输多个类成为可能，而且我们还知道JAR文件中的数据是经过压缩的，这样可以进一步减少下载时间。Java基础架构对网络的支持，《深入Java虚拟机》（第二版）的4.3节进行了很好阐述，有兴趣不妨看一下。 对Reflection思考让我有机会对Java本身的设计进行深入的思考。一个好的软件设计需要一个核心理念作为支撑，所有的一切都是围绕核心进行的，而对于Java，这个核心就是网络。 一次有趣的思考体验