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

最近因为写书的事情，一段时间没有写博客了，有朋友最近问到了 spring 加载类的过程，尤其是基于 annotation 注解的加载过程，有些时候如果由于某些系统部署的问题，加载不到，很是不解！就针对这个问题，我这篇博客说说spring启动过程，用源码来说明，这部分内容也会在书中出现，只是表达方式会稍微有些区别，我将使用spring 3.0的版本来说明（虽然版本有所区别，但是变化并不是特别大），另外，这里会从WEB中使用spring开始，中途会穿插自己通过new  ClassPathXmlApplicationContext 的区别和联系。

要看这部分源码，其实在spring 3.0以上大家都一般会配置一个Servelet，如下所示：

<servlet>         <servlet-name>spring</servlet-name>         <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>         <load-on-startup>1</load-on-startup>     </servlet>

当然 servlet 的名字决定了，你自己获取 SpringContext 的方式，在前面文章：《 spring里头各种获取ApplicationContext的方法 》有详细的说明，这里就不细说了，我们就通过DispatcherServlet来说明和跟踪（注意我们这里不说请求转发，就说bean的加载过程），我们知道servlet的规范中，如果load-on-startup被设定了，那么就会被初始化的时候装载，而servlet装载时会调用其 init ()方法，那么自然是调用 DispatcherServlet 的 init 方法，通过源码一看，竟然没有，但是并不带表真的没有，你会发现在父类的父类中：org.springframework.web.servlet.HttpServletBean有这个方法，如下图所示：

