深入理解Java数组的引用传递逻辑

## 深入理解 Java 数组的引用传递机制 许多 Java 初学者在编写数组传参时，或多或少都曾遇到过这样的困惑——明明在方法内部修改了数组元素，但返回的结果却与预期不符；或者试图通过给形参赋予一个新数组来“替换”原数组，却发现调用方丝毫不受影响。究其根本，核心规律只有一条：**Java 数组作为参数传递时，传递的是引用的副本，本质上仍属于值传递**。一旦透彻理解这一点，绝大多数因传参引发的奇怪问题，都能一眼看穿。 ### 数组变量存储的是地址，而非数据本身 先来看这行代码：`int[] arr = {1, 2, 3};` 执行时发生了什么？JVM 会在堆内存中划分出一块连续的存储区域，依次存放 1、2、3 这三个 int 值，假设这块区域的首地址为 `0x0011`。而栈中的变量 `arr`，实际上只保存了那个地址 `0x0011`。换句话说，`arr` 本质上是一个指向数组对象的指针变量，它本身并不“拥有”那三个数值。就好比你手里拿着一张房子的门牌号——门牌号并不是房子本身，但通过它你可以找到房子。 ### 传入方法时，复制的是这个地址，而不是数组本身 现在调用 `change(arr)`：JVM 会将 `arr` 中存放的地址值（`0x0011`）复制一份，交给方法的形参 `arr2`。注意，`arr` 和 `arr2` 是两个完全独立的变量，但它们持有的地址完全相同，指向同一块堆内存。因此，当你通过 `arr2[0] = 99` 修改数组元素时，本质上是直接操作那块堆内存中的数据。回到调用方，`arr[0]` 自然也就变成了 99。 这个场景就好比两个人各持一把相同的钥匙，都可以打开同一扇门去移动物品——只要改变的是屋内的东西，另一个人回头一看，屋内必然也发生了变化。 ### 但重新赋值形参，并不会影响实参 假设有人在方法中写了这样一行代码： ```ja va arr2 = new int[]{4, 5, 6}; ``` 这仅仅是让 `arr2` 这把钥匙指向了一栋全新的房子，原来的 `arr` 依然牢牢握着旧地址 `0x0011`。对调用方来说，数组内容纹丝未动。即使你写 `arr2 = null`，也只是清空了形参手中的钥匙，实参手里的那把钥匙依旧完好无损。这类操作之所以无效，是因为我们并没有改动原始的地址值，只是将局部引用的指向更换了而已。 ### 需要原地修改时，必须操作元素，不能替换引用 在实际开发中，经常需要编写修改数组内容的方法，比如数组旋转 `void rotate(int[] nums)`。此时最容易犯的错误是： ```ja va // ❌ 错误：只改了形参指向 nums = newArr; ``` 你以为将新数组赋值给 `nums`，调用方就能看到一个新数组？遗憾的是，调用方持有的引用仍然是原来的那个。正确的做法，要么使用 `System.arraycopy(newArr, 0, nums, 0, nums.length);`，要么逐个将新值赋给原数组的各个元素。核心原则非常简单：所有修改必须作用于原数组对象本身的元素上，而不是替换数组变量所持有的引用。记住这一点，数组传参的陷阱基本就能轻松规避。