java 引用传递的三种类型小结

java引用传递的三种类型

我这里使用了mldn视频里的例子，只用于学习交流。

第一种

结果：调用前：50

调用后：1000

分析：

理解：好理解

第二种传递方式

先看例子

运行结果：

分析图片：

第三种传递方式

结果：

分析：

对于三种引用传递的理解

第一种和第三种都好理解：

其实就是c语言那样传递的是地址，当然能够修改属性值，对于第二种其实就是因为String类比较特殊，在第二个例子中fun()函数str2="mldn"其实mldn是个匿名对象！！！这个等式其实就是将str2的引用的地址值改变了，也即使str1的引用地址指向了mldn这个在堆内存的这个对象。

java引用传值问题

一图胜万言（配上一张启舰大神的图，一个自定义控件写的很吊的大神）:

这几天一直在写一个项目，果然只搞理论是不行的，距离上一次写项目已经快有半年了，今天无论是效率还是熟练度都大不如前

好了言归正传，今天要说的这个问题其实很简单——在java中的参数传递问题。（其实我承认，这个地方我只是知道对象传引用、普通类型传值，典型的理论派-。+），但是这个问题可大可小，我觉得还是要把这些缕得清清楚楚才好。

问题起源，一个蠢到家的是失败案例

其实今天写这篇文章完全是咋呼-。+，恰好是因为自己在做RecyclerView的万能适配器的时候出现的问题，先给大家引入一下当时的场景：

@Override
   public void resultCallbackFromFragment(List<Contact> list) {
       Toast.makeText(this, "修改成功！", Toast.LENGTH_SHORT).show();
       ......
       contactList = list;
       adapter.notifyDataSetChanged();
       ......
   }

只留下了我们设计的代码，其他部分的代码全部打&hellip;&hellip;了。接下来我用极其简单的组织语言介绍一下场景：

打开一个具有复选框的界面，退出时返回选中的数据，方法为一个回调方法，方法的效果是更新列表数据（contactList为我们传入RecyclerView的源数据）。

理论上说先给contactList更新为获取到的最新的值，然后调用notifyDataSetChanged方法，列表就刷新了，看上去一切都是那么的圆满。然后我们看一下效果：

不要吐槽这个App背景，因为是给我的小仙女做的-。+！

在上面的效果中，我们看到，在选中了两个联系人，点击确定之后，按道理说应该是显示成两个人，怎么还是刚才的数据呢？

当时也是知道引用类型的传递传递的是引用，回忆了一下自己当时的思路：引用传递给了另一个引用，这一个引用的内容改变了，所有的都改变了。。。。 (可能有的朋友看到我这句话觉得很好笑：哇博主你好菜啊，这么基础的问题都被绕住了，好吧我得承认java基础是有些差。。)

就是这么简单的一句话让我饶了好几个大弯，当时自己已经被绕进去了，觉得这个数据就是被改变了啊，然后就开始从其他地方找错误，过了好久才开始反思：是不是数据传递的过程出现了点问题-。+

然后自己就开始查找参数传递相关问题，好了，现在开始，我们先跳出上面这个案例中，我不希望大家被上面花里胡哨的东西影响，因为我们今天讲的问题只有一个：java的引用传值。

两类参数传递

参数传递主要分为两种：一种是参数是基本类型，一种是参数为引用类型。

基本数据类型

这个相信大家都没什么问题，基本类型作为参数传递的时候是在一个方法栈中开辟了一块新内存，拷贝了原来的数据值，所以无论我们如何修改，原来的数据值不会受到任何影响。

举个简单的栗子：

public class Practice2 {
public static void main(String[] args) {
// TODO Auto-generated method stub
int a = 5;
System.out.println(a);
change(a);
System.out.println(a);
}
public static void change(int b) {
b = 500;
}
}

结果如下：

5
5

没有任何变化，对吧。

引用数据类型

首先我们要知道引用的数据存储在栈内存中，而引用指向的对象存储在堆内存中。

当引用作为方法参数传递给方法的时候，是将引用的值拷贝一份给另一个引用，但引用指向的都是同一个堆内存，所以进行的修改操作同样有效。

实例代码：

public class Practice {
static A a = new A(10);
public static void main(String[] args) {
// TODO Auto-generated method stub
Practice practice = new Practice();
System.out.println(practice.a.intData);
change(practice.a);
System.out.println(practice.a.intData);
}
public static void change(A aa) {
aa.intData = 500;
System.out.println(aa.intData);
}
}
class A{
int intData;
public A(int intData) {
this.intData = intData;
}
}

10
500

这么说起来没什么难度，对吧。

引用传递

其实上面所说的引用形参传递，本质上就是引用的传递，我们将引用传递给了另一个引用，那么这两个引用都有了相同的值&mdash;&mdash;既指向了相同的对象。

A a1 = new A(10);
A a2 = a1;
System.out.println("a1的intData： " + a1.intData + "   a2的intData：  " + a2.intData );
a2.intData = 500;
System.out.println("a1的intData： " + a1.intData + "   a2的intData：  " + a2.intData );

结果如下：

a1的intData： 10   a2的intData：  10
a1的intData： 500   a2的intData：  500

注意）：引用类型中，形参能够改变实参的值，或者一个引用能够改变另一个引用的值，仅仅是因为他们栈内存中存储的值相同，但这个值是随时可以修改的。

这个也就是本人之前一直被困住的地方，其实只要引用存储的值改变了，这两个引用就毫无关系了。请见下面的例子：

A a1 = new A();
A a2 = a1;
System.out.println(a1);
System.out.println(a2);
a2 = new A();
System.out.println(a1);
System.out.println(a2);

结果如下：

A@33909752
A@33909752
A@33909752
A@55f96302

在a2指向新的对象后，a1和a2就已经没有任何关系了，因为他们两个引用存储的值已经完全不一样了。

相信这张图已经说的很明白了吧。

反过来再解决这个案例

现在有了上面的理论知识，我们在反过头来看一开始的这个问题。

@Override
   public void resultCallbackFromFragment(List<Contact> list) {
       Toast.makeText(this, "修改成功！", Toast.LENGTH_SHORT).show();
       ......
       contactList = list;
       adapter.notifyDataSetChanged();
       ......
   }

在我们获取到了新的list之后，是给contactList赋值了一个新的引用，此时他指向的为一个新的堆内存空间。但是适配器中的list还是指向之前的引用，因为我们只是改变了contactList引用的值，然后执行notifyDataSetChanged方法，可是适配器中list数据还是原来contactList指向的数据。

因此解决的办法是：直接改变适配器中的list引用，然后调用notifyDataSetChanged方法：

public void notifyData(List<T> mList){
       this.mList = mList;
       notifyDataSetChanged();
   }

直接在适配器中写一个修改数据的方法，然后在外面调用就好啦：

@Override
   public void resultCallbackFromFragment(List<Contact> list) {
       Toast.makeText(this, "修改成功！", Toast.LENGTH_SHORT).show();
       ......
       contactList = list;
       adapter.notifyData(contactList);
       ......
   }

来源：https://blog.csdn.net/weixin_43157199/article/details/82902658