分享、成長，拒絕淺藏輒止，搜索公眾號【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的烏托邦回復專欄二字即可全部獲取，分享、成長，拒絕淺藏輒止，

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

?關注A哥?

Author	A哥(YourBatman)
個人站點	www.yourbatman.cn
E-mail	yourbatman@qq.com
微 信	fsx1056342982
活躍平臺
公眾號	BAT的烏托邦（ID：BAT-utopia）
知識星球	BAT的烏托邦
每日文章推薦	每日文章推薦