Java参数传递：值传递还是引用传递？一文彻底搞懂原理与陷阱

昨天有个读者私信我，说自己面试时被问到“Java参数传递到底是值传递还是引用传递”，他张口就回答“引用传递”，还自信满满地补了一句“因为对象传的是引用”。结果面试官让他现场写个交换两个对象的swap方法，他当场愣住了。这种场景我见得太多了，因为这道题表面上就八个字，但几乎有一半以上的Java开发者都会答错，或者答不到点子上。

我最早入行时也栽过这个跟头。当时照着某本教材上的说法背“基本类型是值传递，对象是引用传递”，自我感觉良好。后来被人追问“那为什么方法里给参数重新new一个对象，外面没变？”，我瞬间不知道怎么解释。也就是从那时起，我才开始认真去看JVM的内存模型，去看Java到底怎么处理形参和实参的关系。这篇文章就把我这些年反复梳理的结论、实验、面试话术和实际开发里的教训一次讲清楚。

1. 一个面试场景引发的争论：结论不是“背”出来的

1.1 为什么这道题能成为面试高频题

你打开任何一份Java面试题库，“值传递还是引用传递”基本都是前排常客。它之所以被反复问，不是面试官闲得慌，而是这道题天然适合用来区分“背答案的人”和“真正理解底层的人”。

很多人背的结论是：基本类型传值，对象传引用。这个简化的说法在笔试选择题里能蒙对方向，但只要面试官往深了追问一句“你刚才说的引用，是Java里的对象引用，还是C++里的引用语义”，大部分人就会露馅。因为这两种“引用”根本不是一个东西。

C++里的引用传递，形参是实参的别名，你在函数里给形参重新赋值，外面那个变量也一起变。Java里没有这种机制。Java里的对象引用，本质上只是一个存放对象地址的变量，它被复制过去的时候，复制的是地址值本身。所以严格从参数传递的语义来说，Java里只有值传递，没有引用传递。

1.2 先给一个经得起推敲的标准结论

我把结论写在这里，你先记住，后面再用代码验证：

Java方法的参数传递是值传递。

• 如果参数是基本类型，传递的是值的副本。方法内修改形参，实参不受影响。
• 如果参数是引用类型，传递的是引用地址的副本。方法内对形参重新赋值（比如指向一个新对象），实参不受影响；但通过形参修改它指向的那个对象的内容，实参变量指向的对象会受影响。

也就是说，无论参数是什么类型，方法拿到的都是“实参变量里那个值的复印件”。区别只在于：基本类型复印件里装的是数值，引用类型复印件里装的是对象地址。你拿着复印件改不了原件上的数字，但如果复印件和原件写的是同一个储物柜编号，你把储物柜里的东西换了，别人打开同一个柜子时看到的自然也就是你放进去的新东西。

这个比喻很关键，它解释了后面所有实验现象。

2. 栈帧里的真相：参数传递在底层到底做了什么

2.1 方法调用时JVM做了什么

要真正理解值传递，不能只看源代码层，得往下看一层：JVM的方法调用机制。

Java的方法调用是基于虚拟机栈的。每次调用一个方法，JVM就会在当前线程的虚拟机栈里创建一个栈帧。局部变量表、操作数栈、动态链接、方法出口这些信息都存在这个栈帧里。其中局部变量表就是我们说的“变量”真正存放的地方，它是以槽为单位的，一个槽可以装一个int、一个引用地址，long和double这种64位的类型会占两个槽。

当你执行 int b = add(a);，在进入add方法的那一刻，JVM会为add方法创建新栈帧，并把你传入的实参值复制到新栈帧的局部变量表里。注意“复制”这个动作，它是值传递的物理基础。实参和形参，分别在两个不同的栈帧里，各自占各自的槽位。形参不是实参的引用，它就是一个独立的副本变量。

这个机制解释了为什么在方法内给形参赋值，外面的实参根本感知不到——因为它们是两个栈帧里的两个独立槽位，操作方法内的那个槽位，当然影响不了方法外的那个槽位。

2.2 “引用也是一种值”是理解整道题的关键

很多人卡在“引用传递”这四个字上，是因为混淆了两个层面的“引用”。

