Java有陷阱，用时需谨慎-慎用入参做返回值

在Java中，慎用入参作为返回值，否则可能导致代码逻辑错误且难以维护，核心问题在于Java是值传递而非引用传递，对入参重新赋值不会影响原始对象。

问题背景

以下是一段存在问题的代码示例：

服务A代码：

@Namedpublic class AService { private SupplyAssignment localSupply = new SupplyAssignment(); @Inject private BService bervice; public List<Supply> calcSupplyAssignment() { List<Supply> supplyList = bService.getLocalSupplyList(this.localSupply); … return supplyList; }}

服务A调用服务B获取supplyList，同时希望修改localSupply的状态值，但为避免修改calcSupplyAssignment接口的返回类型，将localSupply作为入参并尝试用作返回值。

服务B代码：

@Namedpublic class BService { public List<Supply> getLocalSupplyList (SupplyAssignment localSupply) { SupplyAssignment supplyAssignment = this.getSupplyAssignment(); // 希望localSupply被重新赋值后返回 localSupply = supplyAssignment; … return supplyList; }}

服务B内部对入参localSupply重新赋值为supplyAssignment，期望返回新值，但实际无效。

问题原因

Java的参数传递机制：
值传递：调用函数时复制实际参数的值传递到函数中，函数内修改参数不影响实际参数。
引用传递：调用函数时传递实际参数的地址，函数内修改参数会影响实际参数。
Java采用值传递：没有指针概念，方法得到的是参数值的拷贝，无法直接修改传递给它的任何参数变量的内容。
具体分析：
服务A调用服务B时，服务B的参数localSupply是服务A的localSupply的拷贝，二者初始指向同一对象supplyAssignment1。
服务B内部对参数localSupply重新赋值为supplyAssignment后，服务B的参数localSupply指向新对象supplyAssignment2。
服务A的localSupply和服务B的参数localSupply指向不同对象，对服务B的参数localSupply的修改不会影响服务A的localSupply的原值。

解决方案

方案1：入参不要用作返回值
避免将入参直接作为返回值使用，重新设计方法逻辑，明确返回值与入参的关系，提高代码的可读性和可维护性。
方案2：入参不要赋值新对象，直接修改其状态
直接在入参的对象上修改状态，而不赋值新对象。例如，使用Spring的工具类BeanUtils的copyProperties方法，将一个对象的属性值复制到另一个对象的属性上。
修改后的服务B代码：

@Namedpublic class BService { public List<Supply> getLocalSupplyList (SupplyAssignment localSupply) { SupplyAssignment supplyAssignment = this.getSupplyAssignment(); // 针对localSupply不能新建引用，只能重新赋值属性 BeanUtils.copyProperties(supplyAssignment, localSupply); … return supplyList; }}

原理：通过BeanUtils.copyProperties(supplyAssignment, localSupply)将supplyAssignment的属性值赋值到localSupply的属性上，修改的是服务B的参数localSupply的属性，而非新建对象，因此服务A的localSupply的状态会相应改变。

您可能感兴趣问答

Collapsible

热门标签

热点问答