往期文章

• 用最简单的话讲最明白的红黑树
• java源码阅读 - HashMap
• 数据结构 - 堆与堆排序

  目录

  文章目录

  • 往期文章
  • 目录
  • 前言
  • 介绍
  • 正文
  • OnClassCondition类
  • 调用场景

    前言

    用过springboot的小伙伴们都知道，相比于spring，它最大的优势是帮我们省去了一大堆超大一堆繁琐的配置。比如在spring中，当我们需要在项目中整合第三方插件(如redis、mybatis、rabbitmq)时，往往需要在xml配置文件中去配置这些插件的ConnectionFactory等将其与spring进行整合。而在springboot中，他会根据项目中引入哪些插件自动地将插件进行整合，这都得益于springboot的自动装配 或称为 自动配置。

    那么springboot是如何知道我们项目中引入了哪些插件，又怎么知道需要帮助我们配置哪些插件呢？

    介绍

    所谓@ConditionalOnClass注解，翻译过来就是基于class的条件，它为所标注的类或方法添加限制条件，当该条件的值为true时，其所标注的类或方法才能生效。基于class的意思是在类路径classpath中存在value()属性指定的类或存在name()属性指定的类名。

    为了让上面的介绍更加容易理解，我们就举个例子吧

    • 在rabbitmq的自动配置类RabbitAutoConfiguration中，有一行注解为@ConditionalOnClass({ RabbitTemplate.class, Channel.class })，则表示当类路径classpath中存在 RabbitTemplate 和 Channel这两个类时，该条件注解才会通过，rabbitmq的自动配置RabbitAutoConfiguration才会生效。如下图所示。由于我项目中已经引入了rabbitmq的依赖，该依赖中存在着两个类，因此该条件是通过的。

      

      • 在redis的自动配置类RedisAutoConfiguration中，有一行注解为@ConditionalOnClass(RedisOperations.class)，则表示当类路径classpath中存在 RedisOperations 这个类时，该条件注解才会通过，redis的自动配置RedisAutoConfiguration才会生效。如下图所示。由于我项目中没有引入redis的依赖，类路径classpath中不存在RedisOperations，因此该条件是不通过的，从代码爆红即可得知。

        

        正文

        是否觉得这个注解如此流批？今天我们从源码扒开它神秘的面纱。

        先看一下该注解的源码，该注解只提供给我们两个属性，实现条件的逻辑在哪呢？

        @Target({ ElementType.TYPE, ElementType.METHOD })
        @Retention(RetentionPolicy.RUNTIME)
        @Documented
        @Conditional(OnClassCondition.class)
        public @interface ConditionalOnClass {
            // The classes that must be present.
        	Class[] value() default {};
            // The classes names that must be present.
        	String[] name() default {};
        }
        

        我们应当注意到该注解上还有另一个注解@Conditional(OnClassCondition.class)，它才是@ConditionalOnClass注解的核心所在。

        那么我们就看一下@Conditional()注解的源码。该注解通过value()属性接收一个Condition数组的参数。

        @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[] value();
        }
        

        那么Condition又是什么？继续看源码。从源码中我们知道，Condition是一个接口，其内部声明一个方法matches()，且返回boolean类型的值。

        @FunctionalInterface
        public interface Condition {
            /**
             * 决定条件是否通过
             * @param context - 条件上下文
             * @param metadata - 元数据，里面标注该注解的类或方法
             * @return true-通过，false-不通过
             **/
           boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
        }
        

        至此，通过两个注解 + 一个接口，我们可以对@ConditionalOnClass注解得出以下结论：

        @Conditional注解接收Condition类型的参数，通过其matches()方法的返回值判断条件是否通过，而在@ConditionalOnClass注解上向@Conditional注解传入的实际类型为Condition的实现类OnClassCondition。

        现在，我们只需要把目光转移到Condition接口的实现类OnClassCondition上面来。

        OnClassCondition类

        OnClassCondition类表示为基于classpath类路径下的条件，因此它在对条件进行判断时，都是从classpath类路径中进行判断的。这一点从命名上可以看出。 先看一下该类的UML图吧，对源码的阅读有所帮助。

        

        从图中我们看到，中间两个类SpringBootCondition 和 FilteringSpringBootCondition均为抽象类，而OnClassCondition为具体实现类，因此我们猜测这里定有模版方法的设计模式，这使代码读起来可能有点跳来跳去。

        那么我们看一下OnClassCondition是如何实现接口Condition的matches()方法的。但是找来找去并为找到matches()方法，其实该方法是在其父类SpringBootCondition中实现的。

        public abstract class SpringBootCondition implements Condition {
        	private final Log logger = LogFactory.getLog(getClass());
            /**
             * matches()方法的实现————决定条件是否通过
             * @param context - 条件上下文
             * @param metadata - 元数据，里面标注该注解的类或方法
             * @return true-通过，false-不通过
             **/
        	@Override
        	public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
                // 获取方法名或类名
        		String classOrMethodName = getClassOrMethodName(metadata);
        		try {
                    // 对元数据进行判断，看是否符合要求。
                    // ConditionOutcome中封装了判断的结果和相应的结果信息，
        			ConditionOutcome outcome = getMatchOutcome(context, metadata);
                    // 日志，
        			logOutcome(classOrMethodName, outcome);
                    // 记录
        			recordEvaluation(context, classOrMethodName, outcome);
                    // 如果isMatch()的值为true，则表示条件通过
        			return outcome.isMatch();
        		}
        		catch (NoClassDefFoundError ex) {
        			// 抛出IllegalStateException异常
        		}
        		catch (RuntimeException ex) {
        			// 抛出IllegalStateException异常
        		}
        	}
            
            public abstract ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata);
        }
        

        从SpringBootCondition抽象类中实现的matches()方法来看，它只是提供了一个模版，而真正对条件进行判断的逻辑在其抽象方法getMatchOutcome()中，OnClassCondition类对该抽象方法提供了实现。这就是设计模式—模版方法的体现。

        class OnClassCondition extends FilteringSpringBootCondition {
            
            // 该方法分三部分
            // 1. 处理ConditionalOnClass注解
            // 2. 处理ConditionalOnMissingClass注解
            // 3. 返回条件判断的结果
            @Override
        	public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
        		ClassLoader classLoader = context.getClassLoader();
                // 通过静态方法，创建一个ConditionMessage实例，用来保存条件判断结果对应的信息
        		ConditionMessage matchMessage = ConditionMessage.empty();
                
                // 1. 处理ConditionalOnClass注解
                // 获取该元数据表示的类或方法上的ConditionalOnClass注解中标注的类的限定名，
                // 表示这些类应当在classpath类路径中存在，所以叫onClass
                // 例如：@ConditionalOnClass({ RabbitTemplate.class, Channel.class })，
                //      则返回RabbitTemplate和Channel的全限定类名
        		List onClasses = getCandidates(metadata, ConditionalOnClass.class);
        		if (onClasses != null) {
                    // filter()方法内部 对onClass表示的类进行反射，条件为MISSING，
                    // 如果得到的集合不为空，则说明类路径中不存在ConditionalOnClass注解中标注的类
                    // 这种情况下直接通过ConditionOutcome.noMatch()封装ConditionOutcome条件判断的结果并返回，noMatch()即表示不通过。
        			List missing = filter(onClasses, ClassNameFilter.MISSING, classLoader);
        			if (!missing.isEmpty()) {
        				return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class)
        						.didNotFind("required class", "required classes").items(Style.QUOTE, missing));
        			}
                    
                    // 对ConditionalOnClass注解的条件判断通过，并保存对应的信息到matchMessage
        			matchMessage = matchMessage.andCondition(ConditionalOnClass.class)
        					.found("required class", "required classes")
        					.items(Style.QUOTE, filter(onClasses, ClassNameFilter.PRESENT, classLoader));
        		}
                
                // 2. 处理ConditionalOnMissingClass注解
                // 获取该元数据表示的类或方法上的ConditionalOnMissingClass注解中标注的类的限定名，
                // 表示这些类应当在classpath类路径中不存在，所以叫onMissingClass
                // 例如：@ConditionalOnMissingClass({ RabbitTemplate.class, Channel.class })，
                //      则返回RabbitTemplate和Channel的全限定类名
        		List onMissingClasses = getCandidates(metadata, ConditionalOnMissingClass.class);
        		if (onMissingClasses != null) {
                    // filter()方法内部 对onMissingClasses表示的类进行反射，条件为PRESENT，
                    // 如果得到的集合不为空，则说明类路径中存在ConditionalOnMissingClass注解中标注的类
                    // 这种情况下直接通过ConditionOutcome.noMatch()封装ConditionOutcome条件判断的结果并返回，noMatch()即表示不通过。
        			List present = filter(onMissingClasses, ClassNameFilter.PRESENT, classLoader);
        			if (!present.isEmpty()) {
        				return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class)
        						.found("unwanted class", "unwanted classes").items(Style.QUOTE, present));
        			}
                    
                    // 对ConditionalOnMissingClass注解的条件判断通过，并保存对应的信息到matchMessage
        			matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class)
        					.didNotFind("unwanted class", "unwanted classes")
        					.items(Style.QUOTE, filter(onMissingClasses, ClassNameFilter.MISSING, classLoader));
        		}
                
                // 3. 返回条件判断的结果，到这一步，就说明ConditionalOnClass注解和ConditionalOnMissingClass注解上的条件都已经通过了。
        		return ConditionOutcome.match(matchMessage);
        	}
        }
        

        到这里，我们把抽象父类SpringBootCondition的matches()模版方法，和具体实现类OnClassCondition的getMatchOutcome()真正方法搞定后，就已经对@ConditionalOnClass和@ConditionalOnMissingClass这两个注解的实现原理搞清楚了。

        调用场景

        上面我们搞清楚@ConditionalOnClass和@ConditionalOnMissingClass这两个注解了，但他们内部的逻辑是如何调用的呢？也就是说springboot在启动过程中，如果通过这两个注解实现自动装配的呢？

        一般我们能想到的是通过AOP对这两个注解实现切面，在切面里进行装配。但其实不是的，我们继续往下看。

        要想知道matches()方法如何被调用起来，打个断点不就行了。

        如下图所示，我在OnClassCondition的getMatchOutcome()方法上打个条件断点，以rabbitmq的自动装配为例，给该断点添加条件，当方法参数metadata表示的类为RabbitAutoConfiguration时，进入断点。

        

        下面我们启动项目，当springboot要对rabbitmq进行自动装配时，我们可以看到进入断点了。

        

        那如何查看该方法是被谁调用的呢？在上面源码的解析中，我们知道该方法是被其抽象父类的模版方法matches()所调用的。那matches()方法又是谁调用的呢？这就涉及到框架源码的阅读技巧了。把目光放在idea的左下方，可以看到方法的调用栈，而栈顶就是断点的方法getMatchOutcome()，点击下面的一层就可以回到抽象父类的模版方法matches()

        

        再点击调用栈下面的一层，就可以看到调用matches()方法的地方

        

        shouldSkip()方法是springboot启动过程中重要的一环。大家都知道springboot在启动过程中会将很多类作为spring的Bean放在IOC容器中，但有些类是不需要添加到容器中的，这种情况下shouldSkip()方法就返回true表示应当跳过当前类不要把它放到IOC容器中。

        而在shouldSkip()方法中，判断当前类应当跳过的重要依据就是matches()方法返回false(即条件判断不通过)。

        springboot的启动流程以及shouldSkip()方法我们留到以后再聊。拜拜

        纸上得来终觉浅，绝知此事要躬行。

        ————————————————我是万万岁，我们下期再见————————————————

         
         哪里做网络推广  优秀网页设计作品欣赏  建站公司排名  做网站多少钱一年  企业黄页  武汉快速建站模板