3. 搞定收工，PropertyEditor就到這

分享、成長，拒絕淺藏輒止。搜索公衆號【BAT的烏托邦】，回覆關鍵字專欄有Spring技術棧、中間件等小而美的原創專欄供以免費學習。本文已被 https://www.yourbatman.cn 收錄。

✍前言

你好，我是YourBatman。

上篇文章介紹了PropertyEditor在類型轉換裏的作用，以及舉例說明了Spring內置實現的PropertyEditor們，它們各司其職完成 String <-> 各種類型 的互轉。

在知曉了這些基礎知識後，本文將更進一步，爲你介紹Spring是如何註冊、管理這些轉換器，以及如何自定義轉換器去實現私有轉換協議。

版本約定

• Spring Framework：5.3.1
• Spring Boot：2.4.0

✍正文

稍微熟悉點Spring Framework的小夥伴就知道，Spring特別擅長API設計、模塊化設計。後綴模式是它常用的一種管理手段，比如xxxRegistry註冊中心在Spring內部就有非常多：

xxxRegistry用於管理（註冊、修改、刪除、查找）一類組件，當組件類型較多時使用註冊中心統一管理是一種非常有效的手段。誠然，PropertyEditor就屬於這種場景，管理它們的註冊中心是PropertyEditorRegistry。

PropertyEditorRegistry

它是管理PropertyEditor的中心接口，負責註冊、查找對應的PropertyEditor。

// @since 1.2.6
public interface PropertyEditorRegistry {

    // 註冊一個轉換器：該type類型【所有的屬性】都將交給此轉換器去轉換（即使是個集合類型）
    // 效果等同於調用下方法：registerCustomEditor(type,null,editor);
	void registerCustomEditor(Class<?> requiredType, PropertyEditor propertyEditor);
	// 註冊一個轉換器：該type類型的【propertyPath】屬性將交給此轉換器
	// 此方法是重點，詳解見下文
	void registerCustomEditor(Class<?> requiredType, String propertyPath, PropertyEditor propertyEditor);
	// 查找到一個合適的轉換器
	PropertyEditor findCustomEditor(Class<?> requiredType, String propertyPath);
	
}

說明：該API是1.2.6這個小版本新增的。Spring 一般 不會在小版本里新增核心API以確保穩定性，但這並非100%。Spring認爲該API對使用者無感的話（你不可能會用到它），增/減也是有可能的

此接口的繼承樹如下：

值得注意的是：雖然此接口看似實現者衆多，但其實其它所有的實現關於PropertyEditor的管理部分都是委託給PropertyEditorRegistrySupport來管理，無一例外。因此，本文只需關注PropertyEditorRegistrySupport足矣，這爲後面的高級應用（如數據綁定、BeanWrapper等）打好堅實基礎。

用不太正確的理解可這麼認爲：PropertyEditorRegistry接口的唯一實現只有PropertyEditorRegistrySupport

PropertyEditorRegistrySupport

它是PropertyEditorRegistry接口的實現，提供對default editors和custom editors的管理，最終主要爲BeanWrapperImpl和DataBinder服務。

一般來說，Registry註冊中心內部會使用多個Map來維護，代表註冊表。此處也不例外：

// 裝載【默認的】編輯器們，初始化的時候會註冊好
private Map<Class<?>, PropertyEditor> defaultEditors;
// 如果想覆蓋掉【默認行爲】，可通過此Map覆蓋（比如處理Charset類型你不想用默認的編輯器處理）
// 通過API：overrideDefaultEditor(...)放進此Map裏
private Map<Class<?>, PropertyEditor> overriddenDefaultEditors;

// ======================註冊自定義的編輯器======================
// 通過API：registerCustomEditor(...)放進此Map裏（若沒指定propertyPath）
private Map<Class<?>, PropertyEditor> customEditors;
// 通過API：registerCustomEditor(...)放進此Map裏（若指定了propertyPath）
private Map<String, CustomEditorHolder> customEditorsForPath;

PropertyEditorRegistrySupport使用了4個 Map來維護不同來源的編輯器，作爲查找的 “數據源”。

這4個Map可分爲兩大組，並且有如下規律：

• 默認編輯器組：defaultEditors和overriddenDefaultEditors
  • overriddenDefaultEditors優先級 高於 defaultEditors
• 自定義編輯器組：customEditors和customEditorsForPath
  • 它倆爲互斥關係

細心的小夥伴會發現還有一個Map咱還未提到：

private Map<Class<?>, PropertyEditor> customEditorCache;

從屬性名上理解，它表示customEditors屬性的緩存。那麼問題來了：customEditors和customEditorCache的數據結構一毛一樣（都是Map），談何緩存呢？直接從customEditors裏獲取值不更香嗎？

