SpringBoot面试题

1 SpringBoot启动Tomcat

1.1 Spring在启动时创建一个Spring容器
1.2 利用@ConditionalOnClass技术判断classpath中是否存丰Tomcat依赖，如果存在则生成一个启动Tomcat的Bean
1.3 Spring容器创建完后，就会获取启动Tomcat的Bean,并创建Tomcat对象，绑定端口，启动Tomcat

2 SpringBoot核心注解

2.1 Spring3已经包含以下注解@Configuration,@Bean,@Import
2.2 SpringBoot注解
@SpringBootApplication  - SpringBoot启动注解
@SpringBootConfiguration - 标注这个类是一个配置类
@EnableAutoConfiguration - 向Spring容器中导入一个Selector,用来加载ClassPath下的SpringFatories中所定义的自动配置类，将这些自动加载为配置Bean
@ComponentScan - 标识扫描路径
@Conditional - 作用是按照一定的条件进行判断，满足条件给容器注册Bean
@Resource的作用相当于@Autowired,只不过@Autowired按byType自动注入,而@Resource默认按 byName自动注入罢了.@Resource有两个属性是比较重要的,分是name和type,Spring将@Resource注解的name属性解析为bean的名字,而type属性则解析
https://blog.51cto.com/u_15491409/5103442

3 为什么SpringBoot的jar可以直接运行

3.1 部署springboot插件，才可以正常运行java -jar xxx.jar - spring-boot-maven-plugin
3.2 加了这个插件后，生成一个Fat jar(jar包含jar)，包含了所有依赖的jar
3.3 java -jar会在jar中找到mainfest文件->启动Main函数JarLauncher->创建一个ClassLoader来加载boot-lib下面的jar，并以一个新线程启动Main函数(Start-Class)

4 配置一个简单SpringMVC

4.1 创建一个spring.xml，配置controller类和service类(Bean)
4.2 将spring.xml配置在web.xml里的DispatherServlet
4.3 将准备好web.xml放在WEB-INF文件里面让Tomcat启动加载->创建DispatherServlet->创建 Spring容器(AppliactionContext)—>创建Bean（生命周期）
4.4 解析web.xml ->listener->servlet

 

 

5 SpringBoot自动配置原理

5.1 自动配置类由各个starter提供，使用@Configuration+@Bean定义配置类，放在META-INF/spring.factories下，使用Spring spi扫描META-INF/spring.factories下的配置类，使用@Import导入自动配置类。

 

 

 

 

6 Spring事务什么时候会失效

https://blog.csdn.net/sufu1065/article/details/122076645

1 bean对象没有被Spring容器管理
2 方法的访问修饰符不是public
3 自身调用问题 - 同一个类A方法没有用事务，B方法用了事务，方法A调用方法B，则方法B的事务会失效
4 数据源没有配置事务管理器
5 数据库不支持事务 - 如果使用的数据库为MySQL，并且选用了MyISAM存储引擎，则Spring的事务就会失效
6 异常被捕获
7 异常类型错误或配置错误 - Spring中对于默认回滚的事务异常类型为RuntimeException，上述代码抛出的是Exception异常

7 Spring事务的隔离级别有哪些

https://blog.csdn.net/jj89929665/article/details/111321842

Spring中的事务隔离级别就是数据库中的隔离级别，有以下几种：
7.1 读未提交（read uncommitted）

事务尚未提交，其他事务即可以看到该事务的修改结果。隔离级别最差，脏读、不可重复读、幻读都不能避免。
7.2 读提交（read committed）

事务只能看到其他事务提交之后的数据。可避免脏读，不可重复读、幻读无法避免。
不可重复读原因：A事务修改，B事务查询，A提交前和提交后，B事务看到的数据是不一致的。
幻读原因：A事务修改，B事务新增，B事务提交前，A事务已经提交。B事务提交后，A发现仍有数据未修改。
7.3 可重复读（repeatable read）-------innodb默认隔离级别

一个事务多次查询，无论其他事务对数据如何修改，看到的数据都是一致的。因为A事务查询数据时，若B同时在修改数据，A事务看到的永远是B事务执行前的数据。只有当A提交或者回滚之后，看到的才是最新的被B修改知乎的数据。可避免脏读、不可重复读，幻读无法避免
7.4 序列化（serializable）

事务顺序执行，可避免脏读、不可重复读、幻读，但效率最差。因为A事务执行时，其他事务必须等待。

    Spring 事务隔离级别设置为（isolation = Isolation.DEFAULT）时，以数据库的隔离级别为准。Spring 事务隔离级别设置为非（isolation = Isolation.DEFAULT）时，Spring会拿到当前会话链接，重写了数据库的隔离级别，但没有直接修改数据库的隔离级别，此时以 Spring 事务为准。

    隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免更新丢失、脏读，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

脏读：A事务读出一条不存在的数据，这个问题很严重

不可重复读：A事务多次读取同一个数据，B事务在事务A读取过程中，对数据更新并提交，导致事务A多次读取同一数据时结果不一致。

幻读：select某条记录是否存在，不存在准备插入此记录时，但执行instert时发现此记录已存在，无法插入。

Oracle数据库支持Read Commited/Serialized/read only隔离级别，默认隔离级别是Read Commited。
大多数数据库默认的事务隔离级别是Read committed，如Sql Server , Oracle。Mysql的默认隔离级别是Repeatable read。