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。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

 

posted @ 2022-11-27 19:54  NingShare  阅读(234)  评论(0编辑  收藏  举报