Java突击面试八股文（15个技术栈，持续更新中）

1. Java如何避免死锁

• 注意加锁的顺序，保证每个线程按顺序进行加锁；
• 加锁时限，可以设置一个超时时间；
• 注意死锁检查，这是一种预防机制，可以确保发生死锁的第一时间进行处理。

3、 多线程（线程池）

2 线程有哪些状态（生命周期）
新建、就绪、运行、阻塞、死亡

3 如何获取多线程的返回值？
深坑！如果问多线程的创建方式，你一定知道是继承Thread类，实现runnable,callable接口。这里就是拐了个弯，变相的了解有返回值的callable接口。通过中间媒介FutureTask，将实现callable接口的类对象传递进去，调用FutureTask里面的get（）方法，即可获取多线程的返回值。

4 为什么使用线程池，几个参数？
降低资源消耗（创建、销毁耗资源），提高响应速度（任务来了，可以有线程直接使用）；

• 核心线程数、 最大线程数量、最大空闲时间、 空闲时间单位、任务队列、 线程工厂、拒绝策略；

4、并发相关问题

4.1、 并行、串行、并发？

• 并行： 同一时刻，多个任务互不干扰的同时进行；
• 串行：任务排队，一个一个执行；
• 并发：同一时刻，只有一个任务，多个任务交替执行；

篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处即可】免费获取

4.2、 谈谈对AQS的理解，AQS如何实现可重入锁？

• AQS是一个Java线程同步的框架，是JDK很多锁的核心实现框架。
• 在AQS中,维护了一个信号量state和一个由线程组成的双向链表队列。其中，这个线程队列就是给线程排队的，而state就像是红绿灯，用来控制线程排队或者放行的。不同场景下，有不同的意义。
• 在可重入锁（锁了还可以再锁）场景下，state表示加锁次数，0表示无锁，每加一次锁，state就加1，释放锁state就减1。点击阅读 并发编程小结；

二、mysql相关问题

笔者总结了一篇Mysql高级，涉及内容较深些，也是常问的面试题，点击链接查阅

Mysql高级篇

1、Mysql索引

1.1 索引的类型可以是String类型吗？
聚簇索引----数据和索引放一块，像主键索引，具有唯一性（Innodb就是）
数据库第一范式：必须要有id，这个id是自带索引的。

一般用自增id，字符串可以做id，但是不好，像uuid做的id是随机的，都没有排序！！！不像自增id维护索引的成本会很低

1.2 什么是索引？什么情况下用索引？什么时候不用？

1）就是一种数据结构，目的就是为了快速查找数据。
2）对查询频率高（索引就是为了提高查询效率），像where后的字段
数据量特别大， 索引不是越多越好，会影响增删的效率，典型的用空间换时间。
分组字段可以建立索引，因为分组的前提是排序（覆盖索引）
3）频繁更新的字段、查询少的、参与计算的不适合建索引。

1.3 索引失效？

在MySQL中，查询不走索引可能有以下几种情况：

1. 数据量太小：如果表中的数据量比较小，MySQL会选择进行全表扫描而不使用索引，因为全表扫描的开销可能比使用索引更小。

2. 对索引列进行了函数操作：如果在查询语句中对索引列进行了函数操作或表达式运算，MySQL无法使用索引进行优化，因此可能不走索引。

3. 范围查询：如果查询语句中包含范围查询（例如大于、小于、区间查询等），MySQL可能无法使用索引进行优化，导致不走索引（模糊查询like,%前置不会走，后置会走）。

4. 数据分布不均匀：如果索引列的数据分布不均匀，索引的选择性较低，MySQL可能选择进行全表扫描而不使用索引。

在进行MySQL索引优化时，需要考虑以上情况，并通过分析查询语句、优化索引设计、适时更新统计信息等方法，提高MySQL查询性能，尽可能减少不走索引的情况。

1.4 查看索引使用和查看索引信息？
索引使用： explain 结果 （只要数字大于1）1 row in set 即生效了
查看索引信息： show indexs from 表名

1.5 复合索引？最左匹配原则？
最核心的是 等值比较
复合索引就是多个字段放一块（企业最常用的是符合索引！！！唯一索引，普通索引我们也用）
mysql会一直向右查询，直到遇到范围查询（> < like），比如用 a b c d四个字段创建了一个复合索引， a=3 b=5 c>7 d=9 只会用到前三个，因为b c d 是根据a 的后面进行规则的排序，即a是有序的，后面的bcd是无序的。 （hash索引用的不多，因为无序，但是定位快，了解即可）

