Java到底是引用传递还是值传递
前言
前段时间在群里看到类似这样一个问题,下面的代码会输出什么呢?
public void test() {
String str = "hello";
change(str);
System.out.println(str);
}
private void change(String str) {
str = "world";
}
当时看到这题,瞬间勾起了我的回忆。遥想当年,也曾经碰到过类似的问题,当时研究了好久才搞明白,这里再记录一下这个问题的思路。
先来说一下答案:输出:hello;
解决这类问题首先要搞明白Java到底是引用传递还是值传递。
Java到底是引用传递还是值传递
首先来解释一下什么是引用传递,什么是值传递。
-
引用传递(pass by reference)是指在调用方法时将实际参数的地址直接传递到方法中,那么在方法中对参数所进行的修改,将影响到实际参数。 -
值传递(pass by value)是指在调用方法时将实际参数拷贝一份传递到方法中,这样在方法中如果对参数进行修改,将不会影响到实际参数。
那在Java中到底是引用传递还是值传递呢?其实这个问题也一直是争论不断,而且官方也没给个确切答案。但是就我个人理解,Java是值转递。
我们先来看一个简单的例子:
public void test() {
int a = 1;
change(a);
System.out.println("a的值:" + a);
}
private void change(int a) {
a = a + 1;
}
// 输出
a的值:1
在test()方法中定义了一个基本类型的变量a,然后调用change()方法试图改变这个变量,最后输出的还是原来的值。
首先我们要清楚,一个方法中的局部变量是存在栈中的,如果是基本类型的变量则直接存的是这个变量的值,如果是引用类型的变量则存的是值的地址,指向堆中具体的值。
上面的例子中,调用change()方法传递的a,其实是a变量的拷贝,不是真正的a,在change()方法中改变的是拷贝,对真正的a是没有影响的。
这么一看,Java确实是值传递,但是我们再看下面这个例子,你就会纠结了
public void test() {
User user = new User();
user.setAge(18);
change(user);
System.out.println("年龄:" + user.getAge());
}
private void change(User user) {
user.setAge(19);
}
// 输出
年龄:19
看,对象里的属性被改变了,不是值传递吗,应该不会改变啊,这时候就有人总结了,当传的值是基本类型时是值传递、当传的是引用类型时是引用传递。真的是这样吗?
分析这个问题,我们需要知道变量在jvm中是怎么存储的。
首先看基本类型,这个很简单,变量在栈中直接存的是值,传到change()方法的是这个变量的拷贝,因此对拷贝的变量修改不会影响原变量的值。
接着看引用类型,变量在栈中存储的是引用地址,这个地址指向堆中具体的值,如下图:
当调用change()方法传入变量时,也是拷贝变量,但是这里的拷贝只是栈中的引用地址,并不会拷贝堆中的数据,因此会变成下图这样:
虽然变量是拷贝,但是指向的地址是同一个,因此对变量中的数据修改时,还是会影响到原来真实的变量,但是,如果我们修改的是变量在栈中的地址,则不会影响原变量,例如下面这段代码:
public void test() {
User user = new User();
user.setAge(18);
change(user);
System.out.println("年龄:" + user.getAge());
}
private void change(User user) {
user = new User();
user.setAge(19);
}
// 输出
年龄:18
这种是修改变量在栈中的地址,则不会影响原变量。
说到这里,大家差不多懂了,但是回头看最开始的那个问题,传入String类型的变量,String是引用类型,按道理,原变量是会被改变的呀,结果怎么是不变呢?
String变量比较特殊,我们看String的源码可以知道,String的值是通过内部的char[]数组来维护的,但是这个数据定义的是final类型的,因此,String的值是不可变的。我们平时修改String的值,其实是重新new了一个String对象,例如下面这段代码:
String a = "hello";
a = "world";
这段代码里,其实a变量并没有被修改成world,只是重新new了一个String对象,这个对象的值是world,并把这个对象的引用地址赋给了a,原来的hello还是在堆中,只是这个值没有被引用,过段时间会被gc垃圾回收。
String变量传值在内存中的变化如下图:
String拷贝的是变量地址,但是它改变不了原String的值,因为String是不可变的,所以在change()方法中是重新new了一个String对象,改变的是新对象的值,原变量是没有影响的。
结论
Java是值传递。当传的是基本类型时,传的是值的拷贝,对拷贝变量的修改不影响原变量;当传的是引用类型时,传的是引用地址的拷贝,但是拷贝的地址和真实地址指向的都是同一个真实数据,因此可以修改原变量中的值;当传的是String类型时,虽然拷贝的也是引用地址,指向的是同一个数据,但是String的值不能被修改,因此无法修改原变量中的值。
2020-08-02
2020-07-23
2020-07-05
2020-06-18
2020-06-05
本文分享自微信公众号 - pipi蛋(pipidan_fuyun)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Golang | 简介channel常见用法,完成goroutin通信
点击上方蓝字,关注并星标,和我一起学技术。 今天是golang专题的第14篇文章,大家可以点击上方的专辑回顾之前的内容。 今天我们来看看golang当中另一个很重要的概念——信道。我们之前介绍goroutine的时候曾经提过一个问题,当我们启动了多个goroutine之后,我们怎么样让goroutine之间保持通信呢? 要回答这个问题就需要用到信道。 channel 信道的英文是channel,在golang当中的关键字是chan。它的用途是用来在goroutine之间传输数据,这里你可能要问了,为什么一定得是goroutine之间传输数据呢,函数之间传递不行吗? 因为正常的传输数据直接以参数的形式传递就可以了,只有在并发场景当中,多个线程彼此隔离的情况下,才需要一个特殊的结构传输数据。 Chan看起来比较怪,在其他语言当中基本没有出现过,但是它的原理和使用都非常简单。 我们先来看它的使用,首先是定义一个chan,还是老规矩,通过make关键字创建。我们之前也提过,golang当中的一个设计原则就是能省则省,能简单则简单。从这个make关键字就看得出来,它可以创建的东西太多了,既可以创...
- 下一篇
从上到下,一文带你看全所有GNN分类
↑公众号关注Graph-AI 专注于图网络与机器学习 文 · 成森 封面 · pixabay 从上到下,一文带你看全所有GNN分类 一般来说,我喜欢 从上往下 的角度来入门一个方向,毕竟入门的秘诀就是 从广到深 ,而不至于在一开始就只见枝叶不见森林。先在心中有个谱,然后再慢慢奏好每个音符,这样就会出来美妙的旋律。 这个系列挑选了清华大学刘知远老师的《 Introduction to Graph Neural Networks 》和他们的一份综述《 Graph Neural Networks: A Review of Methods and Applications 》作为参考。优秀的综述很多,我可能也参考了其他,但主要还是这两者。 本文是一个序章,是一篇导读文,从本文开始,后面的文章我再细细拆分和详解。 让我们开始吧。 总架构 首先是总架构,从下方的思维导图可以看到,我们可以从九个方面来全方面了解我们的GNN。 简单来说可以分成五大部分: 基础 :包括理解GNN需要的数学基础、图论基础,和神经网络基础。 GNN的了解 :包括图的种类、传播类型、训练方法、通用框架。 应用场景 :GN...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS关闭SELinux安全模块
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7设置SWAP分区,小内存服务器的救世主