蔚来Java实习面经

1.解释一下MySQL中脏读、不可重复读、幻读

• 脏读是指一个事务读取了另一个事务未提交的数据。例如，事务A读取了务B正在修改的数据，但是事务B最终回滚了修改，导致事务A读取到的数据是不正确的。
• 不可重读是指在同一个事务中，多次读取同一行数据，但是每次读取的结果都不同。例如，事务A读取了一行数据，然后事务B修改了这行数据并提交了，然后事务A再次读取这行数据，发现数据已经发生了变化。
• 幻读是指在同一个事务中，多次执行同一个查询，但是每次查询返回的结果集都不同。例如，事务A执行了一个查询，返回了一些行，然后事务B插入了一些新的行，然后务A再次执行同一个查询，发现结果集中出现了新插入的行。

2.索引失效的场景有哪些？

最佳左前缀法则
过滤条件要使用索引必须按照索引建立时的顺序，依次满足，一旦跳过某个字段，索引后面的字段都无法被使用。
计算、函数导致索引失效
范围条件右边的列索引失效
建议：将可能做范围查询的字段的索引顺序放在最后
不等于(!= 或者<>)索引失效
is not null无法使用索引，is null可使用索引
like以通配符%开头索引失效
类型转换导致索引失效

3.Explain执行计划用过吗

常用的字段id，type，key_len,rows,extra

4.Type字段有哪一些

system>const>eq_ref>ref>range>index>ALL
system
表仅有一行记录，必须是系统表，这是const类型的特例，查询起来非常迅速。
const
表示通过索引一次就找到了,const用于primary key或者unique索引。
eq_ref
唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见主键或唯一索引扫描
ref
非唯一性索引扫描，返回匹配某个单独值的所有行. 本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而， 它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
range
只检索给定范围的行,使用一个索引来选择行。
Index
出现index是sql使用了索引但是没用通过索引进行过滤，一般是使用了覆盖索引或者是利用索引进行了排序分组
all
Full Table Scan，将遍历全表以找到匹配的行

5.binlog和redolog的区别

bin log
1.作用
MySQL的bin log日志是用来记录MySQL中增删改时的记录日志。
当你的一条sql操作对数据库中的内容进行了更新，就会增加一条bin log日志。查询操作不会记录到bin log中。
bin log最大的用处就是进行主从复制，以及数据库的恢复。
主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
数据恢复：通过使用mysqlbinlog工具来恢复数据。

2.刷盘时机
对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中，那么biglog是什么时候刷到磁盘中的呢？mysql通过sync_binlog参数控制biglog的刷盘时机，取值范围是0-N：
1、sync_binlog=0 的时候，表示每次提交事务binlog不会马上写入到磁盘，而是先写到page cache,相对于磁盘写入来说写page cache要快得多,不过在Mysql 崩溃的时候会有丢失日志的风险。
2、sync_binlog=1 的时候，表示每次提交事务都会执行 fsync 写入到磁盘 ；
3、sync_binlog的值大于1 的时候，表示每次提交事务都 先写到page cach，只有等到积累了N个事务之后才fsync 写入到磁盘，同样在此设置下Mysql 崩溃的时候会有丢失N个事务日志的风险。
很显然三种模式下，sync_binlog=1 是强一致的选择，选择0或者N的情况下在极端情况下就会有丢失日志的风险，具体选择什么模式还是得看系统对于一致性的要求。

3.日志格式
logbin格式：

• binlog_format=STATEMENT（默认）：数据操作的时间，同步时不一致 每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致 master-slave 中的数据不一致( 如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会 出 现 问题)
• binlog_format=ROW：批量数据操作时，效率低 不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样 了。而且不会出 现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的 问题。缺 点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。
• binlog_format=MIXED：是以上两种level的混合使用，有函数用ROW，没函数用STATEMENT，但是无法识别系统变量

redo log
1.为什么需要redo log
事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么mysql是如何保证持久性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中

2.基本概念
redo log包括两部分：一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo log file)。mysql每执行一条DML(Data Manipulation Language增删改)语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging)预写日志 技术。

