spring原理

一、 IoC(Inversion of control): 控制反转 1、IoC： 概念：控制权由对象本身转向容器；由容器根据配置文件去创建实例并创建各个实例之间的依赖关系 核心：bean工厂；在Spring中，bean工厂创建的各个实例称作bean 2、bean工厂创建bean的三种方式： u 通过构造方法直接创建： < bean id =”” class =”bean class name” > u 通过静态工厂方法创建： < bean id =”” class =”factory class name” factory-method =”” > u 通过非静态工厂方法创建： < bean id =”factory” class =”factory class name” > < bean id =”” factory-bean =” factory” factory-method =”” > 3、Spring中实现IoC的方式：依赖注入（Dependency Injection） Spring中依赖注入的两种方式： u 通过setter方法注入： < property name =”” > </ property > 其中，name属性的取值依setter方法名而定 u 通过构造方法注入： < constructor-arg index =”” > </

Dubbo RPC即Remote Procedure Call，即为远程调用。这和Java的远程代理RMI有点类似，不过RMI只能在Java系统之间进行调用，并且是使用序列化对象的方式进行通信。相比之下，RPC模式的Dubbo性能更高一些，由于使用HTTP进行通信，因此可以在不同语言的服务之间进行调用。 快速入门 首先导入Spring以及Dubbo相关依赖： maven依赖 <properties> <spring.version>5.0.5.RELEASE</spring.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org

由来 如果实现类改变，需要在业务层的每个类里面修改，违背松耦合的特点。 思路一： 中间加一个工厂，工厂返回一个实现类给你，这种方法虽然业务层不用每个修改，但如果使用别的实现类，也需要指定工厂返回哪个实现类。 思路二 如果交给spring管理，配置文件里面的id名字自己取，id对应一个类的全路径，通过spring工厂根据id获得实现类的全路径，通过反射创建这个类交给你，此时，如果你的业务层需要换成别的实现类，业务层不用修改，只需要把配置文件id对应的那个类的全路径替换成你需要的类的全路径。 DI：依赖注入 给spring管理类当中的依赖的属性，通过配置文件进行赋值的过程。 传统方式：接口 变量 = new 实现类，变量.实现类当中的属性=多少，无法赋值 来源： https://www.cnblogs.com/flyduckforever/p/11532992.html