1.6 Btree和B+tree？为什么mysql用的是B+ tree？**
B+tree是Btree的升级版。
Btree：多路平衡树，当增删数据时，会自动的将数据进行这个平衡（旋转）
为什么从Btree转到B+tree? 因为：索引也是一个文件，存档在磁盘，在使用时读入到内存。内存是有限的，如果索引文件过大，无法一次性全部加载，需要分批加载。在有限磁盘的限制下，B+tree可以减少磁盘的I/O。

对于B+tree，所有的数据都存在叶子节点，根和非叶子节点只是存储的指针，指向下一个数据的地址，由叶子节点再去查找到关联的数据信息。对于查询的数据，都要从root节点走到叶子节点，所以查询相比于Btree更加稳定。

对于mysql，是在B+tree的基础上，在相邻节点间增加了一个链表指针，形成了带有顺序的B+tree,提高了区间的访问性能。

1.7 覆盖索引与回表
如果只需要在一棵索引树上就可以获取Sql所需要的所有列，就不需要回表查询，这样查询速度会更快。而实现覆盖索引最快的方式就是将所需要的字段放在一起建一个联合索引。

1.8 Mysql的锁有哪些？什么是间隙锁？
从锁的粒度来分
1、行锁：加锁粒度小，但是加锁的资源开销比较大。Innodb支持。
1）共享锁：多个事务可以共享一把锁，但是只能读不能修改
2）排他锁：只有一个事务可以获得排他锁，其他事务不能获取该行的锁。Innodb会自行对增删改操作添加排他锁。
2、表锁：加锁粒度大，加锁的资源消耗小，Mysalm和Innodb都支持。
3、全局锁：加锁后全库都处于只读状态，用于全库数据备份。

表被锁了怎么办，kill掉！！！

1.9 海量数据下，如何快速找到一条数据
1）使用布隆过滤器，快速过滤不存在的数据；
2）redis中建立数据缓存
3）查询优化

2、数据库分库分表

2.1 数据库的分库分表？什么时候分？怎么分？
当单表数据超过1000W时，很多操作的性能会下降，所以需要切分，以减少数据库的压力，缩短查询时间。
垂直切分：将关系联系不紧密的表进行分库，将一张表中不常用的字段进行抽取新建一张表。优点类似于微服务。
水平切分：当一个应用难以再细粒度的垂直切分，根据数据间的逻辑进行划分，比如客户、存款、支付；
2.2 数据库的优化?
1）sql优化以及索引的优化，索引建立要合理，过多会影响增删性能
2）数据可设计要满足他的三大范式、五大约束
3）硬件优化

2.3 表设计的时候注意哪些，字段？

在设计数据库表时，需要注意以下几点，特别是在定义字段的时候：

1. 数据类型选择：选择最适合的数据类型可以减小数据库表的存储空间，提高检索效率。对于整数、浮点数、字符串等不同类型的数据，选择合适的数据类型是设计表结构时的关键之一。

2. 索引设计：根据实际查询需求设计合适的索引，可以提高查询效率。通常在主键、外键、经常用于查询的字段上创建索引。

3. 主键设计：选择一个唯一、稳定、易于理解的字段作为主键，以确保每条记录都有唯一标识，便于数据访问和管理。

4. 字段命名规范：字段命名应具有描述性，易于理解和记忆，建议使用下划线分隔（如：first_name），避免使用含糊不清或缩写的字段名。

5. 字段约束：定义字段的约束条件，如NOT NULL、UNIQUE、DEFAULT值等，可以保证数据的完整性和一致性。

6. 数据冗余：避免数据冗余，尽可能将重复的数据抽取成单独的表，以减小数据存储量，同时避免数据更新异常。

7. 参照完整性：在设计外键关系时，保证参照完整性，确保相关数据的一致性，避免数据关联异常。

8. 考虑数据增长：预估数据表的增长情况，选择适当的存储引擎和分区方案，以支持未来数据量的增长。

综上所述，在设计数据库表结构时，字段的数据类型、索引设计、主键选择、命名规范、约束条件、数据冗余、参照完整性、数据增长等方面都需要认真考虑，以保证数据库表的稳健性、性能和灵活性。