3.作用
redo log是一种基于磁盘的数据结构，用来在MySQL宕机情况下将不完整的事务执行数据纠正，redo日志记录事务执行后的状态。
当事务开始后，redo log就开始产生，并且随着事务的执行不断写入redo log file中。redo log file中记录了xxx页做了xx修改的信息，我们都知道数据库的更新操作会在内存中先执行，最后刷入磁盘。
redo log就是为了恢复更新了内存但是由于宕机等原因没有刷入磁盘中的那部分数据。

3.刷盘时机
mysql支持三种将redo log buffer写入redo log file的时机，可以通过innodb_flush_log_at_trx_commit参数配置，各参数值含义如下：

参数值	含义
取值0	每秒（一秒钟内提交的事务）写入磁盘 每秒触发一次缓存日志回写磁盘操作，并调用操作系统fsync刷新IO缓存。
取值1	有事务提交就立即刷盘 每次提交事务都立即调用操作系统fsync刷新IO缓存。
取值2	每次事务提交 都写给操作系统 由系统接管什么时候写入磁盘 每次都把redo log写到系统的page cache中，由系统接管什么时候写入磁盘

innodb_flush_log_at_trx_commit = 1：实时写，实时刷
这种策略会在每次事务提交之前，每次都会将数据从redo log刷到磁盘中去，理论上只要磁盘不出问题，数据就不会丢失。

innodb_flush_log_at_trx_commit = 0：延迟写，延迟刷
每秒（一秒钟内提交的事务）写入磁盘 每秒触发一次缓存日志回写磁盘操作，并调用操作系统fsync刷新IO缓存。当系统崩溃，会丢失1秒钟的数据。

innodb_flush_log_at_trx_commit = 2：实时写，延迟刷
这种策略在事务提交之前会把redo log写到os cache中，但并不会实时地将redo log刷到磁盘，而是会每秒执行一次刷新磁盘操作。
这种情况下如果MySQL进程挂了，操作系统没挂的话，操作系统还是会将os cache刷到磁盘，数据不会丢失
但如果MySQL所在的服务器挂掉了，也就是操作系统都挂了，那么os cache也会被清空，数据还是会丢失。

6.Redis基本数据类型

String
Hash
List
Set
Zset

7.有序集合的底层数据结构使用的是？

ziplist
明明有链表了，为什么出来一个压缩链表?

• 1 普通的双向链表会有两个指针，在存储数据很小的情况下，我们存储的实际数据的大小可能还没有指针占用的内存大，得不偿失。ziplist 是一个特殊的双向链表没有维护双向指针:prev next；而是存储上一个 entry的长度和 当前entry的长度，通过长度推算下一个元素在什么地方。牺牲读取的性能，获得高效的存储空间，因为(简短字符串的情况)存储指针比存储entry长度更费内存。这是典型的“时间换空间”。

• 2 链表在内存中一般是不连续的，遍历相对比较慢，而ziplist可以很好的解决这个问题，普通数组的遍历是根据数组里存储的数据类型找到下一个元素的(例如int类型的数组访问下一个元素时每次只需要移动一个sizeof(int)就行)，但是ziplist的每个节点的长度是可以不一样的，而我们面对不同长度的节点又不可能直接sizeof(entry)，所以ziplist只好将一些必要的偏移量信息记录在了每一个节点里，使之能跳到上一个节点或下一个节点。

• 3 头节点里有头节点里同时还有一个参数 len，和string类型提到的 SDS 类似，这里是用来记录链表长度的。因此获取链表长度时不用再遍历整个链表，直接拿到len值就可以了，这个时间复杂度是 O(1)

skiplist
1.是什么
跳表是可以实现二分查找的有序链表

• skiplist是一种以空间换取时间的结构。
• 由于链表，无法进行二分查找，因此借鉴数据库索引的思想，提取出链表中关键节点（索引），先在关键节点上查找，再进入下层链表查找。
• 提取多层关键节点，就形成了跳跃表

总结来讲 跳表 = 链表 + 多级索引
2.说说链表和数组的优缺点？为什么引出跳表
痛点

解决方法：升维，也叫空间换时间。

优化