第一个层面：Java语言里的“引用类型”，指的是除基本类型之外的所有类型，包括类、接口、数组、枚举。一个引用类型变量里存储的并不是对象本身，而是对象的地址（或者说“指向”）。这是Java隔离栈和堆的一种设计。

第二个层面：参数传递里的“引用传递”，是一种传参机制，它要求形参直接绑定到实参变量上，操作形参就是操作实参本身。Java没有这种机制。

所以当你听到“对象传的是引用”，这句话本身没错，因为对象参数变量里装的就是引用地址。但是“传引用”不等于“引用传递”。Java把引用地址复制了一份再传过去，这个复制出来的地址又是值，所以从整体上，参数传递的机制仍然是值传递。

我记得当年把这些概念彻底捋清楚的瞬间，是在JDK源码里看到一句话：Java把“references to objects are passed by value”。这句话比各种博客总结都准确：对象引用以值的方式传递。你要非用一句极简的话概括整个Java参数传递，那就是这句。

2.3 需要顺带理解的堆和栈分工

为什么基本类型不用new就能用，对象却要new？这背后就是栈和堆的分工。

基本类型变量直接存在栈帧的局部变量表里，它的“值”就是数据本身。所以复制的时候，复制的是数据。

对象实例存放在堆里。一个对象在堆里占据一块内存，也有自己的地址。引用类型变量存在栈里，但存的是堆地址。所以复制的时候，复制的是地址。

数组和字符串比较特殊。数组在Java里本身就是一个对象，所以数组变量也是引用类型，传数组参数同样传的是引用地址的副本。字符串String虽然用起来像基本类型，但它也是引用类型，只是它被设计成了不可变对象，这导致它在参数传递中的表现有一些迷惑性，后面我会单独讲。

3. 四大实验把值传递钉死：代码逐行验证

3.1 实验一：基本类型交换，不生效

最常见的反面教材就是swap方法。

java复制public class PassByValueDemo {

    public static void main(String[] args) {
        int a = 10;
        int b = 20;
        swap(a, b);
        System.out.println("a = " + a); // 10
        System.out.println("b = " + b); // 20
    }

    public static void swap(int x, int y) {
        int temp = x;
        x = y;
        y = temp;
    }
}

运行结果就是 a = 10、b = 20，交换完全没有生效。原因就是你在swap方法里交换的是x和y，这两个是复制出来的新变量，和main方法里的a、b除了初始值一样之外，没有任何关系。方法执行完，栈帧销毁，x和y的修改随风而去。

这个实验基本都懂，不需要多说。它只能证明“基本类型是值传递”，还不足以证明“引用类型也是值传递”。

3.2 实验二：两个对象交换，同样不生效

再把swap改成对象版本。

java复制public class PassByValueDemo2 {

    public static void main(String[] args) {
        Person p1 = new Person("张三");
        Person p2 = new Person("李四");
        swap(p1, p2);
        System.out.println("p1.name = " + p1.name); // 张三
        System.out.println("p2.name = " + p2.name); // 李四
    }

    public static void swap(Person x, Person y) {
        Person temp = x;
        x = y;
        y = temp;
    }
}

class Person {
    String name;

    Person(String name) {
        this.name = name;
    }
}

运行结果仍然是张三、李四，交换没有生效。这是推翻“引用传递”说法的最有力实验。如果Java真的支持引用传递，swap里交换了x和y的指向，p1和p2就应当指向对方。但实际上，swap方法里拿到的是p1和p2两个引用的副本，对副本重新赋值，只是改变了局部变量表里两个槽位的指向，根本碰不到p1和p2。

这个实验你应该亲手跑一遍，并且以后面试时能当场写出来。它能证明：即使参数是引用类型，方法也没能力改变实参变量本身的指向。这就是值传递的直接证据。

3.3 实验三：通过形参修改对象内容，却能生效

这个实验经常被用来支持“引用传递”的错误结论。

java复制public class PassByValueDemo3 {

    public static void main(String[] args) {
        Person person = new Person("张三");
        changeName(person);
        System.out.println("person.name = " + person.name); // 王五
    }

    public static void changeName(Person p) {
        p.name = "王五";
    }
}

运行结果是王五，看起来“对象在方法里被改了，外面也变了”，于是很多人得出结论：这不就是引用传递吗？

