Java陷阱之慎用入?yún)⒆龇祷刂翟斀?/h1>
更新時間:2020年12月03日 12:11:19 作者:waylau
這篇文章主要給大家介紹了關于Java陷阱之慎用入?yún)⒆龇祷刂档南嚓P資料,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
正常情況下,在Java中入?yún)⑹遣唤ㄗh用做返回值的。除了造成代碼不易理解、語義不清等問題外,可能還埋下了陷阱等你入坑。
問題背景
比如有這么一段代碼:
@Named
public 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希望調(diào)用服務B,以獲取supplyList,但同時,服務A又希望修改localSupply的狀態(tài)值,未能避免修改calcSupplyAssignment接口的(不想改返回的類型),將localSupply作為了入?yún)⒌瑫r也用作了返回值。
服務B代碼如下:
@Named
public class BService {
public List<Supply> getLocalSupplyList (SupplyAssignment localSupply)
SupplyAssignment supplyAssignment = this.getSupplyAssignment();
// 希望localSupply被重新賦值后返回
localSupply = supplyAssignment;
…
return supplyList;
}
}
在服務B代碼內(nèi)部,服務A的入?yún)ocalSupply被傳入,希望重新被supplyAssignment賦值而后返回新值。然而,這樣做是無效的。
問題原因
先來看下編程語言中關于參數(shù)傳遞的類型:
- 值傳遞(pass by value)是指在調(diào)用函數(shù)時將實際參數(shù)復制一份傳遞到函數(shù)中,這樣在函數(shù)中如果對參數(shù)進行修改,將不會影響到實際參數(shù)。
- 引用傳遞(pass by reference)是指在調(diào)用函數(shù)時將實際參數(shù)的地址直接傳遞到函數(shù)中,那么在函數(shù)中對參數(shù)所進行的修改,將影響到實際參數(shù)。
因為Java程序設計語言是采用的值傳遞,因為Java沒有指針的概念。也就是說方法得到的是所有參數(shù)值的一個拷貝,方法并不能修改傳遞給它的任何參數(shù)變量的內(nèi)容。
因此,上述代碼中,服務A調(diào)用服務B時,服務B的參數(shù)localSupply實際上是服務A的localSupply的一個拷貝,當然,這兩個都是指向了同一個地址對象supplyAssignment1。

當在服務B內(nèi)部對參數(shù)localSupply進行重新賦值是localSupply = supplyAssignment,實際上,只是對B的參數(shù)localSupply做了從新賦值,B的參數(shù)localSupply會指向一個新的地址對象supplyAssignment2。

從上圖可以清晰看到,因此,服務A的localSupply和B的參數(shù)localSupply已經(jīng)指向了不同的對象了,對B的參數(shù)localSupply做任何的修改,都不會影響服務A的localSupply的原值。這就是問題的原因,你希望服務B來修改服務A入?yún)⒌臓顟B(tài),并將改后的值返回給服務A,但并不奏效。
解決方案
方案1:入?yún)⒉灰米鞣祷刂?br />
當然,這個是最清晰的且易于理解的,但這會導致有的接口的返回類型產(chǎn)生變化。
有時確實想要入?yún)⒆龇祷刂?,那看方?。
方案2:入?yún)⒉灰x值新對象
這個方案就是直接在入?yún)⒌膶ο笊献鰻顟B(tài)的修改,而不要去賦值新對象。還是這個圖:

