SpringCore
IOC
三级缓存
AOP
Spring AOP 和 AspectJ AOP 有什么区别？
Spring AOP 属于运行时增强，而 AspectJ 是编译时增强。 Spring AOP 基于代理(Proxying)，而 AspectJ 基于字节码操作(Bytecode Manipulation)。
Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单，
如果我们的切面比较少，那么两者性能差异不大。但是，当切面太多的话，最好选择 AspectJ ，它比Spring AOP 快很多。
对象作用域
- singleton : 唯一 bean 实例，Spring 中的 bean 默认都是单例的。
- prototype : 每次请求都会创建一个新的 bean 实例。
- request : 每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效。
- session : 每一次HTTP请求都会产生一个新的 bean，该bean仅在当前 HTTP session 内有效。
- global-session： 全局session作用域，仅仅在基于portlet的web应用中才有意义，Spring5已经没有了。Portlet是能够生成语义代码(例如：HTML)片段的小型Java Web插件。它们基于portlet容器，可以像servlet一样处理HTTP请求。但是，与 servlet 不同，每个 portlet 都有不同的会话
Spring 中的单例 bean 的线程安全问题了解吗？
的确是存在安全问题的。因为，当多个线程操作同一个对象的时候，对这个对象的成员变量的写操作会存在线程安全问题。
但是，一般情况下，我们常用的 Controller、Service、Dao 这些 Bean 是无状态的。无状态的 Bean 不能保存数据，因此是线程安全的。
常见的有 2 种解决办法：
在类中定义一个 ThreadLocal 成员变量，将需要的可变成员变量保存在 ThreadLocal 中（推荐的一种方式）。
改变 Bean 的作用域为 “prototype”：每次请求都会创建一个新的 bean 实例，自然不会存在线程安全问题。
Bean生命周期
4个阶段：实例化、属性赋值、初始化、销毁
Spring 事务
https://blog.csdn.net/qq_22130209/article/details/110306296
- 编程式事务，在代码中硬编码。(不推荐使用)
- 声明式事务，在配置文件中配置（推荐使用）
加上注解 @Transactional
@Transactional注解应该写在哪?
@Transactional 可以标记在类上面（当前类所有的方法都运用上了事务）
@Transactional 标记在方法则只是当前方法运用事务
事务配置的属性
isolation：设置事务的隔离级别
propagation：事务的传播行为
noRollbackFor：那些异常事务可以不回滚
noRollbackForClassName：填写的参数是全类名
rollbackFor：哪些异常事务需要回滚
rollbackForClassName：填写的参数是全类名
readOnly：设置事务是否为只读事务
timeout：事务超出指定执行时长后自动终止并回滚,单位是秒
TransactionDefinition 接口中定义了五个表示隔离级别的常量：
- TransactionDefinition.ISOLATION_DEFAULT: 使用后端数据库默认的隔离级别，Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别.
- TransactionDefinition.ISOLATION_READ_UNCOMMITTED: 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读
- TransactionDefinition.ISOLATION_READ_COMMITTED: 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生
- TransactionDefinition.ISOLATION_REPEATABLE_READ: 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
- TransactionDefinition.ISOLATION_SERIALIZABLE: 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。
Spring 事务传播行为
REQUIRED（默认） 开启新的事务 融合到外部事务中
支持当前事务的情况：
TransactionDefinition.PROPAGATIONREQUIRED： 单独调用开启事务，被其他事务调用加入事务中。 （常用）
TransactionDefinition.PROPAGATIONSUPPORTS： 单独调用不开启事务，被其他事务调用加入事务中。 （常用）
TransactionDefinition.PROPAGATION_MANDATORY： 如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。（mandatory：强制性）
不支持当前事务的情况：
TransactionDefinition.PROPAGATIONREQUIRES_NEW： 创建一个新的事务，如果当前存在事务，则把当前事务挂起。 （常用于日志）
TransactionDefinition.PROPAGATIONNOT_SUPPORTED： 以非事务方式运行，如果当前存在事务，则把当前事务挂起。
TransactionDefinition.PROPAGATION_NEVER： 以非事务方式运行，如果当前存在事务，则抛出异常
Spring 框架中用到了哪些设计模式？
关于下面一些设计模式的详细介绍，可以看笔主前段时间的原创文章《面试官:“谈谈Spring中都用到了那些设计模式?”。》 。
- 工厂设计模式 : Spring使用工厂模式通过
BeanFactory、ApplicationContext创建 bean 对象。 - 代理设计模式 : Spring AOP 功能的实现。
- 单例设计模式 : Spring 中的 Bean 默认都是单例的。
- 模板方法模式 : Spring 中
jdbcTemplate、hibernateTemplate等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。 - 包装器设计模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。
- 观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。
- 适配器模式 :Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配
Controller。 - ……
SpringMVC
发展历史
SpringMVC也是为了解耦的架构
没有 Spring MVC 的时代。
- Model1 时代 : 整个 Web 应用几乎全部用 JSP 页面组成，只用少量的 JavaBean 来处理数据库连接、访问等操作。这个模式下 JSP 既是控制层又是表现层。显而易见，这种模式存在很多问题。比如①将控制逻辑和表现逻辑混杂在一起，导致代码重用率极低；②前端和后端相互依赖，难以进行测试并且开发效率极低；
- Model2 时代 ：“Java Bean(Model)+ JSP（View,）+Servlet（Controller） ”这种开发模式,这就是早期的 JavaWeb MVC 开发模式。Model:系统涉及的数据，也就是 dao 和 bean。View：展示模型中的数据，只是用来展示。Controller：处理用户请求都发送给 ，返回数据给 JSP 并展示给用户。
框架阶段 Struts2
Spring MVC
工作原理
流程说明（重要）：
- 客户端（浏览器）发送请求，直接请求到
DispatcherServlet。 DispatcherServlet根据请求信息调用HandlerMapping，解析请求对应的Handler。- 解析到对应的
Handler（也就是我们平常说的Controller控制器）后，开始由HandlerAdapter适配器处理。 HandlerAdapter会根据Handler来调用真正的处理器来处理请求，并处理相应的业务逻辑。- 处理器处理完业务后，会返回一个
ModelAndView对象，Model是返回的数据对象，View是个逻辑上的View。 ViewResolver会根据逻辑View查找实际的View。DispaterServlet把返回的Model传给View（视图渲染）。- 把
View返回给请求者（浏览器
前后端交互
SpringBoot
自动配置原理
若有收获，就点个赞吧
0 人点赞
