SPRING BOOT 注解之OBJECTPROVIDER源码追踪

最近依旧在学习阅读Spring Boot的源代码,在此过程中涉及到很多在日常项目中比较少见的功能特性,对此深入研究一下,也挺有意思,这也是阅读源码的魅力之一。这里写成文章,分享给大家。

自动配置中的ObjectProvider

在阅读Spring Boot自动配置源码中关于redis的配置时,看到这样如下的自动配置配置源代码。

    /**
     * Redis connection configuration.
     */
    @Configuration
    @ConditionalOnClass(GenericObjectPool.class)
    protected static class RedisConnectionConfiguration {

        private final RedisProperties properties;

        private final RedisSentinelConfiguration sentinelConfiguration;

        private final RedisClusterConfiguration clusterConfiguration;

        public RedisConnectionConfiguration(RedisProperties properties,
                ObjectProvider<RedisSentinelConfiguration> sentinelConfiguration,
                ObjectProvider<RedisClusterConfiguration> clusterConfiguration) {
            this.properties = properties;
            this.sentinelConfiguration = sentinelConfiguration.getIfAvailable();
            this.clusterConfiguration = clusterConfiguration.getIfAvailable();
        }

 和

//源自org.springframework.boot.autoconfigure.web.WebClientAutoConfiguration
@Configuration
@AutoConfigureAfter(HttpMessageConvertersAutoConfiguration.class)
public class WebClientAutoConfiguration {
 
    @Configuration
    @ConditionalOnClass(RestTemplate.class)
    public static class RestTemplateConfiguration {
 
        private final ObjectProvider<HttpMessageConverters> messageConverters;
 
        private final ObjectProvider<List<RestTemplateCustomizer>> restTemplateCustomizers;
 
        public RestTemplateConfiguration(
                ObjectProvider<HttpMessageConverters> messageConverters,
                ObjectProvider<List<RestTemplateCustomizer>> restTemplateCustomizers) {
            this.messageConverters = messageConverters;
            this.restTemplateCustomizers = restTemplateCustomizers;
        }
.....

 

这就是一个常规的基于Java的配置类,那么你是否发现它在用法与其他的有所不同?是的,那就是三个ObjectProvider的参数。这也是本文要讲的内容。

Spring的注入

在介绍ObjectProvider的使用之前,我们先来回顾一下注入相关的知识。

在Spring的使用过程中,我们可以通过多种形式将一个类注入到另外一个类当中,比如通过@Autowired和@Resources注解。

而@Autowired又可以注解在不同的地方来达到注入的效果,比如注解在构造函数上:

@Service
public class FooService {
    private final FooRepository repository;
    @Autowired
    public FooService(FooRepository repository) {
        this.repository = repository
    }
}

注解在属性上:

@Service
public class FooService {
    @Autowired
    private final FooRepository repository;
}

注解在setter方法上:

@Service
public class FooService {
    private final FooRepository repository;
    @Autowired
    public void setFooRepository(FooRepository repository) {
        this.repository = repository
    }
}

spring4.3新特性--构造函数隐式注入

上面是最常见的注入方式,如果忘记写@Autowired注解,那么在启动的时候就会抛出异常。

但在spring 4.3之后,引入了一个新特性:当构造方法的参数为单个构造参数时,可以不使用@Autowired进行注解。

因此,上面的代码可变为如下形式:

@Service
public class FooService {
    private final FooRepository repository;
    public FooService(FooRepository repository) {
        this.repository = repository
    }
}

同样,您可能已经注意到@Configuration类历史上不支持构造函数注入。它们现在从4.3开始,它们显然也允许在单构造函数场景中省略@Autowired。使用此种形式便会显得优雅一些。该特性,在Spring Boot的自动配置类中大量被使用但是隐式注入也不是完美的,个人理解不完美是它是强依赖,如果这个依赖不存在,就会发生这样的悲剧:

Parameter 0 of constructor in com.example.demo.FooRepository required a bean of type 'com.example.demo.OrderServiceV2' that could not be found.

怎么破?接下来就是今天的主角:ObjectProvider

依赖关系的改进版编程

Spring Framework 4.3版本中,

  1. 隐式的注入了单构造参数的属性
  2. 还引入了ObjectProvider接口

ObjectProvider的使用场景:

  1. @Autowire注解可以用于字段,setter,构造函数
  2. 但是构造函数有多个参数的时候,@Autowire就不知道怎么办了。
  3. Spring 4.x 以后,如果构造方法的参数只有一个,那么会自动加入@autowire进行依赖注入
  4. 同时,针对多个参数的情况,可以只用ObjectProvider进行包裹,在构造函数中,由编码的方式进行延迟调用

引入了ObjectProvider,它是现有ObjectFactory接口的扩展,具有方便的签名,例如getIfAvailable和getIfUnique,只有在它实际存在时才检索bean(可选支持)或者如果可以确定单个候选者(特别是:主要候选者)在多个匹配的bean的情况下)。使用ObjectProvider之后,上面的代码便变为如下方式:

@Service
public class FooService {
    private final FooRepository repository;
    public FooService(ObjectProvider<FooRepository> repositoryProvider) {
        this.repository = repositoryProvider.getIfUnique();
    }
}

 

这样的好处很显然,当容器中不存在FooRepository或存在多个时,可以从容处理。但坏处也很明显,如果FooRepository不能为null,则可能将异常从启动阶段转移到业务运行阶段。

ObjectProvider

ObjectProvider接口是ObjectFactory接口的扩展,专门为注入点设计的,可以让注入变得更加宽松和更具有可选项。

那么什么时候使用ObjectProvider接口?

如果待注入参数的Bean为空或有多个时,便是ObjectProvider发挥作用的时候了。

如果注入实例为空时,使用ObjectProvider则避免了强依赖导致的依赖对象不存在异常;如果有多个实例,ObjectProvider的方法会根据Bean实现的Ordered接口或@Order注解指定的先后顺序获取一个Bean。从而了提供了一个更加宽松的依赖注入方式。

Spring 5.1之后提供了基于Stream的orderedStream方法来获取有序的Stream的方法。

ObjectProvider源码

ObjectProvider接口是ObjectFactory接口的扩展,先看ObjectFactory接口源码:

public interface ObjectFactory<T> {

    /**
     * Return an instance (possibly shared or independent)
     * of the object managed by this factory.
     * @return an instance of the bean (should never be {@code null})
     * @throws BeansException in case of creation errors
     */
    T getObject() throws BeansException;

}

 

 

ObjectProvider的源码及解析如下:

@since 4.3
public
interface ObjectProvider<T> extends ObjectFactory<T>, Iterable<T> { // 返回指定类型的bean, 如果容器中不存在, 抛出NoSuchBeanDefinitionException异常 // 如果容器中有多个此类型的bean, 抛出NoUniqueBeanDefinitionException异常 T getObject(Object... args) throws BeansException; // 如果指定类型的bean注册到容器中, 返回 bean 实例, 否则返回 null @Nullable T getIfAvailable() throws BeansException; // 如果返回对象不存在,则进行回调,回调对象由Supplier传入 default T getIfAvailable(Supplier<T> defaultSupplier) throws BeansException { T dependency = getIfAvailable(); return (dependency != null ? dependency : defaultSupplier.get()); } // 消费对象的一个实例(可能是共享的或独立的),如果存在通过Consumer回调消耗目标对象。 default void ifAvailable(Consumer<T> dependencyConsumer) throws BeansException { T dependency = getIfAvailable(); if (dependency != null) { dependencyConsumer.accept(dependency); } } // 如果不可用或不唯一(没有指定primary)则返回null。否则,返回对象。 @Nullable T getIfUnique() throws BeansException; // 如果存在唯一对象,则调用Supplier的回调函数 default T getIfUnique(Supplier<T> defaultSupplier) throws BeansException { T dependency = getIfUnique(); return (dependency != null ? dependency : defaultSupplier.get()); } // 如果存在唯一对象,则消耗掉该对象 default void ifUnique(Consumer<T> dependencyConsumer) throws BeansException { T dependency = getIfUnique(); if (dependency != null) { dependencyConsumer.accept(dependency); } } // 返回符合条件的对象的Iterator,没有特殊顺序保证(一般为注册顺序) @Override default Iterator<T> iterator() { return stream().iterator(); } // 返回符合条件对象的连续的Stream,没有特殊顺序保证(一般为注册顺序) default Stream<T> stream() { throw new UnsupportedOperationException("Multi element access not supported"); } // 返回符合条件对象的连续的Stream。在标注Spring应用上下文中采用@Order注解或实现Order接口的顺序 default Stream<T> orderedStream() { throw new UnsupportedOperationException("Ordered element access not supported"); } }

@since 4.3 :也就是说它是spring 4.3版本才有的新东西。属于ObjectFactory的变体,ObjectFactory接口的扩展,专门为注入点设计的,可以让注入变得更加宽松和更具有可选项。

其中,在BeanFactory中也使用了该接口来定义方法的返回值:

public interface BeanFactory {

    <T> ObjectProvider<T> getBeanProvider(Class<T> requiredType);
    <T> ObjectProvider<T> getBeanProvider(ResolvableType requiredType);
    ...
}

看ObjectProvider的继承关系,只有一个DependencyObjectProvider,它的核心源码在DefaultListableBeanFactory中,跟进去查看源码:

/**
     * Serializable ObjectFactory/ObjectProvider for lazy resolution of a dependency.
     */
    private class DependencyObjectProvider implements ObjectProvider<Object>, Serializable {

        private final DependencyDescriptor descriptor;

        private final boolean optional;

        private final String beanName;

        public DependencyObjectProvider(DependencyDescriptor descriptor, String beanName) {
            this.descriptor = new NestedDependencyDescriptor(descriptor);
            this.optional = (this.descriptor.getDependencyType() == javaUtilOptionalClass);
            this.beanName = beanName;
        }

        @Override
        public Object getObject() throws BeansException {
            if (this.optional) {
                return new OptionalDependencyFactory().createOptionalDependency(this.descriptor, this.beanName);
            }
            else {
                return doResolveDependency(this.descriptor, this.beanName, null, null);
            }
        }

        @Override
        public Object getObject(final Object... args) throws BeansException {
            if (this.optional) {
                return new OptionalDependencyFactory().createOptionalDependency(this.descriptor, this.beanName, args);
            }
            else {
                DependencyDescriptor descriptorToUse = new DependencyDescriptor(descriptor) {
                    @Override
                    public Object resolveCandidate(String beanName, Class<?> requiredType, BeanFactory beanFactory) {
                        return ((AbstractBeanFactory) beanFactory).getBean(beanName, requiredType, args);
                    }
                };
                return doResolveDependency(descriptorToUse, this.beanName, null, null);
            }
        }

        @Override
        public Object getIfAvailable() throws BeansException {
            if (this.optional) {
                return new OptionalDependencyFactory().createOptionalDependency(this.descriptor, this.beanName);
            }
            else {
                DependencyDescriptor descriptorToUse = new DependencyDescriptor(descriptor) {
                    @Override
                    public boolean isRequired() {
                        return false;
                    }
                };
                return doResolveDependency(descriptorToUse, this.beanName, null, null);
            }
        }

        @Override
        public Object getIfUnique() throws BeansException {
            DependencyDescriptor descriptorToUse = new DependencyDescriptor(descriptor) {
                @Override
                public boolean isRequired() {
                    return false;
                }
                @Override
                public Object resolveNotUnique(Class<?> type, Map<String, Object> matchingBeans) {
                    return null;
                }
            };
            if (this.optional) {
                return new OptionalDependencyFactory().createOptionalDependency(descriptorToUse, this.beanName);
            }
            else {
                return doResolveDependency(descriptorToUse, this.beanName, null, null);
            }
        }
    }

大概了解了起使用场景,他的解释:
Serializable ObjectFactory/ObjectProvider for lazy resolution of a dependency.他的大概意图就是用于延迟延迟加载使用。在查看很多Spring的代码时候,用处大多数是用于在构造方法上进行使用

Spring使用的代码段,
DefaultListableBeanFactory

@Override
    public Object resolveDependency(DependencyDescriptor descriptor, String requestingBeanName,
        Set<String> autowiredBeanNames, TypeConverter typeConverter) throws BeansException {

    descriptor.initParameterNameDiscovery(getParameterNameDiscoverer());
    if (javaUtilOptionalClass == descriptor.getDependencyType()) {
        return new OptionalDependencyFactory().createOptionalDependency(descriptor, requestingBeanName);
    }
    else if (ObjectFactory.class == descriptor.getDependencyType() ||
            ObjectProvider.class == descriptor.getDependencyType()) {
        return new DependencyObjectProvider(descriptor, requestingBeanName);
    }

使用场景:

@Service
public class FooService {
    private final FooRepository repository;
    public FooService(ObjectProvider<FooRepository> repositoryProvider) {
        this.repository = repositoryProvider.getIfUnique();
    }
}

其实深入观察,它实际上调用了的就是DefaultListableBeanFactory去解析依赖的Bean。

至此,关于ObjectProvider的使用和源码解析完成。

原文链接:《SPRING BOOT 注解之OBJECTPROVIDER源码追踪

 

posted on 2020-09-23 11:08  duanxz  阅读(791)  评论(0编辑  收藏  举报