分享、成长，拒绝浅藏辄止。搜索公众号【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.6public 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 会发挥作用？也就说什么时候会出现父子类匹配情况呢？为了加深理解，下面搞个例子玩一玩

代码示例

准备两个具有继承关系的实体类型

@Datapublic 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

@Testpublic 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());}

运行程序，结果为：

trueAnimalPropertyEditor

结论：

• 类型精确匹配优先级最高

• 若没精确匹配到结果且本类型的父类型已注册上去，则最终也会匹配成功

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

@Datapublic class Cat extends Animal {    private UUID uuid;}
@Datapublic 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);    }}

向注册中心注册编辑器，并且书写测试代码如下：

@Testpublic 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-00000000000500000001-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的乌托邦

每日文章推荐 | 每日文章推荐