java基础复盘



前言：现在大环境不好，企业对候选人的要求越来越高。面试更多的是问项目问场景题，偶尔穿插八股文，但本质还是要回归八股文的理论知识。几个面试小tip：
1、相比全程微笑，不如冷漠脸显得成熟稳重，不卑不亢反而让人觉得你厉害。
2、回答问题要慢！慢下来能够有时间思考，回答思路更清晰。同时在有限的时间里可以让面试官提问更少的问题。
3、收到第一个offer，不论工资多低，不想去也要接下来。有个保底的就有了挑的资本，也多了几分底气。
4、只有真正入职才可以拒绝多余offer，否则对方爽约只能重新花时间找（亲身被坑，导致丢掉已有的2个offer）

一、Java基础面试题

1、面向对象

1.1 面向对象和面向过程的区别？
面向过程，是站在计算机的角度出发，以代码执行过程为核心，考虑到让计算机先做什么、再做什么。而面向对象，是站在人的角度，从现实生活出发。比如一个司机和车，是use a 的关系，不管司机开不开车，车这个对象都要有能跑的属性。说白了，人们生活中解决问题的思路其实就是面向对象。
1.2 面向对象的三大特性？

• 封装：核心思想就是“隐藏细节”，对外提供访问属性的方法。保证了数据的安全和程序的稳定。
• 继承：将子类共性的属性或者方法抽取出来成为父类，子类继承后就不用重复定义父类的属性和方法，只需要扩展自己的个性化。强制继承父类非私有的属性和方法，破坏了封装性原则。
• 多态：基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同。
  继承，方法重写，父类指向子类对象。无法调用子类特有的功能；

笔者在看设计模式和spring源码时，对面向对象有了进一步的认识。如果说封装和继承是面向对象的基石，那么多态则是面向对象的具体使用。编译看左边，运行看右边。 在日常书写代码时，尽量使用List list=new ArrayList();这种形式，左边为抽象父类，右边为具体的实现子类。这样的书写方式，不仅代码兼容性更好而且具体的实现细节由具体的对象去执行完成，这才是面向对象的初衷和设计核心！

2、HashMap底层原理

2.1 什么是哈希表？哈希冲突？如何处理哈希冲突？
1）、什么是哈希表？
如何在一个无序的线性表中查找一个数据元素？答：对着线性表遍历！但这样时间复杂度会很高，查找耗费性能。那有没有这样一种数据结构，数据结构中的元素和它所在位置有一个对应关系，这样就可以通过元素找到它的位置，时间复杂度就降低了。这种数据结构就是哈希表！
哈希表又叫散列表，通过映射函数f(key)将一组数据散列存储在数组中的一种数据结构。在哈希表中，每个key和它所在位置都有一个映射关系，可以通过f(key)来轻易找到。比如映射关系f(key)=key/11;
2）、什么是哈希冲突（哈希碰撞）？
比如f(key)=key/11，当值为key为6和72时，余数都是6，72该怎么存呢？这就是哈希冲突！
3）、如何减少哈希冲突？
哈希冲突不可避免，但能减少！这里提供几种最容易理解的几种解决方案：
1）再哈希法：选取若干个不同的哈希函数，当发生哈希冲突时，执行另外的哈希函数，直至不冲突为止。
2）链地址法（最常用！！！）：这个就是与红黑树相关了！当我们出现[48,15,26,4,70,82,59，28，6，17]。我们这组数据仍然散列存储到长度为11的数组中，出现多个能被11整除的元素时（6，28，17），就会在第一个余数为6的元素下依次挂上，即形成所谓的链表！但链表太长查询效率又会降低，为了优化时间复杂度，当链表长度大于8时，会形成红黑树（可自平衡的二叉红黑树）
4）、哈希表的扩容与Rehash
在链表长度不变的情况下，插入元素越多，越容易哈希冲突。这时就进行扩容，当装载因子填充到一定数值（一般选0.75），就进行2倍扩容，然后将原来的数据重新装到新的扩容好的数组中（该过程即Rehash）

