面试考察点
- 能否准确区分对象、引用和引用变量的副本。
- 是否能解释修改对象与重新赋值的不同结果。
- 是否避免使用含糊的“引用传递”表述。
核心答案
Java 只有值传递。基本类型参数复制具体值；引用类型参数复制的是引用值，调用方和被调用方的两个引用副本可以指向同一对象，但方法内给参数重新赋值不会改变调用方变量。
因此方法可以通过引用副本修改同一可变对象的字段，却不能用 obj = new Object() 替换调用方持有的引用。
示例分析
void change(User user) {
user.setName("new"); // 调用方可观察到对象状态变化
user = new User(); // 只改变局部引用副本
}
两个现象并不矛盾：变化的是共享对象状态，未变化的是调用方变量中保存的引用值。
四类情况放在一起看
| 传入内容 | 方法内操作 | 调用方能否观察到 |
|---|---|---|
基本类型 int |
给参数重新赋值 | 不能 |
| 对象引用 | 修改同一可变对象字段 | 能 |
| 对象引用 | 给参数指向新对象 | 不能 |
| 数组引用 | 修改数组元素 | 能 |
数组也是对象，所以数组参数复制的仍是引用值。集合、StringBuilder、自定义实体都遵循同一规则，不存在“集合特殊传引用”。
为什么 swap 交换不了引用
static void swap(User left, User right) {
User temp = left;
left = right;
right = temp;
}
User a = new User("A");
User b = new User("B");
swap(a, b);
进入方法后可以理解为创建了 left = a 中的引用值、right = b 中的引用值 两个局部副本。swap 只交换局部变量，调用结束后 a 和 b 完全没变。若真要交换，应该返回包含两个结果的对象，或让调用方显式重新赋值。
可变对象带来的副作用
void normalize(List<String> names) {
names.replaceAll(String::trim);
names.removeIf(String::isEmpty);
}
这个方法会修改调用方共享的列表。语法没有问题，但 API 名称和契约必须明确；更安全的版本可以创建新列表并返回。尤其在缓存、并发和领域对象中，隐式修改会让状态来源难以追踪。
不可变对象能降低这种心智负担。方法接收值对象，计算后返回新值，调用方不会担心传入参数被悄悄改变；代价是可能产生额外对象，需要按场景衡量。
与其他语言术语的区别
引用传递意味着函数参数是调用方变量本身的别名，被调用方能让调用方变量指向另一个对象。Java 没有这种普通参数机制。C++ 的引用参数、某些语言的 ref/out 更接近真正引用传递，不能把它们的术语直接套到 Java。
实践边界
可变参数可能造成隐式副作用。公共 API 可以优先接收不可变值对象，或明确说明方法是否修改传入集合；需要返回新对象时直接以返回值表达。
常见误区
“对象作为参数就是引用传递”不准确。真正的引用传递允许被调用方替换调用方变量所引用的对象，而 Java 做不到这一点。
高频追问与参考回答
追问：为什么 String 传入方法后看起来改不了？
仍然是引用值的复制，只是 String 不可变；拼接或重新赋值会产生并指向新对象，不会修改原对象和调用方引用。
追问：Integer 参数能在方法里自增并影响调用方吗？
不能。value++ 会先拆箱计算，再装箱并让局部参数指向新 Integer；包装对象本身不可变，调用方变量没有被替换。
追问：AtomicInteger 为什么可以被方法修改？
方法拿到引用值的副本，但副本指向同一个可变 AtomicInteger，调用其更新方法改变共享对象状态。它仍然不是引用传递。
追问：如何让方法返回多个修改结果？
定义记录类或结果对象，例如 record SwapResult(User left, User right)，通过返回值显式传递。这比依赖可变数组作为“输出参数”更清晰。
总结
只需抓住一句话：参数变量总是复制值，对象参数复制的值恰好是一个引用。
机制全景图
下面把「Java 到底是值传递还是引用传递？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["计算实参表达式"]
A --> B["复制值到形参槽位"]
B --> C["方法内部操作副本"]
C --> D["可能修改共享对象"]
D --> E["返回后形参消失"]
完整链路：从输入到结果
沿着「计算实参表达式 → 复制值到形参槽位 → 方法内部操作副本 → 可能修改共享对象 → 返回后形参消失」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 计算实参表达式
调用前先计算实参；基本类型得到数值，对象表达式得到的是指向对象的引用值。
2. 复制值到形参槽位
Java 总是把这个值复制给形参，因此基本数值和引用值本身都不会被方法反向替换。
3. 方法内部操作副本
给形参重新赋值只改变局部槽位，不会让调用方变量指向新对象。
4. 可能修改共享对象
通过两个引用访问同一个可变对象时，方法内部字段修改会被调用方观察到，这属于共享对象变化而非引用传递。
5. 返回后形参消失
方法结束后形参生命周期结束；要改变调用方持有的值，应返回新值、修改明确的可变容器或使用领域命令。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| JVM Spec 2.6 Frames | 局部变量表与操作数栈槽位 |
| javap astore/aload | 观察引用值复制和形参重新赋值 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
static void replace(User user) { user = new User("new"); }
static void mutate(User user) { user.rename("new"); }
在调用前后记录 System.identityHashCode 与字段值，分别验证 replace 和 mutate；并发场景再检查共享可变对象是否存在数据竞争。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「调用方引用身份」为主基线，记录值应满足「replace 前后应相同」；同时保存 对象身份标识、方法前后字段差异，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「JVM Spec 2.6 Frames」确认请求确实进入「局部变量表与操作数栈槽位」对应的实现，再沿「javap astore/aload」观察「观察引用值复制和形参重新赋值」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「把对象可变误判为引用传递」，并把单一变量逐级放大，直到「调用方引用身份」越过「意外替换来自返回值/容器」。随后再分别验证「给形参赋新对象后期待调用方改变」和「隐式修改共享集合造成并发问题」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「需要替换时显式返回新对象」，确认它能控制影响范围；第二轮应用「跨线程传递不可变 DTO」，验证核心链路恢复；最后落实「消除隐藏修改并在 API 名称表达副作用」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「调用方引用身份」回到「replace 前后应相同」、「对象字段变化」回到「仅 mutate 可见」、「共享引用线程数」回到「单所有者最佳」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| 调用方引用身份 | replace 前后应相同 | 意外替换来自返回值/容器 | 追踪赋值点 |
| 对象字段变化 | 仅 mutate 可见 | 非预期字段改变 | 检查别名共享 |
| 共享引用线程数 | 单所有者最佳 | 多线程无同步 | 改不可变或加所有权 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：交换两个对象的方法始终无效
代码试图通过 swap(User a, User b) 交换调用方变量，方法内打印正常，返回后引用却未变化。原因是交换的只是两个引用副本。若需求是调整列表顺序，应操作调用方传入的列表位置；若是替换对象，应返回包含两个新引用的结果。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 把对象可变误判为引用传递 | 对象身份标识 | 需要替换时显式返回新对象 |
| 给形参赋新对象后期待调用方改变 | 方法前后字段差异 | 跨线程传递不可变 DTO |
| 隐式修改共享集合造成并发问题 | 共享引用数量 | 消除隐藏修改并在 API 名称表达副作用 |
发布与回滚检查点
- 发布前：确认「JVM Spec 2.6 Frames」对应实现和上述配置在目标版本仍然有效，并保存「调用方引用身份」基线。
- 灰度中：同时观察 对象身份标识、方法前后字段差异、共享引用数量；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「需要替换时显式返回新对象」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「把对象可变误判为引用传递」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| 返回新值 | 不可变对象或需要明确替换 | 副作用小、数据流清晰 | 调用方必须接收返回值 |
| 修改可变对象 | 聚合内部状态有明确所有者 | 避免额外复制 | 别名共享会扩大副作用 |
| 包装器/数组持有槽位 | 框架 API 必须模拟输出参数 | 可以原地写回 | 语义绕、通常不如结果对象清晰 |
选型至少带上 对象创建率、调用频次、输入规模和 API 边界，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
“值传递”描述的是调用语义，不代表对象不可变；引用值被复制后仍可访问同一个对象，所以必须另外讨论对象所有权和可变性。
工程落地遵循：优先保证语言语义、类型契约和向后兼容，再讨论微小性能收益。回答时直接引用「JVM Spec 2.6 Frames」、配置实验和事故数据，比复述固定模板更有说服力。