这里必须停下来仔细看。changeName方法能修改person.name，不是因为形参和实参是同一个变量，而是因为两个变量里的地址值相同，它们指向同一个堆对象。你拿着这个对象的门牌号（地址），当然可以进去改里面的东西。但你不能说这个门牌号本身是“引用传递”，因为门牌号是复制过来的。

关键区别在于：如果Java是引用传递，你在方法里给形参p重新赋一个新对象（p = new Person(...)），外面的person也应该指向新对象。但实验二已经证明它不会。所以实验三的“生效”，本质上和“我复制了一把钥匙，然后用复制出来的钥匙打开了房间，把桌子换成椅子，你口袋里那把钥匙再插进去时看到的也是新桌子”是一个道理。这是对象共享带来的效应，不是参数传递机制带来的效应。

3.4 实验四：一个方法里同时出现“改内容”和“改指向”

我在团队带人时，最常用来考察理解程度的例子，是下面这个组合版。

java复制public class PassByValueDemo4 {

    public static void main(String[] args) {
        Person person = new Person("张三");
        change(person);
        System.out.println("person.name = " + person.name); // 王五
    }

    public static void change(Person p) {
        p.name = "王五";      // 修改对象内容，生效
        p = new Person("赵六"); // 让形参指向新对象，不生效
    }
}

最终结果person.name还是王五。如果你彻底理解值传递的语义，看到这个结果不会觉得意外：第一行改的是地址指向的那个对象，当然生效；第二行改的是形参变量自己的指向，和外部无关。但如果脑子里装的是“对象是引用传递”这个简单结论，你就无法解释为什么第二行没生效。

这也是为什么我一直强调：不要只背结论，要把“变量里存的是什么”“复制的是什么”想清楚。

3.5 实验五：String和Integer的迷惑行为

String是一个特殊陷阱，因为它是不可变对象。

java复制public class PassByValueDemo5 {

    public static void main(String[] args) {
        String s = "hello";
        change(s);
        System.out.println(s); // hello
    }

    public static void change(String str) {
        str = "world";
    }
}

结果还是hello，看起来像是“String传了值”。但更准确的理解是：String是不可变对象，你根本没有办法通过形参去修改原来那个字符串对象的内容，所以在change里能做的只有让形参指向一个新字符串对象。这个动作当然不影响实参。

如果你换成StringBuilder，结果就完全不同。

java复制public class PassByValueDemo6 {

    public static void main(String[] args) {
        StringBuilder sb = new StringBuilder("hello");
        appendWorld(sb);
        System.out.println(sb.toString()); // hello world
    }

    public static void appendWorld(StringBuilder builder) {
        builder.append(" world");
    }
}

这里builder和外面的sb指向同一个对象，append修改了对象内容，所以外部看到的是“hello world”。如果把appendWorld里改成 builder = new StringBuilder("bye");，外部sb仍然是“hello”，因为重新赋值只影响形参的指向。

Integer也存在类似的迷惑性。Integer是不可变对象，并且JVM对-128到127之间的整数有缓存。当你写 Integer i = 100;，i存的是缓存池里那个Integer对象的地址；当你给i重新赋值为200，其实是在让i指向另一个Integer对象。所以方法内对Integer形参重新赋值，外面也不会变。网上有人用Integer做实验得出各种奇怪结论，根因都在这里。

4. “引用传递”的错觉是怎么来的：三个根源

4.1 C++概念的历史包袱

我身边很多转Java的同学都写过C++，C++里确实存在“引用传递”，形参和实参是同一个变量的别名，函数里修改形参等于修改实参。他们在学Java时，很自然地把“对象变量是引用类型”理解成了“对象是引用传递”。

C++里写 void swap(int& a, int& b)，你在函数里交换a和b，外面确实会变。Java里没有类似 & 的语法，没有任何办法声明一个“参数别名”。语言设计上就不支持，所以你没法在Java里写出真正意义上的引用传递。这个历史包袱是很多人第一次接触Java参数传递时踩坑的根源。

4.2 “引用”这个词在Java语境下有多重含义

“引用传递”里的“引用”，和Java里的“引用类型”，是两个层面的概念，但名字撞车了。

