spring原理

在Spring/Spring-Boot的入门上我绕了很多弯路，我绕过的一个典型的弯路是： 找一个Spring-Boot的入门案例，下载代码跟着跑了一遍，跑通之后确不能理解代码，尤其是各种配置文件以及注解让我难以理解这个程序究竟是怎么跑起来的。@Autowired, @Controller这些注解到底是什么意思，它的工作流程是怎样的? 我怀疑自己是注解相关的知识没有学好，于是往下挖注解的工作原理-->动态代理机制-->反射-->类加载过程-->类加载器的工作原理。这样一套走下来之后，即使我懵懵懂懂明白了类加载器、反射、动态代理、注解, 我还是不能看懂spring的这些注解是怎么工作的，也不知道怎么去实际使用他们。 很多的入门教程，给出了很多具体的操作，但是并没有告诉我们为什么spring要用这个注解，这个注解用了之后他会有什么作用，以及这些注解的工作流程（我指的是使用流程不是底层的实现原理）。 下面是我自己的一些学习反思。 首先我们从最基本的需求讲起。 java是面向对象的语言，每个对象都可以绑定一定的操作，通过将多个对象组合，我们可以完成一个任务所需要的所有操作。 举个例子，假设我们的任务是接收用户对 localhost:8080/user 这个链接的get请求，返回给用户浏览器一个含有用户数据的json数据串 “{"name":"bob"}”。我们把这个任务分成到多个对象去完成

1. 介绍spring框架 Spring是一套为了解决企业应用开发的复杂性而创建的框架，特点是分层的架构，允许用户在不同层面使用不同的组件进行组合。同时通过IOC容器来降低耦合，简化开发。利用AOP来进行切面编程统一管理通用模块。 2.Spring中AOP的应用场景、Aop原理、好处？ 主要是两种，一种是JDK动态代理，一种是Cglib代理。 两者的区别： JDK动态代理只能代理实现了接口的类，动态代理类的字节码在程序运行时由Java反射机制动态生成。 Cglib是可以代理没有实现接口的类，cglib是针对类来实现代理的，他的原理是对指定的目标类生成一个子类，并覆盖其中方法实现增强，所以不能对final修饰的类进行代理。底层采用ASM实现。 原理： AOP是面向切面编程，是通过动态代理(jdk动态代理)的方式为程序添加统一功能，集中解决一些公共问题。 AOP就是纵向的编程，如业务1和业务2都需要一个共同的操作，与其往每个业务中都添加同样的代码，不如写一遍代码，让两个业务共同使用这段代码。在日常有订单管理、商品管理、资金管理、库存管理等业务，都会需要到类似日志记录、事务控制、权限控制、性能统计、异常处理及事务处理等。AOP把所有共有代码全部抽取出来，放置到某个地方集中管理，然后在具体运行时，再由容器动态织入这些共有代码。 优点： 各个步骤之间的良好隔离性耦合性大大降低 源代码无关性

它是一个全面的、企业应用开发一站式的解决方案，贯穿表现层、业务层、持久层。但是 Spring 仍然可以和其他的框架无缝整合。 6.1.1. Spring 特点 6.1.1.1. 轻量级 6.1.1.2. 控制反转 6.1.1.3. 面向切面 6.1.1.4. 容器 6.1.1.5. 框架集合 6.1.7. Spring IOC 原理 6.1.7.1. 概念 Spring 通过一个配置文件描述 Bean 及 Bean 之间的依赖关系，利用 Java 语言的反射功能实例化 Bean 并建立 Bean 之间的依赖关系。 Spring 的 IoC 容器在完成这些底层工作的基础上，还提供 了 Bean 实例缓存、生命周期管理、 Bean 实例代理、事件发布、资源装载等高级服务 6.1.7.2. Spring 容器高层视图 Spring 启动时读取应用程序提供的 Bean 配置信息，并在 Spring 容器中生成一份相应的 Bean 配 置注册表，然后根据这张注册表实例化 Bean，装配好 Bean 之间的依赖关系，为上层应用提供准 备就绪的运行环境。 其中 Bean 缓存池为 HashMap 实现 6.1.7.3. IOC 容器实现 BeanFactory-框架基础设施 BeanFactory 是 Spring 框架的基础设施，面向 Spring 本身； ApplicationContext