2.2 hashmap为什么是线程不安全的？
在并发下put数据，会发生数据覆盖、数据错乱。hashtable用的是synchronized关键字，而ConcurrentHashMap在jdk1.7之前是用了粒度更小的分段锁，1.8之后用的是synchronized+cas锁。
cas锁：没有获取到锁的线程不会阻塞，而是会循环控制不断获取锁。
2.3 HashMap扩容机制
jdk1.7，是数组+链表，扩容时会新生成一个数组，遍历老数组的每个链表上的元素，取每个元素的key，基于新数组的长度，计算出在新数组中的位置，将元素添加进去；
jdk1.8,是数组+链表+红黑树，扩容与jdk1.7时大致相同，不同的是，一棵红黑树进行计算时可能在新的数组中形成2个链表或是1个链表+1个红黑树。
2.4 说一下HashMap的Put（）方法？
在jdk1.7和jdk1.8，都是先根据key哈希计算出在数组中的位置。

• 1、如果数组下标为空，则将key和value封装成一个Entry对象（jdk1.7是Entry对象，jdk1.8是Node对象），直接添加。
• 2、数组下标不为空，jdk1.7先判断是否需要扩容，不需要则通过头插法插入到链表中；jdk1.8,先判断当前Node节点上是红黑树还是链表，先生成一个Node节点通过尾插法进行插入，然后在进行扩容判断，不需要扩容则结束Put()。

2.5 CorrentHashMap()如何保证线程安全？

• 并发工具类-ConcurrentHashMap1.7原理
  
• 并发工具类-ConcurrentHashMap1.8原理
  

jdk1.8时的总结 :

​ 1）如果使用空参构造创建ConcurrentHashMap对象，则什么事情都不做。在第一次添加元素的时候创建哈希表，计算当前元素应存入的索引；
2）如果该索引位置为null，则利用cas算法，将本结点添加到数组中；
3）如果该索引位置不为null，则利用volatile关键字获得当前位置最新的结点地址，挂在他下面，变成链表；
​ 4）当链表的长度大于等于8时，自动转换成红黑树；以链表或者红黑树头结点为锁对象，配合悲观锁保证多线程操作集合时数据的安全性

3、 ==和equals（常见于笔试）

==　： 对于基本数据类型的变量，比较的是值。引用类型比较的地址值。

equals：equals方法不能作用于基本数据类型。对于引用类型的变量，没有重写equals比较的是内存地址；重写equals比较的是变量所指的对象内容。

4、 ArrayList 和LinkedList区别

• ArrayList:
  基于动态数组，内存空间连续，所以查询快。但如果使用尾插法，并且制定好初始容量，会使性能极大提高，甚至超过LinkedList的插入速度。
• LinkedList:
  基于链表，可以存储在分散的内存中，适合做增删，不适合查询。

两者都实现了List接口，但LinkedList额外实现了Deque接口，所以LinkedList还可以当队列来使用。

5、 过滤器和拦截器区别

（这个问题基础，没想到问的频率挺高，还容易回答不好）
他们都可以在请求的过程中插入一手，他们的请求过程如下：当一个请求过来时，会交给web服务器提供的过滤器，再来到servert。有一个叫DispatchServert的servert,在它里面就会调用我们的拦截器，再由我们的DispatchServert分发给对应的controller来处理我们的请求。请求完成后，就会从调用的链路原路返回，在到我们的拦截器，然后过滤器。最终响应给客户端。
区别：
1）执行顺序不同
过滤器先执行，它是servert的一部分更接近底层，他会在servert之前和响应之后进行处理，依赖servert容器提供的filter，多个过滤器会根据过滤器的配置顺序来决定他们的执行顺序；
拦截器后执行，是springmvc的一部分，更接近业务层，会在controller请求之前和处理完毕之后进行处理。依赖于springmvc提供的handleInterceptor接口。多个拦截器的顺序由bean的配置顺序决定，可以通过@order来设置
2）用途不同
拦截器通常用于跟业务相关，像身份认证与授权、日志记录；
过滤器通过用于必要的基础工作，像编码处理，请求参数处理；

二、Java并发面试题

1、 ThreadLocal

1.1 谈谈你对ThreadLocal的理解？
ThreadLocal的作用主要是做数据隔离，填充的数据只属于当前线程，变量的数据对别的线程而言是相对隔离的。它不是针对程序的全局变量，只是针对当前线程的全局变量。

1.2 ThreadLocal底层实现原理？
Threadlocal内部有一个非常关键的内部类ThreadlocalMap，里面定义了一个由key - value组成的Entry数组，key存放的就是当前的线程，value为我们所需的数据。 而key是弱引用会被gc清除，value是强引用不会被清除，所以会造成内存泄漏。如果我们在线程池中使用了Threadlocal，一定要记得调用remove（）方法（），避免ThreadLocal 保存的数据被泄漏或污染！！！ 可以理解为 ThreadLocal 的 remove() 方法将当前线程的 ThreadLocal 变量的值替换成了 null。