在這個圖中,只要我們是一直在B的參數(shù)localSupply修改的是supplyAssignment1的狀態(tài)值,那結(jié)果就能反饋到服務A的localSupply上。如何實現(xiàn)?看下下面代碼:
@Named
public class BService {
public List<Supply> getLocalSupplyList (SupplyAssignment localSupply)
SupplyAssignment supplyAssignment = this.getSupplyAssignment();
// 針對localSupply不能新建引用,只能重新賦值屬性
BeanUtils.copyProperties(supplyAssignment, localSupply);
…
return supplyList;
}
}
在上面的方法中,我們用到了Spring的工具類BeanUtils,該類的copyProperties方法的實質(zhì)是將supplyAssignment的屬性值,賦值到了localSupply的屬性上。這意味著我們是修改的B的參數(shù)localSupply上的屬性,而并未新建對象。
參考引用
到此這篇關于Java陷阱之慎用入?yún)⒆龇祷刂档奈恼戮徒榻B到這了,更多相關Java慎用入?yún)⒆龇祷刂祪?nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
-
AsyncHttpClient exception異常源碼流程解析
這篇文章主要為大家介紹了AsyncHttpClient的exception源碼流程解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪 2023-12-12
-
springboot中redis的緩存穿透問題實現(xiàn)
這篇文章主要介紹了springboot中redis的緩存穿透問題實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧 2021-02-02
最新評論
正常情況下,在Java中入?yún)⑹遣唤ㄗh用做返回值的。除了造成代碼不易理解、語義不清等問題外,可能還埋下了陷阱等你入坑。
問題背景
比如有這么一段代碼:
@Named public 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希望調(diào)用服務B,以獲取supplyList,但同時,服務A又希望修改localSupply的狀態(tài)值,未能避免修改calcSupplyAssignment接口的(不想改返回的類型),將localSupply作為了入?yún)⒌瑫r也用作了返回值。
服務B代碼如下:
@Named public class BService { public List<Supply> getLocalSupplyList (SupplyAssignment localSupply) SupplyAssignment supplyAssignment = this.getSupplyAssignment(); // 希望localSupply被重新賦值后返回 localSupply = supplyAssignment; … return supplyList; } }
在服務B代碼內(nèi)部,服務A的入?yún)ocalSupply被傳入,希望重新被supplyAssignment賦值而后返回新值。然而,這樣做是無效的。
問題原因
先來看下編程語言中關于參數(shù)傳遞的類型:
- 值傳遞(pass by value)是指在調(diào)用函數(shù)時將實際參數(shù)復制一份傳遞到函數(shù)中,這樣在函數(shù)中如果對參數(shù)進行修改,將不會影響到實際參數(shù)。
- 引用傳遞(pass by reference)是指在調(diào)用函數(shù)時將實際參數(shù)的地址直接傳遞到函數(shù)中,那么在函數(shù)中對參數(shù)所進行的修改,將影響到實際參數(shù)。
因為Java程序設計語言是采用的值傳遞,因為Java沒有指針的概念。也就是說方法得到的是所有參數(shù)值的一個拷貝,方法并不能修改傳遞給它的任何參數(shù)變量的內(nèi)容。
因此,上述代碼中,服務A調(diào)用服務B時,服務B的參數(shù)localSupply實際上是服務A的localSupply的一個拷貝,當然,這兩個都是指向了同一個地址對象supplyAssignment1。
當在服務B內(nèi)部對參數(shù)localSupply進行重新賦值是localSupply = supplyAssignment,實際上,只是對B的參數(shù)localSupply做了從新賦值,B的參數(shù)localSupply會指向一個新的地址對象supplyAssignment2。
從上圖可以清晰看到,因此,服務A的localSupply和B的參數(shù)localSupply已經(jīng)指向了不同的對象了,對B的參數(shù)localSupply做任何的修改,都不會影響服務A的localSupply的原值。這就是問題的原因,你希望服務B來修改服務A入?yún)⒌臓顟B(tài),并將改后的值返回給服務A,但并不奏效。
解決方案
方案1:入?yún)⒉灰米鞣祷刂?br />
當然,這個是最清晰的且易于理解的,但這會導致有的接口的返回類型產(chǎn)生變化。
有時確實想要入?yún)⒆龇祷刂?,那看方?。
方案2:入?yún)⒉灰x值新對象
這個方案就是直接在入?yún)⒌膶ο笊献鰻顟B(tài)的修改,而不要去賦值新對象。還是這個圖:
在這個圖中,只要我們是一直在B的參數(shù)localSupply修改的是supplyAssignment1的狀態(tài)值,那結(jié)果就能反饋到服務A的localSupply上。如何實現(xiàn)?看下下面代碼:
@Named public class BService { public List<Supply> getLocalSupplyList (SupplyAssignment localSupply) SupplyAssignment supplyAssignment = this.getSupplyAssignment(); // 針對localSupply不能新建引用,只能重新賦值屬性 BeanUtils.copyProperties(supplyAssignment, localSupply); … return supplyList; } }
在上面的方法中,我們用到了Spring的工具類BeanUtils,該類的copyProperties方法的實質(zhì)是將supplyAssignment的屬性值,賦值到了localSupply的屬性上。這意味著我們是修改的B的參數(shù)localSupply上的屬性,而并未新建對象。
參考引用
到此這篇關于Java陷阱之慎用入?yún)⒆龇祷刂档奈恼戮徒榻B到這了,更多相關Java慎用入?yún)⒆龇祷刂祪?nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
AsyncHttpClient exception異常源碼流程解析
這篇文章主要為大家介紹了AsyncHttpClient的exception源碼流程解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-12-12springboot中redis的緩存穿透問題實現(xiàn)
這篇文章主要介紹了springboot中redis的緩存穿透問題實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2021-02-02