实现BeanPostProcessor

现在，我们已经完成了扫描Class名称、创建BeanDefinition、创建Bean实例、初始化Bean，理论上一个可用的IoC容器就已经就绪。

然而，BeanPostProcessor的出现改变了这一切。Spring允许用户自定义一种特殊的Bean，即实现了BeanPostProcessor接口，它有什么用呢？其实就是替换Bean。我们举个例子，下面的代码是基于Spring代码：

@Configuration
@ComponentScan
public class AppConfig {

    public static void main(String[] args) {
        var ctx = new AnnotationConfigApplicationContext(AppConfig.class);
        // 可以获取到ZonedDateTime:
        ZonedDateTime dt = ctx.getBean(ZonedDateTime.class);
        System.out.println(dt);
        // 错误:NoSuchBeanDefinitionException:
        System.out.println(ctx.getBean(LocalDateTime.class));
    }

    // 创建LocalDateTime实例
    @Bean
    public LocalDateTime localDateTime() {
        return LocalDateTime.now();
    }

    // 实现一个BeanPostProcessor
    @Bean
    BeanPostProcessor replaceLocalDateTime() {
        return new BeanPostProcessor() {
            @Override
            public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
                // 将LocalDateTime类型实例替换为ZonedDateTime类型实例:
                if (bean instanceof LocalDateTime) {
                    return ZonedDateTime.now();
                }
                return bean;
            }
        };
    }
}

运行可知，我们定义的@Bean类型明明是LocalDateTime类型，但却被另一个BeanPostProcessor替换成了ZonedDateTime，于是，调用getBean(ZonedDateTime.class)可以拿到替换后的Bean，调用getBean(LocalDateTime.class)会报错，提示找不到Bean。那么原始的Bean哪去了？答案是被BeanPostProcessor扔掉了。

可见，BeanPostProcessor是一种特殊Bean，它的作用是根据条件替换某些Bean。上述的例子中，LocalDateTime被替换为ZonedDateTime其实没啥意义，但实际应用中，把原始Bean替换为代理后的Bean是非常常见的，比如下面的基于Spring的代码：

@Configuration
@ComponentScan
public class AppConfig {

    public static void main(String[] args) {
        var ctx = new AnnotationConfigApplicationContext(AppConfig.class);
        UserService u = ctx.getBean(UserService.class);
        System.out.println(u.getClass().getSimpleName()); // UserServiceProxy
        u.register("bob@example.com", "bob12345");
    }

    @Bean
    BeanPostProcessor createProxy() {
        return new BeanPostProcessor() {
            @Override
            public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
                // 实现事务功能:
                if (bean instanceof UserService u) {
                    return new UserServiceProxy(u);
                }
                return bean;
            }
        };
    }
}

@Component
class UserService {
    public void register(String email, String password) {
        System.out.println("INSERT INTO ...");
    }
}

// 代理类:
class UserServiceProxy extends UserService {
    UserService target;

    public UserServiceProxy(UserService target) {
        this.target = target;
    }

    @Override
    public void register(String email, String password) {
        System.out.println("begin tx");
        target.register(email, password);
        System.out.println("commit tx");
    }
}

如果执行上述代码，打印出的Bean类型不是UserService，而是UserServiceProxy，因此，调用register()会打印出begin tx和commit tx，说明“事务”生效了。

迄今为止，创建Proxy似乎没有什么影响。让我们把代码再按实际情况扩展一下，UserService是用户编写的业务代码，需要注入JdbcTemplate：

@Component
class UserService {
    @Autowired JdbcTemplate jdbcTemplate;
    
    public void register(String email, String password) {
        jdbcTemplate.update("INSERT INTO ...");
    }
}

而PostBeanProcessor一般由框架本身提供事务功能，所以它会动态创建一个UserServiceProxy：

class UserServiceProxy extends UserService {
    UserService target;

    public UserServiceProxy(UserService target) {
        this.target = target;
    }

    @Override
    public void register(String email, String password) {
        System.out.println("begin tx");
        target.register(email, password);
        System.out.println("commit tx");
    }
}

调用用户注册的页面由MvcController控制，因此，将UserService注入到MvcController：

@Controller
class MvcController {
    @Autowired UserService userService;
    
    @PostMapping("/register")
    void register() {
        userService.register(...);
    }
}

一开始，由IoC容器创建的Bean包括：

JdbcTemplate
UserService
MvcController

接着，由于BeanPostProcessor的介入，原始的UserService被替换为UserServiceProxy：

JdbcTemplate
UserServiceProxy
MvcController

那么问题来了：注意到UserServiceProxy是从UserService继承的，它也有一个@Autowired JdbcTemplate，那JdbcTemplate实例应注入到原始的UserService还是UserServiceProxy？

从业务逻辑出发，JdbcTemplate实例必须注入到原始的UserService，否则，代理类UserServiceProxy执行target.register()时，相当于对原始的UserService调用register()方法，如果JdbcTemplate没有注入，将直接报NullPointerException错误。