3、数据库事务

spring里面的事务和mysql里面的事务是一个概念，如果mysql不支持事务，加上@transation也是无效的。但是spring里面的@transation不能用于分布式环境下，分布式多线程下用的是senta+@globalTransation注解。
3.1 @transation用于类和方法有什么区别？
@transation只能修饰public方法。
类上：相当于在所有的public方法上加上了@transation注解
方法：会覆盖类上的配置。

 篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处即可】免费获取

3.2 事务的4个条件ACID
原子性：所有的操作是一个整体，要么全部成功，要么全部失败（回滚）
一致性：事务开始前后，数据库的完整性没有被破坏，也就是写入的资料完全符合我们的预设。
隔离性：允许多个并发事务对数据进行读写操作，它可以有效的防止多个事务并发执行时由于交叉执行而导致数据的不一致。（隔离性里面有4个隔离级别：读未提交、读以提交、可重复读、串行化）
持久性：事务完成，对数据的操作就是永久的，即使系统故障也不会丢失。

3.3 事务的传播机制
事务的传播行为是针对嵌套事务而言,解决方案也就是融合、嵌套、外部挂起这三种的组合，一共7种：
Require： 外部事物有，融入外部事物，没有就自己创建一个事务，适合修改多的

Support：当前方法不需要事务上下文，support表示支持，B支持A的事务
Not- support：此方法不应该存在在事务里，如果存在当前事务，将事务挂起

Mandatory：必须有事务，当前事务不存在就抛异常
Never： 不能有事务，有事务就抛异常

Require- new： 外面有就将外面的挂起，开启一个新的
Nested：嵌套，可以支持独立的回滚、提交

3.4 mysql事物隔离级别？

MySQL 提供了四种隔离级别，用于控制事务之间的隔离程度，以确保事务操作的一致性和并发性。这四种隔离级别分别是：

1. 读未提交（Read Uncommitted）：最低的隔离级别，允许一个事务读取另一个事务未提交的数据。可能会出现脏读（Dirty Read）问题。

2. 读提交（Read Committed）：其他事务提交后才能读取数据，避免脏读问题。但可能会出现不可重复读（指的是在同一个事务中，某个查询操作在不同时间点内多次执行，但由于其他事务的并发操作，在多次执行过程中返回的数据结果不一致的情况）问题。

3. 可重复读（Repeatable Read）：保证在同一个事务中多次读取同一行数据时，结果始终一致。避免了脏读和不可重复读问题。但依然可能存在幻读（在相同的查询条件下，不同的事务在不同时间点执行查询操作时，可能会看到不同数量的行，从而产生"幻像"的错觉）问题。

4. 串行化（Serializable）：最高的隔离级别，通过确保事务串行执行来避免脏读、不可重复读和幻读问题。确保所有事务的并发执行不会导致数据不一致。

在 MySQL 中，可以通过设置事务的隔离级别来控制事务的隔离程度，从而灵活地平衡并发性能和数据的一致性。开发者可以根据实际需求选择合适的隔离级别来确保数据操作的正确性和安全性。

4、Mysql其他问题

4.1 mysql中的null和空值有什么不一样？
1）空值是不占空间的，null值占用空间。两者就像：空值是真空状态的杯子，而null值是装满空气的杯子。
2）查寻上：null 值是用is null/is not null来查询，而空值( ’ ’ )则可以用 = > !=等。 在使用聚合函数count时，会过滤掉null，而不会过滤掉 （ ’ ’ ）值。
在实际开发中，没有特定需求，可以直接使用空值！！！

4.2 mysql主从数据库延时的原因？

MySQL主从数据库延时可能有多种原因，以下是一些常见的原因：

1. 网络延迟：主从数据库之间的网络连接如果不稳定或者网络质量差，会导致数据同步的延迟。

2. 主从数据库负载：主数据库的负载过高，或者从数据库的性能不足，都可能导致数据同步延迟。

3. 数据量过大：如果要同步的数据量过大，或者有大量的写操作，都会增加同步的时间。

4. 复制方式设置不当：MySQL复制方式（如异步复制、半同步复制等）的配置不合理也会导致延时。

5. 主从数据库版本不兼容：如果主从数据库的版本不一致或不兼容，也可能导致数据同步延迟。

在排查MySQL主从数据库延时问题时，可以逐一检查上述可能的原因，逐步定位并解决问题。

