Spring启动component-scan类扫描加载过程---源码分析

来自ling
跳转至: 导航搜索

http://www.tuicool.com/articles/FNBVzmq


此时根据名称“ component-scan ”就会找到对应的解析器来解析,而与之对应的就是 ComponentScanBeanDefinitionParser 的 parse 方法,这地方已经很明显有扫描bean的概念在里面了,这里的parse获取到后,中间有一个非常非常关键的步骤那就是定义了 ClassPathBeanDefinitionScanner 来扫描类的信息,它扫描的是什么?是加载的类还是class文件呢?答案是后者,为何,因为有些类在初始化化时根本还没被加载,ClassLoader根本还没加载,只是ClassLoader可以找到这些class的路径而已:


注意这里的scanner创建后,最关键的是 doScan 的功能,解析XML我想来看这个的不是问题,如果还不熟悉可以先看看,那么我们得到了类似: com.xxx 这样的信息,就要开始扫描类的列表,那么再哪里扫描呢?这里的doScan返回了一个 Set<BeanDefinitionHolder> 我们感到希望就在不远处,进去看看 doScan 方法。


我们看到这么大一坨代码,其实我们目前不关心的代码,暂时可以不管,我们就看怎么扫描出来的,可以看出最关键的扫描代码是: findCandidateComponents(String basePackage) 方法,也就是通过每个 basePackage 去找到有那些类是匹配的,我们这里假如配置了 com.abc ,或配置了 * 两种情况说明。


主要看红线部分,下面非红线部分,是已经拿到了类的定义,红线部分,会组装信息,如果我们配置了 com.abc会组装为: classpath*:com/abc/**/*.class ,如果配置是 * ,那么将会被组装为 classpath*:*/**/*.class ,但是这个好像和我们用的东西不太一样,java中也没见这种URL可以获取到,spring到底是怎么搞的呢?就要看第二个红线部分的代码:

Resource[] resources = this.resourcePatternResolver.getResources(packageSearchPath); 它竟然神奇般的通过这个路径获取到了URL,你一旦跟踪你会发现,获取出来的全是.class的路径,包括jar包中的相关class路径,这里有些细节,我们先不说,先看下这个resourcePatternResolover是什么类型的,看到定义部分是:

private ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver(); 为此胖哥还将其做了一个测试,用一个简单main方法写了一段:

ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver();

Resource[] resources = resourcePatternResolver.getResources("classpath*:com/abc/**/*.class"); 获取出来的果然是那样,胖哥开始猜测,这个和ClassLoader的getResource方法有关系了,因为太类似了,我们跟踪进去看下:


这个 CLASSPATH_ALL_URL_PREFIX 就是字符串 classpath*: , 我们传递参数进来的时候,自然会走第一个红圈圈住部分的代码,但是第二个红圈圈住部分的代码是干嘛的呢,胖哥告诉你先知道有这个,然后回头会有用,继续找 findPathMatchingResources 方法,好了,越来越接近真相了。


这里有一个 rootDirPath ,这个地方有个容易出错的,是如果你配置的是 com.abc,那么 rootDirPath 部分应该是: classpath*:com/abc/ 而如果配置是 * 那么 classpath*: 只有这个结果,而不是 classpath*:* (这里我就不说截取字符串的源码了),回到上一段代码,这里再次调用了getResources(String)方法,又回到前面一个方法,这一次,依然是以classpath*:开头,所以第一层 if 语句会进去,而第二层不会,为什么?在里面的isPattern() 的实现中是这样写的:

      public boolean isPattern(String path) {  
   return (path.indexOf('*') != -1 || path.indexOf('?') != -1);  

} 在匹配前,做了一个 substring 的操作,会将“ classpath*: ”这个字符串去掉,如果是配置的是com.abc就变成了"com/abc/",而如果配置为*,那么得到的就是“” ,也就是长度为0的字符串,因此在我们的这条路上,这个方法返回的是false,就会走到代码段 findAllClassPathResources 中,这就是为什么上面提到会有用途的原因,好了,最最最最关键的地方来了哦。例如我们知道了一个com/abc/为前缀,此时要知道相关的classpath下面有哪些class是匹配的,如何做?自然用ClassLoader,我们看看Spring是不是这样做的:


果然不出所料,它也是用ClassLoader,只是它自己提供的getClassLoader()方法,也就是和spring的类使用同一个加载器范围内的,以保证可以识别到一样的classpath,自己模拟的时候,可以用一个类

类名.class.getClassLoader().getResources("")

如果放为空,那么就是获取classpath的相关的根路径(classpath可能有很多,但是根路径,可以被合并),也就是如果你配置的*,获取到的将是这个,也许你在web项目中,你会获取到项目的根路径(classes下面,以及tomcat的lib目录)。

如果写入一个: com/abc/ 那么得到的将是扫描相关classpath下面所有的class和jar包中与之匹配的类名(前缀部分)的路径信息,但是需要注意的是,如果有 两层jar包 ,而你想要扫描的类或者说想要通过spring加载的类在 第二层jar包中 ,这个方法是获取不到的,这不是spring没有去做这个事情,而是,java提供的getResources方法就是这样的,有朋友问我的时候,正好遇到了类似的事情,另外需要注意的是, getResources 这个方法是包含当前路径的一个递归文件查找(一般环境变量中都会配置 . ),所以如果是一个jar包,你要运行的话,切记放在某个根目录来跑,因为当前目录,就是根目录也会被递归下去,你的程序会被莫名奇怪地慢。