这时第二个问题又来了：MvcController需要注入的UserService，应该是原始的UserService还是UserServiceProxy？

还是从业务逻辑出发，MvcController需要注入的UserService必须是UserServiceProxy，否则，事务不起作用。

我们用图描述一下注入关系：

┌───────────────┐
│MvcController  │
├───────────────┤   ┌────────────────┐
│- userService ─┼──▶│UserServiceProxy│
└───────────────┘   ├────────────────┤
                    │- jdbcTemplate  │
                    ├────────────────┤   ┌────────────────┐
                    │- target       ─┼──▶│UserService     │
                    └────────────────┘   ├────────────────┤   ┌────────────┐
                                         │- jdbcTemplate ─┼──▶│JdbcTemplate│
                                         └────────────────┘   └────────────┘

注意到上图的UserService已经脱离了IoC容器的管理，因为此时UserService对应的BeanDefinition中，存放的instance是UserServiceProxy。

可见，引入BeanPostProcessor可以实现Proxy机制，但也让依赖注入变得更加复杂。

但是我们仔细分析依赖关系，还是可以总结出两条原则：

一个Bean如果被Proxy替换，则依赖它的Bean应注入Proxy，即上图的MvcController应注入UserServiceProxy；
一个Bean如果被Proxy替换，如果要注入依赖，则应该注入到原始对象，即上图的JdbcTemplate应注入到原始的UserService。

基于这个原则，要满足条件1是很容易的，因为只要创建Bean完成后，立刻调用BeanPostProcessor就实现了替换，后续其他Bean引用的肯定就是Proxy了。先改造创建Bean的流程，在创建@Configuration后，接着创建BeanPostProcessor，再创建其他普通Bean：

public AnnotationConfigApplicationContext(Class<?> configClass, PropertyResolver propertyResolver) {
    ...
    // 创建@Configuration类型的Bean:
    this.beans.values().stream()
            // 过滤出@Configuration:
            .filter(this::isConfigurationDefinition).sorted().map(def -> {
                createBeanAsEarlySingleton(def);
                return def.getName();
            }).collect(Collectors.toList());

    // 创建BeanPostProcessor类型的Bean:
    List<BeanPostProcessor> processors = this.beans.values().stream()
            // 过滤出BeanPostProcessor:
            .filter(this::isBeanPostProcessorDefinition)
            // 排序:
            .sorted()
            // 创建BeanPostProcessor实例:
            .map(def -> {
                return (BeanPostProcessor) createBeanAsEarlySingleton(def);
            }).collect(Collectors.toList());
    this.beanPostProcessors.addAll(processors);

    // 创建其他普通Bean:
    createNormalBeans();
    ...
}

再继续修改createBeanAsEarlySingleton()，创建Bean实例后，调用BeanPostProcessor处理：

public Object createBeanAsEarlySingleton(BeanDefinition def) {
    ...

    // 创建Bean实例:
    Object instance = ...;
    def.setInstance(instance);

    // 调用BeanPostProcessor处理Bean:
    for (BeanPostProcessor processor : beanPostProcessors) {
        Object processed = processor.postProcessBeforeInitialization(def.getInstance(), def.getName());
        // 如果一个BeanPostProcessor替换了原始Bean，则更新Bean的引用:
        if (def.getInstance() != processed) {
            def.setInstance(processed);
        }
    }
    return def.getInstance();
}

现在，如果一个Bean被替换为Proxy，那么BeanDefinition中的instance已经是Proxy了，这时，对这个Bean进行依赖注入会有问题，因为注入的是Proxy而不是原始Bean，怎么办？

这时我们要思考原始Bean去哪了？原始Bean实际上是被BeanPostProcessor给丢了！如果BeanPostProcessor能保存原始Bean，那么，注入前先找到原始Bean，就可以把依赖正确地注入给原始Bean。我们给BeanPostProcessor加一个postProcessOnSetProperty()方法，让它返回原始Bean：

public interface BeanPostProcessor {
    // 注入依赖时,应该使用的Bean实例:
    default Object postProcessOnSetProperty(Object bean, String beanName) {
        return bean;
    }
}

再继续把injectBean()改一下，不要直接拿BeanDefinition.getInstance()，而是拿到原始Bean：

void injectBean(BeanDefinition def) {
    // 获取Bean实例，或被代理的原始实例:
    Object beanInstance = getProxiedInstance(def);
    try {
        injectProperties(def, def.getBeanClass(), beanInstance);
    } catch (ReflectiveOperationException e) {
        throw new BeanCreationException(e);
    }
}

getProxiedInstance()就是为了获取原始Bean：

Object getProxiedInstance(BeanDefinition def) {
    Object beanInstance = def.getInstance();
    // 如果Proxy改变了原始Bean，又希望注入到原始Bean，则由BeanPostProcessor指定原始Bean:
    List<BeanPostProcessor> reversedBeanPostProcessors = new ArrayList<>(this.beanPostProcessors);
    Collections.reverse(reversedBeanPostProcessors);
    for (BeanPostProcessor beanPostProcessor : reversedBeanPostProcessors) {
        Object restoredInstance = beanPostProcessor.postProcessOnSetProperty(beanInstance, def.getName());
        if (restoredInstance != beanInstance) {
            beanInstance = restoredInstance;
        }
    }
    return beanInstance;
}

