1、谈一谈你对IOC和DI的理解?

IoC（控制反转）和 DI（依赖注入）是 Spring 框架的核心概念，IoC是指让对象的创建交给容器去进行管理，DI就是不仅帮你创建对象，还会帮你把对象依赖的其他东西都注入进去。在 Spring 里，IoC 容器就像一个 “对象工厂”，它负责创建、管理和装配所有的 Bean（组件），让你的代码更加灵活和可维护。

本质与价值

• IOC是思想：程序控制权由应用代码转移到外部容器
• DI是手段：通过注入实现依赖关系的动态绑定
• 最终目标：**解耦**（对象间依赖关系由容器管理，而非硬编码）

2、Spring Bean依赖注入(DI)的方式有哪些?

1. 构造器注入：通过类的构造方法来注入依赖对象
2. Setter 方法注入：通过类的 setter 方法来注入依赖对象。
3. 字段注入:通过类的字段（成员变量）直接注入依赖对象，使用 @Autowired 或 @Resource 注解
4. 接口注入:通过实现特定接口的方法来注入依赖。

3、举例说明spring 事务注解失效的场景?

• 数据库引擎不支持事务（innoDB ）
• 没有被Spring管理,也就是不是代理对象，没有对代码进行一个增强
• 方法不是public的,因为@Transactional 注解是依靠 Spring AOP 来实现事务管理的，而 AOP 的动态代理（默认是 JDK 代理）在运行时需要通过反射来调用目标方法。由于 Java 的反射机制默认无法访问非 public 方法（例如 private 方法），所以当该注解应用在非 public 方法上时，事务配置会被 Spring 忽略。
• 传播行为中设置了不支持事务
• 异常被捕获掉，若异常被方法内部捕获并处理，Spring 无法感知到异常，会认为方法正常执行完毕，从而提交事务
• 异常类型错误， 默认捕获RuntimeException异常，比如说在rollbackFor中设置的是NullPointerException，但是内部的异常是SQLException，这样事务也会失效
• 数据源未配置事务管理器：Spring 需要事务管理器来驱动事务，若未配置，事务注解将失效。

4、spring事务传播行为有哪些？

1. REQUIRED：默认的Spring事物传播级别，如果当前存在事务，则加入这个事务，如果不存在事务，就新建一个事务。
2. REQUIRE_NEW：不管是否存在事务，都会新开一个事务，新老事务相互独立。外部事务抛出异常回滚不会影响内部事务的正常提交。
3. NESTED：如果当前存在事务，则嵌套在当前事务中执行。如果当前没有事务，则新建一个事务，类似于REQUIRE_NEW。
4. SUPPORTS：表示支持当前事务，如果当前不存在事务，以非事务的方式执行。
5. NOT_SUPPORTED：表示以非事务的方式来运行，如果当前存在事务，则把当前事务挂起。
6. MANDATORY：强制事务执行，若当前不存在事务，则抛出异常.
7. NEVER：以非事务的方式执行，如果当前存在事务，则抛出异常

5、spring boot是什么？

Spring Boot 是 Spring 团队推出的一个快速开发框架，它的核心目标是让你开箱即用，不用再为 Spring 项目的配置操心。
Spring Boot 的核心特点 有五个
1.自动配置 框架根据你添加的依赖（比如spring-boot-starter-web），自动帮你配置好 Web 环境（如 Tomcat、Spring MVC）。
2.起步依赖 把常用的依赖打包成 “启动器”，比如：不用再自己一个个找依赖，版本也自动协调好。
3.嵌入式服务器 内置 Tomcat、Jetty 等服务器，直接用java -jar运行项目，不用部署 WAR 包。
4.Actuator（监控） 提供生产级特性（如健康检查、指标监控、环境信息），通过 HTTP 接口或 JMX 查看。
5.无代码生成、无 XML 配置 用注解（如@SpringBootApplication）和 Java Config 搞定一切

6、SpringBoot和SpringCloud有什么区别？

• SpringBoot使⽤了默认⼤于配置的理念，集成了快速开发的Spring多个插件，同时⾃动过滤不需要配置的多余的插
  件，简化了项⽬的开发配置流程，⼀定程度上取消xml配置，是⼀套快速配置开发的脚⼿架，能快速开发单个微服
  务；
• SpringCloud⼤部分的功能插件都是基于SpringBoot去实现的，SpringCloud关注于全局的微服务整合和管理，将
  多个SpringBoot单体微服务进⾏整合以及管理；SpringCloud依赖于SpringBoot开发，⽽SpringBoot可以独⽴开
  发；

7、SpringBoot配置文件有哪些？怎么实现多环境配置？

Spring Boot 的核心配置文件是 application 和 bootstrap 配置文件。
application 配置文件是项目的主配置文件，用于定义应用级配置（如端口、数据库连接、日志级别等），支持动态修改和属性覆盖，可通过环境变量、命令行参数等方式调整配置内容，主要用于 Spring Boot 项目的自动化配置。
bootstrap配置文件属于引导配置文件，加载顺序优先于 application，主要用于系统级配置（如配置中心连接信息、加密密钥等），其内容通常为启动时必须的固定配置，不可被后续配置覆盖。
Spring Boot 支持通过 命名规则 或 @Profile 注解 实现多环境隔离。

8、SpringAOP你的理解

