springMvc 启动过程

转载自https://www.jianshu.com/p/dc64d02e49ac

 

 

 

这里给出一个简洁的文字描述版SpringMVC启动过程:

tomcat web容器启动时会去读取web.xml这样的部署描述文件，相关组件启动顺序为: 解析<context-param> => 解析<listener> => 解析<filter> => 解析<servlet>，具体初始化过程如下:

• 1、解析<context-param>里的键值对。

• 2、创建一个application内置对象即ServletContext，servlet上下文，用于全局共享。

• 3、将<context-param>的键值对放入ServletContext即application中，Web应用内全局共享。

• 4、读取<listener>标签创建监听器，一般会使用ContextLoaderListener类，如果使用了ContextLoaderListener类，Spring就会创建一个WebApplicationContext类的对象，WebApplicationContext类就是IoC容器，ContextLoaderListener类创建的IoC容器是根IoC容器为全局性的，并将其放置在appication中，作为应用内全局共享，键名为WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE

• 5、listener创建完成后如果有<filter>则会去创建filter。
• 6、初始化创建<servlet>，一般使用DispatchServlet类。
• 7、DispatchServlet的父类FrameworkServlet会重写其父类的initServletBean方法，并调用initWebApplicationContext()以及onRefresh()方法。
• 8、initWebApplicationContext()方法会创建一个当前servlet的一个IoC子容器，如果存在上述的全局WebApplicationContext则将其设置为父容器，如果不存在上述全局的则父容器为null。
• 9、读取<servlet>标签的<init-param>配置的xml文件并加载相关Bean。
• 10、onRefresh()方法创建Web应用相关组件。

 

三、spring上下文容器配置后，初始化了什么？

　　既然，ServletContext是由Servlet容器初始化的，那spring的ContextLoaderListener又做了什么初始化呢？

        1、servlet容器启动，为应用创建一个“全局上下文环境”：ServletContext

        2、容器调用web.xml中配置的contextLoaderListener，初始化WebApplicationContext上下文环境（即IOC容器），加载context-param指定的配置文件信息到IOC容器中。WebApplicationContext在ServletContext中以键值对的形式保存

        3、容器初始化web.xml中配置的servlet，为其初始化自己的上下文信息servletContext，并加载其设置的配置信息到该上下文中。将WebApplicationContext设置为它的父容器。

        4、此后的所有servlet的初始化都按照3步中方式创建，初始化自己的上下文环境，将WebApplicationContext设置为自己的父上下文环境。

 

 

       对于作用范围而言，在DispatcherServlet中可以引用由ContextLoaderListener所创建的ApplicationContext中的内容，而反过来不行。

       当Spring在执行ApplicationContext的getBean时，如果在自己context中找不到对应的bean，则会在父ApplicationContext中去找。这也解释了为什么我们可以在DispatcherServlet中获取到由ContextLoaderListener对应的ApplicationContext中的bean。

 

 四、spring配置时：<context:exclude-filter>的使用原因，为什么在applicationContext.xml中排除controller，而在spring-mvc.xml中incloud这个controller

    既然知道了spring的启动流程，那么web容器初始化webApplicationContext时作为公共的上下文环境，只需要将service、dao等的配置信息在这里加载，而servlet自己的上下文环境信息不需要加载。故，在applicationContext.xml中将@Controller注释的组件排除在外，而在dispatcherServlet加载的配置文件中将@Controller注释的组件加载进来，方便dispatcherServlet进行控制和查找。故，配置如下：

 

applicationContext.mxl中：

 <context:component-scan base-package="com.linkage.edumanage">

      <context:exclude-filter expression="org.springframework.stereotype.Controller"    type="annotation" /> 

 </context:component-scan>

 

spring-mvc.xml中：

  <context:component-scan base-package="com.brolanda.cloud"   use-default-filters="false"> 

      <context:include-filter expression="org.springframework.stereotype.Controller"    type="annotation" /> 

 </context:component-scan>

 

 

谈谈springmvc的优化

　　上面我们已经对springmvc的工作原理和源码进行了分析,在这个过程发现了几个优化点:

　　1.controller如果能保持单例,尽量使用单例,这样可以减少创建对象和回收对象的开销.也就是说,如果controller的类变量和实例变量可以以方法形参声明的尽量以方法的形参声明,不要以类变量和实例变量声明,这样可以避免线程安全问题.

　　2.处理request的方法中的形参务必加上@RequestParam注解,这样可以避免springmvc使用asm框架读取class文件获取方法参数名的过程.即便springmvc对读取出的方法参数名进行了缓存,如果不要读取class文件当然是更加好.

　　3.阅读源码的过程中,发现springmvc并没有对处理url的方法进行缓存,也就是说每次都要根据请求url去匹配controller中的方法url,如果把url和method的关系缓存起来,会不会带来性能上的提升呢?有点恶心的是,负责解析url和method对应关系的ServletHandlerMethodResolver是一个private的内部类,不能直接继承该类增强代码,必须要该代码后重新编译.当然,如果缓存起来,必须要考虑缓存的线程安全问题.