2、synchronized相关问题

2.1 synchronized与Reentrantlock的区别

• synchronized是一个关键字，属于JVM层面的，Reentrantlock是一个类，是API层面的；
• synchronized是自动加锁、释放锁，Reentrantlock则需要手动加锁和释放；
• synchronized底层有一个锁升级的过程（偏向锁—轻量级锁----重量级锁）

当一个线程获取一个琐时，此时该锁为偏向锁，当第二个线程尝试获取锁时，该锁会升级为轻量级锁,底层通过自旋来实现（不会造成线程阻塞）,当自旋次数过多，会升级为重量级锁，会造成线程阻塞。

2.2 volatile关键字如何保证可见性和有序性

• 可见性：对加了volatile的成员变量进行修改时，会直接将cpu高级缓存区的数据放到主内存中，对这个数据的读取，会直接从主内存中取。
• 有序性：对加了volatile的成员变量进行读写时，会插入内存屏障，防止指令重排，保障了有序性。

volatile只有写操作是原子性的，也就是数据操作完成后会立刻刷新到主内存中。但是被volatile修饰的变量在读的时候可能会被多个线程读,所以它不能保证原子性。

2.3 Java如何避免死锁

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

3、 多线程（线程池）

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

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

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

• 核心线程数、 最大线程数量、最大空闲时间、 空闲时间单位、任务队列、 线程工厂、拒绝策略（默认抛出异常）；

小坑： 线程池的核心线程和空闲线程是怎么区分的？答案是线程池不区分，只是保证了线程池里有固定的线程是一直存活的（也就是核心线程数）

4、并发相关问题

4.1、 并行、串行、并发？

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

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时，很多操作的性能会下降，所以需要切分，以减少数据库的压力，缩短查询时间。
垂直切分：将关系联系不紧密的表进行分库，将一张表中不常用的字段进行抽取新建一张表。优点类似于微服务。
水平切分：当一个应用难以再细粒度的垂直切分，根据数据间的逻辑进行划分，比如客户、存款、支付； java基础复盘
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注解
方法：会覆盖类上的配置。

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

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

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虚拟机

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

1、JVM常问面试题

JVM常问面试题

2、JVM进阶面试题

JVM进阶面试题

五、Redis面试题

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

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

2、 如何保证数据库和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发生故障，会有数据丢失；

优点：

• 数据安全，每次修改都会被记录到磁盘中；
• 通过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实现）。

1.2 说一下Spring的事务机制

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

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

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

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

八、消息中间件

死信队列是什么？延时队列是什么？
1、死信队列也是一个消息队列，他是用来存放那些没有成功消息的消息的，通常可以用来作为消息重试
2、延时队列就是用来存放在指定时间被处理的元素，比如十分钟内未支付则取消订单。

MQ如何保证消息的幂等性？
其实就是要消费者解决重复消费的问题，所有的MQ产品都没有提供解决消息幂等性的机制，需要我们在消费端做处理。
RocketMQ: 给每个消息分配了一个MessageID,这个MessageID就可以作为消费者判断幂等的依据（消息量巨大时，无法保证MessageID是唯一的），所以最好是自己带一个全局唯一的业务id。

如何保证消息不丢失?

重点！！！ 将消息id和业务id放到一个队列里，消费成功后回调删除队列里的消息id来保证消息的一致性和不丢失，这种方法对所有的mq都通用。而在Kafka中，ack结合偏移量（offset）的方式来实现。ack确保消息发送成功，偏移量确保消息成功消费。

1、哪些环节会造成消息丢失？

• 主节点向从节点同步消息（跨网络），主节点挂了；
• MQ是基于内存工作的，最终消息都是要存到硬盘。（断电内存消息丢失）；

2、如何防止消息丢失？

• 生产者发送消息不丢失
  Kafka: 消息发送+回调（ack机制）
  RocketMQ: ①消息发送+回调 ②事务消息
  
• MQ同步消息不丢失

RocketMQ:普通集群中，同步同步（消息来，主从同步好发送成功）、异步同步（消息来，主节点直接发送成功，再异步给从节点）。同步同步安全性高，同步异步效率高，有消息丢失可能。

Kafka:通常使用在允许消息少量丢失的场景