Java里说“这个变量是个引用”，通常意思是：这个引用类型变量存储了对象的地址。这是语言层面的数据类型术语。参数传递里的“引用传递”，指的是传参的语义机制。你用同一句话“对象传的是引用”，在不同人耳朵里可能被解读成完全不同的意思。

很多中文教材为了让学生快速上手，直接给出“基本类型值传递，引用类型引用传递”的口诀。这个口诀在教学上降低了理解成本，但也埋下了隐患。因为学习者如果不去深究“这里的引用到底是指引用地址，还是指引用传递机制”，就会把它当成标准答案。

4.3 把“对象内容被修改”误当成“引用传递”

这是最核心的认知误区。很多人判断是不是引用传递，只看“方法内改了对象，外面变没变”。外面变了，就觉得是引用传递。

这个判断标准是错的。引用传递的定义是：方法能否改变实参变量本身的绑定关系，也就是能否让实参变量指向另一个对象。在实验三里，实参person和形参p共享同一个堆对象，所以你能改对象内容，但这不等于你能改变person变量的指向。真正的引用传递，连“让形参指向新对象”这种操作也会传导到实参上。而Java做不到，实验二已经证明了这一点。

所以每当有人问我“对象到底是不是引用传递”，我都会反问一句：那你写一个swap，能把两个对象交换过来吗？只要他写不出来，这个问题的答案其实已经自己浮现了。

5. 面试怎么答才算完整：从结论到追问一整套

5.1 主回答：直接给结论，然后用例子锚定

面试官问“Java参数传递是值传递还是引用传递”，不要绕弯子，第一句就给结论：

Java的参数传递是值传递，无论是基本类型还是引用类型。基本类型传递的是具体数值的副本，引用类型传递的是引用地址的副本。引用地址本身也是一个值，所以本质上都是值传递。

说完结论，马上补一个代码级例子。最好是在白板上写出实验二的swap对象版本，然后指着x和y的赋值说：这里交换的只是形参副本的指向，所以实参不会变。这比任何长篇大论都有说服力。

5.2 被追问“那对象为什么能改”：用共享对象解释

面试官大概率会追问：那为什么方法里修改对象属性，外面能看到？

这时候你回答：因为形参和实参持有的引用地址副本指向同一个堆对象。通过地址访问对象，修改对象内部状态，自然会被看到。但这不改变参数传递的性质，因为如果我在方法里给形参重新赋值一个新对象，外面的实参变量仍然指向原来的对象，证明我没有办法改变实参的绑定关系。

这段话是面试中的分水岭。能说清楚“改对象内容”和“改实参指向”的区别，说明你是真的理解，而不是背了结论。

5.3 加分的进阶点：String、Integer和不可变对象

如果时间允许，可以主动补充一层，展示你对不可变对象的理解。

比如主动提一句String：String是引用类型，但因为不可变，所以方法内对String形参重新赋值，不会影响外部；而StringBuilder可变，通过形参调用append修改对象内容，外部可以看到变化。这说明底层机制没有变化，只是对象可变性不同，导致外在表现不同。

这个话题也可以自然过渡到“为什么不能只用现象判断传递机制”。能够主动把String和StringBuilder拉到对比里，面试官会对你另眼相看。

5.4 一个容易被问倒的变体：数组参数

数组也是对象，所以数组作为参数的时候，同样是值传递。面试官如果拿数组考你，你只要记住一件事：arr[0] = 99 这种操作修改的是数组对象内部的数据，外部看得到；arr = new int[]{1,2,3} 这种重新赋值，外部看不到。

这段逻辑和对象完全一致。能把数组这套说清楚，说明你不是只会背对象的例子，而是掌握了底层通用规律。

6. 落实到日常开发：参数传递陷阱怎么避免

6.1 方法签名设计：别把参数当“输出通道”

很多初学者在写业务代码时，会天然地把参数当作可以带回结果的通道。比如写了一个方法，希望它内部给传入的User对象list补充数据，然后调用方直接使用这个list，省得写返回值。

这种写法在Java里其实是反模式。因为Java只有值传递，你无法通过参数真正地带回一个“新对象”。如果方法内部只是往传入的集合里add元素，那没问题，因为集合对象是共享的；但只要你在某个分支里对参数执行了重新赋值，外面拿到的就是老对象，逻辑就开始出错了。