customEditorCache作用解釋

customEditorCache用於緩存自定義的編輯器，輔以成員屬性customEditors屬性一起使用。具體（唯一）使用方式在私有方法：根據類型獲取自定義編輯器PropertyEditorRegistrySupport#getCustomEditor

private PropertyEditor getCustomEditor(Class<?> requiredType) {
	if (requiredType == null || this.customEditors == null) {
		return null;
	}
	PropertyEditor editor = this.customEditors.get(requiredType);

	// 重點：若customEditors沒有並不代表處理不了，因爲還得考慮父子關係、接口關係
	if (editor == null) {
		// 去緩存裏查詢，是否存在父子類作爲key的情況
		if (this.customEditorCache != null) {
			editor = this.customEditorCache.get(requiredType);
		}
	
		// 若緩存沒命中，就得遍歷customEditors了，時間複雜度爲O(n)
		if (editor == null) {
			for (Iterator<Class<?>> it = this.customEditors.keySet().iterator(); it.hasNext() && editor == null;) {
				Class<?> key = it.next();
				if (key.isAssignableFrom(requiredType)) {
					editor = this.customEditors.get(key);
					if (this.customEditorCache == null) {
						this.customEditorCache = new HashMap<Class<?>, PropertyEditor>();
					}
					this.customEditorCache.put(requiredType, editor);
				}
			}
		}
	}
	return editor;
}

這段邏輯不難理解，此流程用一張圖可描繪如下：

因爲遍歷customEditors屬於比較重的操作（複雜度爲O(n)），從而使用了customEditorCache避免每次出現父子類的匹配情況就去遍歷一次，大大提高匹配效率。

什麼時候customEditorCache會發揮作用？也就說什麼時候會出現父子類匹配情況呢？爲了加深理解，下面搞個例子玩一玩

代碼示例

準備兩個具有繼承關係的實體類型

@Data
public abstract class Animal {
    private Long id;
    private String name;
}

public class Cat extends Animal {

}

書寫針對於父類（父接口）類型的編輯器：

public class AnimalPropertyEditor extends PropertyEditorSupport {

    @Override
    public String getAsText() {
        return null;
    }

    @Override
    public void setAsText(String text) throws IllegalArgumentException {
    }
}

說明：由於此部分只關注查找/匹配過程邏輯，因此對編輯器內部處理邏輯並不關心

註冊此編輯器，對應的類型爲父類型：Animal

@Test
public void test5() {
    PropertyEditorRegistry propertyEditorRegistry = new PropertyEditorRegistrySupport();
    propertyEditorRegistry.registerCustomEditor(Animal.class, new AnimalPropertyEditor());

	// 付類型、子類型均可匹配上對應的編輯器
    PropertyEditor customEditor1 = propertyEditorRegistry.findCustomEditor(Cat.class, null);
    PropertyEditor customEditor2 = propertyEditorRegistry.findCustomEditor(Animal.class, null);
    System.out.println(customEditor1 == customEditor2);
    System.out.println(customEditor1.getClass().getSimpleName());
}

運行程序，結果爲：

true
AnimalPropertyEditor

結論：

• 類型精確匹配優先級最高
• 若沒精確匹配到結果且本類型的父類型已註冊上去，則最終也會匹配成功

customEditorCache的作用可總結爲一句話：幫助customEditors屬性裝載對已匹配上的子類型的編輯器，從而避免了每次全部遍歷，有效的提升了匹配效率。

值得注意的是，每次調用API向customEditors添加新元素時，customEditorCache就會被清空，因此因儘量避免在運行期註冊編輯器，以避免緩存失效而降低性能

customEditorsForPath作用解釋

上面說了，它是和customEditors互斥的。

customEditorsForPath的作用是能夠實現更精準匹配，針對屬性級別精準處理。此Map的值通過此API註冊進來：

public void registerCustomEditor(Class<?> requiredType, String propertyPath, PropertyEditor propertyEditor);

說明：propertyPath不能爲null才進此處，否則會註冊進customEditors嘍

可能你會想，有了customEditors爲何還需要customEditorsForPath呢？這裏就不得不說兩者的最大區別了：

• customEditors：粒度較粗，通用性強。key爲類型，即該類型的轉換全部交給此編輯器處理
  • 如：registerCustomEditor(UUID.class,new UUIDEditor())，那麼此編輯器就能處理全天下所有的String <-> UUID 轉換工作
• customEditorsForPath：粒度細精確到屬性（字段）級別，有點專車專座的意思
  • 如：registerCustomEditor(Person.class, "cat.uuid" , new UUIDEditor())，那麼此編輯器就有且僅能處理Person.cat.uuid屬性，其它的一概不管