引言 Spring中提供了各种Aware接口，方便从上下文中获取当前的运行环境，比较常见的几个子接口有：BeanFactoryAware,BeanNameAware,ApplicationContextAware,EnvironmentAware，BeanClassLoaderAware等，这些Aware的作用都可以从命名得知 Aware 处理 其中 BeanNameAware 、 BeanClassLoaderAware 和 BeanFactoryAware 这三个是直接在bean的初始化之前就处理了的，具体代码在 AbstractAutowireCapableBeanFactory.initializeBean 方法中： protected Object initializeBean(String beanName, Object bean, RootBeanDefinition mbd) { // 判断对象实现的接口类型，处理特定的三种接口类型：BeanNameAware、BeanClassLoaderAware和BeanFactoryAware。 if (bean instanceof BeanNameAware) { ((BeanNameAware) bean).setBeanName(beanName); } if (bean instanceof

前言 BeanPostProcessor 接口是Spring中一个非常重要的接口，它的接口定义如下 public interface BeanPostProcessor { Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException; Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException; } 当你实现了这个接口的时候，Spring会保证在每一个bean对象初始化方法调用之前调用 postProcessBeforeInitialization 方法，在初始化方法调用之后调用 postProcessAfterInitialization BeanPostProcessor 的注册 看过我之前写的IOC源码分析系列文章的同学应该对这个都比较有印象 Spring在执行到这的时候会把所有实现 BeanPostProcessor 接口的实现类都注册到 BeanFactory 中，一起来看一下实现的细节 protected void registerBeanPostProcessors(ConfigurableListableBeanFactory

1.1 何为 EntityResolver : 官方解释: 如果ＳＡＸ应用程序叙事实现自定义处理外部实体,则必须实现此接口, 并使用setEntityResolver 方法向SAX 驱动器注册一个实例. 也就是说,对于解析一个xml,sax 首先会读取该xml文档上的声明,根据声明去寻找相应的dtd定义,以便对文档的进行验证, 默认的寻找规则,(即:通过网络,实现上就是声明DTD的地址URI地址来下载DTD声明), 并进行认证,下载的过程是一个漫长的过程,而且当网络不可用时,这里会报错,就是应为相应的dtd没找到, 1.2 EntityResolver 的作用就是项目本身就可以提供一个如何寻找DtD 的声明方法 , 即:由程序来实现寻找DTD声明的过程,比如我们将ＤＴＤ放在项目的某处在实现时直接将此文档读取并返回个SAX即可,这样就避免了通过网络来寻找DTD的声明 1.3 首先看看EntityResolver 接口声明的方法. public abstract InputSource resolveEntity (String publicId, String systemId) throws SAXException, IOException; 这里,他接收2个参数,publicId ,systemId ,并返回一个InputStream对象, 这里我们以特定的文件来讲解; 1.3

　　1.0 registerBeanDefinition 　　对于配置文件,解析也解析完了,装饰也装饰完了,对于得到的BeanDefinition已经可以满足后续的使用了,唯一剩下的工作就是注册了, 也就是: processBeanDefinition 方法中的 BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder,getReaderContext().getRegistry()); 　　代码如下: 1 /** 2 * Process the given bean element, parsing the bean definition and registering it with 3 * the registry. 4 */ 5 protected void processBeanDefinition(Element ele, 6 BeanDefinitionParserDelegate delegate) { 7 // 委托BeanDefinition类的parseBeanDefinitionElement方法进行元素解析,返回Beandefinition 8 // 类型的实例bdHolder 经过这个方法之后, 9 // bdHolder实例已经包含了我们配置文件中的各种属性了,例如 : class,name

Springmvc执行原理： 一、 入门案例的执行流程 1. 当启动Tomcat服务器的时候，因为配置了load-on-startup标签，所以会创建DispatcherServlet对象， 就会加载springmvc.xml配置文件 2. 开启了注解扫描，那么HelloController对象就会被创建 3. 从index.jsp发送请求，请求会先到达DispatcherServlet核心控制器，根据配置@RequestMapping注解 找到执行的具体方法 4. 根据执行方法的返回值，再根据配置的视图解析器，去指定的目录下查找指定名称的JSP文件 5. Tomcat服务器渲染页面，做出响应 二、 SpringMVC官方提供图形 三、 入门案例中的组件分析 1. 前端控制器（DispatcherServlet） 2. 处理器映射器（HandlerMapping） 3. 处理器（Handler） 4. 处理器适配器（HandlAdapter） 5. 视图解析器（View Resolver） 6. 视图（View） 四、RequestMapping注解 1. RequestMapping注解的作用是建立请求URL和处理方法之间的对应关系 2. RequestMapping注解可以作用在方法和类上 　　1. 作用在类上：第一级的访问目录 　　2. 作用在方法上：第二级的访问目录 　　3

Spring MVC工作流程图 图一 图二 Spring工作流程描述 1. 用户向服务器发送请求，请求被Spring 前端控制Servelt DispatcherServlet捕获； 2. DispatcherServlet对请求URL进行解析，得到请求资源标识符（URI）。然后根据该URI，调用HandlerMapping获得该Handler配置的所有相关的对象（包括Handler对象以及Handler对象对应的拦截器），最后以HandlerExecutionChain对象的形式返回； 3. DispatcherServlet 根据获得的Handler，选择一个合适的HandlerAdapter 。（ 附注 ：如果成功获得HandlerAdapter后，此时将开始执行拦截器的preHandler(...)方法 ） 4. 提取Request中的模型数据，填充Handler入参，开始执行Handler（Controller) 。 在填充Handler的入参过程中，根据你的配置，Spring将帮你做一些额外的工作： HttpMessageConveter ： 将请求消息（如Json、xml等数据）转换成一个对象，将对象转换为指定的响应信息 数据转换 ：对请求消息进行数据转换。如String转换成Integer、Double等 数据根式化 ：对请求消息进行数据格式化。

在上一篇文章 @EnableTransactionManagement注解解析 中，我们搭建了源码阅读的环境，以及解析了开启Spring事务功能的注解 @EnableTransactionManagement 的实现逻辑 在进行接下来的源码解析之前我想大家应该知道，当我们使用传统的jdbc应用事务的时候是不是做了如下操作： 开启事务 save、update、delete等操作 出现异常进行回滚 正常情况提交事务 而在Spring中我们好像只需要关心第三步，也就是我们的业务，而其他的操作都不需要关心。那么我想你应该猜到了Spring是如何实现的呢？ 答案就是基于 @Transactional 注解的SpringAOP实现，在接着往下阅读本篇文章的时候希望您对于SpringAOP的源码有一定的了解，如果不了解可以参考如下文章： 基于注解的SpringAOP源码解析（一） 基于注解的SpringAOP源码解析（二） 基于注解的SpringAOP源码解析（三） 获取增强 在阅读完AOP的原理之后，我们知道，当一个bean实例化之后会尝试获取所有适用于此Bean的增强。而在上篇文章中，我们已经发现了， @EnableTransactionManagement 注解会往Spring中注入一个增强 BeanFactoryTransactionAttributeSourceAdvisor