作为使用Spring Boot框架的开发者来讲，如果你连如下的这些注解你都没有听说过，没有用过，那我劝你还是放弃吧？

在Spring Boot中我们最常见到的注解应该是条件注解了吧！也就是@ConditionalXXX的注解。例如在我们自动配置类上经常会看到@ConditionalOnMissingBean，表示在容器中不存在这样一个Bean注入的时候才会生效。

在Spring Boot的框架中使用了大量的这样的条件注解来实现根据不同的应用场景加载不同的配置项的逻辑，那么接下来我们就来看看在Spring Boot中都有那些值得我们学习和了解的注解呢？

@Conditional

@Conditional注解是从Spring 4.0版本之后出现的注解，可以标注在任何的类型或者方法上面，通过这个注解来实现一些条件的判断，当满足了对应的条件之后标注了该注解的类或者方法才会被注入到容器中。

在Spring 或者是SpringBoot中@Conditional注解被大量的使用，例如在控制某个JavaBean对象是否要被注入到容器中的时候，需要采用不同的条件判断来实现。例如前面提到的@ConditionalOnMissingBean、@ConditionalOnBean等等。

而@Conditional源码相对来说比较简单，如下所示。

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Conditional {

	/**
	 * All {@link Condition} classes that must {@linkplain Condition#matches match}
	 * in order for the component to be registered.
	 */
	Class<? extends Condition>[] value();

}

在注解中有一个属性value，可以是一个也可以是多个，而对于这个注解的判断则是由Condition接口实现来进行判断，代码如下

@FunctionalInterface
public interface Condition {

	boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);

}

Condition接口

在@Conditional注解判断中，条件是否城里取决于在value中指定的类对象是否是Condition接口的实现，在Condition接口中有一个matches()的方法，如果这个方法返回值为ture的时候则表示判断的条件城里，否则就表示判断条件不成立，也就不能往容器中进行注入操作。其中matches()方法有两个参数分别表示如下的含义

• ConditionContext ：表示要判断条件成立对应的上下文环境是什么，也就是说判断条件成立的时候需要从上下文环境中获取对应的判断条件。
• AnnotatedTypeMetadata：表示被标记了@Conditional注解的对象的所有元数据信息。用来判断是否满足注入到容器中的条件。

这其中AnnotatedTypeMetadata没有什么好说的，就是对象标注的信息，而ConditionContext则是条件判断的关键内容。下面我们就来详细分析一下。

ConditionContext接口

在上面我们提到了在Condition接口中matches()方法有两个参数一个其中一个参数就是ConditionContext。这个接口表示可以从Spring 的上下文中获取到信息。其源码如下

public interface ConditionContext {

	/**
	 * Return the {@link BeanDefinitionRegistry} that will hold the bean definition
	 * should the condition match.
	 * @throws IllegalStateException if no registry is available (which is unusual:
	 * only the case with a plain {@link ClassPathScanningCandidateComponentProvider})
	 */
	BeanDefinitionRegistry getRegistry();

	/**
	 * Return the {@link ConfigurableListableBeanFactory} that will hold the bean
	 * definition should the condition match, or {@code null} if the bean factory is
	 * not available (or not downcastable to {@code ConfigurableListableBeanFactory}).
	 */
	@Nullable
	ConfigurableListableBeanFactory getBeanFactory();

	/**
	 * Return the {@link Environment} for which the current application is running.
	 */
	Environment getEnvironment();

	/**
	 * Return the {@link ResourceLoader} currently being used.
	 */
	ResourceLoader getResourceLoader();

	/**
	 * Return the {@link ClassLoader} that should be used to load additional classes
	 * (only {@code null} if even the system ClassLoader isn't accessible).
	 * @see org.springframework.util.ClassUtils#forName(String, ClassLoader)
	 */
	@Nullable
	ClassLoader getClassLoader();

}

会看到这个接口会获取到BeanDefinitionRegistry返回的Bean的定义注册器，可以通过这个注册器获取到Bean对象定义的各种信息；
ConfigurableListableBeanFactory返回的工厂类型，这个工厂就是IOC容器；Environment返回的Spring容器对象的环境配置相关信息；ResourceLoader 返回Spring容器资源加载器；ClassLoader返回容器的类加载器信息。

从这里可以看到ConditionContext对象几乎可以获取到容器相关的所有上下文信息，也是因为有了这些信息，所以条件注入才会那么得心应手。既然这样，我们为何不尝试自定义一个条件注入呢？

如何自定义注入的Condition呢？

有这样一个比较经典的例子，就是需要我们的应用程序根据运行环境的不同来载入不同的JavaBean配置，以便适应不同的运行环境。这里我们就拿Windows运行环境和Mac运行环境来做测试，这里先不考虑其他的运行环境。

第一步定义一个Mac Linux环境的条件类

public class LinuxCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        // 首先需要获取到当前运行环境信息
        Environment environment = context.getEnvironment();
        String property = environment.getProperty("os.name");
        if (property.contains("Mac")){
            return true;
        }
        return false;
    }
}

定一个Windows的条件类

public class WindowsCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        // 首先需要获取到当前运行环境信息
        Environment environment = context.getEnvironment();
        String property = environment.getProperty("os.name");
        if (property.contains("Windows")){
            return true;
        }
        return false;
    }
}

配合一个测试的配置类，将两个环境中的数据都注入到容器中，看最终加载哪一个

@Configuration
public class SystemConfig {

    @Bean("windows")
    @Conditional(value = WindowsCondition.class)
    public OSDesc windowsosDesc(){
        OSDesc osDesc = new OSDesc();
        osDesc.setOs("Windows");
        osDesc.setCpu("4C");
        osDesc.setMemory("8G");
        return osDesc;
    }

    @Bean("linux")
    @Conditional(value = LinuxCondition.class)
    public OSDesc linuxosDesc(){
        OSDesc osDesc = new OSDesc();
        osDesc.setOs("Linux");
        osDesc.setCpu("4C");
        osDesc.setMemory("16G");
        return osDesc;
    }
}

还是采用接口触发的方式进行测试，这样更能模拟真实的环境，代码如下

@RestController
public class HelloWorldController {

    @Autowired(required = false)
    @Qualifier(value = "windows")
    private OSDesc windows;

    @Autowired(required = false)
    @Qualifier(value = "linux")
    private OSDesc linux;

    @GetMapping("/hello")
    public String hello()  {
        System.out.println(linux.getOs());
        System.out.println(windows.getOs());
        return "OK";
    }

}

调用之后，会发现如果在Mac环境下，输出的结果是Linux，如果是在Windows的环境下，输出的结果是Windows。

总结

这篇文章我们主要讲解了关于条件注解相关的内容，在下篇文章中我们来深入了解一下这个条件注解到底是在什么时候被加载，采用什么样的顺序进行加载，还有哪些我们日常开发中的注解需要我们去了解。