• MQ消息存盘不丢失
  RocketMQ：（一个简单配置）同步刷盘（安全性高,消息不容易丢失）、异步刷盘（效率高、有消息丢失可能）
• 消费者消费消息不丢失
  RocketMQ：使用默认的消费，不要使用异步消费。
  Kafka:手动提交offset

1、Kafka

1、Kafka高性能、高吞吐的原因

• 磁盘的 顺序读写 ： 保证了消息的堆积（相比内存来说高吞吐）；顺序读速度接近内存，远高于随机读（传统的都是随机读写）；
• 零拷贝：磁盘文件–>内存缓冲区
• 批量压缩：多条消息一起压缩，降低带宽
• 批量读写

2、Kafka是pull还是push?
pull,这样consumer端可以根据自己的消费能力来拉取，可以批量也可以单条拉取。
缺点：没有消息会导致consumer的空循环，浪费资源。解决方案：设置参数，让空循环阻塞；

3、Kafka消息丢失场景及解决方案

发送：ack=0时，发送失败也就丢了
消费：先commit再处理消息，如果在处理消息时异常，但是offset已经提交了，这条消息对消费者来说就是丢失了，不会再消费了
减小broker的刷盘间隔：消息存放到broker中（page缓存），但最终是会刷到硬件中，如果这个间隔太长，刷的时间也会长，也更容易宕机。

4、Kafka如何保证消息有序
消息有序核心在于：发送有序和消费有序。
Kafka是partition内的消息有序，partition与partition之间不一定有序。所以在生产端可以设置相同的分区键（Partition Key），使得所有消息都发送到同一个partition里。消费端只有一个消费线程去处理这个partition里的数据。

5、Kafka那么多的主题，你们怎么管理的？
使用 Kafka 管理工具Kafka Manager进行主题的监控、配置和管理，提供可视化界面。然后在使用这个可视化工具的时候，我们主要注意了以下几点：
1、命名规范：
制定统一的命名规则，以便于识别和分类，然后在不同的环境（如开发、测试、生产）中使用不同的主题命名空间，以避免混淆和数据污染。
2、主题分类：
根据业务逻辑将主题分为不同的类别，如用户、订单、支付等，便于管理和维护。
3、定期审计与清理：
定期审查主题的使用情况，清理不再使用的主题，减少资源占用。
4、文档和知识库：
最后，我们有维护的详细文档，记录每个主题的用途、数据格式、生产者和消费者信息，方便团队成员参考。

6、Kafka消息积压怎么解决？
消息积压是因为生产端生产了很多消息，消费端由于处理业务代码忙不过来，所以导致了这种积压情况。本质是：broker满了，消息会写到硬件磁盘里然后将broker给清空继续放其他的消息，这时消费者在broker上找不到要消费的消息（因为写到了磁盘里），就会去磁盘里找（硬件读写慢）。后续的broker满了又会往磁盘里写，恶性循环。

方法2:使用kafkaStream或flink

7、你们是怎么解决消息幂等性的？
在 Kafka 中，避免重复消费可以通过以下几种方法实现：
1、 使用消息的唯一标识符
幂等性：在消费者端，可以为每条消息分配一个唯一的标识符（如 UUID）。消费者在处理消息时，先检查这个标识符是否已处理过。如果已处理，则跳过该消息。
2、 使用 Kafka 的幂等生产者
幂等生产者：Kafka 提供了幂等性功能，确保同一条消息不会被重复写入同一分区。通过设置生产者的 enable.idempotence 为 true，可以避免因网络问题等导致的重复发送。
3、消费者的偏移量管理
手动提交偏移量：使用手动提交偏移量的方式，确保只有在成功处理消息后才提交偏移量。这样，如果处理失败，可以重新消费未提交的消息。
4、使用外部存储
状态存储：将处理状态存储在外部数据库中（如 Redis、MySQL）。在处理每条消息时，先检查外部存储中是否已记录该消息的处理状态。处理后更新状态。
5、消息去重
消息去重逻辑：在业务逻辑中实现去重机制，例如在数据库中使用唯一索引来防止重复插入。

2、RocketMQ

3、Kafka与RocketMQ的对比

1、Kafka为什么比RocketMQ吞吐量高

Kafka生产者采用异步发送消息，并不是直接向Broker发送，而是放入缓存，直接向业务代码发送成功消息。当缓存到达一定数量时，再向Broker发送消息，减少了网络IO，但降低了可靠性。
分区机制：单区有序，但整体不保证有序 零拷贝：跳过“用户缓冲区”的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”；
还有其他原因，比如顺序读写、文件压缩，不解释了！