public final void init() throws ServletException {   if (logger.isDebugEnabled()) {    logger.debug("Initializing servlet '" + getServletName() + "'");   }    // Set bean properties from init parameters.   try {    PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties);    BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);    ResourceLoader resourceLoader = new ServletContextResourceLoader(getServletContext());    bw.registerCustomEditor(Resource.class, new ResourceEditor(resourceLoader));    initBeanWrapper(bw);    bw.setPropertyValues(pvs, true);   }   catch (BeansException ex) {    logger.error("Failed to set bean properties on servlet '" + getServletName() + "'", ex);    throw ex;   }    // Let subclasses do whatever initialization they like.   initServletBean();    if (logger.isDebugEnabled()) {    logger.debug("Servlet '" + getServletName() + "' configured successfully");   }  }

注意代码： initServletBean(); 其余的都和加载bean关系并不是特别大，跟踪进去会发I发现这个方法是在类：org.springframework.web.servlet. FrameworkServlet 类中（是 DispatcherServlet 的父类、 HttpServletBean 的子类），内部通过调用 initWebApplicationContext ()来初始化一个 WebApplicationContext ，源码片段（篇幅所限，不拷贝所有源码，仅仅截取片段）

接下来需要知道的是如何初始化这个context的（按照使用习惯，其实只要得到了ApplicationContext，就得到了bean的信息，所以在初始化ApplicationCotext的时候，就已经初始化好了bean的信息，至少至少，它初始化好了bean的路径，以及描述信息），所以我们一旦知道 ApplicationCotext 是怎么初始化的，就基本知道 bean 是如何加载的了。

这里的parent基本不用管，因为Root的 ApplicationContext 的信息还根本没创建，所以主要是看createWebApplicationContext这个方法，进去后，该方法前面部分，都是在设置一些相关的参数，例如我们需要将WEB容器、以及容器的配置信息设置进去，然后会调用一个 refresh() 方法，这个方法表面上是用来刷新的，其实也是用来做初始化bean用的，也就是配置修改后，如果你能调用它的这个方法，就可以重新装载 spring 的信息，我们看看源码中的片段如下（同样，不相关的部分，我们就不贴太多了）：

其实这个方法，不论是通过 ClassPathXmlApplicationContext 还是WEB装载都会调用这里，我们看下 ClassPathXmlApplicationContext 中调用的部分：

他们的区别在于， web 容器中，用 servlet 装载了， servlet 中包装了一个 XmlWebApplicationContext 而已，而 ClassPathXmlApplicationContext 是直接调用的，他们共同点是，不论是 XmlWebApplicationContext 、还是 ClassPathXmlApplicationContext 都继承了类（间接继承）：

AbstractApplicationContext，这个类中的 refresh() 方法是共用的，也就是他们都调用的这个方法来加载 bean 的，在这个方法中，通过obtainFreshBeanFactory方法来构造 beanFactory 的，如下图所示：

是不是看到一层调用一层很烦人，其实回过头来想一想，它没一层都有自己的处理动作，毕竟spring不是简单的做一个bean加载，即使是这样，我们最少也需要做xml解析、类装载和实例化的过程，每个步骤可能都有很多需求，因此分离设计，使得代码更加具有扩展性，我们继续来看 obtainFreshBeanFactory 方法的描述：

这里很多人可能会不太注意 refreshBeanFactory ()这个方法，尤其是第一遍看这个代码的，如果你忽略掉，你可能会找不到bean在哪里加载的，前面提到了 refresh 其实可以用以初始化，这里也是这样， refreshBeanFactory 如果没有初始化 beanFactory 就是初始化它了，后面你看到的都是 getBeanFactory 的代码，也就是已经初始化好了，这个refreshBeanFactory方法类 AbstractRefreshableApplicationContext 中的方法，它是 AbstractApplicationContext 的子类，同样不论是 XmlWebApplicationContext 、还是 ClassPathXmlApplicationContext 都继承了它，因此都能调用到这个一样的初始化方法，来看看body部分的代码：

注意第一个红圈圈住的地方，是创建了一个beanFactory，然后下面的方法可以通过名称就能看出是“ 加载bean的定义 ”，将beanFactory传入，自然要加载到beanFactory中了，createBeanFactory就是实例化一个beanFactory没别的，我们要看的是bean在哪里加载的，现在貌似还没看到重点，继续跟踪

loadBeanDefinitions(DefaultListableBeanFactory)方法

它由 AbstractXmlApplicationContext 类中的方法实现，web项目中将会由类： XmlWebApplicationContext 来实现，其实差不多，主要是看启动文件是在那里而已，如果在非web类项目中没有自定义的XmlApplicationContext，那么其实功能可以参考 XmlWebApplicationContext ，可以认为是一样的功能。那么看看loadBeanDefinitions方法如下：

这里有一个XmlBeanDefineitionReader，是读取XML中spring的相关信息（也就是解析SpringContext.xml的），这里通过 getConfigLocations() 获取到的就是这个或多个文件的路径，会循环，通过 XmlBeanDefineitionReader 来解析，跟踪到loadBeanDefinitions方法里面，会发现方法实现体在XmlBeanDefineitionReader的父类：AbstractBeanDefinitionReader中，代码如下：

这里大家会疑惑，为啥里面还有一个 loadBeanDefinitions ，大家要知道，我们目前只解析到我们的springContext.xml在哪里，但是还没解析到springContext.xml的内容是什么，可能有多个spring的配置文件，这里会出现多个Resource，所以是一个数组（这里如何通过location找到文件部分，在我们找class的时候自然明了，大家先不纠结这个问题）。

接下来有很多层调用，会以此调用：

AbstractBeanDefinitionReader.loadBeanDefinitions(Resources []) 循环Resource数组，调用方法：

XmlBeanDefinitionReader.loadBeanDefinitions(Resource ) 和上面这个类是父子关系，接下来会做： doLoadBeanDefinitions、registerBeanDefinitions 的操作，在注册beanDefinitions的时候，其实就是要真正开始解析XML了

它调用了 DefaultBeanDefinitionDocumentReader 类的registerBeanDefinitions方法，如下图所示：

中间有解析XML的过程，但是貌似我们不是很关心，我们就关系类是怎么加载的，虽然已经到XML解析部分了，所以主要看parseBeanDefinitions这个方法，里面会调用到BeanDefinitionParserDelegate类的parseCustomElement方法，用来解析bean的信息：

这里解析了XML的信息，跟踪进去，会发现用了 NamespaceHandlerSupport 的parse方法，它会根据节点的类型，找到一种合适的解析 BeanDefinitionParser（接口） ，他们预先被spring注册好了，放在一个HashMap中，例如我们在spring 的annotation扫描中，通常会配置：

<context:component-scan base-package="com.xxx" />

此时根据名称“ 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发神经，我回复的内容提示我链接过多，其实一个链接都没有，神奇，所以回复在正文）】：

此时类还没有被装载，Resource中仅仅是类的目录信息，Spring也没有通过ClassLoader将类加载后通过反射读取类的Annotation信息（这条路也是通的），而是通过自己的asm对类的class字节码的解析来完成的，这部分是字节码相关的知识，在我的书中和其它博客有所介绍。spring我想这样做的目的是方便自己做AOP相关的字节码增强一带搞定，也不会多加载不需要的类，因为本文提到的访问如果写了目录，可以访问到jar包中的内容，可能类信息会比较多。