3. 搞定收工，PropertyEditor就到這

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

目錄

• ✍前言
  • 版本約定
• ✍正文
  • PropertyEditorRegistry
  • PropertyEditorRegistrySupport
    • customEditorCache作用解釋
      • 程式碼示例
    • customEditorsForPath作用解釋
      • 程式碼示例
  • PropertyEditorRegistrar
    • ResourceEditorRegistrar
  • PropertyEditor自動發現機制
• ✍總結
  • ✔✔✔推薦閱讀✔✔✔

✍前言

你好，我是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的烏托邦回覆專欄二字即可全部獲取，分享、成長，拒絕淺藏輒止。

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