回到上面的代码中,在 findPathMatchingResources 中我们这里刚刚获取到base的路径列表,也就是所有包含类似com/abc/为前缀的路径,或classpath合并后的目录根路径;此时我们需要下面所有的class,那么就需要的是递归,这里我就不再跟踪了,大家可以自己去跟踪里面的几个方法调用: doFindPathMatchingJarResources、doFindPathMatchingFileResources 。

几乎不会用到:VfsResourceMatchingDelegate.findMatchingResources,所以主要是上面两个,分别是jar包中的和 工程里面的class,跟踪进去会发现,代码会不断递归循环调用目录路径下的class文件的路径信息,最终会拿到相关的class列表信息,但是这些class还并没有做检测是否有annotation,那是下一步做的事情,但是下一个步骤已经很简单了,因为要检测一个类的 annotation ,在前面的文章中:《 java之annotation与框架的那些秘密 》中已经提到了。

这里大家还可以通过以下简单的方式来测试调用路径的问题:

ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider(true); Set<BeanDefinition> beanDefinitions = provider.findCandidateComponents("com/abc"); for(BeanDefinition beanDefinition : beanDefinitions) {

   System.out.println(beanDefinition.getBeanClassName()   
                   + "\t" + beanDefinition.getResourceDescription()  
                   + "\t" + beanDefinition.getClass());  

} 这是直接引用spring的源码部分的内容,如果这里可以获取到, 且路径是正确 的,一般情况下,都是可以加载到类的。

看了这么多,是不是有点晕,没关系,谁第一回看都这样,当你下一次看的时候,有个思路就好了,我这里并没有像UML一样理出他们的层次关系,和调用关系,仅仅针对代码调用逐层来说明,大家如果初步看就是,由Servlet初始化来创建ApplicationContext,在设置了Servelt相关参数后,获取servlet的配置文件路径或自己指定的配置文件路径(applicationContext.xml或其他的名字,可以一个或多个),然后通过系列的XML解析,以及针对每种不同的节点类型使用不同的加载方式,其中 component-scan 用于指定扫描类的对应有一个Scanner,它会通过ClassLoader的getResources方法来获取到class的路径信息,那么class的路径都能获取到,类的什么还拿不到呢?呵呵!

好,本文基本内容就说到这里,接下来我会提到 spring MVC 的中的简单跳转的解析,其中有部分源码是这里看过的,只是还不是这里的重点而已。

而我想说的也是这点,其实本文虽然在说启动,其实有很多代码也没说,因为那样的话我就是一个复制咱贴机了;

其实看源码,要带着目的,大家要知道主体情况或实现的功能,不要就看源码而看源码,一个是根本记不下来,另一个这样看代码没有太大的意义。

当你有了疑问,遇到了难题不知道原因,或发现了新大陆,很有兴趣,那么去看看,也许看之前你会思考下如果我来实现会怎么做?再看看别人是怎么做的,有何区别,不断吸取这些开源框架中优秀的品质,包括代码的设计层次,了解它用到了什么,为何要这样设计,那么你的代码相信会越来越漂亮,你对开源界的代码也会越来越熟悉,熟悉得像自己亲人一样,呵呵。

【对于5楼的回复(CSDN发神经,我回复的内容提示我链接过多,其实一个链接都没有,神奇,所以回复在正文)】:

你能看到isCandidateComponent(MetadataReader metadataReader)方法,其实呢,你再跟下应该就有结果了!要细写可以写一篇文章,简单写下如下: 这个方法里先循环excludeFilters,再循环includeFilters,excludeFilters默认情况下没有啥内容,includeFilters默认情况下最少会有一个new AnnotationTypeFilter(Component.class); 也就是默认情况下excludeFilters排除内容不会循环,includeFilters包含内容最少会匹配到AnnotationTypeFilter,调用AnnotationTypeFilter.match方法是其父类AbstractTypeHierarchyTraversingFilter.math()方法,其内部调用matchSelf()调回子类的AnnotationTypeFilter.matchSelf()方法。该方法中用||连接两个判定分别是hasAnnotation、hasMetaAnnotation,前者判定注解名称本身是否匹配因此Component肯定能匹配上,后者会判定注解的meta注解是否包含,Service、Controller、Repository注解都注解了Component因此它们会在后者匹配上。这样match就肯定成立了。 此时类还没有被装载,Resource中仅仅是类的目录信息,Spring也没有通过ClassLoader将类加载后通过反射读取类的Annotation信息(这条路也是通的),而是通过自己的asm对类的class字节码的解析来完成的,这部分是字节码相关的知识,在我的书中和其它博客有所介绍。spring我想这样做的目的是方便自己做AOP相关的字节码增强一带搞定,也不会多加载不需要的类,因为本文提到的访问如果写了目录,可以访问到jar包中的内容,可能类信息会比较多。