这里我们还能处理多次代理的情况，即一个原始Bean，比如UserService，被一个事务处理的BeanPostProcsssor代理为UserServiceTx，又被一个性能监控的BeanPostProcessor代理为UserServiceMetric，还原的时候，对BeanPostProcsssor做一个倒序，先还原为UserServiceTx，再还原为UserService。

测试

我们可以写一个测试来验证Bean的注入是否正确。先定义原始Bean：

@Component
public class OriginBean {
    @Value("${app.title}")
    public String name;

    @Value("${app.version}")
    public String version;

    public String getName() {
        return name;
    }
}

通过FirstProxyBeanPostProcessor代理为FirstProxyBean：

@Order(100)
@Component
public class FirstProxyBeanPostProcessor implements BeanPostProcessor {
    // 保存原始Bean:
    Map<String, Object> originBeans = new HashMap<>();

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        if (OriginBean.class.isAssignableFrom(bean.getClass())) {
            // 检测到OriginBean,创建FirstProxyBean:
            var proxy = new FirstProxyBean((OriginBean) bean);
            // 保存原始Bean:
            originBeans.put(beanName, bean);
            // 返回Proxy:
            return proxy;
        }
        return bean;
    }

    @Override
    public Object postProcessOnSetProperty(Object bean, String beanName) {
        Object origin = originBeans.get(beanName);
        if (origin != null) {
            // 存在原始Bean时,返回原始Bean:
            return origin;
        }
        return bean;
    }
}

// 代理Bean:
class FirstProxyBean extends OriginBean {
    final OriginBean target;

    public FirstProxyBean(OriginBean target) {
        this.target = target;
    }
}

通过SecondProxyBeanPostProcessor代理为SecondProxyBean：

@Order(200)
@Component
public class SecondProxyBeanPostProcessor implements BeanPostProcessor {
    // 保存原始Bean:
    Map<String, Object> originBeans = new HashMap<>();

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        if (OriginBean.class.isAssignableFrom(bean.getClass())) {
            // 检测到OriginBean,创建SecondProxyBean:
            var proxy = new SecondProxyBean((OriginBean) bean);
            // 保存原始Bean:
            originBeans.put(beanName, bean);
            // 返回Proxy:
            return proxy;
        }
        return bean;
    }

    @Override
    public Object postProcessOnSetProperty(Object bean, String beanName) {
        Object origin = originBeans.get(beanName);
        if (origin != null) {
            // 存在原始Bean时,返回原始Bean:
            return origin;
        }
        return bean;
    }
}

// 代理Bean:
class SecondProxyBean extends OriginBean {
    final OriginBean target;

    public SecondProxyBean(OriginBean target) {
        this.target = target;
    }
}

定义一个Bean，用于检测是否注入了Proxy：

@Component
public class InjectProxyOnConstructorBean {
    public final OriginBean injected;

    public InjectProxyOnConstructorBean(@Autowired OriginBean injected) {
        this.injected = injected;
    }
}

测试代码如下：

var ctx = new AnnotationConfigApplicationContext(ScanApplication.class, createPropertyResolver());

// 获取OriginBean的实例,此处获取的应该是SendProxyBeanProxy:
OriginBean proxy = ctx.getBean(OriginBean.class);
assertSame(SecondProxyBean.class, proxy.getClass());

// proxy的name和version字段并没有被注入:
assertNull(proxy.name);
assertNull(proxy.version);

// 但是调用proxy的getName()会最终调用原始Bean的getName(),从而返回正确的值:
assertEquals("Scan App", proxy.getName());

// 获取InjectProxyOnConstructorBean实例:
var inject = ctx.getBean(InjectProxyOnConstructorBean.class);
// 注入的OriginBean应该为Proxy，而且和前面返回的proxy是同一实例:
assertSame(proxy, inject.injected);

从上面的测试代码我们也能看出，对于使用Proxy模式的Bean来说，正常的方法调用对用户是透明的，但是，直接访问Bean注入的字段，如果获取的是Proxy，则字段全部为null，因为注入并没有发生在Proxy，而是原始Bean。这也是为什么当我们需要访问某个注入的Bean时，总是调用方法而不是直接访问字段：

@Component
public class MailService {
    @Autowired
    UserService userService;

    public String sendMail() {
        // 错误:不要直接访问UserService的字段,因为如果UserService被代理,则返回null:
        ZoneId zoneId = userService.zoneId;
        // 正确:通过方法访问UserService的字段,无论是否被代理,返回值均是正确的:
        ZoneId zoneId = userService.getZoneId();
        ...
    }
}

可以从GitHub或Gitee下载源码。

GitHub

初始化Bean

完成IoC容器

Comments

Loading comments...

手写Spring

实现BeanPostProcessor

测试

Comments