跳表的时间复杂度
时间复杂度是O(logN)
跳表查询的时间复杂度分析
首先每一级索引我们提升了2倍的跨度，那就是减少了2倍的步数，所以是n/2、n/4、n/8以此类推；
第 k 级索引结点的个数就是 n/(2^k)；
假设索引有 h 级， 最高的索引有2个结点；n/(2^h) = 2, 从这个公式我们可以求得 h = log2(N)-1；
所以最后得出跳表的时间复杂度是O(logN)

跳表的空间复杂度
所以空间复杂度是O(N)
跳表查询的空间复杂度分析
首先原始链表长度为n
如果索引是每2个结点有一个索引结点，每层索引的结点数：n/2, n/4, n/8 … , 8, 4, 2 以此类推；
或者所以是每3个结点有一个索引结点，每层索引的结点数：n/3, n/9, n/27 … , 9, 3, 1 以此类推；
所以空间复杂度是O(n)；
3.优缺点
跳表是一个最典型的空间换时间解决方案，而且只有在数据量较大的情况下才能体现出来优势。而且应该是读多写少的情况下才能使用，所以它的适用范围应该还是比较有限的

维护成本相对要高 - 新增或者删除时需要把所有索引都更新一遍；
最后在新增和删除的过程中的更新，时间复杂度也是O(log n)

8.跳表插入数据的过程能描述一下吗

插入数据看起来也很简单，跳表的原始链表需要保持有序，所以我们会向查找元素一样，找到元素应该插入的位置。如下图所示，要插入数据6，整个过程类似于查找6，整个的查找路径为 1、1、1、4、4、5。查找到第底层原始链表的元素 5 时，发现 5 小于 6 但是后继节点 7 大于 6，所以应该把 6 插入到 5 之后 7 之前。整个时间复杂度为查找元素的时间复杂度 O(logn)。

9.线程池，参数有哪些

1、corePoolSize：线程池中的常驻核心线程数
2、maximumPoolSize：线程池中能够容纳同时执行的最大线程数，此值必须大于等于1
3、keepAliveTime：多余的空闲线程的存活时间，当前池中线程数量超过corePoolSize时，当空闲时间达到keepAliveTime时，多余线程会被销毁直到只剩下corePoolSize个线程为止
4、unit：keepAliveTime的单位
5、workQueue：任务队列，被提交但尚未被执行的任务
6、threadFactory：表示生成线程池中工作线程的线程工厂，用于创建线程，一般默认的即可
7、handler：拒绝策略，表示当队列满了，并且工作线程大于等于线程池的最大线程数（maximumPoolSize）时如何来拒绝请求执行的runnable的策略

10.拒绝策略有几种？

1.AbortPolicy(默认)：直接抛出RejectedExecutionException异常阻止系统正常运行
2.CallerRunsPolicy：“调用者运行”一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务的流量。
3.DiscardOldestPolicy：抛弃队列中等待最久的任务，然后把当前任务加人队列中尝试再次提交当前任务。
4.DiscardPolicy：该策略默默地丢弃无法处理的任务，不予任何处理也不抛出异常。如果允许任务丢失，这是最好的一种策略。

11.你常用的拒绝策略是哪种，为什么

AbortPolicy:如果是比较关键的业务，推荐使用此拒绝策略，这样子在系统不能承载更大的并发量的时候，能够及时的通过异常发现。
DiscardPolicy:如果你提交的任务无关紧要，你就可以使用它 。因为它就是个空实现，会悄无声息的吞噬你的的任务。
DiscardOldestPolicy:基于这个特性，想到的场景就是，发布消息和修改消息，当消息发布出去后，还未执行，此时更新的消息又来了，这个时候未执行的消息的版本比现在提交的消息版本要低就可以被丢弃了。因为队列中还有可能存在消息版本更低的消息会排队执行，所以在真正处理消息的时候一定要做好消息的版本比较。
CallerRunsPolicy:一般在不允许失败的、对性能要求不高、并发量较小的场景下使用，因为线程池一般情况下不会关闭，也就是提交的任务一定会被运行，但是由于是调用者线程自己执行的，当多次提交任务时，就会阻塞后续任务执行，性能和效率自然就慢了。