AOP（面向切面编程）是 Spring 框架的另一个核心概念，它可以让你在不修改原有代码的情况下，对程序的多个部分添加额外功能。它采用的是动态代理的思想。动态代理分为JDK动态代理和CGLIB动态代理两种。
(1)JDK 动态代理只提供接口代理，不支持类代理，核心 InvocationHandler 接口和 Proxy 类，InvocationHandler 通过 invoke()方法反射来调用目标类中的代码，动态地将 横切逻辑和业务编织在一起，Proxy 利用 InvocationHandler 动态创建一个符合某一接口 的的实例, 生成目标类的代理对象。
(2) 如果代理类没有实现 InvocationHandler 接口，那么 Spring AOP 会选择使用 CGLIB 来动态代理目标类。CGLIB（Code Generation Library），是一个代码生成的类库， 可以在运行时动态的生成指定类的一个子类对象，并覆盖其中特定方法并添加增强代码，从 而实现 AOP。CGLIB 是通过继承的方式做的动态代理，因此如果某个类被标记为 final， 那么它是无法使用 CGLIB 做动态代理的。

## 9、Autowired 和 Resource注解有什么区别?

@Autowired 和 @Resource 都是 Spring 框架中用于依赖注入的注解，但它们来自不同的规范，用法和行为上有一些关键区别。

@Autowired是Spring 框架自己的注解。默认按类型（byType）匹配,若存在多个同类型 Bean，则尝试按名称（byName）匹配

@Resource是 JSR-250 标准的注解。默认按名称（byName）匹配先根据 name 属性查找 Bean，若未指定 name，则使用字段名或方法名作为 Bean 名称。若按名称找不到，则按类型（byType）匹配

10、SpringMVC 主要组件

Spring的主要组件有
1. DispatcherServlet（核心前端控制器，接收所有请求并调度处理流程）：统一处理请求和响应，是整个流程的入口。
2. HandlerMapping（请求 URL 到处理器的映射器）：根据请求 URL 找到对应的 Handler（如 Controller 中的方法）。
3. HandlerAdapter(处理器适配器)：统一调用不同类型的 Handler（如注解式 Controller、实现特定接口的 Controller）。
4. Controller(业务逻辑处理器)：处理请求，调用 Service 层，返回 ModelAndView（数据 + 视图信息）。
5. ModelAndView(数据和视图的封装对象)：包含业务处理结果（Model）和视图名称（View）。
6. ViewResolver(视图解析器)：将逻辑视图名（如 “home”）解析为具体的 View 对象（如 JSP、Thymeleaf 模板）。
7. View(视图渲染器):将 Model 中的数据渲染为 HTML 响应（如 JSP 页面、JSON/XML 数据）。
8. Interceptor(请求拦截器)：在请求处理前后执行额外逻辑（如日志记录、权限校验）。
9. ExceptionResolver(异常处理器):捕获并处理请求过程中的异常，返回错误视图或 JSON 错误信息。
10. MultipartResolver(文件上传解析器)：处理文件上传请求，解析 Multipart 请求数据。

11、spring mvc的运⾏流程？

用户请求进入 Spring MVC 后，就像进了一家餐馆：

DispatcherServlet（服务员）接收到请求，查HandlerMapping（菜单）找到对应的Controller（厨师），厨师处理完业务逻辑后返回ModelAndView（菜品），服务员再通过ViewResolver（送餐指南）找到合适的View（餐盘），把数据渲染后返回给用户。

12、谈一谈你对 Mybatis 框架的理解

MyBatis 是一款优秀的持久层框架，一个半 ORM（对象关系映射）框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生类型、接口和 Java 的 POJO（Plain Old Java Objects，普通老式 Java 对象）为数据库中的记录。

13、在 mybatis 中,resultType 和 ResultMap 的区别是什么?

如果数据库结果集中的列名和要封装实体的属性名完全一致的话用resultType 属性
如果数据库结果集中的列名和要封装实体的属性名有不一致的情况用resultMap属性，通过 resultMap 手动建立对象关系映射，resultMap 要配置一下表和类的一一对应关系，所以说就算你的字段名和你的实体类的属性名不一样也没关系，都会给你映射出来

14、在 mybatis 中,${} 和 #{} 的区别是什么？

#{} 是占位符，预编译处理，${}是字符串替换。
Mybatis 在处理#{}时，会将 sql 中的#{}替换为?号，调用 PreparedStatement 的set
方法来赋值；
Mybatis 在处理${}时，就是把${}替换成变量的值。
使用#{}可以有效的防止 SQL 注入，提高系统安全性

15、谈一下你对 mybatis 缓存机制的理解?

Mybatis 有两级缓存，一级缓存是 SqlSession 级别的，默认开启，无法关闭；二级缓存是 Mapper 级别的，二级缓存默认是没有开启的，但是手动开启1. 一级缓存：基础 PerpetualCache 的 HashMap 本地缓存，其存储作用域为Session, 当 Session flush 或 close 之后，Session 中的所有 Cache 就将清空2. 二级缓存其存储作用域为 Mapper(Namespace），使用二级缓存属性类需要实现Serializable 序列化接口
3. 对于缓存数据更新机制，当某一个作用域(一级缓存Session/二级缓存Namespaces)
的进行了 C(增加)/U(更新)/D(删除)操作后，默认该作用域下所有 select 中的缓存将被clear. 需要在 setting 全局参数中配置开启二级缓存，如下 conf.xml 配置：当我们的配置文件配置了 cacheEnabled=true 时，就会开启二级缓存，二级缓存是mapper 级别的，如果你配置了二级缓存，那么查询数据的顺序应该为：二级缓存→一级缓存→数据库。