[[413038]]

本文的內(nèi)容是最近我剛剛遇到的一個(gè)問題，問題代碼是我自己寫的，也是我自己寫單元測試的時(shí)候發(fā)現(xiàn)的，也是我自己修復(fù)的，修復(fù)完之后，我反思了一下：這樣的問題代碼，我實(shí)習(xí)的時(shí)候都寫不出來。

可是為什么我就寫出來了呢?其實(shí)還是因?yàn)橛行┲R沒那么扎實(shí)了~就容易被忽略了，于是我在團(tuán)隊(duì)群里面強(qiáng)調(diào)了一下這個(gè)問題：

所以，本文主要是關(guān)于BeanUtils工具的屬性拷貝以及深拷貝、淺拷貝等問題的。好了開始正文，介紹下問題代碼是什么，為什么有問題，又符合修改?

在日常開發(fā)中，我們經(jīng)常需要給對象進(jìn)行賦值，通常會調(diào)用其set/get方法，有些時(shí)候，如果我們要轉(zhuǎn)換的兩個(gè)對象之間屬性大致相同，會考慮使用屬性拷貝工具進(jìn)行。

如我們經(jīng)常在代碼中會對一個(gè)數(shù)據(jù)結(jié)構(gòu)封裝成DO、SDO、DTO、VO等，而這些Bean中的大部分屬性都是一樣的，所以使用屬性拷貝類工具可以幫助我們節(jié)省大量的set和get操作。

市面上有很多類似的工具類，比較常用的有

1、Spring BeanUtils

2、Cglib BeanCopier

3、Apache BeanUtils

4、Apache PropertyUtils

5、Dozer

6、MapStucts

這里面我比較建議大家使用的是MapStructs，我在《丟棄掉那些BeanUtils工具類吧，MapStruct真香!!!》中介紹過原因。這里就不再贅述了。

最近我們有個(gè)新項(xiàng)目，要?jiǎng)?chuàng)建一個(gè)新的應(yīng)用，因?yàn)槲易约悍治鲞^這些工具的效率，也去看過他們的實(shí)現(xiàn)原理，比較下來之后，我覺得MapStruct是最適合我們的，于是就在代碼中引入了這個(gè)框架。

另外，因?yàn)镾pring的BeanUtils用起來也比較方便，所以，代碼中對于需要beanCopy的地方主要在使用這兩個(gè)框架。

我們一般是這樣的，如果是DO和DTO/Entity之間的轉(zhuǎn)換，我們統(tǒng)一使用MapStruct，因?yàn)樗梢灾付▎为?dú)的Mapper，可以自定義一些策略。

如果是同對象之間的拷貝(如用一個(gè)DO創(chuàng)建一個(gè)新的DO)，或者完全不相關(guān)的兩個(gè)對象轉(zhuǎn)換，則使用Spring的BeanUtils。

剛開始都沒什么問題，但是后面我在寫單測的時(shí)候，發(fā)現(xiàn)了一個(gè)問題。

問題

先來看看我們是在什么地方用的Spring的BeanUtils

我們的業(yè)務(wù)邏輯中，需要對訂單信息進(jìn)行修改，在更改時(shí)，不僅要更新訂單的上面的屬性信息，還需要?jiǎng)?chuàng)建一條變更流水。

而變更流水中同時(shí)記錄了變更前和變更后的數(shù)據(jù)，所以就有了以下代碼：

//從數(shù)據(jù)庫中查詢出當(dāng)前訂單，并加鎖 
 
OrderDetail orderDetail = orderDetailDao.queryForLock(); 
 
 
//copy一個(gè)新的訂單模型 
 
OrderDetail newOrderDetail = new OrderDetail(); 
 
BeanUtils.copyProperties(orderDetail, newOrderDetail); 
 
 
//對新的訂單模型進(jìn)行修改邏輯操作 
 
newOrderDetail.update(); 
 
 
//使用修改前的訂單模型和修改后的訂單模型組裝出訂單變更流水 
 
OrderDetailStream orderDetailStream = new OrderDetailStream(); 
 
orderDetailStream.create(orderDetail, newOrderDetail); 

大致邏輯是這樣的，因?yàn)閯?chuàng)建訂單變更流水的時(shí)候，需要一個(gè)改變前的訂單和改變后的訂單。所以我們想到了要new一個(gè)新的訂單模型，然后操作新的訂單模型，避免對舊的有影響。

但是，就是這個(gè)BeanUtils.copyProperties的過程其實(shí)是有問題的。

因?yàn)锽eanUtils在進(jìn)行屬性copy的時(shí)候，本質(zhì)上是淺拷貝，而不是深拷貝。

淺拷貝?深拷貝?

什么是淺拷貝和深拷貝?來看下概念。

1、淺拷貝：對基本數(shù)據(jù)類型進(jìn)行值傳遞，對引用數(shù)據(jù)類型進(jìn)行引用傳遞般的拷貝，此為淺拷貝。

2、深拷貝：對基本數(shù)據(jù)類型進(jìn)行值傳遞，對引用數(shù)據(jù)類型，創(chuàng)建一個(gè)新的對象，并復(fù)制其內(nèi)容，此為深拷貝。

