目录
编辑BeanFactory 和ApplicationContext的区别
mybaits的执行过程分析
开发者只需要关注sql本身,而不需要去处理如注册驱动,创建connection,创建statement,手动设置参数,结果集搜索等jdbc繁琐操作,mybaits通过xml或者注解方式将执行的statement配置起来,并通过Java对象和statement中的sql进行映射生成最终的sql语句,然后由mybaits框架执行sql并将结果映射成Java对象并返回
拦截器与过滤器
过滤器（Filter）：是在java web中将你传入的request、response提前过滤掉一些信息，或者提前设置一些参数。然后再传入Servlet或Struts2的 action进行业务逻辑处理。比如过滤掉非法url（不是login.do的地址请求，如果用户没有登陆都过滤掉），或者在传入Servlet或Struts2的action前统一设置字符集，或者去除掉一些非法字符。
拦截器（Interceptor）：是面向切面编程（AOP，Aspect Oriented Program）的。就是在你的Service或者一个方法前调用一个方法，或者在方法后调用一个方法。比如动态代理就是拦截器的简单实现，在你调用方法前打印出字符串（或者做其它业务逻辑的操作），也可以在你调用方法后打印出字符串，甚至在你抛出异常的时候做业务逻辑的操作。
通俗理解：
（1）过滤器（Filter）：当你有一堆东西的时候，你只希望选择符合你要求的某一些东西。定义这些要求的工具，就是过滤器。（理解：就是一堆字母中取一个B）
（2）拦截器（Interceptor）：在一个流程正在进行的时候，你希望干预它的进展，甚至终止它进行，这是拦截器做的事情。（理解：就是一堆字母中，干预它，通过验证的少点，顺便干点别的东西）
拦截器与过滤器的区别
①：拦截器是基于java的反射机制的，而过滤器是基于函数的回调。
②：拦截器不依赖于servlet容器，而过滤器依赖于servlet容器。
③：拦截器只对action请求起作用，而过滤器则可以对几乎所有的请求起作用。
④：拦截器可以访问action上下文、值、栈里面的对象，而过滤器不可以。
⑤：在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次。
⑥：拦截器可以获取IOC容器中的各个bean，而过滤器不行，这点很重要，在拦截器里注入一个service，可以调用业务逻辑。
springMVC执行流程
IOC
IOC 是面向对象编程中的一种设计原则，IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。 是说创建对象的控制权进行转移，以前创建对象的主动权和创建时机是由自己把控的，而现在这种权力转移到第三方。
实现原理：
它是通过反射机制+工厂模式实现的，在实例化一个类时，它通过反射调用类中set方法将事先保存在HashMap中的类属性注入到类中。
控制反转就是：获得依赖对象的方式反转了。`
依赖注入发生的时间
(1).用户第一次通过getBean方法向IoC容索要Bean时，IoC容器触发依赖注入。
(2).当用户在Bean定义资源中为元素配置了lazy-init属性，即让容器在解析注册Bean定义时进行预实例化，触发依赖注入。
2.依赖注入实现在以下两个方法中：
(1).createBeanInstance：生成Bean所包含的java对象实例。
(2).populateBean ：对Bean属性的依赖注入进行处理。
依赖注入的方式:
1.构造函数方式进行注入
2.set方法的方式进行注入
3.p命名空间的方式进行注入
注入的数据类型：
1.简单数据类型:包含基本数据类型和String，使用value注入值
2.对象类型：我们使用ref引用spring核心容器中的对象
3.集合类型(了解)
AOP面向切面编程
AOP（Aspect-OrientedProgramming，面向方面编程）它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其名为“Aspect”，即方面。便于减少系统的重复代码，降低模块间的耦合度，核心思想就是“将应用程序中的商业逻辑同对其提供支持的通用服务进行分离。
性能监控，在方法调用前后记录调用时间，方法执行太长或超时报警。
缓存代理，缓存某方法的返回值，下次执行该方法时，直接从缓存里获取。
软件破解，使用AOP修改软件的验证类的判断逻辑。
记录日志，在方法执行前后记录系统日志。
工作流系统，工作流系统需要将业务代码和流程引擎代码混合在一起执行，那么我们可以使用AOP将其分离，并动态挂接业务。
权限验证，方法执行前验证是否有权限执行当前方法，没有则抛出没有权限执行异常，由业务代码捕捉。
AOP能干什么，也是AOP带来的好处
1：降低模块的耦合度
2：使系统容易扩展
3：设计决定的迟绑定：使用AOP,设计师可以推迟为将来的需求作决定，因为它
可以把这种需求作为独立的方面很容易的实现。
4：更好的代码复用性
AOP基本概念
3、aop编程
3.1 导入命名空间
3.2 使用 <aop:config>进行配置
proxy-target-class="true" 声明时使用cglib代理
如果不声明，Spring 会自动选择cglib代理还是JDK动态代理
<aop:pointcut> 切入点 ，从目标对象获得具体方法
<aop:advisor> 特殊的切面，只有一个通知 和 一个切入点
advice-ref 通知引用
pointcut-ref 切入点引用
3.3 切入点表达式
execution(* com.ys.aop.*.*(..))
选择方法 返回值任意 包 类名任意 方法名任意 参数任意
连接点（Joinpoint）：
表示需要在程序中插入横切关注点的扩展点，连接点可能是类初始化、方法执行、方法调用、字段调用或处理异常等等，Spring只支持方法执行连接点，在AOP中表示为“在哪里做”；
切入点（Pointcut）：
选择一组相关连接点的模式，即可以认为连接点的集合，Spring支持perl5正则表达式和AspectJ切入点模式，Spring默认使用AspectJ语法，在AOP中表示为“在哪里做的集合”；
语法：execution(修饰符 返回值 包.类.方法名(参数) throws异常)
<aop:pointcut expression="execution(* com.ys.aop.*.*(..))" id="myPointCut"/>
增强（Advice）：
在连接点上执行的行为，增强提供了在AOP中需要在切入点所选择的连接点处进行扩展现有行为的手段；包括前置增强（before advice）、后置增强 (after advice)、环绕增强 （around advice），在Spring中通过代理模式实现AOP，并通过拦截器模式以环绕连接点的拦截器链织入增强 ；在AOP中表示为“做什么”；
切面（Aspect）：
横切关注点的模块化，比如上边提到的日志组件。可以认为是增强、引入和切入点的组合；在Spring中可以使用Schema和@AspectJ方式进行组织实现；在AOP中表示为“在哪里做和做什么集合”；
目标对象（Target Object）：
需要被织入横切关注点的对象，即该对象是切入点选择的对象，需要被增强的对象，从而也可称为“被增强对象”；由于Spring AOP 通过代理模式实现，从而这个对象永远是被代理对象，在AOP中表示为“对谁做”；
AOP代理（AOP Proxy）：
AOP框架使用代理模式创建的对象，从而实现在连接点处插入增强（即应用切面），就是通过代理来对目标对象应用切面。在Spring中，AOP代理可以用JDK动态代理或CGLIB代理实现，而通过拦截器模型应用切面。
织入（Weaving）：
织入是一个过程，是将切面应用到目标对象从而创建出AOP代理对象的过程，织入可以在编译期、类装载期、运行期（AOP三种织入方式）进行。
引入（inter-type declaration）：
也称为内部类型声明，为已有的类添加额外新的字段或方法，Spring允许引入新的接口（必须对应一个实现）到所有被代理对象（目标对象）, 在AOP中表示为“做什么（新增什么）”；
AOP的Advice类型
前置通知[Before advice]：在连接点前面执行，前置通知不会影响连接点的执行，除非此处抛出异常。 在方法前切入
正常返回通知[After returning advice]：在连接点正常执行完成后执行，如果连接点抛出异常，则不会执行。
异常返回通知[After throwing advice]：在连接点抛出异常后执行。
返回通知[After (finally) advice]：在连接点执行完成后执行，不管是正常执行完成，还是抛出异常，都会执行返回通知中的内容。
环绕通知[Around advice]：环绕通知围绕在连接点前后，比如一个方法调用的前后。这是最强大的通知类型，能在方法调用前后自定义一些操作。环绕通知还需要负责决定是继续处理join point(调用ProceedingJoinPoint的proceed方法)还是中断执行。
包围一个连接点的增强，如方法调用。这是最强大的一种增强类型。 环绕增强可以在方法调用前后完成自定义的行为。它也会选择是否继续执行连接点或直接返回它们自己的返回值或抛出异常来结束执行。
动态字节码生成 （Cglib）
使用动态字节码生成技术实现AOP原理是在运行期间目标字节码加载后，生成目标类的子类，将切面逻辑加入到子类中，所以使用Cglib实现AOP不需要基于接口。
Cglib是一个强大的,高性能的Code生成类库，它可以在运行期间扩展Java类和实现Java接口，它封装了Asm，所以使用Cglib前需要引入Asm的jar。
Spring默认采取的动态代理机制实现AOP，当动态代理不可用时（代理类无接口）会使用CGlib机制。但Spring的AOP有一定的缺点，第一个只能对方法进行切入，不能对接口，字段，静态代码块进行切入（切入接口的某个方法，则该接口下所有实现类的该方法将被切入）。第二个同类中的互相调用方法将不会使用代理类。因为要使用代理类必须从Spring容器中获取Bean。
spring框架实现实例化
1.无参构造的方式，直接使用bean标签配置对应的Bean对象
2.使用静态工厂方式实例化Bean
3.使用实例工厂方法实例化Bean
spring的bean的生命周期
1.Spring 容器根据配置中的 bean 定义中实例化 bean。
2.Spring 使用依赖注入填充所有属性，如 bean 中所定义的配置。
3.如果 bean 实现 BeanNameAware 接口，则工厂通过传递 bean 的 ID 来调用 setBeanName()。
4.如果 bean 实现 BeanFactoryAware 接口，工厂通过传递自身的实例来调用 setBeanFactory()。
5.如果存在与 bean 关联的任何 BeanPostProcessors，则调用 postProcessBeforeInitialization() 方法。
6.如果为 bean 指定了 init 方法（的 init-method 属性），那么将调用它。
7.最后，如果存在与 bean 关联的任何 BeanPostProcessors，则将调用 postProcessAfterInitialization() 方法。
8.如果 bean 实现 DisposableBean 接口，当 spring 容器关闭时，会调用 destory()。
9.如果为 bean 指定了 destroy 方法（的 destroy-method 属性），那么将调用它。
Spring Bean的作用域
BeanFactory 和ApplicationContext的区别
1）BeanFactory和ApplicationContext都是接口，并且ApplicationContext间接继承了BeanFactory。
2）BeanFactory是Spring中最底层的接口，提供了最简单的容器的功能，只提供了实例化对象和获取对象的功能，而ApplicationContext是Spring的一个更高级的容器，提供了更多的有用的功能。
3）ApplicationContext提供的额外的功能：获取Bean的详细信息(如定义、类型)、国际化的功能、统一加载资源的功能、强大的事件机制、对Web应用的支持等等。
4）加载方式的区别：BeanFactory采用的是延迟加载的形式来注入Bean；ApplicationContext则相反的，它是在Ioc启动时就一次性创建所有的Bean,好处是可以马上发现Spring配置文件中的错误，坏处是造成浪费。
BeanFactory和FactoryBean的区别与联系
两者都是接口；
BeanFactory主要是用来创建Bean和获得Bean的；
FactoryBean跟普通Bean不同，其返回的对象不是指定类的一个实例，而是该FactoryBean的getObject方法所返回的对象；
通过BeanFactory和beanName获取bean时，如果beanName不加&则获取到对应bean的实例；如果beanName加上&，则获取到FactoryBean本身的实例
FactoryBean 通常是用来创建比较复杂的bean(如创建mybatis的SqlSessionFactory很复杂)，一般的bean 直接用xml配置即可，但如果创建一个bean的创建过程中涉及到很多其他的bean 和复杂的逻辑，用xml配置比较困难，这时可以考虑用FactoryBean。
Spring 为什么把bean默认设计成单例
由于不会每次都新创建新对象所以有一下几个性能上的优势：
减少了新生成实例的消耗
新生成实例消耗包括两方面，spring会通过反射或者cglib来生成bean实例这都是耗性能的操作，其次给对象分配内存也会涉及复杂算法。
减少jvm垃圾回收
由于不会给每个请求都新生成bean实例，所以自然回收的对象少了。
可以快速获取到bean
因为单例的获取bean操作除了第一次生成之外其余的都是从缓存里获取的所以很快。
一个方法调用另外一个有事务的方法失效
单例的bean一个很大的劣势就是他不能做到线程安全，由于所有请求都共享一个bean实例，所以这个bean要是有状态的一个bean的话可能在并发场景下出现问题，而原型的bean则不会有这样问题（但也有例外，比如他被单例bean依赖），因为给每个请求都新创建实例。
spring 在扫描bean的时候会扫描方法上是否包含@Transactional注解，如果包含，spring会为这个bean动态地生成一个子类（即代理类，proxy），代理类是继承原来那个bean的。此时，当这个有注解的方法被调用的时候，实际上是由代理类来调用的，代理类在调用之前就会启动transaction。然而，如果这个有注解的方法是被同一个类中的其他方法调用的，那么该方法的调用并没有通过代理类，而是直接通过原来的那个bean，所以就不会启动transaction，我们看到的现象就是@Transactional注解无效。
解决方法:
把这两个方法分开到不同的类中
把注解加到类名上面
可以Autowired注入自己，然后再调用注入的类中的方法，即自己依赖自己，循环依赖
在SpringBoot 入口类中添加 @EnableAspectJAutoProxy(exposeProxy = true) 注解,把调用方法改为 AopContext.currentProxy().method(); 就可以执行事务了
Spring事务机制中7种传播行为
1.propagation-required: 支持当前事务,如果有就加入当前事务中;如果当前方法没有事务,就新建一个事务;
2.propagation-supports: 支持当前事务,如果有就加入当前事务中;如果当前方法没有事务,就以非事务的方式执行;
3.propagation-mandatory: 支持当前事务,如果有就加入当前事务中;如果当前没有事务,就抛出异常;
4.propagation-requires_new: 新建事务,如果当前存在事务,就把当前事务挂起;如果当前方法没有事务,就新建事务;
5.propagation-not-supported: 以非事务方式执行,如果当前方法存在事务就挂起当前事务;如果当前方法不存在事务,就以非事务方式执行;
6.propagation-never: 以非事务方式执行,如果当前方法存在事务就抛出异常;如果当前方法不存在事务,就以非事务方式执行;
7.propagation-nested: 如果当前方法有事务,则在嵌套事务内执行;如果当前方法没有事务,则与required操作类似;
Spring 中用到的设计模式：
工厂模式 : Spring使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。
代理模式 : Spring AOP 功能的实现。
单例模式 : Spring 中的 Bean 默认都是单例的。
模板方法模式 : Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。
装饰者模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以 根据客户的需求能够动态切换不同的数据源。
观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。
适配器模式 :Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配Controller。
spring和springmvc常用注解
@Component:标准一个普通的spring Bean类。
@Service:标注一个业务逻辑组件类。
@Repository:标注一个DAO组件类。
@RequestMapping:主要用于在SpringMVC后台控制层获取参数
@Resource和@Autowired :@Resource和@Autowired都是做bean的注入时使用
@requestParam:主要用于在SpringMVC后台控制层获取参数
@ResponseBody :该注解用于将Controller的方法返回的对象，通过适当的HttpMessageConverter转换为指定格式后，写入到Response对象的body数据区
@PathVariable:用于将请求URL中的模板变量映射到功能处理方法的参数上，即取出uri模板中的变量作为参数
@Transactional: 是声明式事务管理
@RestController @RestController注解相当于@ResponseBody ＋ @Controller合在一起的作用。
@Aspect 配置切面
可以将 MyBatis 分为哪几层？每层都有哪些主要模块？
mybatis架构自下而上分为基础支撑层、数据处理层、API接口层这三层。
基础支撑层:主要是用来做连接管理、事务管理、配置加载、缓存管理等最基础组件，为上层提供最基础的支撑。
数据处理层:主要是用来做参数映射、sql解析、sql执行、结果映射等处理，可以理解为请求到达，完成一次数据库操作的流程。
API接口层:主要对外提供API，提供诸如数据的增删改查、获取配置等接口
MyBatis 的一级缓存和二级缓存？
一级缓存：基于 PerpetualCache 的 HashMap 本地缓存，它的声明周期是和 SQLSession 一致的，有多个 SQLSession 或者分布式的环境中数据库操作，可能会出现脏数据。当 Session flush 或 close 之后，该 Session 中的所有 Cache 就将清空，默认一级缓存是开启的。
二级缓存：也是基于 PerpetualCache 的 HashMap 本地缓存，不同在于其存储作用域为 Mapper 级别的，如果多个SQLSession之间需要共享缓存，则需要使用到二级缓存，并且二级缓存可自定义存储源，如 Ehcache。默认不打开二级缓存，要开启二级缓存，使用二级缓存属性类需要实现 Serializable 序列化接口(可用来保存对象的状态)。
springboot自动配置原理
从classpath中搜寻所有的META-INF/spring.factories配置文件，并将其中org.springframework.boot.autoconfigure.EnableAutoConfiguration对应的配置项，通过反射机制实例化为IOC容器配置类（这些配置类都是使用了@Configuration注解声明的），然后汇总并加载到Spring框架的IOC容器。
@SpringBootConfiguration：我们点进去以后可以发现底层是Configuration注解，说白了就是支持JavaConfig的方式来进行配置(使用Configuration配置类等同于XML文件)。
@EnableAutoConfiguration：开启自动配置功能(后文详解)
@ComponentScan：这个注解，学过Spring的同学应该对它不会陌生，就是扫描注解，默认是扫描当前类下的package。将@Controller/@Service/@Component/@Repository等注解加载到IOC容器中。
@SpringBootApplication等同于下面三个注解：
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan
其中@EnableAutoConfiguration是关键(启用自动配置)，内部实际上就去加载META-INF/spring.factories文件的信息，然后筛选出以EnableAutoConfiguration为key的数据，加载到IOC容器中，实现自动配置功能！
SpringBoot的优点：
1.去除了大量的xml配置文件 ，约定大于配置
2.简化复杂的依赖管理，避免大量的 Maven 导入和各种版本冲突。
3.配合各种starter使用，基本上可以做到自动化配置
4.快速启动容器
5.嵌入的Tomcat 无需部署war文件，配合Maven或Gradle等构件工具打成Jar包后，Java -jar 进行部署运行还是蛮简单的
Ribbon负载均衡策略
1.轮询法
2.加权轮询法
3.随机法
4.加权随机法
5.原地址哈希法
6.最小连接数法
服务隔离
因为默认情况下，只有一个线程池会维护所有的服务接口，如果大量的请求访问同一个接口，达到tomcat 线程池默认极限，可能会导致其他服务无法访问。
解决服务雪崩效应:使用服务隔离机制(线程池方式和信号量)，使用线程池方式实現隔离的原理: 相当于每个接口(服务)都有自己独立的线程池，因为每个线程池互不影响，这样的话就可以解决服务雪崩效应。
线程池隔离:
每个服务接口，都有自己独立的线程池，每个线程池互不影响。
信号量隔离:
使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，当请求进来时先判断计数器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则通行，这时候计数器+1，请求返 回成功后计数器-1。
服务雪崩
在微服务架构中，微服务之间的数据交互通过远程调用完成，微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，此时如果链路上某个微服务的调用响应时间过长或者不可用，那么对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，导致“雪崩效应”。
服务限流
服务熔断
服务熔断是应对雪崩效应的一种微服务链路保护机制。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。
服务熔断解决如下问题： 1. 当所依赖的对象不稳定时，能够起到快速失败的目的；2. 快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复。
服务降级
服务降级是指 当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。说白了，就是尽可能的把系统资源让给优先级高的服务。资源有限，而请求是无限的。如果在并发高峰期，不做服务降级处理，一方面肯定会影响整体服务的性能，严重的话可能会导致宕机某些重要的服务不可用。所以，一般在高峰期，为了保证核心功能服务的可用性，都要对某些服务降级处理。比如当双11活动时，把交易无关的服务统统降级，如查看蚂蚁深林，查看历史订单等等。
延迟处理
这个模式需要在系统的前端设置一个流量缓冲池，将所有的请求全部缓冲进这个池子，不立即处理。然后后端真正的业务处理程序从这个池子中取出请求依次处理，常见的可以用队列模式来实现。这就相当于用异步的方式去减少了后端的处理压力，但是当流量较大时，后端的处理能力有限，缓冲池里的请求可能处理不及时，会有一定程度延迟。
特权处理
这个模式需要将用户进行分类，通过预设的分类，让系统优先处理需要高保障的用户群体，其它用户群的请求就会延迟处理或者直接不处理。
限流算法
计数器方法
系统维护一个计数器，来一个请求就加1，请求处理完成就减1，当计数器大于指定的阈值，就拒绝新的请求。
基于这个简单的方法，可以再延伸出一些高级功能，比如阈值可以不是固定值，是动态调整的。另外，还可以有多组计数器分别管理不同的服务，以保证互不影响等。
漏桶方法
漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.
令牌桶方法
首先还是要基于一个队列，请求放到队列里面。但除了队列以外，还要设置一个令牌桶，另外有一个脚本以持续恒定的速度往令牌桶里面放令牌，后端处理程序每处理一个请求就必须从桶里拿出一个令牌，如果令牌拿完了，那就不能处理请求了。我们可以控制脚本放令牌的速度来达到控制后端处理的速度，以实现动态流控。
Gateway路由规则（链接）
359
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
