spring中bean实例化时机以及整个运转方式

接上一篇文章,一般在servlet获取到请求之后 在service方法中就可以完成所有的请求处理以及返回,但是我们会采用更高级的MVC框架来做。也就是说所有的MVC框架入口就是serlvet中的service方法。

springmvc中的bean实例化:

 

spring中bean默认是sinleton的,延迟加载为false 。即 
如果想要一个类延迟实例化,那么将其的lazy-init=”true”或改变其 scope(类的管理方式)。

spring在服务器启动时就将所有的 singleton 的 bean提前实例化,这个应该是 在web.xml中配置的 ContextLoaderListener做的。

这里写图片描述

在ssh框架下,新建了3个类,UserDaoImpl,UserServiceImpl,UserAction,他们的空参构造方法中都写了一句话表示本类被初始化了。 
测试如下,启动服务器,三句话都被打印出来了,说明这三个bean在服务器启动的时候都被初始化了。 
这里写图片描述

如果使用单例singleton来管理action的话,如下图,两次调用的是同一个UserAction实例的save()方法 
这里写图片描述

但是因为struts2的action是不是单例的,线程安全的,效率比较低。 
修改UserAction的scop为prototype原型,启动服务器,发现UserAction是没有被初始化的。 
这里写图片描述

再次两次访问save方法。发现使用了prototype之后,生成两个UserAction实例 
这里写图片描述

继续修改代码,将UserService的lazy-init设置为ture。如下图,可以发现,现在只有UserDaoImpl被初始化了 
这里写图片描述

修改了一下UserAction,在其中调用了UserService的save方法。此时访问save()方法,可以发现UserServiceImpl被初始化了。 
spring文档:需要说明的是,如果一个bean被设置为延迟初始化,而另一个非延迟初始化的singleton bean依赖于它,那么当ApplicationContext提前实例化singleton bean时,它必须也确保所有上述singleton 依赖bean也被预先初始化,当然也包括设置为延迟实例化的bean。因此,如果Ioc容器在启动的时候创建了那些设置为延迟实例化的bean的实例,你也不要觉得奇怪,因为那些延迟初始化的bean可能在配置的某个地方被注入到了一个非延迟初始化singleton bean里面。 
这里写图片描述

总结 
spring管理的bean在默认情况下是会在服务器启动的时候初始化的。 
bean设置了scope为prototype(原型)之后,会每次使用时生产一个 
bean设置了lazy-init=”true”后,启动服务器不会马上实例化,而是在用到的时候被实例化。

SpringMVC核心处理流程:

1、DispatcherServlet前端控制器接收发过来的请求,交给HandlerMapping处理器映射器

2、HandlerMapping处理器映射器,根据请求路径找到相应的HandlerAdapter处理器适配器(处理器适配器就是那些拦截器或Controller)

3、HandlerAdapter处理器适配器,处理一些功能请求,返回一个ModelAndView对象(包括模型数据、逻辑视图名)

4、ViewResolver视图解析器,先根据ModelAndView中设置的View解析具体视图

5、然后再将Model模型中的数据渲染到View上

这些过程都是以DispatcherServlet为中轴线进行的。

 

posted @ 2017-05-27 14:12  hadoop_dev  阅读(3604)  评论(1编辑  收藏  举报