写业务代码时间久了会发现一件事真正每天都在敲的既不是多线程也不是反射而是把一个对象塞进方法再让方法吐出一个对象。形参位置写类名、返回值位置写类名这看着像最基础的语法点实际却决定了代码是一年就烂掉还是能撑五年。我在几个中型项目里重构过参数列表见过最夸张的一个方法有十一个形参全是 String 和 BigDecimal调一次要数三遍位置。后来把它改成接收一个类名类型的形参对象方法签名立刻从三行缩成一行调用方也再没传错过顺序。这篇就围绕「类名作为形参和返回值」这件事把概念、内存机制、业务场景、返回值设计、接口与泛型的取舍以及踩过的坑一次讲透。不管你是刚学完面向对象、还分不清引用传递和值传递的新手还是已经写了一段时间业务代码、想让方法签名更干净的开发者下面这些内容都能直接拿去用。1. 概念的边界类名出现在形参和返回值位置意味着什么1.1 形参写类名方法拿到的是对象的遥控器很多教材把这件事讲成传对象进去这句话本身没错但它掩盖了关键细节。形参位置写Order方法内部拿到的并不是 Order 对象本体而是一份指向该对象的引用值的拷贝。对象本体躺在堆上栈上的形参变量只存了个遥控器。方法拿着这个遥控器可以按下对象身上的按钮也就是调用它的 setter、修改它的字段但对遥控器本身重新赋值比如让形参指向一个新对象外面那个变量完全不知道。这个区别决定了两种截然不同的写法。下面这段代码外部对象会被改掉public void applyDiscount(Order order, BigDecimal rate) { BigDecimal real order.getAmount().multiply(rate); order.setAmount(order.getAmount().subtract(real)); }而下面这段代码外部对象纹丝不动只是方法内部换了个遥控器public void replaceWithNew(Order order) { order new Order(); order.setAmount(BigDecimal.ZERO); }第二段代码在真实项目里几乎没有意义但它恰好是理解形参机制的最好反例。很多人第一次遇到方法里改了对象外面没变或者方法里没改外面却变了的困惑根源都在这里形参是引用的拷贝拷贝后两个遥控器指向同一台电视但换遥控器不影响对方。1.2 返回值写类名方法交出的是一张取货凭证返回值位置写类名方法结束时交出来的同样是一份引用值。这份引用可能指向三种东西方法内部 new 出来的新对象、方法从别处拿到的已有对象、或者 null。只有第一种是全新的货第二种是把仓库里已有的货指给你第三种是凭证是空的。这三种情况在语义上差别巨大但方法签名长得一模一样编译器不会提醒你。我见过一个查询方法返回了缓存的内部集合调用方顺手往里 add 了一条数据结果所有读到这份缓存的地方都多出一条脏数据排查了两个下午。问题不在于语法而在于返回值写类名时方法作者没有说清楚交出去的是不是同一个对象。所以写返回值时我心里会过三个问题这个对象是新建的还是共享的调用方能不能改它返回 null 是不是合法的业务状态这三个问题答不上来方法签名写对了也是隐患。1.3 为什么不让一堆基本类型和数组硬扛有人会说形参写类名和直接写几个 String、int 有什么区别反正都是传值。区别在于三件事语义、校验、演化。先说语义。transfer(String from, String to, BigDecimal amount)这行签名三个 String 谁是谁全靠位置和命名。写成transfer(TransferRequest request)字段名本身就是文档调用方写request.setFromAccount(...)不可能传错。IDE 的提示、编译期的类型检查、重构时的重命名全部站在你这边。再说校验。一堆散参数的方法校验代码只能堆在方法开头重复且容易漏。把参数收进一个类校验逻辑可以收进这个类自己的构造方法或静态工厂里所有调用方自动受益这叫把约束集中在一处。最后说演化。散参数的方法每加一个参数所有调用点全要改改动量和调用点数量成正比。参数对象加一个字段只要给默认值调用点可以不动。这条在长期维护的项目里价值极高我自己负责的一个模块参数对象从四个字段长到十一个字段调用点一次都没改过。数组也能装多个值但Object[]丢掉了全部类型信息取出来还得强转等于把编译期检查推迟到了运行期得不偿失。2. 底层机制值传递、引用拷贝和对象生命周期2.1 一次方法调用在内存里发生了什么Java 只有值传递这句话是对的但容易让人误解成传对象就是传对象本身。准确的说法是基本类型传的是数值本身引用类型传的是引用值本身而引用值指向堆上的对象。方法调用发生时JVM 在栈上压入一个新的栈帧形参作为局部变量存在这个栈帧的局部变量表里赋值动作就是把实参的值复制进去。实参类型复制进形参的内容方法内修改形参变量方法内修改对象状态int、long 等基本类型数值副本外部不受影响不适用引用类型类名引用值副本外部不受影响外部可见数组引用值副本外部不受影响数组元素修改外部可见不可变对象如 String引用值副本外部不受影响无法修改只能换引用这张表建议直接记住。我面试过不少人能背Java 是值传递但一追问那为什么改对象外面能看到就开始含糊。区别就在表格第三列和第四列改的是形参变量还是形参指向的对象。2.2 引用拷贝和对象拷贝的分界线形参传递永远只发生引用拷贝绝不发生对象拷贝。这意味着传一个含十个字段的对象进方法开销和传一个 int 差不多都是一个引用宽度。这点性能上的好处经常被忽视有人担心传大对象慢于是把对象拆成几个字段传反而增加了调用开销和代码复杂度。真正需要对象拷贝的场景是另一回事你希望方法拿到的是一份独立副本改了不影响外面。这叫防御性拷贝是主动行为不是传参自动发生的。public void audit(Order order) { Order copy order.deepCopy(); copy.setAmount(BigDecimal.ZERO); // 只改副本 // ... }注意这里必须是深拷贝。浅拷贝只复制一层引用副本里的集合字段还和原对象指向同一个 List改集合内容照样穿透。我在一个导出功能里踩过这个坑为了不影响原数据做了浅拷贝结果导出的报表里商品明细被清空了原对象也跟着空了。后来改成对集合字段逐个重新构造问题才消失。2.3 返回值逃逸之后对象归谁管方法返回一个引用对象就从方法内部逃逸到了调用方手里。Java 没有所有权标注逃逸之后谁都能改靠的是约定和设计。这里有三条实用原则。第一能返回不可变对象就别返回可变对象。String、BigDecimal、LocalDate这些类型天生安全调用方拿它没办法也就不会误伤别人。自己写的类想做到这点字段全 final、不提供 setter、集合字段在构造时做不可变包装。第二返回内部集合时做包装。类里有个ListItem items直接return items等于把内部结构的钥匙交出去。正确做法是return Collections.unmodifiableList(items)或者返回一个新 List。前者省内存但会抛异常后者安全但多一次复制按调用频率选。第三明确 null 的语义。返回 null 本身不违法违法的是调用方不知道会返回 null。要么用Optional把可能没有写进签名要么在文档里写死要么干脆返回一个空对象。我现在的习惯是集合类返回值一律返回空集合而不是 null单个对象返回值在方法名上体现find和get的区别find 可能没有get 必须有。3. 场景一类名作形参把散参数收成业务上下文3.1 一个结算方法的演化过程早些年我接手过一个结算方法签名是这样的public BigDecimal calculate(String userLevel, BigDecimal amount, String couponCode, boolean firstOrder, int channel, String regionCode) { // 两百多行 }六个参数三种基本类型混着三个 String调用方每次都得翻到定义处确认顺序。更麻烦的是新需求要加会员日活动标识这个参数只在特定渠道生效加进去之后方法变成七个参数十七个调用点全要改。后来改成接收一个上下文对象public class SettleContext { private final String userLevel; private final BigDecimal amount; private final String couponCode; private final boolean firstOrder; private final int channel; private final String regionCode; // 构造方法、getter 省略 } public BigDecimal calculate(SettleContext ctx) { // 方法体不变取值改成 ctx.getXxx() }调用方从数位置变成设字段可读性提升是立刻能感知的。更关键的是后面再加会员日标识时只需要在 SettleContext 里加一个字段并给默认值十七个调用点一个都没动。这就是参数对象的演化优势。3.2 形参对象该由谁构造、谁校验这里有个容易吵起来的问题参数对象里的字段校验放在构造方还是接收方我的实践是分两层。格式校验放在参数对象自己的构造方法里比如金额不能为负、渠道编码不能为空构造时就抛异常问题暴露在离错误最近的地方。业务校验放在接收方比如这个用户等级不支持该优惠券因为它依赖方法内部的上下文参数对象自己不知道。public SettleContext(BigDecimal amount, int channel) { if (amount null || amount.signum() 0) { throw new IllegalArgumentException(金额不能为空或负数); } this.amount amount; this.channel channel; }这样写的好处是任何拿到 SettleContext 实例的方法都可以假定基础字段是合法的不用在每个方法开头重复判空。我在一个项目里推行这个做法之后方法开头的防御性判空代码减少了大概三成Review 时也少了很多这里是不是漏判了的讨论。3.3 形参设计的三条硬经验第一条形参对象要聚焦别做万能袋。我见过一个叫CommonParam的类七十多个字段付款用它、退款用它、报表也用它最后没人敢删任何一个字段因为不知道谁在用。参数对象一旦超过十五个字段就该考虑按场景拆成几个。名字里带 Common、Base、General 的类往往就是这种味道的开始。第二条明确方法会不会修改入参。如果方法只读就别碰 setter如果确实要改在方法名里体现比如normalize(Order order)、fillDefault(SettleContext ctx)。调用方看到方法名就知道自己的对象可能被改心里有数。最怕的是方法名叫check里面顺手把对象改了一半。第三条不要把形参对象当成输出通道。有些代码喜欢传入一个对象方法内部往里面填结果靠副作用返回数据。这种写法调试时极其难受因为你不知道哪个字段是被哪个方法填的。返回结果就用返回值别走形参。4. 场景二类名作返回值把结果说得明明白白4.1 从返回 null 到返回一个明确的结果对象查询类方法最容易写成查到了返回对象查不到返回 null。调用方每次都得判空判漏一个就是线上空指针。我现在的做法是凡是可能没有结果的场景返回值都换成一个结果包装对象把状态和原因一起带回来。public class QueryResultT { private final boolean found; private final T data; private final String reason; public static T QueryResultT hit(T data) { return new QueryResult(true, data, null); } public static T QueryResultT miss(String reason) { return new QueryResult(false, null, reason); } public boolean isFound() { return found; } public T getData() { return data; } public String getReason() { return reason; } }这个方法返回的就是一个类名类型的对象调用方拿到之后先看isFound()再看getData()逻辑清清楚楚。相比返回 null多写了一个类但省掉了无数个判空分支而且为什么没查到这个信息能一路传到前端。顺带说一句Optional也能表达可能没有但Optional装不下失败原因只能表达空与非空。业务里需要区分不存在无权限已删除这几种情况时自定义结果对象更合适。4.2 静态工厂方法与返回值类名的组合返回类名时不一定非得让调用方 new。静态工厂方法能给出更有语义的返回值也能顺手做缓存和校验。public class Money { private final BigDecimal value; private final String currency; private Money(BigDecimal value, String currency) { this.value value; this.currency currency; } public static Money of(BigDecimal value, String currency) { if (value null) { throw new IllegalArgumentException(金额不能为空); } return new Money(value.setScale(2, RoundingMode.HALF_UP), currency); } public static Money zero(String currency) { return new Money(BigDecimal.ZERO, currency); } }调用方写Money.of(amount, CNY)比new Money(...)多了两件事一是构造方法私有化之后外部无法绕过校验创建非法对象二是方法名可以承载语义zero、of、valueOf一眼能看出用途。这个套路在 JDK 里到处都是LocalDate.of、BigDecimal.valueOf、List.of都是同一个思路。返回值写类名的时候我倾向于把构造方法收起来只留静态工厂。这样类的不变量由自己维护外部改不坏。4.3 链式调用与 Builder返回值还是那个类名链式 setter 的写法很多人都用过原理就是每个方法返回this返回类型写的就是类名本身。public class OrderBuilder { private final Order order new Order(); public OrderBuilder orderNo(String no) { order.setOrderNo(no); return this; } public OrderBuilder amount(BigDecimal amount) { order.setAmount(amount); return this; } public Order build() { return order; } }orderNo的返回值类型是OrderBuilderbuild的返回值类型是Order。前者的返回值让调用可以一路点下去后者的返回值把最终成果交出去。这套组合在字段多、可选参数多的场景里特别舒服调用方只设自己关心的字段没设的走默认值。不过要注意链式 setter 和 Builder 都会让对象在构造过程中处于半成品状态多线程下不能共享。我的习惯是 Builder 只在单线程的组装阶段用组装完立刻 build 出不可变对象后面谁都不能再改。5. 进阶取舍形参和返回值写接口、抽象类还是具体类5.1 形参写接口可测试性从哪来形参写具体类方法就只能接受这一个类形参写接口任何实现了该接口的对象都能传进来。这不只是灵活性问题直接决定了代码能不能方便地测试。public interface SmsSender { void send(String phone, String content); } public class RegisterService { private final SmsSender sender; public RegisterService(SmsSender sender) { this.sender sender; } public void register(User user) { // ... sender.send(user.getPhone(), 注册成功); } }RegisterService的构造方法形参写的是接口SmsSender测试时传一个只记录调用的假实现就行不用真的发短信。如果形参写死成某个具体实现类测试就得连带那个类的所有依赖一起搭起来。这条经验我是在一个老项目里被迫学会的。当时有个服务类的构造方法形参是具体实现为了写一个单元测试得先起消息队列、连数据库、配配置中心一个测试跑二十秒。后来把形参改成接口测试时间降到几十毫秒。5.2 返回值写接口把实现藏起来返回值写接口是另一个方向的取舍。方法内部用ArrayList装数据返回值类型写List而不是ArrayList调用方就只能用 List 的方法你以后想换成LinkedList或者不可变实现调用方一行都不用改。public ListItem listItems(Long orderId) { ListItem result new ArrayList(); // ... return result; }如果返回值写成ArrayListItem调用方可能顺手用了ensureCapacity你就被钉死在这个实现上了。返回值类型越抽象未来改动空间越大这条在公共工具类里尤其重要因为改一次影响一大片。反过来如果方法内部确实依赖某个具体实现的特性比如需要TreeMap的有序性返回值就写SortedMap把关键特性表达出来而不是写成Map让调用方去猜。5.3 泛型方法里的类名别被尖括号吓住泛型方法把类名这件事推到了参数化层面常见形态是返回值类型由形参决定。public T T pickOne(ListT candidates) { if (candidates null || candidates.isEmpty()) { return null; } return candidates.get(0); }调用pickOne(orderList)返回值自动推断成Order调用pickOne(userList)返回值是User。方法体里没写任何一个具体类名但返回值类型跟着形参走这就是泛型在形参和返回值上的配合。还有一种更常见的形态是ClassT作形参public T T parse(String json, ClassT type) { // 根据 type 反序列化 return null; }这里形参是ClassT返回值是T两者通过同一个类型变量绑定调用方传Order.class就拿到Order不用强转。理解这一点再看各种框架里的泛型 API 就不会发怵了尖括号只是把类名从写死变成了可传入的参数。6. 常见问题与排查技巧实录6.1 高频问题速查表下面这张表是我这几年在 Code Review 和线上排查里反复遇到的几乎覆盖了形参和返回值相关的绝大多数坑。现象常见原因排查方向处理方式方法内改了对象调用方数据被污染形参是引用拷贝指向同一对象检查方法是否调用了入参的 setter 或修改其集合只读场景做防御性拷贝或约定不可变方法内给形参重新赋值外部没变换的是引用副本不是对象本体确认是否误以为能带出新对象需要带出就用返回值别走形参返回值改了别处数据跟着变返回的是内部共享对象检查是否直接 return 了成员变量返回不可变包装或副本调用返回结果时报空指针方法可能返回 null 但未标注看方法实现里所有 return 分支返回空对象、Optional 或结果包装类链式调用中途报空指针某个链式方法返回了 null逐个检查链式方法的 return链式方法统一返回 this泛型方法调用后类型不对类型推断失败或用了原始类型检查实参是否带了明确类型显式指定类型参数或改用ClassT参数对象字段越来越多万能参数袋场景混用统计字段的实际使用方按场景拆分参数对象表格里的每一条我都至少踩过一次其中返回值改了别处跟着变这条代价最大直接导致过一次数据错乱从那以后我养成了返回集合前先想一遍这是不是内部结构的习惯。6.2 几个高频坑的具体实录坑一形参对象被悄悄修改。有个对账方法形参是ReconcileContext方法内部为了让金额单位统一顺手把 ctx 里的金额乘了一百。调用方后面还要用原始金额生成报表结果报表金额全错。这类问题的隐蔽之处在于方法名看起来像只读的实际有副作用。后来我们定了个规矩方法名以 check、validate、calc 开头的一律不许改入参需要改就返回新对象。坑二返回内部集合导致数据串台。前面提过的缓存例子根因是return this.items。修复方式有两种看调用频率选读多写少的场景返回Collections.unmodifiableList(items)调用方改了会立刻抛异常问题暴露得早调用方确实需要改的场景返回new ArrayList(items)各改各的互不影响。坑三链式调用里混进 null。有人写链式方法某个分支return null表示不需要继续结果调用方一路点下去直接空指针。链式调用的前提是每个环节都返回对象本身中途返回 null 就破坏了契约。要么全程返回 this要么明确告诉调用方这不是链式方法。坑四用形参对象当返回值容器。老代码里有void query(QueryParam param, ResultHolder holder)这种写法结果塞进 holder 带出来。调试时完全看不出数据从哪来只能一层层往上翻。新代码我一律要求用返回值实在要带多个结果就定义一个结果类字段命名清楚。坑五重载方法形参类型相近导致误调。有send(Order order)和send(OrderVO vo)两个重载OrderVO 继承自 Order调用时传子类对象实际走的是哪个方法得看编译期类型。这种重载要尽量避免宁可改方法名。6.3 调试这类问题的几个实用手法第一看对象身份。怀疑两个变量是不是指向同一个对象直接打印System.identityHashCode(obj)值相同就是同一个对象。equals相等不代表同一个对象这点在排查共享问题时特别关键。第二断点看引用。IDE 的调试器里对象变量展开后能看到对象的 id两个变量 id 一样就是同一个。这个方法比打印日志快尤其在多层调用里。第三给可变对象加只读视图。排查阶段临时把返回集合包成不可变谁改谁抛异常异常栈直接指到肇事代码。这个手法我用过好几次比一行行读代码快得多。第四写最小复现。形参和返回值的问题往往藏在调用链里与其在大项目里猜不如把相关几个类抽出来写个十几行的小 Demo跑一遍就清楚了。我现在的习惯是遇到改了没生效或者没改却变了这类反直觉现象先写 Demo十分钟内基本能定位。7. 我在实际项目里沉淀下来的几条习惯写到最后分享几条不用记语法、但确实能少踩坑的习惯。第一方法签名先想清楚进和出。写方法之前先问自己进来的东西是一个整体还是几个散值出去的东西是确定有还是可能没有这两个问题答完形参和返回值的类型基本就定了。最怕的是上来就写public Object doSomething(Object input)这种签名写出来后面怎么改都是补丁。第二参数超过四个就考虑收成对象。四个是个经验阈值不是硬标准。超过之后调用方的可读性下降速度很快而且以后每加一个参数都要动所有调用点。收成对象之后字段校验、默认值、演化都变得容易。第三返回值尽量不返回 null。集合返回空集合单个对象返回 Optional 或结果包装类实在要返回 null 就在方法名和注释里写清楚。这条坚持下来调用方的判空代码会少很多线上空指针也会少很多。第四形参对象优先设计成不可变。字段 final、不提供 setter、集合字段构造时包装。不可变对象传进方法方法作者不用纠结我改了会不会影响别人调用方也不用担心我的对象会不会被改双方都省心。需要改的时候返回一个新对象而不是原地修改。第五接口在前实现在后。形参和返回值能写接口就写接口把具体实现留在方法内部。这一条在团队协作里价值最大因为接口是契约实现可以换换实现的时候调用方无感。第六别用形参传结果。这条我重复过好几次因为它太常见了。返回值就是用来返回结果的形参就是用来传输入的两者混用代码的可读性和可调试性都会打折。真需要返回多个值定义一个结果类字段命名清楚比塞进形参强得多。这套东西没有什么高深技巧都是被线上问题逼出来的。类名作为形参和返回值语法层面十分钟就能讲完但要在项目里用得不别扭靠的是对引用语义的清楚认识加上一点对这个方法会不会改我的对象的敏感。养成这个敏感之后很多问题在写代码的时候就被挡掉了根本轮不到测试和线上。
写业务代码时间久了会发现一件事真正每天都在敲的既不是多线程也不是反射而是把一个对象塞进方法再让方法吐出一个对象。形参位置写类名、返回值位置写类名这看着像最基础的语法点实际却决定了代码是一年就烂掉还是能撑五年。我在几个中型项目里重构过参数列表见过最夸张的一个方法有十一个形参全是 String 和 BigDecimal调一次要数三遍位置。后来把它改成接收一个类名类型的形参对象方法签名立刻从三行缩成一行调用方也再没传错过顺序。这篇就围绕「类名作为形参和返回值」这件事把概念、内存机制、业务场景、返回值设计、接口与泛型的取舍以及踩过的坑一次讲透。不管你是刚学完面向对象、还分不清引用传递和值传递的新手还是已经写了一段时间业务代码、想让方法签名更干净的开发者下面这些内容都能直接拿去用。1. 概念的边界类名出现在形参和返回值位置意味着什么1.1 形参写类名方法拿到的是对象的遥控器很多教材把这件事讲成传对象进去这句话本身没错但它掩盖了关键细节。形参位置写Order方法内部拿到的并不是 Order 对象本体而是一份指向该对象的引用值的拷贝。对象本体躺在堆上栈上的形参变量只存了个遥控器。方法拿着这个遥控器可以按下对象身上的按钮也就是调用它的 setter、修改它的字段但对遥控器本身重新赋值比如让形参指向一个新对象外面那个变量完全不知道。这个区别决定了两种截然不同的写法。下面这段代码外部对象会被改掉public void applyDiscount(Order order, BigDecimal rate) { BigDecimal real order.getAmount().multiply(rate); order.setAmount(order.getAmount().subtract(real)); }而下面这段代码外部对象纹丝不动只是方法内部换了个遥控器public void replaceWithNew(Order order) { order new Order(); order.setAmount(BigDecimal.ZERO); }第二段代码在真实项目里几乎没有意义但它恰好是理解形参机制的最好反例。很多人第一次遇到方法里改了对象外面没变或者方法里没改外面却变了的困惑根源都在这里形参是引用的拷贝拷贝后两个遥控器指向同一台电视但换遥控器不影响对方。1.2 返回值写类名方法交出的是一张取货凭证返回值位置写类名方法结束时交出来的同样是一份引用值。这份引用可能指向三种东西方法内部 new 出来的新对象、方法从别处拿到的已有对象、或者 null。只有第一种是全新的货第二种是把仓库里已有的货指给你第三种是凭证是空的。这三种情况在语义上差别巨大但方法签名长得一模一样编译器不会提醒你。我见过一个查询方法返回了缓存的内部集合调用方顺手往里 add 了一条数据结果所有读到这份缓存的地方都多出一条脏数据排查了两个下午。问题不在于语法而在于返回值写类名时方法作者没有说清楚交出去的是不是同一个对象。所以写返回值时我心里会过三个问题这个对象是新建的还是共享的调用方能不能改它返回 null 是不是合法的业务状态这三个问题答不上来方法签名写对了也是隐患。1.3 为什么不让一堆基本类型和数组硬扛有人会说形参写类名和直接写几个 String、int 有什么区别反正都是传值。区别在于三件事语义、校验、演化。先说语义。transfer(String from, String to, BigDecimal amount)这行签名三个 String 谁是谁全靠位置和命名。写成transfer(TransferRequest request)字段名本身就是文档调用方写request.setFromAccount(...)不可能传错。IDE 的提示、编译期的类型检查、重构时的重命名全部站在你这边。再说校验。一堆散参数的方法校验代码只能堆在方法开头重复且容易漏。把参数收进一个类校验逻辑可以收进这个类自己的构造方法或静态工厂里所有调用方自动受益这叫把约束集中在一处。最后说演化。散参数的方法每加一个参数所有调用点全要改改动量和调用点数量成正比。参数对象加一个字段只要给默认值调用点可以不动。这条在长期维护的项目里价值极高我自己负责的一个模块参数对象从四个字段长到十一个字段调用点一次都没改过。数组也能装多个值但Object[]丢掉了全部类型信息取出来还得强转等于把编译期检查推迟到了运行期得不偿失。2. 底层机制值传递、引用拷贝和对象生命周期2.1 一次方法调用在内存里发生了什么Java 只有值传递这句话是对的但容易让人误解成传对象就是传对象本身。准确的说法是基本类型传的是数值本身引用类型传的是引用值本身而引用值指向堆上的对象。方法调用发生时JVM 在栈上压入一个新的栈帧形参作为局部变量存在这个栈帧的局部变量表里赋值动作就是把实参的值复制进去。实参类型复制进形参的内容方法内修改形参变量方法内修改对象状态int、long 等基本类型数值副本外部不受影响不适用引用类型类名引用值副本外部不受影响外部可见数组引用值副本外部不受影响数组元素修改外部可见不可变对象如 String引用值副本外部不受影响无法修改只能换引用这张表建议直接记住。我面试过不少人能背Java 是值传递但一追问那为什么改对象外面能看到就开始含糊。区别就在表格第三列和第四列改的是形参变量还是形参指向的对象。2.2 引用拷贝和对象拷贝的分界线形参传递永远只发生引用拷贝绝不发生对象拷贝。这意味着传一个含十个字段的对象进方法开销和传一个 int 差不多都是一个引用宽度。这点性能上的好处经常被忽视有人担心传大对象慢于是把对象拆成几个字段传反而增加了调用开销和代码复杂度。真正需要对象拷贝的场景是另一回事你希望方法拿到的是一份独立副本改了不影响外面。这叫防御性拷贝是主动行为不是传参自动发生的。public void audit(Order order) { Order copy order.deepCopy(); copy.setAmount(BigDecimal.ZERO); // 只改副本 // ... }注意这里必须是深拷贝。浅拷贝只复制一层引用副本里的集合字段还和原对象指向同一个 List改集合内容照样穿透。我在一个导出功能里踩过这个坑为了不影响原数据做了浅拷贝结果导出的报表里商品明细被清空了原对象也跟着空了。后来改成对集合字段逐个重新构造问题才消失。2.3 返回值逃逸之后对象归谁管方法返回一个引用对象就从方法内部逃逸到了调用方手里。Java 没有所有权标注逃逸之后谁都能改靠的是约定和设计。这里有三条实用原则。第一能返回不可变对象就别返回可变对象。String、BigDecimal、LocalDate这些类型天生安全调用方拿它没办法也就不会误伤别人。自己写的类想做到这点字段全 final、不提供 setter、集合字段在构造时做不可变包装。第二返回内部集合时做包装。类里有个ListItem items直接return items等于把内部结构的钥匙交出去。正确做法是return Collections.unmodifiableList(items)或者返回一个新 List。前者省内存但会抛异常后者安全但多一次复制按调用频率选。第三明确 null 的语义。返回 null 本身不违法违法的是调用方不知道会返回 null。要么用Optional把可能没有写进签名要么在文档里写死要么干脆返回一个空对象。我现在的习惯是集合类返回值一律返回空集合而不是 null单个对象返回值在方法名上体现find和get的区别find 可能没有get 必须有。3. 场景一类名作形参把散参数收成业务上下文3.1 一个结算方法的演化过程早些年我接手过一个结算方法签名是这样的public BigDecimal calculate(String userLevel, BigDecimal amount, String couponCode, boolean firstOrder, int channel, String regionCode) { // 两百多行 }六个参数三种基本类型混着三个 String调用方每次都得翻到定义处确认顺序。更麻烦的是新需求要加会员日活动标识这个参数只在特定渠道生效加进去之后方法变成七个参数十七个调用点全要改。后来改成接收一个上下文对象public class SettleContext { private final String userLevel; private final BigDecimal amount; private final String couponCode; private final boolean firstOrder; private final int channel; private final String regionCode; // 构造方法、getter 省略 } public BigDecimal calculate(SettleContext ctx) { // 方法体不变取值改成 ctx.getXxx() }调用方从数位置变成设字段可读性提升是立刻能感知的。更关键的是后面再加会员日标识时只需要在 SettleContext 里加一个字段并给默认值十七个调用点一个都没动。这就是参数对象的演化优势。3.2 形参对象该由谁构造、谁校验这里有个容易吵起来的问题参数对象里的字段校验放在构造方还是接收方我的实践是分两层。格式校验放在参数对象自己的构造方法里比如金额不能为负、渠道编码不能为空构造时就抛异常问题暴露在离错误最近的地方。业务校验放在接收方比如这个用户等级不支持该优惠券因为它依赖方法内部的上下文参数对象自己不知道。public SettleContext(BigDecimal amount, int channel) { if (amount null || amount.signum() 0) { throw new IllegalArgumentException(金额不能为空或负数); } this.amount amount; this.channel channel; }这样写的好处是任何拿到 SettleContext 实例的方法都可以假定基础字段是合法的不用在每个方法开头重复判空。我在一个项目里推行这个做法之后方法开头的防御性判空代码减少了大概三成Review 时也少了很多这里是不是漏判了的讨论。3.3 形参设计的三条硬经验第一条形参对象要聚焦别做万能袋。我见过一个叫CommonParam的类七十多个字段付款用它、退款用它、报表也用它最后没人敢删任何一个字段因为不知道谁在用。参数对象一旦超过十五个字段就该考虑按场景拆成几个。名字里带 Common、Base、General 的类往往就是这种味道的开始。第二条明确方法会不会修改入参。如果方法只读就别碰 setter如果确实要改在方法名里体现比如normalize(Order order)、fillDefault(SettleContext ctx)。调用方看到方法名就知道自己的对象可能被改心里有数。最怕的是方法名叫check里面顺手把对象改了一半。第三条不要把形参对象当成输出通道。有些代码喜欢传入一个对象方法内部往里面填结果靠副作用返回数据。这种写法调试时极其难受因为你不知道哪个字段是被哪个方法填的。返回结果就用返回值别走形参。4. 场景二类名作返回值把结果说得明明白白4.1 从返回 null 到返回一个明确的结果对象查询类方法最容易写成查到了返回对象查不到返回 null。调用方每次都得判空判漏一个就是线上空指针。我现在的做法是凡是可能没有结果的场景返回值都换成一个结果包装对象把状态和原因一起带回来。public class QueryResultT { private final boolean found; private final T data; private final String reason; public static T QueryResultT hit(T data) { return new QueryResult(true, data, null); } public static T QueryResultT miss(String reason) { return new QueryResult(false, null, reason); } public boolean isFound() { return found; } public T getData() { return data; } public String getReason() { return reason; } }这个方法返回的就是一个类名类型的对象调用方拿到之后先看isFound()再看getData()逻辑清清楚楚。相比返回 null多写了一个类但省掉了无数个判空分支而且为什么没查到这个信息能一路传到前端。顺带说一句Optional也能表达可能没有但Optional装不下失败原因只能表达空与非空。业务里需要区分不存在无权限已删除这几种情况时自定义结果对象更合适。4.2 静态工厂方法与返回值类名的组合返回类名时不一定非得让调用方 new。静态工厂方法能给出更有语义的返回值也能顺手做缓存和校验。public class Money { private final BigDecimal value; private final String currency; private Money(BigDecimal value, String currency) { this.value value; this.currency currency; } public static Money of(BigDecimal value, String currency) { if (value null) { throw new IllegalArgumentException(金额不能为空); } return new Money(value.setScale(2, RoundingMode.HALF_UP), currency); } public static Money zero(String currency) { return new Money(BigDecimal.ZERO, currency); } }调用方写Money.of(amount, CNY)比new Money(...)多了两件事一是构造方法私有化之后外部无法绕过校验创建非法对象二是方法名可以承载语义zero、of、valueOf一眼能看出用途。这个套路在 JDK 里到处都是LocalDate.of、BigDecimal.valueOf、List.of都是同一个思路。返回值写类名的时候我倾向于把构造方法收起来只留静态工厂。这样类的不变量由自己维护外部改不坏。4.3 链式调用与 Builder返回值还是那个类名链式 setter 的写法很多人都用过原理就是每个方法返回this返回类型写的就是类名本身。public class OrderBuilder { private final Order order new Order(); public OrderBuilder orderNo(String no) { order.setOrderNo(no); return this; } public OrderBuilder amount(BigDecimal amount) { order.setAmount(amount); return this; } public Order build() { return order; } }orderNo的返回值类型是OrderBuilderbuild的返回值类型是Order。前者的返回值让调用可以一路点下去后者的返回值把最终成果交出去。这套组合在字段多、可选参数多的场景里特别舒服调用方只设自己关心的字段没设的走默认值。不过要注意链式 setter 和 Builder 都会让对象在构造过程中处于半成品状态多线程下不能共享。我的习惯是 Builder 只在单线程的组装阶段用组装完立刻 build 出不可变对象后面谁都不能再改。5. 进阶取舍形参和返回值写接口、抽象类还是具体类5.1 形参写接口可测试性从哪来形参写具体类方法就只能接受这一个类形参写接口任何实现了该接口的对象都能传进来。这不只是灵活性问题直接决定了代码能不能方便地测试。public interface SmsSender { void send(String phone, String content); } public class RegisterService { private final SmsSender sender; public RegisterService(SmsSender sender) { this.sender sender; } public void register(User user) { // ... sender.send(user.getPhone(), 注册成功); } }RegisterService的构造方法形参写的是接口SmsSender测试时传一个只记录调用的假实现就行不用真的发短信。如果形参写死成某个具体实现类测试就得连带那个类的所有依赖一起搭起来。这条经验我是在一个老项目里被迫学会的。当时有个服务类的构造方法形参是具体实现为了写一个单元测试得先起消息队列、连数据库、配配置中心一个测试跑二十秒。后来把形参改成接口测试时间降到几十毫秒。5.2 返回值写接口把实现藏起来返回值写接口是另一个方向的取舍。方法内部用ArrayList装数据返回值类型写List而不是ArrayList调用方就只能用 List 的方法你以后想换成LinkedList或者不可变实现调用方一行都不用改。public ListItem listItems(Long orderId) { ListItem result new ArrayList(); // ... return result; }如果返回值写成ArrayListItem调用方可能顺手用了ensureCapacity你就被钉死在这个实现上了。返回值类型越抽象未来改动空间越大这条在公共工具类里尤其重要因为改一次影响一大片。反过来如果方法内部确实依赖某个具体实现的特性比如需要TreeMap的有序性返回值就写SortedMap把关键特性表达出来而不是写成Map让调用方去猜。5.3 泛型方法里的类名别被尖括号吓住泛型方法把类名这件事推到了参数化层面常见形态是返回值类型由形参决定。public T T pickOne(ListT candidates) { if (candidates null || candidates.isEmpty()) { return null; } return candidates.get(0); }调用pickOne(orderList)返回值自动推断成Order调用pickOne(userList)返回值是User。方法体里没写任何一个具体类名但返回值类型跟着形参走这就是泛型在形参和返回值上的配合。还有一种更常见的形态是ClassT作形参public T T parse(String json, ClassT type) { // 根据 type 反序列化 return null; }这里形参是ClassT返回值是T两者通过同一个类型变量绑定调用方传Order.class就拿到Order不用强转。理解这一点再看各种框架里的泛型 API 就不会发怵了尖括号只是把类名从写死变成了可传入的参数。6. 常见问题与排查技巧实录6.1 高频问题速查表下面这张表是我这几年在 Code Review 和线上排查里反复遇到的几乎覆盖了形参和返回值相关的绝大多数坑。现象常见原因排查方向处理方式方法内改了对象调用方数据被污染形参是引用拷贝指向同一对象检查方法是否调用了入参的 setter 或修改其集合只读场景做防御性拷贝或约定不可变方法内给形参重新赋值外部没变换的是引用副本不是对象本体确认是否误以为能带出新对象需要带出就用返回值别走形参返回值改了别处数据跟着变返回的是内部共享对象检查是否直接 return 了成员变量返回不可变包装或副本调用返回结果时报空指针方法可能返回 null 但未标注看方法实现里所有 return 分支返回空对象、Optional 或结果包装类链式调用中途报空指针某个链式方法返回了 null逐个检查链式方法的 return链式方法统一返回 this泛型方法调用后类型不对类型推断失败或用了原始类型检查实参是否带了明确类型显式指定类型参数或改用ClassT参数对象字段越来越多万能参数袋场景混用统计字段的实际使用方按场景拆分参数对象表格里的每一条我都至少踩过一次其中返回值改了别处跟着变这条代价最大直接导致过一次数据错乱从那以后我养成了返回集合前先想一遍这是不是内部结构的习惯。6.2 几个高频坑的具体实录坑一形参对象被悄悄修改。有个对账方法形参是ReconcileContext方法内部为了让金额单位统一顺手把 ctx 里的金额乘了一百。调用方后面还要用原始金额生成报表结果报表金额全错。这类问题的隐蔽之处在于方法名看起来像只读的实际有副作用。后来我们定了个规矩方法名以 check、validate、calc 开头的一律不许改入参需要改就返回新对象。坑二返回内部集合导致数据串台。前面提过的缓存例子根因是return this.items。修复方式有两种看调用频率选读多写少的场景返回Collections.unmodifiableList(items)调用方改了会立刻抛异常问题暴露得早调用方确实需要改的场景返回new ArrayList(items)各改各的互不影响。坑三链式调用里混进 null。有人写链式方法某个分支return null表示不需要继续结果调用方一路点下去直接空指针。链式调用的前提是每个环节都返回对象本身中途返回 null 就破坏了契约。要么全程返回 this要么明确告诉调用方这不是链式方法。坑四用形参对象当返回值容器。老代码里有void query(QueryParam param, ResultHolder holder)这种写法结果塞进 holder 带出来。调试时完全看不出数据从哪来只能一层层往上翻。新代码我一律要求用返回值实在要带多个结果就定义一个结果类字段命名清楚。坑五重载方法形参类型相近导致误调。有send(Order order)和send(OrderVO vo)两个重载OrderVO 继承自 Order调用时传子类对象实际走的是哪个方法得看编译期类型。这种重载要尽量避免宁可改方法名。6.3 调试这类问题的几个实用手法第一看对象身份。怀疑两个变量是不是指向同一个对象直接打印System.identityHashCode(obj)值相同就是同一个对象。equals相等不代表同一个对象这点在排查共享问题时特别关键。第二断点看引用。IDE 的调试器里对象变量展开后能看到对象的 id两个变量 id 一样就是同一个。这个方法比打印日志快尤其在多层调用里。第三给可变对象加只读视图。排查阶段临时把返回集合包成不可变谁改谁抛异常异常栈直接指到肇事代码。这个手法我用过好几次比一行行读代码快得多。第四写最小复现。形参和返回值的问题往往藏在调用链里与其在大项目里猜不如把相关几个类抽出来写个十几行的小 Demo跑一遍就清楚了。我现在的习惯是遇到改了没生效或者没改却变了这类反直觉现象先写 Demo十分钟内基本能定位。7. 我在实际项目里沉淀下来的几条习惯写到最后分享几条不用记语法、但确实能少踩坑的习惯。第一方法签名先想清楚进和出。写方法之前先问自己进来的东西是一个整体还是几个散值出去的东西是确定有还是可能没有这两个问题答完形参和返回值的类型基本就定了。最怕的是上来就写public Object doSomething(Object input)这种签名写出来后面怎么改都是补丁。第二参数超过四个就考虑收成对象。四个是个经验阈值不是硬标准。超过之后调用方的可读性下降速度很快而且以后每加一个参数都要动所有调用点。收成对象之后字段校验、默认值、演化都变得容易。第三返回值尽量不返回 null。集合返回空集合单个对象返回 Optional 或结果包装类实在要返回 null 就在方法名和注释里写清楚。这条坚持下来调用方的判空代码会少很多线上空指针也会少很多。第四形参对象优先设计成不可变。字段 final、不提供 setter、集合字段构造时包装。不可变对象传进方法方法作者不用纠结我改了会不会影响别人调用方也不用担心我的对象会不会被改双方都省心。需要改的时候返回一个新对象而不是原地修改。第五接口在前实现在后。形参和返回值能写接口就写接口把具体实现留在方法内部。这一条在团队协作里价值最大因为接口是契约实现可以换换实现的时候调用方无感。第六别用形参传结果。这条我重复过好几次因为它太常见了。返回值就是用来返回结果的形参就是用来传输入的两者混用代码的可读性和可调试性都会打折。真需要返回多个值定义一个结果类字段命名清楚比塞进形参强得多。这套东西没有什么高深技巧都是被线上问题逼出来的。类名作为形参和返回值语法层面十分钟就能讲完但要在项目里用得不别扭靠的是对引用语义的清楚认识加上一点对这个方法会不会改我的对象的敏感。养成这个敏感之后很多问题在写代码的时候就被挡掉了根本轮不到测试和线上。