Spring 框架常用语法进行总结： spring框架的二大主要的功能就是IOC和AOP。 IOC: 控制反转（依赖注入） AOP: 面向切面编程 学习spring最好的方法就是去看官网，里面有详细的说明及使用原则 介绍spring 中的注解的使用，xml配置等目前在市面上面较少。 首先介绍Java自带的元注解 (元注解就是 能注解到注解上的注解，能用在其他注解上的注解 ) Java5.0定义了4个标准的meta-annotation类型 @Target ： 用于描述注解的范围，即注解在哪用。它说明了Annotation所修饰的对象范围：Annotation可被用于 packages、types（类、接口、枚举、Annotation类型）、类型成员（方法、构造方法、成员变量、枚举值）、方法参数和本地变量（如循环变量、catch参数）等。取值类型（ElementType） CONSTRUCTOR:用于描述构造器　　FIELD:用于描述域即类成员变量　　LOCAL_VARIABLE:用于描述局部变量　　METHOD:用于描述方法　　PACKAGE:用于描述包　　PARAMETER:用于描述参数　　TYPE:用于描述类、接口(包括注解类型) 或enum声明　　TYPE_PARAMETER:1.8版本开始，描述类、接口或enum参数的声明　　TYPE_USE:1.8版本开始，描述一种类

在SSH框假中spring充当了管理容器的角色。我们都知道Hibernate用来做持久层，因为它将JDBC做了一个良好的封装，程序员在与数据库进行交互时可以不用书写大量的SQL语句。Struts是用来做应用层的，他它负责调用业务逻辑serivce层。所以SSH框架的流程大致 是：Jsp页面----Struts------Service（业务逻辑处理类）---Hibernate（左到右）struts负责控制Service（业务逻辑处理类），从而控制了Service的生命周期，这样层与层之间的依赖和强，属于耦合。这时，使用spring框架就起到了控制Action对象（Strus中的）和Service类的作用，两者之间的关系就松散了，Spring的Ioc机制（控制反转和依赖注入）正是用在此处 首先想说说IoC（Inversion of Control，控制倒转）。这是spring的核心，贯穿始终。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此

出现循环依赖的情况 1 // setter方式注入 2 @Component("A") 3 public static class A { 4 5 @Autowired 6 private B b; 7 } 8 9 @Component("B") 10 public static class B { 11 12 @Autowired 13 private A a; 14 } 15 //构造器方式注入 16 @Component("A") 17 public static class A { 18 19 private final B b; 20 21 @Autowired 22 public A(B b) { 23 this.b = b; 24 } 25 } 26 27 @Component("B") 28 public static class B { 29 30 private final A a; 31 32 @Autowired 33 public B(A a) { 34 this.a = a; 35 } 36 } 如上代码所示，两个bean之间互相注入即为循环依赖。 　　废话不多说，实验对象时两个bean，实验变量有三个： 　　1. 注入方式：setter注入、构造器注入 　　2. 是否是懒加载 　　3. 是否是单例 每个变量有四种情况，一共4x4x4=64种情况先说结论

