K60至尊版剛預(yù)熱 一加Ace2 Pro正面硬剛
Redmi這邊剛?cè)缁鹑巛钡男麄髁薑60 Ultra的各種技術(shù)和硬件配置，作為競品的一加也坐不住了。一加中國區(qū)總裁李杰發(fā)布了兩條微博，表示在自家的一加Ace2上早就已經(jīng)采用了和PixelWo
新年新氣象，小貓也是踏上了新年新征程，自從小貓按照老貓給的建議【系統(tǒng)梳理大法】完完整整地梳理完畢系統(tǒng)之后，小貓對整個(gè)系統(tǒng)的把控可謂又是上到了一個(gè)新的高度。開工一周，事情還不是很多，寥寥幾個(gè)需求，小貓分分鐘搞定。
類似于開放平臺的老六接到客戶的需求，需要在查詢訂單新增一個(gè)下單時(shí)間的返回值，然后這就需要提供底層服務(wù)的小貓?jiān)诮涌趯咏o出這個(gè)字段，然后老六通過包裝之后給客戶。由于需求比較簡單，所以加完字段之后，老六和小貓也就直接上線了。
上線之后事兒來了，對面客戶研發(fā)一直詢問為什么還是沒有下單時(shí)間，總是空的。老六于是直接找到了小貓，可是小貓經(jīng)過了一系列的自測發(fā)現(xiàn)返回值都是有的，后來排查到在老六封裝之后值不見了。經(jīng)過仔細(xì)排查，終于找到了問題，雖然沒有造成太大的影響，但是總歸給客戶研發(fā)的心里留下了一個(gè)不好的印象。
雖然下單時(shí)間老六和小貓定義的都是orderTime這樣一個(gè)字段，但是字段類型小貓用的是Date類型而老六用的是LocalDate,恰巧老六在進(jìn)行對象賦值的時(shí)候偷了個(gè)懶直接用了spring的BeanUtils.copyProperties工具類，于是導(dǎo)致日期類型的值并沒有被賦值過去，踩坑了。
老六這才回想起前段時(shí)間架構(gòu)師在群里@ALL的一段話，“大家用BeanUtils拷貝對象的時(shí)候注意點(diǎn)，有坑啊，大家盡量用get,set方法啊”。當(dāng)時(shí)的老六不以為意，想著，“切，這得多麻煩，一個(gè)個(gè)set不花時(shí)間啊，有工具類不用”。現(xiàn)在想來是真踩到BeanUtils的坑了。
老六一邊改著代碼一邊叨叨：“這也沒說坑在哪里啊......”
相信很多小伙伴在日常開發(fā)的過程中都用過BeanUtils.copyProperties。因?yàn)槲覀內(nèi)粘ｉ_發(fā)中，經(jīng)常涉及到DO、DTO、VO對象屬性拷貝賦值。很多開發(fā)為了省去繁瑣而又無聊的set方法往往都會(huì)用到這樣的工具類進(jìn)行值拷貝，但是看似簡單的拷貝程序，其實(shí)往往暗藏坑點(diǎn)，這不上面的老六就踩雷了么。
下面咱們一起來盤點(diǎn)一下這個(gè)拷貝存在哪些坑點(diǎn)吧。見下圖。
盤點(diǎn)
這里主要說的是從老對象進(jìn)行屬性拷貝到新對象之后，新對象的屬性值不是所期待的。這里分為兩種。
我們來重放一下老六和小貓遇到坑。代碼如下：
/** * 公眾號：程序員老貓 **/public class BeanCopyHelper { public static void main(String[] args) { Origin a = new Origin(); a.setOrderTime(new Date()); Target b = new Target(); BeanUtils.copyProperties(a,b); System.out.println(a.getOrderTime()); System.out.println(b.getOrderTime()); }}@Dataclass Origin { private Date orderTime;}@Dataclass Target { private LocalDate orderTime;}輸出結(jié)果：
Sun Feb 25 21:52:22 CST 2024null我看看到兩個(gè)對象的命名雖然是一致的，但是一個(gè)是Date另外一個(gè)是LocaDate，這樣導(dǎo)致值并沒有被賦值過去。
這種拷貝不成功的原因很多時(shí)候是由于研發(fā)人員粗心，沒有校對好導(dǎo)致的。例如下面兩個(gè)類：
@Dataclass Origin { private Date ordertime;}@Dataclass Target { private Date orderTime;}這種顯而易見是無法賦值成功的，因?yàn)樽屑?xì)看來兩個(gè)屬性名稱不一致。當(dāng)然不會(huì)賦值成功了。
這種情況是比較極端的，在用loombook和不用loombook的情況下是不一樣的。我們看一下下面例子。當(dāng)我們不用loombook的時(shí)候，如下代碼：
public class BeanCopyHelper { public static void main(String[] args) { Origin origin = new Origin(); origin.setOrderTime(true); Target target = new Target(); BeanUtils.copyProperties(origin,target); System.out.println(origin.getOrderTime()); System.out.println(target.isOrderTime()); }}class Origin { private Boolean isOrderTime; public Boolean getOrderTime() { return isOrderTime; } public void setOrderTime(Boolean orderTime) { isOrderTime = orderTime; }}class Target { private boolean isOrderTime; public boolean isOrderTime() { return isOrderTime; } public void setOrderTime(boolean orderTime) { isOrderTime = orderTime; }}上面的代碼中，我們看到基礎(chǔ)屬性的類型分別是包裝類還有一個(gè)是非包裝類，屬性的命名都是一致的。其最終的輸出結(jié)果，我們看到兩者是一致的：
truetrue如果我們使用loombook的時(shí)候，問題就來了，我們看一下loombook改造之后的代碼：
public class BeanCopyHelper { public static void main(String[] args) { Origin origin = new Origin(); origin.setIsOrderTime(true); Target target = new Target(); BeanUtils.copyProperties(origin,target); System.out.println(origin.getIsOrderTime()); System.out.println(target.isOrderTime()); }}@Dataclass Origin { private Boolean isOrderTime;}@Dataclass Target { private boolean isOrderTime;}最后的輸出結(jié)果為：
truefalse那么這是為什么呢？老貓?jiān)谶@里簡單分享一下，BeanUtils.copyProperties用戶在兩個(gè)對象之間進(jìn)行屬性的復(fù)制，底層基于JavaBean的內(nèi)省機(jī)制，通過內(nèi)省得到拷貝源對象和目的對象屬性的讀方法和寫方法，然后調(diào)用對應(yīng)的方法進(jìn)行屬性的復(fù)制。
所以在進(jìn)行拷貝時(shí)，如果手動(dòng)生成get和set那么方法分別為:getOrderTime()以及setOrderTime()。我們再來看一下如果采用LoomBook的時(shí)候，那么對應(yīng)的get和set的方法分別為：getIsOrderTime()以及setOrderTime()，拋開set和get本身關(guān)鍵字不看，那么后面的肯定是對應(yīng)不起來了。
這里我們再發(fā)散一下，如果說對應(yīng)的兩個(gè)類其屬性壓根連get和set方法都沒有設(shè)置，那么兩個(gè)對象能夠被拷貝成功嗎？答案是顯而易見的，無法被拷貝成功。所以這里也是用這個(gè)拷貝方法的時(shí)候的一個(gè)坑點(diǎn)。
看標(biāo)題還是比較抽象的，我們一起來看一下下面的代碼實(shí)現(xiàn)：
public class BeanCopyHelper { public static void main(String[] args) { Origin test1 = new Origin(); test1.outerName = "程序員老貓"; Origin.InnerClass innerClass = new Origin.InnerClass(); innerClass.InnerName = "程序員老貓 內(nèi)部類"; test1.innerClass = innerClass; System.out.println(test1); Target test2 = new Target(); BeanUtils.copyProperties(test1, test2); System.out.println(test2); }}@Dataclass Origin { public String outerName; public Origin.InnerClass innerClass; @Data public static class InnerClass { public String InnerName; }}@Dataclass Target { public String outerName; public Target.InnerClass innerClass; @Data public static class InnerClass { public String InnerName; }}輸出最終結(jié)果如下：
Origin(outerName=程序員老貓, innerClass=Origin.InnerClass(InnerName=程序員老貓 內(nèi)部類))Target(outerName=程序員老貓, innerClass=null)最終我們發(fā)現(xiàn)其內(nèi)部內(nèi)的屬性并沒有被賦值過去。
BeanUtils.copyProperties其實(shí)同命名的方法存在于兩個(gè)不同的包中，一個(gè)是spring的另外一個(gè)是apache的，如果不注意的話，很容易就會(huì)有問題。如下代碼：
//org.springframework.beans.BeanUtils(源對象在左邊，目標(biāo)對象在右邊)public static void copyProperties(Object source, Object target) throws BeansException //org.apache.commons.beanutils.BeanUtils（源對象在右邊，目標(biāo)對象在左邊）public static void copyProperties(Object dest, Object orig) throws IllegalAccessException, InvocationTargetException位于org.springframework.beans包下。其copyProperties方法實(shí)現(xiàn)原理和Apache BeanUtils.copyProperties原理類似，默認(rèn)實(shí)現(xiàn)淺拷貝 區(qū)別在于對PropertyDescriptor（內(nèi)省機(jī)制相關(guān)）的處理結(jié)果做了緩存來提升性能。這里大家有興趣可以自行去查閱一下源代碼。
當(dāng)我們在排查問題的時(shí)候，或者在熟悉業(yè)務(wù)的過程中，常常會(huì)想要看一個(gè)整個(gè)屬性值的調(diào)用鏈路，從而來跟蹤其設(shè)值源頭。如果我想看當(dāng)前的這個(gè)屬性是什么時(shí)候被設(shè)值值的時(shí)候，老貓的做法通常是找到當(dāng)前的那個(gè)屬性的set方法，然后使用idea中的“Find Usages”或者快捷鍵ALT+F7。得到需要屬性值被設(shè)置的地方。如下圖，就能清晰看到在哪里設(shè)值了。
調(diào)用鏈路
但是，如果用了工具類進(jìn)行拷貝的話，那么在代碼復(fù)雜的情況下，我們就很難定位其在什么時(shí)候被調(diào)用的了。
在這里，咱們要回憶一下什么時(shí)候淺拷貝，什么是深拷貝。淺拷貝：淺拷貝是指創(chuàng)建一個(gè)新對象，然后將原始對象的內(nèi)容逐個(gè)復(fù)制到新對象中。在淺拷貝中，只有最外層對象被復(fù)制，而內(nèi)部的嵌套對象只是引用而已，沒有被遞歸復(fù)制。這意味著原始對象和淺拷貝對象之間共享內(nèi)部對象，修改其中一個(gè)對象的內(nèi)部對象會(huì)影響到另一個(gè)對象。如下示意圖：
淺拷貝
深拷貝：深拷貝是指在進(jìn)行復(fù)制操作時(shí)，創(chuàng)建一個(gè)完全獨(dú)立的新對象，并遞歸地復(fù)制原始對象及其所有子對象。換句話說，深拷貝會(huì)復(fù)制對象的所有層級，包括對象的屬性、嵌套對象、引用等。因此，原始對象和復(fù)制對象是完全獨(dú)立的，修改其中一個(gè)對象不會(huì)影響另一個(gè)對象。
深拷貝
根據(jù)上面的描述，我們通過代碼來重現(xiàn)一下坑點(diǎn)，具體如下：
public class Address { private String city; ...}public class Person { private String name; private Address address; ...}public class TestMain { public static void main(String[] args) { Person sourcePerson = new Person(); sourcePerson.setName("老六"); Address address = new Address(); address.setCity("上海 徐匯"); sourcePerson.setAddress(address); Person targetPerson = new Person(); BeanUtils.copyProperties(sourcePerson, targetPerson); System.out.println(targetPerson.getAddress().getCity()); sourcePerson.getAddress().setCity("上海 黃埔"); System.out.println(targetPerson.getAddress().getCity()); }}輸出結(jié)果為：
上海 徐匯上海 黃埔我們很明顯地看到操作原始屬性的地址，直接影響到了新對象的屬性的地址。所以這個(gè)坑大家也要當(dāng)心。當(dāng)然由于淺拷貝的原因?qū)е驴截惓霈F(xiàn)問題還涉及集合類進(jìn)行拷貝。例如我們需要對List或者M(jìn)ap進(jìn)行拷貝的時(shí)候也不能直接去拷貝list以及map。
由于BeanUtils.copyProperties其實(shí)底層是通過反射實(shí)現(xiàn)的，所以其程序執(zhí)行的效率還是比較低的。我們看一下下面的對比代碼：
public class BeanCopyHelper { public static void main(String[] args) { Origin test1 = new Origin(); test1.outerName = "公眾號:程序員老貓"; Target test2 = new Target(); long beginTime = System.currentTimeMillis(); for (int i = 0; i < 100000; i++) { //循環(huán)10萬次 test2.setOuterName(test1.getOuterName()); } System.out.println(test2); System.out.println("common setter time:" + (System.currentTimeMillis() - beginTime)); long beginTime2 = System.currentTimeMillis(); for (int i = 0; i < 100000; i++) { //循環(huán)10萬次 BeanUtils.copyProperties(test1, test2); } System.out.println(test2); System.out.println("common setter time:" + (System.currentTimeMillis() - beginTime2)); }}@Dataclass Origin { public String outerName;}@Dataclass Target { public String outerName;}輸出結(jié)果如下：
Target(outerName=公眾號:程序員老貓)common setter time:14Target(outerName=公眾號:程序員老貓)common setter time:291上述結(jié)果，很好地證明了這個(gè)結(jié)論。有小伙伴肯定會(huì)說，這種場景應(yīng)該比較少吧，太極端了。那么極端嗎？大家回憶一下上面老貓?zhí)岬降模绻眠@個(gè)工具復(fù)制List或者M(jìn)ap這種集合的時(shí)候，其實(shí)如果把List和Map當(dāng)做整個(gè)對象來復(fù)制往往是失敗的。相信如果不是小白的話一般都會(huì)知道這個(gè)坑點(diǎn)，為了解決這個(gè)問題，很多小伙伴可能會(huì)選擇在List或者M(jìn)ap等集合內(nèi)部進(jìn)行循環(huán)一一遍歷去進(jìn)行單個(gè)對象的拷貝賦值，那么這樣的場景下，性能是不是就受到了影響呢？
既然說了bean拷貝工具類這么多的壞話，那么我們?nèi)绾稳ヌ鎿Q這種寫法呢？第一種：當(dāng)然是直接采用原始的get以及set方法了。這種方式好像除了代碼長了一些之外好像也沒有什么缺點(diǎn)了。有小伙伴可能會(huì)跳出來說，這不擼起來麻煩么。不著急，idea這款強(qiáng)大的工具不是已經(jīng)給我們提供插件了么。如下圖：
插件示意圖
第二種：使用映射工具庫，如MapStruct、ModelMapper等，它們可以自動(dòng)生成屬性映射的代碼。這些工具庫可以減少手動(dòng)編寫setter方法的工作量，并提供更好的性能。如下使用代碼：
/** * 公眾號：程序員老貓 **/ @Mapper public interface SourceTargetMapper { SourceTargetMapper INSTANCE = Mappers.getMapper(SourceTargetMapper.class); @Mapping(source = "name", target = "name") @Mapping(source = "age", target = "age") Target mapToTarget(Source source); } //使用 Target target = SourceTargetMapper.INSTANCE.mapToTarget(source);上述這兩種替換方案，說真的作為開發(fā)者而言，老貓更喜歡第一種，簡單方便，而且不需要依賴第三方maven依賴。第二種個(gè)人感覺用起來反而比較繁瑣，上述當(dāng)然純屬個(gè)人偏好。
上述小貓和老六的案例中，其實(shí)存在的問題需要我們思考的。
即使再小再簡單的需求，作為研發(fā)開發(fā)完畢之后，我們可以直接上線么？其實(shí)很多時(shí)候事故往往就是由于“不以為意”發(fā)生的。事故的發(fā)生往往也遵循“墨菲定律”，這就要求我們更要敬畏生產(chǎn)，再小的需求點(diǎn)都需要經(jīng)過嚴(yán)格的測試驗(yàn)證才能上線。
說了那么多BeanUtils.copyProperties的壞話，那么這種拷貝方式是不是真的就一無是處呢？其實(shí)不是的，所謂存在即合理。很多時(shí)候使用的時(shí)候踩坑說白了我們沒有理解好這個(gè)拷貝工具的特性。很多時(shí)候大家在使用使用一個(gè)技術(shù)的時(shí)候都是囫圇吞棗，為了使用而去使用，壓根就沒有深入了解這個(gè)技術(shù)的特性以及使用注意點(diǎn)。所以在我們使用第三方工具的時(shí)候，我們需要更好地了解其特性，知其所以然才能更好更正確地使用。小伙伴們你們覺得呢？
本文鏈接：http://m.www897cc.com/showinfo-26-75349-0.html都說了別用BeanUtils.copyProperties，這不翻車了吧
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號