4.3 mysql主从复制的过程？

MySQL主从复制是一种常见的数据库复制技术，用于将主数据库中的数据实时同步复制到从数据库。以下是MySQL主从复制的基本过程：

1. 配置主数据库：首先需要在主数据库上开启二进制日志（Binary Log），并配置主机的唯一标识（Server ID）。

2. 配置从数据库：在从数据库上配置连接主数据库的信息，包括主数据库的IP地址、端口号、用户名密码等。同时设置从数据库的唯一标识（Server ID）。

3. 启动主从复制过程：在从数据库上执行CHANGE MASTER TO命令，指定主数据库的连接信息，并启动从数据库与主数据库的连接。

4. 数据传输与同步：当主从数据库连接成功后，主数据库会将变更写入二进制日志，并通过主从复制线程将这些变更传输给从数据库，从数据库接收到变更后应用于自身数据库，实现数据同步。

5. 监控与维护：定期检查主从数据库的状态，确保主从复制正常运行。如果发现延迟或同步失败，需要及时排查并解决问题。

总的来说，MySQL主从复制的过程包括配置主从数据库、启动复制、数据传输与同步以及监控与维护等步骤。通过主从复制，可以实现数据的备份、负载均衡以及容灾等功能。

4.4、mybatis和mybatis-plus的区别？
1、mybatis-plus基于mybatis的基础上，对单表操作进行了优化，能够更快速地进行开发。
2、MyBatis 构造复杂的 SQL 查询条件需要手动编写 SQL 片段，不够直观。mybatis-plus则通过条件构造器，链式编程更直观。

四、JVM虚拟机

笔者此前在其他博客上整理过，不在重复，链接如下：

 篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处即可】免费获取

五、Redis面试题

1 、缓存雪崩、缓存穿透、缓存击穿

• 缓存雪崩： 缓存同一时间大面积失效，大量请求打到数据库上，数据库承受不住崩掉；
  解决方案：过期时间设置成随机、缓存预热（系统出初启动，先存数据到缓存里）
• 缓存穿透： 数据库和redis中都没有数据，导致大量数据查询数据库，导致数据库崩掉；
• 可以将不存在的请求key的value 设置成一个字符串返回，这样就避免了黑君攻击到数据库。
  解决方案： 接口层进行校验（id<0的直接拒绝）、采用布隆过滤器
• 缓存击穿： redis的一个key失效，请求全部打到数据库（缓存没有数据库有）；
  解决方案： 热点数据永不过期，设置成空字符串返回

2、 如何保证数据库和Redis的数据一致性

当我们遇到这个问题时，要考虑是先删缓存，还是先写数据库。
延时双删： 先删redis缓存数据，再更新数据库，然后再删redis缓存,这样就避免了删除redis和更新数据库这期间，其他的线程读不到redis里的值，去读数据库里的旧数据。

将操作可串行化（先写在读就可以了）
1）先删缓存，将更新数据库操作放到一个有序队列中
2）从缓存中查不到的查询操作，都进入有序队列（MQ）
问题：大量读请求积压--------> 将队列水平拆分

3、Redis的数据结构及使用场景

String :字符串 ----------原子计数器
List ：列表 ---------微博、微信等消息流数据
Set ：无序集合 ---------好友推荐
Zset ：有序集合 -----------排行榜
Hash ：哈希表 ----------适合存储对象

----------------------------------前五种为常见，后四种为面试加分项-------------------------------------------
bitmap:布隆过滤器
GeoHash:坐标，（存储坐标的）基于Zset的score进行排序就可以得到坐标附近的值
HyperLoglog: 统计不重复数据，用于大数据基础使用
Streams:内存版的Kafka，消息的订阅发布

4、Redis持久化机制有哪些

基于内存，宕机数据会消失，所以需要持久化。有两种方式

• RDB：Redis DateBase
  在指定的时间间隔内将内存中的数据以快照的形式写入磁盘,实际是fork（分支）一个子进程，先将数据复制写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

优点：

• 整个redis数据库将只有一个dump.rdb文件，方便持久化；
• 容灾性好，方便备份；
• 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。使用单独子进程来进行持久化，主进程不进行任何的IO操作，保证了Redis的高性能；
• 相对于数据集大时，比AOF的启动效率更高；

缺点：

• 数据安全性低。持久化期间Redis发生故障，会有数据丢失；

