JAVA中的传递都是值传递吗?有没有引用传递呢?
在回答这两个问题前,让我们首先来看一段代码:
- public class ParamTest {
-
- protected int num = 0;
-
-
- public void change(int i) {
- i = 5;
- }
-
-
- public void change(ParamTest t) {
- ParamTest tmp = new ParamTest();
- tmp.num = 9;
- t = tmp;
- }
-
-
- public void add(int i) {
- i += 10;
- }
-
-
- public void add(ParamTest pt) {
- pt.num += 20;
- }
-
- public static void main(String[] args) {
- ParamTest t = new ParamTest();
-
- System.out.println("参数--基本类型");
- System.out.println("原有的值:" + t.num);
-
- t.change(t.num);
- System.out.println("赋值之后:" + t.num);
-
- t.change(t);
- System.out.println("运算之后:" + t.num);
-
- System.out.println();
-
- t = new ParamTest();
- System.out.println("参数--引用类型");
- System.out.println("原有的值:" + t.num);
-
- t.add(t.num);
- System.out.println("赋引用后:" + t.num);
-
- t.add(t);
- System.out.println("改属性后:" + t.num);
- }
- }
public class ParamTest {
// 初始值为0
protected int num = 0;
// 为方法参数重新赋值
public void change(int i) {
i = 5;
}
// 为方法参数重新赋值
public void change(ParamTest t) {
ParamTest tmp = new ParamTest();
tmp.num = 9;
t = tmp;
}
// 改变方法参数的值
public void add(int i) {
i += 10;
}
// 改变方法参数属性的值
public void add(ParamTest pt) {
pt.num += 20;
}
public static void main(String[] args) {
ParamTest t = new ParamTest();
System.out.println("参数--基本类型");
System.out.println("原有的值:" + t.num);
// 为基本类型参数重新赋值
t.change(t.num);
System.out.println("赋值之后:" + t.num);
// 为引用型参数重新赋值
t.change(t);
System.out.println("运算之后:" + t.num);
System.out.println();
t = new ParamTest();
System.out.println("参数--引用类型");
System.out.println("原有的值:" + t.num);
// 改变基本类型参数的值
t.add(t.num);
System.out.println("赋引用后:" + t.num);
// 改变引用类型参数所指向对象的属性值
t.add(t);
System.out.println("改属性后:" + t.num);
}
}
这段代码的运行结果如下:
- 参数--基本类型
- 原有的值:0
- 赋值之后:0
- 运算之后:0
-
- 参数--引用类型
- 原有的值:0
- 赋引用后:0
- 改属性后:20
从上面这个直观的结果中我们很容易得出如下结论:
- 对于基本类型,在方法体内对方法参数进行重新赋值,并不会改变原有变量的值。
- 对于引用类型,在方法体内对方法参数进行重新赋予引用,并不会改变原有变量所持有的引用。
- 方法体内对参数进行运算,不影响原有变量的值。
- 方法体内对参数所指向对象的属性进行运算,将改变原有变量所指向对象的属性值。
上面总结出来的不过是我们所看到的表面现象。那么,为什么会出现这样的现象呢?这就要说到值传递和引用传递的概念了。这个问题向来是颇有争议的。
大家都知道,在JAVA中变量有以下两种:
- 基本类型变量,包括char、byte、short、int、long、float、double、boolean。
- 引用类型变量,包括类、接口、数组(基本类型数组和对象数组)。
当基本类型的变量被当作参数传递给方法时,JAVA虚拟机所做的工作是把这个值拷贝了一份,然后把拷贝后的值传递到了方法的内部。因此在上面的例子中,我们回头来看看这个方法:
-
- public void change(int i) {
- i = 5;
- }
// 为方法参数重新赋值
public void change(int i) {
i = 5;
}
在这个方法被调用时,变量i和ParamTest型对象t的属性num具有相同的值,却是两个不同变量。变量i是由JAVA虚拟机创建的作用域在
change(int i)方法内的局部变量,在这个方法执行完毕后,它的生命周期就结束了。在JAVA虚拟机中,它们是以类似如下的方式存储的:
很明显,在基本类型被作为参数传递给方式时,是值传递,在整个过程中根本没有牵扯到引用这个概念。这也是大家所公认的。对于布尔型变量当然也是如此,请看下面的例子:
- public class BooleanTest {
-
- boolean bool = true;
-
-
- public void change(boolean b) {
- b = false;
- }
-
-
- public void calculate(boolean b) {
- b = b && false;
-
- System.out.println("b运算后的值:" + b);
- }
-
- public static void main(String[] args) {
- BooleanTest t = new BooleanTest();
-
- System.out.println("参数--布尔型");
- System.out.println("原有的值:" + t.bool);
-
- t.change(t.bool);
- System.out.println("赋值之后:" + t.bool);
-
-
- t.calculate(t.bool);
- System.out.println("运算之后:" + t.bool);
- }
- }
public class BooleanTest {
// 布尔型值
boolean bool = true;
// 为布尔型参数重新赋值
public void change(boolean b) {
b = false;
}
// 对布尔型参数进行运算
public void calculate(boolean b) {
b = b && false;
// 为了方便对比,将运算结果输出
System.out.println("b运算后的值:" + b);
}
public static void main(String[] args) {
BooleanTest t = new BooleanTest();
System.out.println("参数--布尔型");
System.out.println("原有的值:" + t.bool);
// 为布尔型参数重新赋值
t.change(t.bool);
System.out.println("赋值之后:" + t.bool);
// 改变布尔型参数的值
t.calculate(t.bool);
System.out.println("运算之后:" + t.bool);
}
}
输出结果如下:
- 参数--布尔型
- 原有的值:true
- 赋值之后:true
- b运算后的值:false
- 运算之后:true
那么当引用型变量被当作参数传递给方法时JAVA虚拟机又是怎样处理的呢?同样,它会拷贝一份这个变量所持有的引用,然后把它传递给JAVA虚拟机为方法
创建的局部变量,从而这两个变量指向了同一个对象。在篇首所举的示例中,ParamTest类型变量t和局部变量pt在JAVA虚拟机中是以如下的方式存
储的:
有一种说法是当一个对象或引用类型变量被当作参数传递时,也是值传递,这个值就是对象的引用,因此JAVA中只有值传递,没有引用传递。还有一种说法是引
用可以看作是对象的别名,当对象被当作参数传递给方法时,传递的是对象的引用,因此是引用传递。这两种观点各有支持者,但是前一种观点被绝大多数人所接
受,其中有《Core Java》一书的作者,以及JAVA的创造者James Gosling,而《Thinking in
Java》一书的作者Bruce Eckel则站在了中立的立场上。
我个人认为值传递中的值指的是基本类型的数值,即使对于布尔型,虽然它的表现形式为true和false,但是在栈中,它仍然是以数值形式保存的,即0表
示false,其它数值表示true。而引用是我们用来操作对象的工具,它包含了对象在堆中保存地址的信息。即使在被作为参数传递给方法时,实际上传递的
是它的拷贝,但那仍是引用。因此,用引用传递来区别与值传递,概念上更加清晰。
最后我们得出如下的结论:
- 基本类型和基本类型变量被当作参数传递给方法时,是值传递。在方法实体中,无法给原变量重新赋值,也无法改变它的值。
- 对象和引用型变量被当作参数传递给方法时,在方法实体中,无法给原变量重新赋值,但是可以改变它所指向对象的属性。至于到底它是值传递还是引用传递,这并不重要,重要的是我们要清楚当一个引用被作为参数传递给一个方法时,在这个方法体内会发生什么。
什么叫引用?只因为这个变量的值和其它的不一样.
首先理解:都是变量
int i;
ArrayList b;
i和b都是变量.
但i是基本变量,也叫原始变量.
其它的就叫引用变量,因为它的值是一个内存地址值.引用对象的.但记住:它们都是有一个值的!i是一个数字,而b是一个内存地址值(简单的说是一个十六进
制的值).除了基本变量之外的变量都是引用变量.Vector a;这里的a也是一个变量.它也是有值的,它的值是一个十六进制的值.
变量的赋值:
int i=10;
int j=i;
//这里把i的值10给了j,所以j的值也是10
ArrayList b=new ArrayList();
ArrayList c=b;
//首先,b是一个引用变量,它的"值":是一个内存地址值!!! new
ArrayList()要分配一段内存保存它们,怎么样找到这段内存?那就是通过b里的值了.b的值就是new
ArrayList()所占内存的首地址.然后c也是一个引用变量,它的值(地址值)和b是一样的.也就是new
ArrayList()所占内存的首地址.所以当通过b或者c进行操作时,它们都是操作同一个对象的.
在方法调用的时候,方法的参数实际也就是一个变量.如果是基本类型变量的时候,假设有方法method(int aa);
int j=10;
method(j);
这里边,int aa实际也是定义了一个变量,调用的时候把j的值:10也给了aa.所以aa也是10,改变了aa的值并不会改变j的值.
如果是引用变量的时候,假设有方法methodA(ArrayList aa);
ArrayList b = new ArrayList();
methodA(b);
//方法定义了变量aa,调用的时候把b的值(地址值!!!!!)给了aa,所以aa与b有一样的值(地址值!!!!),在方法里通过aa去操作的时候,b所引用的对象也就被改变了,因为它们引用同一个对象.
纸 a = new 银行帐户();//开一个银行帐户,返回一个卡号给你,写在你的纸a里边.
用一张纸(引用变量),把你的银行卡号写在上边,然后调用我的时候,我用另外一张纸(引用变量---方法的形数),把你的号码抄过来.然后我通过这个卡号,去到银行找到你的帐号,给你存点钱.
然后你用你的纸(引用变量)上的卡号 <没变,还是那个卡号>再去查询银行帐号的时候就会发现了多了一些钱了.....
说说我对值传递和引用传递的看法:
首先我认为,大家对Java传递参数的行为是清楚的,这个争论只是一个语义上的争论。
也就是我们是否需要区分值传递和应用传递呢?或者说这样的区分有没有意义?是否合理?
博主认为存在引用传递的关键点在于,传递的对象地址值,本质上它是一个引用,无论它是否被copy过。
认为只有值传递的关键点在于,传递的对象地址值,它是一个值的copy,这个值代表的意义无所谓。
引用是c++里的概念,由于java跟c++是有一定关系的,这里把引用迁移过来,如果合理未尝不可。
c++中关于引用的解释一般喜欢说是看作“别名”,我查了几本书,大部分提到引用并不会分配内存空间,也有一本书提到,某些编译器会分配存储空间来存储被引用对象的地址。
那么还是回到语义上来,c++里的这个引用,语义上是“别名”的意思,我的理解是,一组指向同一个对象的别名应该只存储一份内存地址。当然具体实现可能会
把引用当做一个不可变的指针来处理(每个别名都存储自己的对象地址)。但是请注意,我们应该关注于它的语义,即:它没有任何值的copy,即使是一个地
址,只是另外一个名字而已。
但是java里面没有这样的概念,所有的地址传递其行为是值的传递方式,语义上统一成值传递更为清晰,我们只需要考虑这个值具体是什么,无非两种,要么是基本类型值,要么是个地址。
所以我认为这个“引用”的概念放到java中并不合适。只有值传递的说法更合理。
posted @
2008-09-12 10:25 保尔任 阅读(3403) |
评论 (1) |
编辑 收藏
Linux 发展到今天,可用的软件已经非常多了。这样自然会有一些软件的功能大致上相同。例如,同样是编辑器,就有
nvi、vim、emacs、nano,而且我说的这些还只是一部分。大多数情况下,这样的功能相似的软件都是同时安装在系统里的,可以用它们的名称来执
行。例如,要执行 vim,只要在终端下输入 vim
并按回车就可以了。不过,有些情况下我们需要用一个相对固定的命令调用这些程序中的一个。例如,当我们写一个脚本程序时,只要写下
editor,而不希望要为“编辑器是哪个”而操心。Debian 提供了一种机制来解决这个问题,而 update-alternatives
就是用来实现这种机制的。
在说明 update-alternatives 的详细内容之间,先让我们看看系统中已有的例子。打开终端,执行下面的命令:
herbert@natsu:~$ ls -l /usr/bin/editor
lrwxrwxrwx 1 root root 24 2004-09-26 08:48 /usr/bin/editor -> /etc/alternatives/editor
herbert@natsu:~$ ls -l /etc/alternatives/editor
lrwxrwxrwx 1 root root 12 2004-10-27 16:24 /etc/alternatives/editor -> /usr/bin/vim
herbert@natsu:~$
我
们看到,editor 这个可执行命令实际上是个符号链接,它指向 /etc/alternatives/editor;而
/etc/alternatives/editor 也是个符号链接,它指向 /usr/bin/vim。这样,当我输入 editor
并回车时,将执行 vim。之所以要在 /usr/bin 和 /etc/alternatives
中费心建立这样两个链接,就是要实现上面说到的特性:方便脚本
程序的编写和系统的管理。
下面我们就来看看 update-alternatives 的功能。当然,如果你觉得我说得不详细,可以看看这个命令的 manpage:UPDATE-ALTERNATIVES(8)。
首先要介绍的参数是 --display。它使我们可以看到一个命令的所有可选命令。执行
natsu:/home/herbert# update-alternatives --display editor
editor - status is auto.
link currently points to /usr/bin/vim
/bin/ed - priority -100
slave editor.1.gz: /usr/share/man/man1/ed.1.gz
/usr/bin/nvi - priority 19
slave editor.1.gz: /usr/share/man/man1/nvi.1.gz
/bin/nano - priority 40
slave editor.1.gz: /usr/share/man/man1/nano.1.gz
/usr/bin/vim - priority 120
slave editor.1.gz: /usr/share/man/man1/vim.1.gz
/usr/bin/emacs21 - priority 0
slave editor.1.gz: /usr/share/man/man1/emacs.1emacs21.gz
Current `best' version is /usr/bin/vim.
natsu:/home/herbert#
你可以看到我的机器上的所有可以用来被 editor 链接的命令。
下面说说 --config。这个选项使我们可以选择其中一个命令:
natsu:/home/herbert# update-alternatives --config editor
There are 5 alternatives which provide `editor'.
Selection Alternative
-----------------------------------------------
1 /bin/ed
2 /usr/bin/nvi
3 /bin/nano
*+ 4 /usr/bin/vim
5 /usr/bin/emacs21
Press enter to keep the default[*], or type selection number: 4
Using `/usr/bin/vim' to provide `editor'.
natsu:/home/herbert#
我并没有修改它,因为我还是比较喜欢 vim 的。当然,你可以选择别的程序。
说
到这里我们就要介绍一些概念了。首先,update-alternatives 在一般情况下是由 postinst 和 prerm
这样的安装脚本自动调用的,所以一个 alternative 的状态有两种:自动和手动。每个 alternative
的初始状态都是自动。如果系统发现管理员手动修改了一个
alternative,它的状态就从自动变成了手动,这样安装脚本就不会更新它了。如果你希望将一个 alternative 变回自动,只要执行
update-alternatives --auto editor
就可以了。你注意到了吗?我们说到了“名字”。该怎样写名字呢?这就是我们要介绍的第二个概念:
general name -- 这是指一系列功能相似的程序的“公用”名字(包括绝对路径),比如 /usr/bin/editor。
link -- 这是指一个 alternative 在 /etc/alternative 中的名字,比如 editor。
alternative -- 顾名思义,这是指一个可选的程序所在的路径(包括绝对路径),比如 /usr/bin/vim。
--
auto,--display 和 --config 跟的都是
link。我们要说的第三个概念是优先级。这个比较简单,当然优先级越高的程序越好啦(在大多数情况下,我不想争论)最后一个概念是主和从的
alternative。想想看,你将 /usr/bin/editor 链接到了 vim,可是当你执行 man editor 时看到的却是
emacs 的 manpage,你会做何感想呢?这就引出了主和从 alternative 的概念了:当更新主的 alternative
时,从的 alternative 也会被更新。
说完这四个重要的概念后,我们介绍另外两个选项。至于其他的。。。。我相信你会去看手册页的,对吗?
第一个是 --install。它的格式是:
update-alternatives --install gen link alt pri [--slave sgen slink salt] ...
gen,
link,alt,pri 分别是我们上面说过的。如果需要从的 alternative,你可以用 --slave
加在后面。如果你在向一个已经存在的 alternative 组中添加新的 alternatives,该命令会把这些 alternatives
加入到这个已经存在的 alternative 组的
列表中,并用新的可选命令作为新的命令;否则,将会建立一个新的自动的 alternative 组。
呜呼!我加入了一个错误的 alternative。我不想要这个 alternative 了。在这种情况 下,可以执行下面的命令:
update-alternatives --remove name path
name
是一个在 /etc/alternatives 中的名字,也就是上面的 link,而 path
是希望删除的可选程序名的绝对路径名(放心,这样只是从列表中删除了这个程序,并不会真的从硬盘上删除程序的可执行文件)。如果从一个
alternative 组中删除了一个正在被链接的程序并且这个组仍然没有变成空的,update-alternatives
会自动用一个具有其他优先级的可选程序代替原来的程序。如果这个组变成空的了,那么连这个 alternative
组都会被移除。如果删除的程序没有被链接,则只有有关这个程序的信息会被移除。
说个例子吧。我下载了 Eclipse,并且安装了
gcj 和 gij。可是我发现 GNU 的 java 工具还不足以运行 Eclipse。我只好到 Sun 公司的网页上下载了它的 java
工具 jdk。因为是自己安装的,我将它们安装在 /usr/local 上,以便将来重新安装 Linux
系统时这些程序仍然可以使用。于是我要做的就是用这个 jdk 中的 java 和 javac 来代替系统原来的。执行
natsu:/home/herbert# update-alternatives --display java
java - status is auto.
link currently points to /usr/local/j2sdk1.4.2_06/bin/java
/usr/bin/gij-wrapper-3.3 - priority 33
slave java.1.gz: /usr/share/man/man1/gij-wrapper-3.3.1.gz
/usr/local/j2sdk1.4.2_06/bin/java - priority 100
slave java.1.gz: /usr/local/j2sdk1.4.2_06/man/man1/java.1
Current `best' version is /usr/local/j2sdk1.4.2_06/bin/java.
natsu:/home/herbert# update-alternatives --display javac
javac - status is auto.
link currently points to /usr/local/j2sdk1.4.2_06/bin/javac
/usr/bin/gcj-wrapper-3.3 - priority 33
slave javah: /usr/bin/gcjh-wrapper-3.3
slave javac.1.gz: /usr/share/man/man1/gcj-wrapper-3.3.1.gz
slave javah.1.gz: /usr/share/man/man1/gcjh-wrapper-3.3.1.gz
/usr/bin/gcj-wrapper-3.4 - priority 33
slave javah: /usr/bin/gcjh-wrapper-3.4
slave javac.1.gz: /usr/share/man/man1/gcj-wrapper-3.4.1.gz
slave javah.1.gz: /usr/share/man/man1/gcjh-wrapper-3.4.1.gz
/usr/local/j2sdk1.4.2_06/bin/javac - priority 100
slave javah: /usr/local/j2sdk1.4.2_06/bin/javah
slave javac.1.gz: /usr/local/j2sdk1.4.2_06/man/man1/javac.1
slave javah.1.gz: /usr/local/j2sdk1.4.2_06/man/man1/javah.1
Current `best' version is /usr/local/j2sdk1.4.2_06/bin/javac.
natsu:/home/herbert#
(你看到的是我更新以后的)就可以得到关于要更新哪些 alternatives 的信息。我是这么更新的:
update-alternatives
--install /usr/bin/javac javac /usr/local/j2sdk1.4.2_06/bin/javac 100
--slave /usr/bin/javah javah /usr/local/j2sdk1.4.2_06/bin/javah --slave
/usr/share/man/man1/javac.1.gz javac.1.gz
/usr/local/j2sdk1.4.2_06/man/man1/javac.1 --slave
/usr/share/man/man1/javah.1.gz javah.1.gz
/usr/local/j2sdk1.4.2_06/man/man1/javah.1
update-alternatives
--install /usr/bin/java java /usr/local/j2sdk1.4.2_06/bin/java 100
--slave /usr/share/man/man1/java.1.gz java.1.gz
/usr/local/j2sdk1.4.2_06/man/man1/java.1
posted @
2008-02-13 10:08 保尔任 阅读(2555) |
评论 (0) |
编辑 收藏