我們舉個(gè)實(shí)際例子，來看下為啥我說BeanUtils.copyProperties的過程是淺拷貝。

先來定義兩個(gè)類：

public class Address { 
 
    private String province; 
 
    private String city; 
 
    private String area; 
 
    //省略構(gòu)造函數(shù)和setter/getter 
 
} 
 
 
class User { 
 
    private String name; 
 
    private String password; 
 
    private Address address; 
 
    //省略構(gòu)造函數(shù)和setter/getter 
 
} 

然后寫一段測試代碼：

User user = new User("Hollis", "hollischuang"); 
 
user.setAddress(new Address("zhejiang", "hangzhou", "binjiang")); 
 
 
User newUser = new User(); 
 
BeanUtils.copyProperties(user, newUser); 
 
System.out.println(user.getAddress() == newUser.getAddress()); 

以上代碼輸出結(jié)果為：true

即，我們BeanUtils.copyProperties拷貝出來的newUser中的address對象和原來的user中的address對象是同一個(gè)對象。

可以嘗試著修改下newUser中的address對象：

newUser.getAddress().setCity("shanghai"); 
 
 System.out.println(JSON.toJSONString(user)); 
 
 System.out.println(JSON.toJSONString(newUser)); 

輸出結(jié)果：

{"address":{"area":"binjiang","city":"shanghai","province":"zhejiang"},"name":"Hollis","password":"hollischuang"} 
 
{"address":{"area":"binjiang","city":"shanghai","province":"zhejiang"},"name":"Hollis","password":"hollischuang"} 

可以發(fā)現(xiàn)，原來的對象也受到了修改的影響。

這就是所謂的淺拷貝!

如何進(jìn)行深拷貝

發(fā)現(xiàn)問題之后，我們就要想辦法解決，那么如何實(shí)現(xiàn)深拷貝呢?

1、實(shí)現(xiàn)Cloneable接口，重寫clone()

在Object類中定義了一個(gè)clone方法，這個(gè)方法其實(shí)在不重寫的情況下，其實(shí)也是淺拷貝的。

如果想要實(shí)現(xiàn)深拷貝，就需要重寫clone方法，而想要重寫clone方法，就必須實(shí)現(xiàn)Cloneable，否則會報(bào)CloneNotSupportedException異常。

將上述代碼修改下，重寫clone方法：

public class Address implements Cloneable{ 
 
    private String province; 
 
    private String city; 
 
    private String area; 
 
    //省略構(gòu)造函數(shù)和setter/getter 
 
 
 
    @Override 
 
    public Object clone() throws CloneNotSupportedException { 
 
        return super.clone(); 
 
    } 
 
} 
 
 
class User implements Cloneable{ 
 
    private String name; 
 
    private String password; 
 
    private Address address; 
 
    //省略構(gòu)造函數(shù)和setter/getter 
 
 
    @Override 
 
    protected Object clone() throws CloneNotSupportedException { 
 
        User user = (User)super.clone(); 
 
        user.setAddress((Address)address.clone()); 
 
        return user; 
 
    } 
 
} 

之后，在執(zhí)行一下上面的測試代碼，就可以發(fā)現(xiàn)，這時(shí)候newUser中的address對象就是一個(gè)新的對象了。

這種方式就能實(shí)現(xiàn)深拷貝，但是問題是如果我們在User中有很多個(gè)對象，那么clone方法就寫的很長，而且如果后面有修改，在User中新增屬性，這個(gè)地方也要改。

那么，有沒有什么辦法可以不需要修改，一勞永逸呢?

2、序列化實(shí)現(xiàn)深拷貝

我們可以借助序列化來實(shí)現(xiàn)深拷貝。先把對象序列化成流，再從流中反序列化成對象，這樣就一定是新的對象了。

序列化的方式有很多，比如我們可以使用各種JSON工具，把對象序列化成JSON字符串，然后再從字符串中反序列化成對象。

如使用fastjson實(shí)現(xiàn)：

User newUser = JSON.parseObject(JSON.toJSONString(user), User.class); 

也可實(shí)現(xiàn)深拷貝。

除此之外，還可以使用Apache Commons Lang中提供的SerializationUtils工具實(shí)現(xiàn)。

我們需要修改下上面的User和Address類，使他們實(shí)現(xiàn)Serializable接口，否則是無法進(jìn)行序列化的。

class User implements Serializable 
 
class Address implements Serializable 

然后在需要拷貝的時(shí)候：

User newUser = (User) SerializationUtils.clone(user); 

同樣，也可以實(shí)現(xiàn)深拷貝啦~!

總結(jié)

當(dāng)我們使用各類BeanUtils的時(shí)候，一定要注意是淺拷貝還是深拷貝，淺拷貝的結(jié)果就是兩個(gè)對象中的引用對象都是同一個(gè)地址，只要發(fā)生改變，都會有影響。

想要實(shí)現(xiàn)深拷貝，有很多種辦法，其中比較常用的就是實(shí)現(xiàn)Cloneable接口重寫clone方法，還有使用序列化+反序列化創(chuàng)建新對象。

好了，以上就是今天的全部內(nèi)容了。