AOF: Append Only File
以日志的形式记录服务器的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录

优点：

• 数据安全，每次修改都会被记录到磁盘中；
• 通过append模式写文件，即使Redis宕机，也不会破坏已经存在的内容，可以通过redis-check-aof工具解决数据一致性问题；

缺点：

• 效率没有RDB高；
• AOF文件比RDB大，且恢复速度慢；

5、Redis其他常见问题

5.1 Redis线程模型，单线程为什么快？

单线程快的原因有以下几点:

• 纯内存操作
• 核心是基于非阻塞的IO多路复用机制(单个线程可以同时处理多个请求)
• 单线程避免了多线程来回切换的上下文环境切换问题

5.2 Redis分布式锁的实现原理
Redis 分布式锁的原理主要基于 Redis 的原子性操作和键过期机制。以下是 Redis 分布式锁的基本原理和实现方式：
set(key,value,setnx,setpx)
setnx----------->加锁的命令
setpx----------->锁的过期时间
setnx+setp在高版本中已经整合为一个原子命令。
当任务超时，锁自动释放怎么办？可以使用redission的看门狗，会自动续期。

1. 获取锁：

   • 客户端使用SET命令尝试在Redis中设置一个特定的键作为锁，可以设置一个固定的值作为锁持有者的标识，同时设置一个过期时间（防止锁无法释放导致死锁）。
   • 设置键时使用NX参数（即只在键不存在时才能设置成功），这样可以确保只有一个客户端能够成功设置该键，获得了锁。

2. 释放锁：

   • 当客户端要释放锁时，可以通过DEL命令来删除这个键，确保该锁被释放。

3. 防止死锁：

   • 设置锁时可以为键设置一个合理的过期时间，以防止锁无法释放导致死锁。即使持有锁的客户端在处理任务时发生异常退出，保证锁在一定时间后会自动释放。

4. 避免误删除：

   • 尽量不要使用DEL命令直接删除锁，因为可能会误删其他客户端的锁。可以使用Lua脚本来确保原子性操作，只有持有锁的客户端才能成功释放锁。

总的来说，Redis分布式锁的实现原理基于对Redis的SET命令设置NX参数进行加锁和DEL命令释放锁，配合合理设置过期时间来保证分布式锁的正确性和稳定性。通过合理设计和管理分布式锁，可以帮助多个客户端在分布式环境中协调访问共享资源，避免竞争条件和数据不一致问题。

5.3 Redis主从复制的原理
简述好下面的流程图即可（基本使用哨兵模式，基于主从复制的基础上，可以保证高可用，哪个节点挂了就重新选举）

5.4、Redis 到底是单线程还是多线程？
Redis6.0 版本之前的单线程指的是网络 I/O 和键值对读写是由一个命令完成的；
Reds6.0 版本之前只有网络请求模块和数据操作模块是单线程的，而其他的特久化，集群数
据同步，其实是由额外的线程完成的
Redis6.0 版本之后的多线程指的是网络请求过程采用了多线程，而键值对的读写命令依然是单线程处理，所以Redis 是线程安全的。命令的执行排队执行
5.5、 单线程为什么快？
内存操作、单线程操作没有线程切换开销、全局 hash表 〈一维数细：链表〉查找快
5.6、Redis 底层数据如何用跳表来存储的？
跳表：将有序链表改造为支持近似“折半查找”算法，可以快速的插入、删除、查找操作。
5.7、Redis 的Key过期了，为什么没有释放？
有两种删除策略：
惰性删除：当读到一个过期的key时触发删除
定时删除：惰性删除无法及时删除，所以 Redis默认每 100ms 主动删除一批己过期的 key,导致可能出现部分 key 过期但没被清理的情况，导致内存并没有被释放。
小坑：如果使用set命令修改某个key 的valve 值，没有加过期时间参数，这个key会被设定为永久有效。
5.8、 Redis 没设置过期期间，为什么被 Redis 主动删除了？
当Redis 已用内存超过最大内存时，会触发主动清理策略（8种)，对过期key所有 key设置了处理。可能触发了对所有key 的筛选删除（LRU：最近最少使用，LFU：最少频率使用)。
5.9、删除key 的命令，会阻塞 Redis吗？
删除 String 类型，时间复杂度 o(1),删除单个列表、集合或 hash 类型的key时间复杂度为 o(M)；
5.10、一次线上事故，Redis 主从切换导致了缓存雪崩
（要保证主从库机器时钟一致）我们假设，slave 的时钟比master 的时钟快很多。我们在master 里设置了过期的key， slave的角度看，可能会有很多在master里没有过期的数据己经过期了。如果此时操作主从切换，把 slave提升为新的master，就会开始清理大量的key;会导致以下结果：
① Master大量清理 key，主线程阻塞，无法及时处理客户端请求；
② Redis 大量数据过期，引发缓存雪崩。