引言 早在15年的时候就开始用spring boot进行开发了，然而一直就只是用用，并没有深入去了解spring boot是以什么原理怎样工作的，说来也惭愧。今天让我们从spring boot启动开始，深入了解一下spring boot的工作原理。 为什么用spring boot 在使用一个东西或者一个工具之前，我们总是会问自己，我为什么要用？用他能给我带来什么好处？ * 最大的好处就是spring boot遵从了java**约定大于配置**不用面对一大堆的配置文件，spring boot是根据你用的包来决定提供什么配置。 * 服务器以jar包的形式内嵌于项目中，对于微服务满天飞的情况，spring boot天生适合微服务架构，方便部署。 * 提供devtools从此改代码就需重启成为历史。 有优点就一定有缺点，缺点来源于优点优点来源于缺点（感觉在说哲学问题了哈哈哈） * 正因为配置对开发者不透明，不看源码会不清楚spring boot如何进行诸如JDBC加载、事务管理等，出现错误也很难调错。 * 自动配置之后要自定义配置需编码javaConfig，需要了解这些配置类api。 * 版本迭代太快，新版本对老版本改动太多导致不兼容，比如1.3.5之前的springBootTest和1.4.0之后的springBootTest。 只有合适的架构才是最好的架构如果能接受spring

概述 毫无疑问，Spring Cloud是目前微服务架构领域的翘楚，无数的书籍博客都在讲解这个技术。不过大多数讲解还停留在对Spring Cloud功能使用的层面，其底层的很多原理，很多人可能并不知晓。 因此本文将通过大量的手绘图 ，给大家谈谈Spring Cloud微服务架构的底层原理。 实际上，Spring Cloud是一个全家桶式的技术栈，包含了很多组件。本文先从其最核心的几个组件入手，来剖析一下其底层的工作原理。 也就是Eureka、Ribbon、Feign、Hystrix、Zuul这几个组件。 一、业务场景介绍 先来给大家说一个业务场景，假设咱们现在开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 针对上述流程， 我们需要有订单服务、库存服务、仓储服务、积分服务 。整个流程的大体思路如下： 用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态 订单服务调用库存服务，完成相应功能 订单服务调用仓储服务，完成相应功能 订单服务调用积分服务，完成相应功能 至此，整个支付订单的业务流程结束 下图这张图，清晰表明了各服务间的调用过程： 好！有了业务场景之后，咱们就一起来看看Spring Cloud微服务架构中

消失的事务 端午节前，组内在讨论一个问题： 一个没有加@Transactional注解的方法，去调用一个加了@Transactional的方法，会不会产生事务？ 文字苍白，还是用代码说话。 先写一个@Transactional的方法（本文的所有代码，可到 Github 上下载）： @Transactional public void deleteAllAndAddOneTransactional(Customer customer) { customerRepository.deleteAll(); if ("Yang".equals(customer.getFirstName())) { throw new RuntimeException(); } customerRepository.save(customer); } 方法内先去执行deleteAll()，删除表中全部数据；然后执行save()保存数据。 这两个方法中间，会判断传进来的firstName是不是等于“Yang”，是，则抛异常，用于模拟两个数据库操作之间可能发生的异常场景。 如果没有加@Transactional注解，那么这两个操作就不在一个事务里面，不具有原子性。如果deleteAll之后抛异常，那么就会导致只删除不新增。 而加了@Transactional之后，这两个动作在一个事务里头，具有原子性

开篇说明： 　　注解本身并没有什么实际的功能（非要说标记也是一个“实际”的功能的话，也可以算吧），隐藏在背后的注解处理器才是实现注解机制的核心。本篇将从这两个层面出发探索 spring boot 自动装配的秘密，并使用 spring boot 的自动装配机制来实现自动装配。 　　本次代码已经放到 github： https://github.com/christmad/code-share/tree/master/spring-boot-config-practice 　　代码中主要是做了 @Configuration 和 @ConfigurationProperties 使用的练习，以及本篇博客笔记重点：自定义 ImportSelector 实现类实现批量扫描包下类文件。 spring boot 自动装配有几个核心的“事件”需要理解： 　　(1) 首先，从 spring 3.X 开始，AnnotationConfigApplicationContext 替代 ClassPathXmlApplicationContext，迎来了全新的 java bean config 配置方式，使用 java bean 和 注解就能轻松添加配置。 　　(2) 3.X 开始提供的致力于零配置文件的注解： 　　　　@Configuration——用来替代 xml 文件的。 　　　　@Bean—