有了這種區別，註冊中心在findCustomEditor(requiredType,propertyPath)匹配的時候也是按照優先級順序執行匹配的：

1. 若指定了propertyPath（不爲null），就先去customEditorsForPath裏找。否則就去customEditors裏找
2. 若沒有指定propertyPath（爲null)，就直接去customEditors裏找

爲了加深理解，講上場景用代碼實現如下。

代碼示例

創建一個Person類，關聯Cat

@Data
public class Cat extends Animal {
    private UUID uuid;
}

@Data
public class Person {
    private Long id;
    private String name;
    private Cat cat;
}

現在的需求場景是：

• UUID類型統一交給UUIDEditor處理（當然包括Cat裏面的UUID類型）
• Person類裏面的Cat的UUID類型，需要單獨特殊處理，因此格式不一樣需要“特殊照顧”

很明顯這就需要兩個不同的屬性編輯器來實現，然後組織起來協同工作。Spring內置了UUIDEditor可以處理一般性的UUID類型（通用），而Person 專用的 UUID編輯器，自定義如下：

public class PersonCatUUIDEditor extends UUIDEditor {

    private static final String SUFFIX = "_YourBatman";

    @Override
    public String getAsText() {
        return super.getAsText().concat(SUFFIX);
    }

    @Override
    public void setAsText(String text) throws IllegalArgumentException {
        text = text.replace(SUFFIX, "");
        super.setAsText(text);
    }
}

向註冊中心註冊編輯器，並且書寫測試代碼如下：

@Test
public void test6() {
    PropertyEditorRegistry propertyEditorRegistry = new PropertyEditorRegistrySupport();
    // 通用的
    propertyEditorRegistry.registerCustomEditor(UUID.class, new UUIDEditor());
    // 專用的
    propertyEditorRegistry.registerCustomEditor(Person.class, "cat.uuid", new PersonCatUUIDEditor());


    String uuidStr = "1-2-3-4-5";
    String personCatUuidStr = "1-2-3-4-5_YourBatman";

    PropertyEditor customEditor = propertyEditorRegistry.findCustomEditor(UUID.class, null);
    // customEditor.setAsText(personCatUuidStr); // 拋異常：java.lang.NumberFormatException: For input string: "5_YourBatman"
    customEditor.setAsText(uuidStr);
    System.out.println(customEditor.getAsText());

    customEditor = propertyEditorRegistry.findCustomEditor(Person.class, "cat.uuid");
    customEditor.setAsText(personCatUuidStr);
    System.out.println(customEditor.getAsText());
}

運行程序，打印輸出：

00000001-0002-0003-0004-000000000005
00000001-0002-0003-0004-000000000005_YourBatman

完美。

customEditorsForPath相當於給你留了鉤子，當你在某些特殊情況需要特殊照顧的時候，你可以藉助它來搞定，十分的方便。

此方式有必要記住並且嘗試，在實際開發中使用得還是比較多的。特別在你不想全局定義，且要確保向下兼容性的時候，使用抽象接口類型 + 此種方式縮小影響範圍將十分有用

說明：propertyPath不僅支持Java Bean導航方式，還支持集合數組方式，如Person.cats[0].uuid這樣格式也是ok的

PropertyEditorRegistrar

Registrar：登記員。它一般和xxxRegistry配合使用，其實內核還是Registry，只是運用了倒排思想屏蔽一些內部實現而已。

public interface PropertyEditorRegistrar {
	void registerCustomEditors(PropertyEditorRegistry registry);
}

同樣的，Spring內部也有很多類似實現模式：

PropertyEditorRegistrar接口在Spring體系內唯一實現爲：ResourceEditorRegistrar。它可值得我們絮叨絮叨。

ResourceEditorRegistrar

從命名上就知道它和Resource資源有關，實際上也確實如此：主要負責將ResourceEditor註冊到註冊中心裏面去，用於處理形如Resource、File、URI等這些資源類型。

你配置classpath:xxx.xml用來啓動Spring容器的配置文件，String -> Resource轉換就是它的功勞嘍

唯一構造器爲：

public ResourceEditorRegistrar(ResourceLoader resourceLoader, PropertyResolver propertyResolver) {
	this.resourceLoader = resourceLoader;
	this.propertyResolver = propertyResolver;
}

• resourceLoader：一般傳入ApplicationContext
• propertyResolver：一般傳入Environment

很明顯，它的設計就是服務於ApplicationContext上下文，在Bean創建過程中輔助BeanWrapper實現資源加載、轉換。

BeanFactory在初始化的準備過程中就將它實例化，從而具備資源處理能力：

AbstractApplicationContext：

	protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
		
		...
		beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
		beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
		...
	}

這也是PropertyEditorRegistrar在Spring Framework的唯一使用處，值的關注。