5.11、线上Redis 持久化策略一般如何设置？
默认 RDB， 如果对性能要求较高，在master最好不要做持久化，可以在某个 slave 开启 AOF
备份数据，策略设置为每秒同步一次即可。
5.12、一次线上事故，Redis 主节点宕机导致数据全部丢失
如果 Redis 采用以下模式部署，就会发生数据丢失问题：
master-slave+哨兵部署实例 ＋master 没有开启持久化功能 ＋Redis 进程使用supervisor管理，并配罟宕机重启。
这样在master言机，哨兵还未发起切换，supervisor 会将 master 立马拉起，但因为 master
没有设置持久化，就相当于是空实例，其他的 slave为了会master 保持数据同生，也会变成一个个空实例，也就发生了数据丟失。
避免：不要给 Redis 主节点设置宕机立马重启，而应该等哨兵把某个 slave选为 master之后，在重启原来宕机的主节点，让其变成 slave。
5.13、Redis主从复制风暴是怎么回事？
Redis 主节点有多个从节点，在某一时刻主节点挂了，重启后从节点重新连上主节点后，进行全量复制，数据量大，加重网络和服务器的页载。避免方法：使用哨兵或集群模式。

red is集群是通过分片技术，hash到不同的节点上

六、SSM和SpringBoot

1、Spring相关问题

Spring必问ioc和aop，基本程序员都知道，但如果想要获得好的印象，拉开差距，就要回答出更深的理解，阅读过源码是最好的，总结过一些spring的细节问题，点击链接阅读 spring杂记

1.1 Spring是什么？谈谈IOC和AOP的理解
Spring是一个企业级的应用框架，减化了配置，简化了项目部署环境。

IOC: 容器概念、控制反转、依赖注入

• ioc容器：
  实质就是一个map（key,value）里面存放了各种对象（xml里的bean节点，@Service 、@Conroller、@Compent等），在项目启动时，会读取配置文件里的bean节点，根据全限定类名使用反射创建对象，存入到map中。这个时候map里就有我们需要的各种对象了，当我们需要使用时，通过DI（@Autowired、@Resource等注解，xml里的ref标签）注入的方式去取。

• 控制反转:
  没有引入ioc容器前，我们A对象依赖于B对象，需要自己手动的去new，引入ioc后，需要B对象的时候ioc自己主动去创建一个B对象到A需要的地方。A对象获取B对象的过程，从主动变成了被动，这个就是控制反转的由来。

• 依赖注入:
  依赖注入是实现IOC的方法，就是在IOC运行期间，主动的将某种依赖关系注入到对象中；

AOP：将程序中的交叉业务逻辑（日志、异常、安全）封装成一个切面，对符合其要求的对象进行一个增强，比如一个方法的增强，在方法执行前或执行后做一些额外的事（通过beanPostProcessor实现）。

 篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处即可】免费获取

1.2 说一下Spring的事务机制

Spring的事务机制是基于数据库事务和AOP。
对于加了@Transation的注解，会创建一个代理对象作为bean，当调用代理对象方法时，会判断该方法上是否加了@Transation的注解，如果加了，就利用事务管理器创建一个数据库连接，将autocommit改为false,禁止自动提交，事务结束没有异常就提交，反之回滚。

什么时候@Transation会失效？方法加了private私有时会失效。非代理对象调用也会失效

1.3 Spring 的bean生命周期
Spring的bean生命周期里面涉及的内容很多，这里只是说一个大致流程，面试非大厂足够了

有一个类 UserService.class--------> 推断构造方法（默认无参构造）---------> 实例化（普通对象）----------> 依赖注入（属性赋值，加了@Autowire -------> 初始化前(@PostConstruct) --------> 初始化(initializingBean)--------> 初始化后（AOP）---------> 代理对象 ------>bean