1）Kafka具备选举功能，当某个partition（分区）的master挂了后，该分区的某个slaver就会升级为master对外提供服务。而RocketMQ不具备选举功能，当某个master挂了，你可以写到其他的master，而不是升级某个slaver。
2）Kafka不支持消息的定时发送，RocketMQ支持。
3）Kafka（和Zookeeper强绑定）专注于大数据处理，是分布式流式系统。而RocketMQ更多的专注于业务，是一个消息中间件。

2、RocketMQ&Kafka各自的优缺点及使用场景？
消息队列的常见使用场景有很多但是核心的有三个：解耦、异步、削峰、
RocketMQ:接口简单易用,扩展性好,缺点：阿里维护，弃用小公司承受不住
常用场景：定时任务，请求削峰、服务间异步通信、顺序消费
Kafka:最大的优点是超高吞吐量，缺点：有可能消息重复消费，那么对数据准确性会造成极其轻微的影响

3、RocketMQ&Kafka的对比？
1）Kafka具备选举功能，当某个partition（分区）的master挂了后，该分区的某个slaver就会升级为master对外提供服务。而RocketMQ不具备选举功能，当某个master挂了，你可以写到其他的master，而不是升级某个slaver。
2）Kafka不支持消息的定时发送，RocketMQ支持。
3）Kafka（和Zookeeper强绑定）专注于大数据处理，是分布式流式系统。而RocketMQ更多的专注于业务，是一个消息中间件。

九 、设计模式

笔者总结设计模式时发现，很多设计模式底层运用的思想都是多态，不同多态的表现决定了不同设计模式的差别。

1、单例模式

• 懒汉式（静态内部类方式）：在真正使用时，才实例化
  1）线程安全问题;
  2）double check加锁优化 （使用synchronized加锁）;
  3）编译期（JIT）,CUP可能对指令重排，使用volatile关键字;

静态内部类单例模式中实例由内部类创建，由于JVM在加载外部类的过程中，是不会加载静态内部类的，只有内部类的属性/方法被调用时才会被加载，并初始化其静态属性。静态属性由于被static修饰，所以只会被实例化一次，并且严格保证实例化顺序。

• 饿汉式：利用的是jvm的类加载机制（类加载器、双亲委派）,在类加载初始阶段就完成实例的初始化（如给类的静态变量赋初始值）。

2、抽象工厂模式（开闭原则：扩展开放、修改关闭）
程序需要处理不同产品，但又不想依赖具体的类，可以使用抽象工厂模式，向jdk里的Connection的接口利用的就是，我们平时写的接口与实现类分离，也是这个思想；避免了职责单一；

3、原型模式（spring里的prototype）

4、享元模式
运用共享技术有效支持大量的细粒度对象
比如：字面量，String=“abc”；Interge

5、门户（Focade）模式

有一个统一的入口，根据不同的入参访问不同的子系统，不需要关心子系统是否变更，也是工作中最为常用的一种设计模式（比如聚合接口）,这样能简化客户端的调用。

• 应用场景：需要使用复杂有限的子系统接口直接调用；想将子系统简组织成层；

6、适配器模式
SpringMVC中使用该模式，DispatcherServlet会通过 handler 的类型找到对应适配器，执行目标 Controller 中的请求处理方法。

7、装饰者模式
不改变原有对象基础上，将功能附加到对象上。

8、模板（Template）设计模式
定义一个操作的算法骨架，而将一些步骤延迟到子类中去实现。比如jdbc的数据库链接、创建，具体的sql我们自己去写。还有RedisTemplate、MongoDBTemplate等都是运用的该模板，减少了大量重复的代码；

子类反向到父类，是模板设计模式的核心。在InputStream类中，read（）方法最终是由具体的抽象子类实现，然后再到父类中进行后面的步骤，部分代码如下：

9、观察者模式
多个对象监听一个主题对象，当主题对象变化时，所有依赖对象会收到消息并更新。Redis的哨兵模式（主从节点）、Zookeeper集群；

10、责任链模式
我们的过滤器就是使用的该模式
http的请求，比如： 一个request---->登录---->----->访问权限----->敏感词过滤----->…

十、Kubernetes容器

版权声明：

本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。

本文网址：https://www.bianchenghao6.com/h6javajc/18301.html