PropertyEditor自動發現機制

最後介紹一個使用中的奇淫小技巧：PropertyEditor自動發現機制。

一般來說，我們自定義一個PropertyEditor是爲了實現自定義類型 <-> 字符串的自動轉換，它一般需要有如下步驟：

1. 爲自定義類型寫好一個xxxPropertyEditor（實現PropertyEditor接口）
2. 將寫好的編輯器註冊到註冊中心PropertyEditorRegistry

顯然步驟1屬個性化行爲無法替代，但步驟2屬於標準行爲，重複勞動是可以標準化的。自動發現機制就是用來解決此問題，對自定義的編輯器制定瞭如下標準：

1. 實現了PropertyEditor接口，具有空構造器
2. 與自定義類型同包（在同一個package內），名稱必須爲：targetType.getName() + "Editor"

這樣你就無需再手動註冊到註冊中心了（當然手動註冊了也不礙事），Spring能夠自動發現它，這在有大量自定義類型編輯器的需要的時候將很有用。

說明：此段核心邏輯在BeanUtils#findEditorByConvention()裏，有興趣者可看看

值得注意的是：此機制屬Spring遵循Java Bean規範而單獨提供，在單獨使用PropertyEditorRegistry時並未開啓，而是在使用Spring產品級能力TypeConverter時有提供，這在後文將有體現，歡迎保持關注。

✍總結

本文在瞭解PropertyEditor基礎支持之上，主要介紹了其註冊中心PropertyEditorRegistry的使用。PropertyEditorRegistrySupport作爲其“唯一”實現，負責管理PropertyEditor，包括通用處理和專用處理。最後介紹了PropertyEditor的自動發現機制，其實在實際生產中我並不建議使用自動機制，因爲對於可能發生改變的因素，顯示指定優於隱式約定。

關於Spring類型轉換PropertyEditor相關內容就介紹到這了，雖然它很“古老”但並沒有退出歷史舞臺，在排查問題，甚至日常擴展開發中還經常會碰到，因此強烈建議你掌握。下面起將介紹Spring類型轉換的另外一個重點：新時代的類型轉換服務ConversionService及其周邊。

---

✔✔✔推薦閱讀✔✔✔

【Spring類型轉換】系列：

• 1. 揭祕Spring類型轉換 - 框架設計的基石
• 2. Spring早期類型轉換，基於PropertyEditor實現
• 3. 搞定收工，PropertyEditor就到這

【Jackson】系列：

• 1. 初識Jackson -- 世界上最好的JSON庫
• 2. 媽呀，Jackson原來是這樣寫JSON的
• 3. 懂了這些，方敢在簡歷上說會用Jackson寫JSON
• 4. JSON字符串是如何被解析的？JsonParser瞭解一下
• 5. JsonFactory工廠而已，還蠻有料，這是我沒想到的
• 6. 二十不惑，ObjectMapper使用也不再迷惑
• 7. Jackson用樹模型處理JSON是必備技能，不信你看

【數據校驗Bean Validation】系列：

• 1. 不吹不擂，第一篇就能提升你對Bean Validation數據校驗的認知
• 2. Bean Validation聲明式校驗方法的參數、返回值
• 3. 站在使用層面，Bean Validation這些標準接口你需要爛熟於胸
• 4. Validator校驗器的五大核心組件，一個都不能少
• 5. Bean Validation聲明式驗證四大級別：字段、屬性、容器元素、類
• 6. 自定義容器類型元素驗證，類級別驗證（多字段聯合驗證）

【新特性】系列：

• IntelliJ IDEA 2020.3正式發佈，年度最後一個版本很講武德
• IntelliJ IDEA 2020.2正式發佈，諸多亮點總有幾款能助你提效
• IntelliJ IDEA 2020.1正式發佈，你要的Almost都在這！
• Spring Framework 5.3.0正式發佈，在雲原生路上繼續發力
• Spring Boot 2.4.0正式發佈，全新的配置文件加載機制（不向下兼容）
• Spring改變版本號命名規則：此舉對非英語國家很友好
• JDK15正式發佈，劃時代的ZGC同時宣佈轉正

【程序人生】系列：

• 螞蟻金服上市了，我不想努力了
• 如果程序員和產品經理都用凡爾賽文學對話......
• 程序人生 | 春風得意馬蹄疾，一日看盡長安花

還有諸如【Spring配置類】【Spring-static】【Spring數據綁定】【Spring Cloud Netflix】【Feign】【Ribbon】【Hystrix】...更多原創專欄，關注BAT的烏托邦回覆專欄二字即可全部獲取，分享、成長，拒絕淺藏輒止。

有些專欄已完結，有些正在連載中，期待你的關注、共同進步