读取配置信息获取到beandefinition（BeanDefinition 是定义 Bean 的配置元信息接口），存入到map中，推断bean的构造方法，进行实例化，然后进行属性赋值，在初始化后会进行aop的切面，如果创建的bean是单例的，会将单例bean放入到单例池中。之后进行bean的使用，使用完后会调用
destroy（）方法进行销毁；

2、SpringMVC执行流程

1、具体执行流程如下，面试前背下来即可(截图可放大)！

2、父子容器

springmvc创建了一个自己的容器，并且继承了spring的容器？
是，在 Spring MVC 中,DispatcherServlet会创建一个自己的 ApplicationContext 容器,这个容器是继承自 Spring 应用程序的根 ApplicationContext 容器的。
具体过程如下:

1. 启动 Spring 应用程序时,会创建一个根 ApplicationContext 容器。这个容器包含了应用程序中所有的bean,如 Service 层和 Repository 层的 bean。

2. 当 DispatcherServlet 被初始化时,它会创建自己的 ApplicationContext 容器。这个容器是根ApplicationContext 容器的子容器。

3. DispatcherServlet 容器会继承根 ApplicationContext 容器中的所有 bean,因此可以访问这些bean。但根 ApplicationContext 容器无法访问 DispatcherServlet 容器中特有的 bean,如Controller 等。

这种父子容器的关系提供了以下优点:

• 关注点分离: Web 层的 bean 和业务层的 bean 被分隔在不同的容器中,提高了代码的可维护性。

• 资源隔离: Web 层的资源不会影响到业务层,提高了应用程序的健壮性和安全性。

• 依赖管理: DispatcherServlet 容器可以访问根容器中的所有 bean,无需重复定义。

总之,Spring MVC 通过创建自己的 ApplicationContext 容器并将其设置为根容器的子容器,实现了父子容器的架构设计,提高了应用程序的模块化和可扩展性。

3、Springboot自动装配原理

Springboot有一个引导类叫SpringBootApplation,在这个类里面有很多注解，@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan
与我们自动装配有关的是@EnableAutoConfiguration这个注解，这个注解里面有个@import注解，里面导入了AutoConfigurationImportSelector这样一个类，在这个类里面有个getCandidateConfigurations方法，这个方法就会找到Meta文件下的spring.factories，在spring.factories里面有很多全路径类名，通过反射加载到ioc容器中

问：spring.factories里面的类都会全部加载吗？不是的，符合条件的才会进行加载！

4、微服务&Dubbo

微服务&Dubbo

七、网络与IO面试题

1、网络

1.1 TCP和UDP的区别

• TCP：面向连接、可靠的、传输层通讯协议。
  特点：好比打电话，点对点的，高可靠的，效率较低，占用的系统资源较多；
• UDP: 面向无连接的、不可靠的、传输层通讯协议
  特点：好比广播，不需要连接，不管接收方有没有准备好，都可以直接发消息。效率高，有可能消息丢失，协议比较简单，所以占用的系统资源较少。

1.2 TCP为什么三次握手，四次挥手？

1)在建立TCP连接时，需要通过三次握手来建立，过程是：

客户端 ---------- 发送syn ----------------> 服务端

客户端 <-------- 发送syn-ack确认------- 服务端

客户端 ----------发送ack -----------------> 服务端

2)在断开TCP连接时，需要通过四次挥手来建立，过程是:

客户端 ---------- 发送 FIN ------------------------> 服务端

客户端 <-------- 发送ACK确认-------------------- 服务端 (表示我收到断开的消息，但还有数据要处理)

客户端 <----------发送FIN -------------------------- 服务端(表示数据处理完了，客户端可以断开了)

客户端 --------发送ACK(表示也会断开--------> 服务端

1.3 Http和Https的区别？

• HTTP:是网络上应用最为广泛的一种网络通讯协议，是基于TCP协议的，可以使得
  浏览器工作更为高效，较少网络传输；

• HTTPS:HTTP的加强版，可以认为是HTTP+SSL(Secure Socket Layer) 。在HTTP的基础上增加了一系列的安全措施。一方面保证了数据的传输，一方面对访问者增加了安全校验机制，是目前现行架构下，最安全的解决方案。 缺点是握手协议费时，会影响吞吐量以及服务器的响应速度。

主要区别：

• http是免费的，https是需要申请证书，收费的
• http默认端口80，https默认端口443

 篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处即可】免费获取