我见过一个真实案例：同事写了一个方法，接收List参数，如果入参为null，就在方法内部 list = new ArrayList<>()，然后往里面添加数据，返回void。调用方传进去一个null，方法结束后检查list，仍然是null，百思不得其解。这就是典型的“把参数当成输出通道”。正确做法是：要么返回新集合，要么在方法外部先初始化一个空集合再传入。

6.2 集合入参的防御性处理

集合是最容易产生参数副作用的地方。方法内部对传入的List做clear、remove、add，都会直接作用到调用方持有的那个集合对象上。在单一方法里这可能不是大问题，但如果你写的是公共方法、工具方法、或者对外提供的SDK接口，这种副作用就成了隐患。

比如一个工具方法，入参是一个List，方法里会做一些过滤处理，如果它直接原地remove掉不符合条件的元素，调用方数据的完整性就被破坏了。更稳妥的做法是先copy一份再处理，或者返回一个新的不可变集合，让调用方决定是否使用。

JDK其实已经给了不少工具，比如 List.copyOf、Collections.unmodifiableList，用它们限制可变性，能把很多因参数共享导致的意外修改在编译期或运行初期就暴露出来。当然，不可变集合也有代价，比如不能修改、不能传null，需要结合具体场景权衡。

6.3 团队协作中如何约定“方法是否修改参数”

在团队协作里，光靠个人自觉不够，代码审查时要对“方法是否修改入参”这件事形成共识。推荐的做法是约定：方法默认不修改传入对象的状态，除非方法名或注释里明确表明该操作是“修改型”的。

比如命名上可以用 updateXxx、fillXxx、appendXxx 来明示会修改入参；纯读方法则尽量用 getXxx、calculateXxx、buildXxx。给入参加上 final 关键字也是一种约束手段。虽然 final 只能防止形参被重新赋值，不能防止通过形参修改对象内容，但它至少能让代码的读者知道“这个参数在本方法内没有被重新绑定”。

更深一层的做法是引入不可变对象模式。比如领域模型里的值对象，全部用 record、final 字段，不提供setter。这样参数传入方法后，就算有人想改也无从下手，必须返回新对象。用这种方式，值传递和不可变对象结合，能极大降低代码里的隐蔽耦合。

6.4 调试时如何确认两个变量是否指向同一个对象

在实际调试中，判断形参和实参是否指向同一个对象，有个简单方法：打印 System.identityHashCode(obj)。即使你没重写hashCode，identityHashCode也能反映对象在JVM中的身份标识。方法内外打印同一个对象的identityHashCode，如果一致，说明两个变量指向同一个堆对象；一旦某个变量被重新赋值，它的identityHashCode就会变化。

在IDEA里调试时，变量面板上会直接显示对象的内部id（类似 {Person@508}），也可以直接观察。这个方法在排查“为什么方法内改了对象，外面却变了/没变”的问题时非常好用，远比肉眼猜可靠。

6.5 我踩过一次最深的坑：异步线程里的对象共享

最后分享一个我实际项目中踩过的坑，它和值传递、对象共享直接相关。

当时有个定时任务，把一个User对象放进线程池跑异步逻辑，线程里调用了 user.setStatus(...)。我原本以为异步线程拿到的是User的“快照”，不会影响主线程里的user。但因为是值传递，异步线程拿到的引用地址和主线程一样，setStatus直接修改了同一个堆对象，主线程后面的判断全部受影响，查了半天才定位到。

这个案例提醒我：值传递搞清楚的不仅是面试题，更是并发编程里对象共享的底层逻辑。你复制的是引用，复制出来的引用还是指向同一个对象。如果你希望隔离对象，必须主动做深拷贝或者使用不可变对象。把pass-by-value理解透彻，很多并发场景下“莫名其妙被修改”的问题，其实都能在第一时间想到原因。

所以最后再总结一句我反复在团队里说的大白话：Java里方法参数传出去的永远是“打不开原包装袋的复印件”，你拿着复印件能做的，要么是在复印件上涂改，要么是照着复印件里的地址去动真实的东西。搞清楚这个区别，值传递这道题，以及它背后的一系列开发陷阱，就都通了。