危險!請馬上替換程式碼中的BeanUtils!!!
1. 背景
之前在專欄中講過“不推薦使用屬性拷貝工具”,推薦直接定義轉換類和方法使用 IDEA 外掛自動填充 get / set 函式。
不推薦的主要理由是:
-
有些屬性拷貝工具效能有點差
-
有些屬性拷貝工具有“BUG”
-
使用屬性拷貝工具容易存在一些隱患(後面例子會講到)
2. 示例
首先公司內部就遇到過 commons 包的 BeanUtils 進行屬性拷貝效能較差的真實案例,然後該同事換成了 Spring 的 BeanUtils 效能好了很多,感興趣大家可以使用效能測試框架或者基準測試框架去對比,這裡就不對比了。
接下來我們看 Spring 的 BeanUtils 的屬性拷貝會存在啥問題:
import lombok.Data;
import java.util.List;
@Data
public class A {
private String name;
private List<Integer> ids;
}
@Data
public class B {
private String name;
private List<String> ids;
}
import org.springframework.beans.BeanUtils;
import java.util.Arrays;
public class BeanUtilDemo {
public static void main(String[] args) {
A first = new A();
first.setName("demo");
first.setIds(Arrays.asList(1, 2, 3));
B second = new B();
BeanUtils.copyProperties(first, second);
for (String each : second.getIds()) {// 型別轉換異常
System.out.println(each);
}
}
}
大家執行上述示例時,會發生型別轉換異常。
打斷點可以看到,屬性拷貝之後 B 型別的 second 物件中 ids 仍然為 Integer 型別:
如果不轉換為字串,直接進行列印,並不會報錯。
使用CGlib 在不定義Converter 的情況下也會遇到類似問題:
import org.easymock.cglib.beans.BeanCopier;
import java.util.Arrays;
public class BeanUtilDemo {
public static void main(String[] args) {
A first = new A();
first.setName("demo");
first.setIds(Arrays.asList(1, 2, 3));
B second = new B();
final BeanCopier beanCopier = BeanCopier.create(A.class, B.class, false);
beanCopier.copy(first,second,null);
for (String each : second.getIds()) {// 型別轉換異常
System.out.println(each);
}
}
}
同樣,問題在執行時才暴露出來。
接下來我們看下 mapstruct:
import org.mapstruct.Mapper;
import org.mapstruct.factory.Mappers;
@Mapper
public interface Converter {
Converter INSTANCE = Mappers.getMapper(Converter.class);
B aToB(A car);
}
import java.util.Arrays;
public class BeanUtilDemo {
public static void main(String[] args) {
A first = new A();
first.setName("demo");
first.setIds(Arrays.asList(1, 2, 3));
B second = Converter.INSTANCE.aToB(first);
for (String each : second.getIds()) {// 正常
System.out.println(each);
}
}
}
可以成功的將 A 中 List<Integer>
轉為 B 中的 List<String>
型別。
我們看下編譯生成的 Converter 實現類:
import java.util.ArrayList;
import java.util.List;
import javax.annotation.Generated;
import org.springframework.stereotype.Component;
@Generated(
value = "org.mapstruct.ap.MappingProcessor",
comments = "version: 1.3.1.Final, compiler: javac, environment: Java 1.8.0_202 (Oracle Corporation)"
)
@Component
public class ConverterImpl implements Converter {
@Override
public B aToB(A car) {
if ( car == null ) {
return null;
}
B b = new B();
b.setName( car.getName() );
b.setIds( integerListToStringList( car.getIds() ) );
return b;
}
protected List<String> integerListToStringList(List<Integer> list) {
if ( list == null ) {
return null;
}
List<String> list1 = new ArrayList<String>( list.size() );
for ( Integer integer : list ) {
list1.add( String.valueOf( integer ) );
}
return list1;
}
}
自動幫我們進行了轉換,我們可能沒有意識到型別並不一致。
如果我們在 A 類中新增一個 String number 屬性,在 B 類中新增一個 Long number 屬性,使用 mapstruect 當 number 設定為非數字型別時就會報 .NumberFormatException
。
@Override
public B aToB(A car) {
if ( car == null ) {
return null;
}
B b = new B();
b.setName( car.getName() );
if ( car.getNumber() != null ) { // 問題出在這裡
b.setNumber( Long.parseLong( car.getNumber() ) );
}
b.setIds( integerListToStringList( car.getIds() ) );
return b;
}
使用 cglib 預設則不會對映 number 屬性,B 中的 number 為 null。
如果手動定義轉換器,使用 IDEA 外掛(如 generateO2O)自動轉換:
public final class A2BConverter {
public static B from(A first) {
B b = new B();
b.setName(first.getName());
b.setIds(first.getIds());
return b;
}
}
在編碼階段就可以非常明確地發現這個問題:
3. 結論
由於 Java 的泛型其實是編譯期檢查,編譯後泛型擦除,導致執行時 List<Integer>
和 List<String>
都是 List 型別,可以正常賦值。這就導致在使用很多屬性對映工具時,編譯時不容易明顯的錯誤。
mapstruct 自定義了註解處理器,在編譯階段可以讀取對映雙方的泛型型別,進而進行對映。但是這種對映也很可怕,有時候我們由於粗心等原因定義錯了型別, 自動幫助我們進行了轉換,會帶了很多副作用。
之前對各種屬性對映工具的效能進行了簡單的對比,結果如下:
因此慎用屬性轉換工具,如果可能建議自定義轉換類,使用 IDEA外掛自動填充,效率也挺高, A 或 B 中任何屬性型別不匹配,甚至刪除一個屬性, 編譯階段即可報錯,而且直接呼叫 get set 的效率也是非常高的。
來源:blog.csdn.net/w605283073/article/details/107371462
相關閱讀:
· END ·
最後,關注公眾號網際網路架構師,在後臺回覆:2T,可以獲取我整理的 Java 系列面試題和答案,非常齊全 。
如果這篇文章對您有所幫助,或者有所啟發的話,幫忙掃描下發二維碼關注一下,您的支援是我堅持寫作最大的動力。
求一鍵三連:點贊、轉發、在看。