你肯定也遇到过这个场景：面试官面带微笑问“Java 到底是值传递还是引用传递”，你脱口而出“对象是引用传递”，结果对方眉头一皱，空气突然安静。更邪门的是，等你上网一搜，发现有人斩钉截铁说“Java 只有值传递”，还有人搬出 C++ 的引用传递来对比，评论区吵成一锅粥。
我带过的实习生几乎都在这道题上栽过跟头。最典型的困惑是：“我明明把一个对象传进方法里，方法里面改属性，外面确实变了，凭什么说这不是引用传递？”这个问题如果只背结论，永远搞不明白；但只要把 JVM 的栈帧、堆内存、局部变量表摆出来，一层层拆开看，你就能像庖丁解牛那样，沿着骨骼关节走一遍，彻底看透值传递、引用传递和底层内存之间的关系。
下面我用实际操作中的代码案例、内存模型和踩坑记录，把这套逻辑从头到尾拆给你看。
1. 先搞清楚：值传递和引用传递到底在争论什么
1.1 教科书里的定义为什么总是“对完就忘”
我先说结论：在 Java 里，不管传的是基本类型还是对象，本质上都是值传递。所谓“引用传递”指的是 C/C++ 里那种把变量地址本身传进去的玩法，Java 根本没这个机制。这句话说出来简单，但为什么那么多人记了又忘？因为大家把“传引用”和“传引用值”混成了一个概念。
- 值传递：把变量存的东西复制一份，传给方法。
- 引用传递：把变量的内存地址传过去，方法里操作的就是同一个地址空间。
Java 传对象时，复制的是“引用”。引用是什么？它可以理解成一把钥匙，钥匙上刻着对象的内存地址信息。你复制了一把钥匙交给方法，方法能用这把钥匙打开同一扇门，但方法里如果把钥匙换成了另一把，你手上的原配钥匙并不会变成新的。
很多人觉得“方法能修改对象里的属性”，就说明是引用传递。但真相很简单：方法拿到的钥匙是复制品，但两把钥匙都能开同一个锁。这个区别，就是“对象是引用传递”这种错误说法的根源。
1.2 用一把钥匙和一扇门理解“引用”的本体
我经常跟团队新人举一个生活化的例子：你把家里备用钥匙借给朋友，让他去你家拿一本书。朋友拿钥匙开了门，把书拿出来，你们俩都知道书被取走了。但如果你把钥匙交给朋友后，朋友转身去买了一把新钥匙，还得意地说“我帮你换了把家门钥匙”，你会一脸懵——你自己手里那把钥匙还是原来的，大门也还是原来的。
Java 的对象引用的本质就是这样：
- 堆内存里有一块区域存着对象数据，比如用户对象的 name、age 字段。
- 栈或局部变量里存的只是一个地址（或者说一个指向堆空间的值）。
- 方法参数接收的是这个地址的拷贝。
这里有个非常容易忽略的细节：“引用”本身也是一个值，这个值可以被人为地用=重新赋值。一旦重新赋值，它就不再指向原来的对象了。但在方法里重新赋值引用参数，只会影响这个拷贝，不会影响外部的原始变量。
1.3 Java 的官方裁决：只有值传递
Oracle 的官方文档和 Java 语言规范里说得很明确：当调用方法时，参数的值会被拷贝并传给方法。注意是“参数的值”。如果参数是基本类型，传的是具体的数值；如果参数是引用类型，传的是引用值——也就是那个“地址”的拷贝。
这导致了一个看似“矛盾”的结论：
- 方法内修改对象的内部状态（比如
user.setName("王五")），外部能看到，因为对象是同一个。 - 方法内重新赋值引用变量（比如
user = new User("李四")），外部看不到，因为引用变量的拷贝被改变了。
我们马上用代码实测这两条结论。
2. 庖丁解牛：从 JVM 栈帧视角看参数传递的底层内存
2.1 栈帧里到底存了什么东西
要理解 Java 参数传递，不能停留在语法层面，得进到 JVM 的方法执行模型里。每次调用方法，JVM 会为这次调用分配一个栈帧。栈帧里有一块区域叫局部变量表，它本质上是一个数组，按索引存了方法内声明的所有局部变量和参数。
关键点在这里：
- 基本类型变量，比如
int age = 18，局部变量表里直接存 18。 - 引用类型变量，比如
User user = new User()，局部变量表里存的是指向堆对象的地址/引用值。 - 引用值本质上像一个数字地址，但它不是 C 语言那个裸指针，JVM 会做很多安全校验。
方法被调用时，调用方会把自己的“实参”按顺序复制到新栈帧的局部变量表里。这一步就是参数传递的全部真相：在栈帧之间复制值。
2.2 方法调用时实际发生的三步
如果在代码里写changeName(user)，JVM 大概做了这样三件事：
- 在调用方的栈帧里读取
user这个局部变量槽位的值。 - 把这个值作为参数，写入新栈帧的局部变量表中对应槽位。
- 跳转到方法字节码开始执行。
你发现没有，这个过程压根没有把调用方栈帧里那个槽位的地址传给新栈帧。新栈帧只是拿到了一个“相同的拷贝”。所以你在新栈帧里对参数槽位重新赋值，改的只是新栈帧自己的局部变量表，和调用方栈帧完全无关。
这一点在字节码层也能看出一二。Java 编译时，局部变量表里对象变量用的是aload_0、astore_1这类“reference load/store”指令，但它们加载和存储的都是引用值，不会把整个对象或者变量的地址倒腾过去。
2.3 基本类型和引用类型在方法调用时的差异
用一个表格把两种类型在栈帧复制层面的区别列明白：
| 对比维度 | 基本类型参数 | 引用类型参数 |
|---|---|---|
| 局部变量表存储内容 | 具体数值，比如 18 | 指向堆对象的引用值（一个地址） |
| 拷贝的是什么 | 数值本体 | 引用值（地址）本身 |
| 方法内赋值后外部变量是否变 | 不变 | 引用变量本身不会变 |
| 方法内修改“对象内容”后外部是否可见 | 无此概念 | 可见，因为拷贝的引用直达同一个堆对象 |
| 典型例子 | int、long、boolean | User、数组、List、StringBuilder |
“引用类型参数”这个名字本身就说明问题：参数类型是一个引用，但传递的是这个引用的值。你可以把引用类型理解为一个类似于long的“地址数值”，它只是恰好能用来索引到堆内存里的对象。
2.4 堆上的对象和数组为什么“看起来像引用传递”
很多人在数组上也会有同样的困惑。比如：
public class Demo { public static void main(String[] args) { int[] arr = {1, 2, 3}; changeFirst(arr); System.out.println(arr[0]); // 会输出 99 } static void changeFirst(int[] array) { if (array.length > 0) { array[0] = 99; } } }外部数组元素变了，所以有些人认为“数组是引用传递”。但真的只是“看起来像”。我来解释底层：数组变量arr里存的是一个引用值，指向堆里的数组对象。方法参数array复制了这个引用值，也指向同一个数组对象。array[0] = 99这句代码是在“通过引用值访问堆对象并修改其内部数据”，这不需要改变外面arr变量本身的引用值。如果我们在方法里写array = new int[]{7, 8, 9}，外部arr依然指向原来的数组。
所以结论是一致的：Java 没有引用传递，只有“引用值的传递”。
3. 经典翻车现场再复盘：三个高频代码案例
3.1 swap 为什么永远换不过来
几乎每本 Java 入门书都有这段祖传代码：
public class SwapDemo { public static void main(String[] args) { int a = 1; int b = 2; swap(a, b); System.out.println("a = " + a + ", b = " + b); // 输出 1 2 } static void swap(int x, int y) { int tmp = x; x = y; y = tmp; } }很多人第一反应是“哪里写错了”，其实代码逻辑没问题，问题出在参数传递模型上。swap方法里的x、y是主方法a、b的一份拷贝副本。方法里交换的是局部变量表里两个槽位的值，交换完，副本回到各自“人生的巅峰”，然后方法结束，栈帧弹出，一切灰飞烟灭。主方法局部变量表里的a、b从头到尾没动过。
如果想要交换两个对象，比如两个User的引用，也是一样的结局：
static void swapObject(User u1, User u2) { User tmp = u1; u1 = u2; u2 = tmp; }调用结束后，外部两个引用变量依然指向原来的对象。
3.2 修改对象的属性为什么又成功了
再看另一段高频代码：
public class UpdateUserDemo { public static void main(String[] args) { User user = new User("张三"); updateName(user); System.out.println(user.getName()); // 输出 王五 } static void updateName(User u) { u.setName("王五"); } }一个很自然的疑问出现了：“不是说值传递吗？为什么这里改了，外面也变了？”如果你理解了堆内存模型，这个问题就迎刃而解。
在main方法里，user变量存着引用值，指向堆上的User对象。调用updateName时，JVM 把user引用的值复制一份，存到updateName栈帧的局部变量u里。这时候user和u是两个槽位，但两个槽位装的是同一个地址，指向同一个堆对象。
u.setName("王五")做的事情是：通过u里存的地址，找到堆上的对象，然后把对象内部的name字段值改成"王五"。对象还是原来那个对象，只是内容变了。外面user里的引用值也不需要变，它依然指向这个对象。所以你看到外部对象“变了”，这个变是堆对象内容的变化，不是引用值的变化。
这就是值传递和引用传递最容易被混淆的核心：值传递的对象，如果对象本身可变，方法内对对象字段的修改当然可以影响外部。因为传递的是“指向该对象的引用值”，不是把整个对象复制一遍。
3.3 String、Integer 这类不可变对象的“欺骗性”
字符串是另一个高频翻车点：
public class StringDemo { public static void main(String[] args) { String s = "hello"; appendStr(s); System.out.println(s); // 输出 hello } static void appendStr(String str) { str += " world"; } }有人一看str += " world"就以为外部s会变成hello world，结果一跑还是hello。这里涉及两个知识点：
第一，String是不可变的。str += " world"实际上等价于str = new String("hello world")，它不会在原有对象上追加内容，而是新建了一个字符串对象。
第二，str是s引用值的拷贝，原来的s指向第一块字符串对象，方法里的str一开始也指向同一块字符串对象。但执行+=后，str被重新赋值为指向新对象的引用值。这个重新赋值只发生在方法栈帧里，外部的s依然指向原来的对象。
类似的情况还有Integer等包装类。你写：
Integer num = 1; increase(num); System.out.println(num); // 还是 1 static void increase(Integer value) { value += 1; }value += 1会拆箱、加一、再装箱成新的Integer对象，然后赋值给局部变量value。外部原对象的引用值始终没变，所以打印结果还是1。
如果你遇到StringBuilder这类可变对象，情况又会不一样：
StringBuilder sb = new StringBuilder("hello"); appendWorld(sb); System.out.println(sb); // hello world static void appendWorld(StringBuilder builder) { builder.append(" world"); }因为builder和sb指向同一个可变对象，append修改的是对象内部结构，所以外部能看到变化。
记住一条判断标准：方法里如果要靠重新赋值来改变外部变量，那就不可能实现；只有通过引用值去修改“对象内部状态”，才能让外部感知到变化。
4. 要让“引用传递”效果生效，正确姿势有哪些
4.1 用返回值交接“新引用”最直观
遇到需要改变外部引用变量的场景，最简单的办法就是让方法返回新的引用值，由调用方自己接收：
public class ReturnValueDemo { public static void main(String[] args) { String s = "hello"; s = appendStr(s); System.out.println(s); // hello world } static String appendStr(String str) { return str + " world"; } }这个方案没有任何歧义，代码语义也清晰：方法负责“生产”，调用方负责“重新赋值”。很多团队在写不可变对象相关代码时都推荐这种风格，因为它避免了在方法内部偷偷修改外部对象带来的隐式副作用。
但要注意，如果你的方法既想返回结果，又想处理其他逻辑，返回值只能承载一个对象。如果你同时需要修改多个外部变量，就得用下面的容器方案。
4.2 使用可变“结果容器”绕过语言限制
虽然 Java 没有引用传递，但我们可以通过一个“持有者/容器对象”来达到类似效果。常见做法有三种：
- 用单元素数组。
- 用自定义 Box 包装类。
- 用
AtomicReference或AtomicInteger这类原子类型。
例如交换两个对象引用：
class Box<T> { T value; Box(T value) { this.value = value; } } public class SwapByBox { public static void main(String[] args) { Box<String> a = new Box<>("甲"); Box<String> b = new Box<>("乙"); swap(a, b); System.out.println(a.value + ", " + b.value); // 乙, 甲 } static <T> void swap(Box<T> a, Box<T> b) { T tmp = a.value; a.value = b.value; b.value = tmp; } }这段代码能成功交换，是因为a、b虽然是引用值的拷贝，但它们指向的Box对象是同一个。swap方法修改的是Box对象的内部字段value，这属于“修改对象内部状态”，外部自然能看到。
用单元素数组同理：
int[] holder = new int[1]; compute(holder);本质上没有绕开值传递，而是改变策略：外部变量不动，只修改这个外部变量所指向对象的内部状态。
4.3 用final修饰参数值，防止误改引用
还有一个容易被忽略的小细节：Java 允许给参数加final修饰符。很多人觉得这只是让代码更“规范”，实际上它能在编译阶段拦住一部分低级错误。
static void updateName(final User user) { // 如果写了 user = new User("王五"); 编译报错 user.setName("王五"); // 没问题 }加上final之后，方法体里不能重新赋值user引用，如果手滑写了赋值语句，编译器直接报错。这是我在带团队时经常推荐的防御式写法，因为遇到复杂业务逻辑，一不小心就可能把参数引用替换成新对象，导致外面数据“纹丝不动”的诡异 bug。
4.4 和 C++ 对比：Java 设计者为什么这么取舍
说“Java 没有引用传递”，得跟真正有引用传递的语言对比一下才够直观。C++ 的引用传递是这么写的：
void swap(int &a, int &b) { int tmp = a; a = b; b = tmp; } int main() { int x = 1, y = 2; swap(x, y); // x = 2, y = 1 return 0; }int &a声明了一个“引用”，它本质上相当于是变量x的别名。在 C++ 函数里对a做任何赋值，都会直接作用于实参x的那块内存。所以 C++ 才能实现真正意义上的引用传递——传递的是变量所在内存空间的访问能力，不只是地址值本身。
Java 为什么不这么做？最核心的原因是为了内存安全和简单性。如果方法能直接拿到调用方变量的“内存绑定关系”，就很容易出现有人乱写导致栈内存被破坏的情况。Java 的设计哲学是：所有参数都按值复制，引用值指向的堆对象可以共享访问，但“变量槽位本身”不能被外部方法直接操作。这让方法调用的边界变得可预测，不容易写出 C++ 那种令人头疼的别名问题。代价就是，很多在 C++ 里很自然的写法，在 Java 里必须换思路实现。
5. 面试、写码、看项目的实际用法
5.1 面试官真正想考察的点
我面试候选人时，如果问这个问题，重点不是要对方背诵“Java 只有值传递”，而是看对方能不能把“栈帧里的引用值”和“堆里的对象”区分开。一个好的回答通常包含三个层次：
- 基本类型参数传的是值拷贝。
- 引用类型参数传的是引用值的拷贝，不是对象实体的拷贝，也不是变量本身。
- 方法内重新赋值引用，不影响外部变量；但方法内修改对象字段，外部能感知。
能做到第三点，说明候选人对“共享引用”有真实体感。我经常追加一个问题：“如果有一个可变对象，也有一个不可变对象，分别作为参数传入方法，方法的修改对外部影响有什么不一样？”这个追问能把一知半解的人直接筛掉。不可变对象如 String，方法内对它的修改往往是生成新对象并重新赋值局部变量，外部不受影响；可变对象如 StringBuilder，方法内修改对象内部结构，外部会看到变化。
5.2 常见错误排查清单
基于实际踩坑记录，我整理了一份速查表：
| 场景 | 外部是否受影响 | 原因 |
|---|---|---|
| 方法内修改对象的可变字段 | 受影响 | 参数引用值是拷贝，但指向同一堆对象 |
| 方法内对引用参数重新赋值 | 不受影响 | 只是修改了栈帧里的槽位，外部引用值未动 |
| 方法内对数组元素赋值 | 受影响 | 数组也是堆对象，元素是对象内部数据 |
| 方法内让数组变量指向新数组 | 不受影响 | 拷贝的引用被重新赋值，外部数组引用不变 |
方法对 String 做+= | 不受影响 | String 不可变，+=生成新对象并重赋引用值 |
方法对 StringBuilder 做append | 受影响 | 修改的是同一个可变对象内部结构 |
方法对 Integer 做+= | 不受影响 | 包装类不可变，+=拆装箱后换对象 |
还有两个容易踩的坑：
第一个坑是误以为“使用包装类型就能改外部基本变量”。很多人写void addOne(Integer num) { num += 1; }，然后发现外面没变，就怀疑“Java 是不是有时候引用传递有时候不是”。其实Integer不可变，num += 1会拆箱、加一、装箱成一个新Integer对象，然后赋值给方法里的num拷贝，原对象毫发无损。
第二个坑是使用List时“改引用还是改元素”分不清。list.add(...)修改的是 List 对象内部结构，外部可见；但list = new ArrayList<>()只是把局部引用拷贝指向新集合，外部原引用不变。
5.3 调试时如何直观观察“引用值”
如果觉得光看代码总隔一层，可以用System.identityHashCode()来观察“引用到底是不是同一个对象”。这个方法返回对象的身份哈希值，在默认情况下和对象内存地址有关联，可以用来判断几次操作之间是否指向同一个堆对象。
比如这个例子：
public class IdentityDemo { public static void main(String[] args) { User user = new User("张三"); System.out.println("外部修改前：" + System.identityHashCode(user)); modify(user); System.out.println("外部修改后：" + System.identityHashCode(user)); } static void modify(User u) { System.out.println("方法内初始：" + System.identityHashCode(u)); u.setName("王五"); System.out.println("方法内改名后：" + System.identityHashCode(u)); u = new User("李四"); System.out.println("方法内重新赋值后：" + System.identityHashCode(u)); } }执行后你会发现，方法内重新赋值前，打印的身份哈希值和外部完全一致，说明两个变量确实指向同一个堆对象；重新赋值后，方法内的身份哈希值会变化，而外部打印的依然保持原样。这个技巧在排查“为什么对象内容没变”或者“改了 A 影响 B”这类问题时非常好用。
如果你在 IDE 里打断点，也能直接看到局部变量里存着一个“对象引用”，它更像是一个带 ID 的句柄。观察方法调用前后这个 ID 的变化，比干看概念清楚得多。
写在最后的一点实操体会
我刚开始带项目组时，很多新人写代码都会犯同一个毛病：把“修改对象内部属性”和“修改对象引用”混为一谈。查一次 bug 往往要花半天，原因就是某段代码在方法里把一个集合变量重新赋值为新集合，外面还等着旧集合被改完呢。后来我们定了两条规矩，项目里类似的坑少了很多：
第一，方法参数尽量不重新赋值，如果一定要重新赋值，先想想返回值怎么处理，或者改用容器对象。
第二，在方法签名上对有把握不多改引用的参数加final，让编译器帮我们守住底线。
这些经验不只在面试里用得上，在实际项目里，尤其是代码量大、并发线程多的地方，能精确区分“改对象内容”和“改引用指向”，往往就是程序正常和偶发 bug 之间的分水岭。你把栈帧、引用值、堆对象这三层关系在脑子里转清楚了，很多内存相关的问题都会有豁然开朗的感觉。
