面经.md · 谢智宇/java

# 面经

### 1. 分布式

#### 问：为什么要使用分布式锁

* 原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

#### 问： 分布式锁的实现

* 数据库实现，对某个字段进行唯一性约束，如果多个请求同时提交，数据库只能保证有一个操作是可以成功的

* redis实现

![在这里插入图片描述](https://img-blog.csdnimg.cn/20190303135212531.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhem91MQ==,size_16,color_FFFFFF,t_70)

* zookeeper实现

### 2. redis

#### 问：缓存穿透，击穿，雪崩

* **缓存穿透**：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

解决：

* 如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

* **布隆过滤器**：

将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

* **缓存击穿**：热点key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决：

* 上锁，根据热点key从缓存中获取到的value为空时，先锁上，再去查DB将数据加载到缓存，若其它线程获取锁失败，则等待一段时间后重试，从而避免了大量请求直接打到DB。单机可以使用synchronized或ReentrantLock，分布式需要加分布式锁，如Redis分布式锁。【为了不阻塞对其他key的请求，此处可以用热点key来加锁】

* **雪崩**：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

* 将缓存失效的时间错开，在原有失效的时间上加一个随机值，错开失效时间

#### 问： redis持久化方式

* rdb

* RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

* 对于灾难性的恢复，rdb能够和轻松的将一个单独的文件压缩后再转移到其他的存储介质上

* 相比于aof，如果数据i很大，rdb的启动效率很高

* 但是一旦rdb再持久化之前出现了宕机的情况，会导致部分数据丢失

* 如果通过fork子进程来进行持久化，如果数据集较大，可能会导致整个服务器停止服务几百毫秒

![img](https://images2017.cnblogs.com/blog/388326/201707/388326-20170726161552843-904424952.png)

* aof

* AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

![img](https://images2017.cnblogs.com/blog/388326/201707/388326-20170726161604968-371688235.png)

* redis提供三种同步策略，每秒同步，每修改同步，不同步，每秒同步也是异步完成的，效率非常高，而每修改同步，是一旦修改就会进行同步，这种方式的安全性很高，但是效率很低，不同步就是，默认时间进行同步30s
  * 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
  *  AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
  * 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
  * 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

* 二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。

### 3. Java基础

#### 问：hashcode和equals

* 当hashmap中键是自定义对象的时候需要重写hashcode和equals方法，因为如果不重写的话是根据键的地址来判断两个键是否是一样的，而有时候他们两个键是一样的，但是地址不一样就导致跟我们预期的一样，因此需要重写hashcode，规定只要键的内容一样那么键就一样的，而不是去比较地址，但是仅重写hashcode是比较的hash值，因为有可能会有hash冲突，实际上如果键的内容相同，计算的hash值相同，会把他认为是hash冲突而不是同一个键，因此还需要重写equals方法，规定他们键的内容相同那么键就应该相同。
* 为什么要重新equals方法和hashcode方法
  * ==，如果是基本数据类型比较的是内容是否相等，如果是引用数据类型比较的是地址是否相等
  * 如果没有重写equals方法，比较对象的时候是比较地址
  * 如果重写了，那么就可以规定比较他们的内容
  * hashcode方法的是对键的内容进行hash获得索引，所以需要重写hashcode方法，否则如果不重写那么比较的是地址，不同对象的地址不一样，hash结果也不一样，那么如果两个键的内容相同，如果不重写hashcode，那么就是比较键的地址，那么得到的索引就不同，这是不合理的，如果只重写了hashcode方法，不重写equals方法，那么在hash冲突的时候，需要比较对象的内容，来进行查找对象，这个时候会调用equals方法，不重写equals方法的话就会导致比较对象的地址，导致找不到对象

#### 问： Java里的Map有哪几种实现

* HashMap, TreeMap, HashTable, LinkedHashMap, ConcurrentHashMap

#### 问： hashmap相关知识

* jdk1.7之前是采用数组加链表，1.8之后采用数组加链表加红黑树
* 在hash冲突之后会在冲突结点后面接链表
* 如果链表长度太长查询数据会很慢，因此当链表的数据长度超过8的时候就会将链表转换为红黑树
* 1.7的时候hashmap的链表是采用头插法进行插入的，1.8之后改为尾插法，因为在多线程的情况下头插法容易导致循环链表
* 然后就是扩容，当hashmap的数据量达到一定的值后会进行扩容，有一个负载因子，默认0.75，超过这个阈值之后，数组扩容为原来两倍，然后对所有数据进行重新hash，存放

#### 问： HashMap和HashTable的区别

* HashTable是线程安全的，他的每个方法都加入Synchronize方法，HashMap是不安全的
* 初始容量和每次扩容不一样，Hashtable默认的初始大小为11，之后每次扩充，容量变为原来的2n+1。HashMap默认的初始化大小为16。之后每次扩充，容量变为原来的2倍。
* 计算hash值的方法不同
  * Hashtable直接使用对象的hashCode。hashCode是JDK根据对象的地址或者字符串或者数字算出来的int类型的数值。然后再使用除留余数发来获得最终的位置。除法比较耗时
  * HashMap为了提高计算效率，将哈希表的大小固定为了2的幂，这样在取模预算时，不需要做除法，只需要做位运算。位运算比除法的效率要高很多。HashMap重新根据hashcode计算hash值后，又对hash值做了一些运算来打散数据。使得取得的位置更加分散，从而减少了hash冲突。当然了，为了高效，HashMap只做了一些简单的位处理。从而不至于把使用2 的幂次方带来的效率提升给抵消掉。

#### 问： TreeMap的使用场景，底层数据结构，红黑树的存取复杂度

* 底层数据结构是红黑树
* 其键是有序的，增删查改的时间复杂度都是O（logn）
* 需要基于排序统计功能的时候用使用TreeMap，对于增删改查以及统计的时间复杂度都控制在O(logn)的级别上，相对于HashMap和LikedHashMap的统计操作的(最大的key，最小的key，大于某一个key的所有Entry等等)时间复杂度O(n)具有较高时间效率。

#### 问： LinkedHashMap的使用场景

* LinkedHashMap保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的。在那种确保键的顺序是插入顺序的情况下可以使用LinkedHashMap。

#### 问： LinkedeList和ArrayList的区别

* 数据结构不同：ArrayList是Array(动态数组)的数据结构，LinkedList是Link(链表)的数据结构。
* 效率不同：
  * 当随机访问List（get和set操作）时，ArrayList比LinkedList的效率更高，因为LinkedList是线性的数据存储方式，所以需要移动指针从前往后依次查找。
  * 当对数据进行增加和删除的操作(add和remove操作)时，LinkedList比ArrayList的效率更高，因为ArrayList是数组，所以在其中进行增删操作时，会对操作点之后所有数据的下标索引造成影响，需要进行数据的移动。

### 4. 计网

#### 问： 三次握手

![img](https://images2018.cnblogs.com/blog/137084/201805/137084-20180525143836269-261381703.png)

* 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 **ISN（c）**。此时客户端处于 **SYN_Send** 状态。
* 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 **SYN_REVD** 的状态。
* 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 **establised** 状态。
* 服务器收到 ACK 报文之后，也处于 **establised 状态**，此时，双方以建立起了链接。

#### 问： 四次挥手

所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：

![img](https://images2018.cnblogs.com/blog/137084/201805/137084-20180525143845820-1670076390.png)

* 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于**FIN_WAIT1**状态。
* 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 **CLOSE_WAIT**状态。
* 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 **LAST_ACK** 的状态。
* 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 **TIME_WAIT** 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
* 服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

#### 问：为什么是三次握手，四次挥手

>  第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
>  第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
>  第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

* 这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

#### 问：为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

* 保证TCP协议的全双工连接能够可靠关闭
* 因为客户端最后一次发送的确认关闭ack有可能会发送失败，导致服务器没法正常关闭，一直处于等待状态，如果服务器超时后还没有接收到最后一个ack，就会再次发送一个FIN-ACK，接着客户端会再重传一次，并且启动等待计时器，直到超时后，服务器正常关闭后，客户端才会关闭连接。

#### 问：TCP协议-如何保证传输可靠性

* 校验和，接收方和发送方的校验和保证一致
* 确认应答和序列号：tcp在传输过程中每次接受数据后都会进行确认应答，也就是发送ack报文，ack中包含有确认序列号，也就是告诉发送方，接收到了哪些数据，下次应该发送哪些数据
* 超时重传：如果发送方发送完数据后，很久没有收到接受方的应答，就会认为发送失败，进行超时重传，超时时间是以动态计算的，指数级增长
* 连接管理：三次握手四次挥手确保连接的可靠性
* 流量控制：接收端缓冲区是有大小的，如果缓冲区比较小的时候就需要限制发送端发送的数据的速度，接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。
* 拥塞控制：TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。
  * 慢开始：所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
  * 拥塞窗口的增长是指数级的，当超过一个阈值的时候就会进行线性增长，避免增长过快导致拥塞
  * 快重传：当发送发收到三个同样的确认时，就会进行快重传，而不是等待超时
  * 快恢复：直接将当前拥塞窗口减半，作为新的阈值

#### 问：syn攻击

* 攻击者发送TCP SYN，SYN是三次握手的第一个数据包，当服务器返回ACK后，该攻击者不对其进行确认，TCP连接处于半挂起状态，不断的发送ACK给攻击者，导致资源浪费，配合IP欺骗，SYN攻击能达到很好的效果，通常，客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
* 使用syn cookie来解决

#### 问： 七层网络模型

![image-20211014102116224](C:\Users\xzydy\AppData\Roaming\Typora\typora-user-images\image-20211014102116224.png)

#### 问： DNS解析过程

* DNS服务器保存有域名和ip地址相互映射的关系，在访问一个服务器的时候不用记住其ip地址，通过域名和映射关系找到ip地址
* DNS协议运行在udp协议之上，端口号53
* 域名解析过程：
  * 首先查浏览器缓存
  * 然后主机host文件中查DNS缓存
  * 然后路由器缓存
  * ISP的DNS服务器缓存
  * 根服务器
  * 根服务器再往下级查询，直到找到正确的记录
  * 然后将结果返回给客户端，客户端通过这个ip地址与对应的web服务器建立连接

#### 问： 什么是Http协议

* [客户端](https://www.nowcoder.com/jump/super-jump/word?word=客户端)和服务器端之间数据传输的格式规范，格式简称为“超文本传输协议”

#### 问： http协议相关问题

* https://www.nowcoder.com/discuss/256231?type=1

#### 问： http1.0，1.1，2.0的区别

* #### HTTP1.0和HTTP1.1的区别

* 1.1支持长连接，默认长连接
  * 节约带宽，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。

* #### HTTP1.1和HTTP2.0的区别

* 2.0使用了多路复用技术，做到同一个连接并发处理多个请求，并发请求数量比1.1大量好几个数量级
  * 2.0对header进行了数据压缩，使网络传输数据更小，提高了传输速度

### 5.mybatis

#### 问： mybatis是怎么防止sql注入

* 使用#{}，#{}是经过预编译的，是安全的，${}是没有经过预编译的，存在sql注入
* #{}会动态传参的时候会加上引号，但是${}不会
* ${}方式一般用于传入数据库对象，例如传入表名，order by后的列名。
* **凡是sql中不能添加引号的值动态传参时都必须使用`${}`,像order by，group by等。**

### 6. 死锁

#### 问：什么是死锁

* 就是两个或者多个进程，每个进程持有某种资源而又等待其他进程释放这些资源，这种状态一直保持，进程之间相互等待，导致程序一直处于阻塞状态无法推进

#### 问：死锁条件

* 互斥条件：一个资源只能被一个进程使用
* 请求保持条件： 一个进程因为请求资源而阻塞，对已获得的资源保持不释放
* 不剥夺条件：进程获得资源后，在未完全使用之前，不能进行强行剥夺
* 循环等待： 两个或者多个进程之间形成一种头尾相接环形等待资源的关系

#### 问：如何预防死锁

* 可以通过破坏死锁的那几个基本条件
* 破坏“不可剥夺”条件：一个进程不能获得所需要的全部资源时便处于等待状态，等待期间他占有的资源将被隐式的释放重新加入到 系统的资源列表中，可以被其他的进程使用，而等待的进程只有重新获得自己原有的资源以及新申请的资源才可以重新启动，执行。
* 破坏”请求与保持条件“：第一种方法静态分配即每个进程在开始执行时就申请他所需要的全部资源。第二种是动态分配即每个进程在申请所需要的资源时他本身不占用系统资源。
* 破坏“循环等待”条件：采用资源有序分配其基本思想是将系统中的所有资源顺序编号，将紧缺的，稀少的采用较大的编号，在申请资源时必须按照编号的顺序进行，一个进程只有获得较小编号的进程才能申请较大编号的进程。

#### 问：死锁避免

* 使用银行家算法
* ![1630142872052](C:\Users\xzydy\AppData\Roaming\Typora\typora-user-images\1630142872052.png)

#### 问：出现死锁如何排查

* 使用jps，jstack或者jconsole进行排查

### 7. mysql

#### 问：mysql引擎常用哪些，有什么区别

* InnoDB和MyISam
* InnoDB支持事务，MyISam不支持
* MyISam的效率更高，InnoDB使用事务的时候会保存很多的中间结果
* Innodb使用的是聚簇索引，MyISam使用的是非聚簇索引
* Innodb是行锁，MyISam是表锁

#### 问：聚簇索引和非聚簇索引的区别

* 聚簇索引就是按照每张表的主键构造一颗B+树，同时叶子节点中存放的就是整张表的行记录数据，也将聚集索引的叶子节点称为数据页。这个特性决定了索引组织表中数据也是索引的一部分，每张表只能拥有一个聚簇索引。
* Innodb通过主键聚集数据，如果没有定义主键，innodb会选择非空的唯一索引代替。如果没有这样的索引，innodb会隐式的定义一个主键来作为聚簇索引。
* 优缺点：
  * **数据访问更快**，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更快
  * 插入速度严重依赖于插入顺序，按照主键的**顺序插入**是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个**自增的ID列为主键**
  * **更新主键的代价很高**，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新。
* 在**聚簇索引之上创建的索引称之为辅助索引**，辅助索引访问数据总是需要二次查找。辅助索引叶子节点存储的不再是行的物理位置，而是主键值。通过辅助索引首先找到的是主键值，再通过主键值找到数据行的数据页，再通过数据页中的Page Directory找到数据行。
* Innodb辅助索引的叶子节点并**不包含行记录的全部数据**，叶子节点除了包含键值外，还包含了相应行数据的聚簇索引键。
* 辅助索引的存在不影响数据在聚簇索引中的组织，所以一张表可以有多个辅助索引。在innodb中有时也称辅助索引为二级索引。

#### 问： 联合索引

* 采用左匹配原则（a,b），联合索引也是一颗b+树，在a排序的基础上，对b进行排序

~~~sql
  selete * from table where a=XX and b=XX -- 是可以使用(a,b)联合索引的
  selete * from table where a=XX -- 也是可以的
  selete * from table where b=XX -- 是不行的，因为b单独看是无序的
  selete * from table where b=XX and a=XX -- 是可以的，因为查询优化器会选择查询效率最高的方式
  ~~~

* 在联合索引中将选择性最高的列放在索引最前面

* 在一个公司里以age 和gender为索引，显然age要放在前面，因为性别就两种选择男或女，选择性不如age

![img](https://img2018.cnblogs.com/blog/469203/201904/469203-20190424110631765-103629844.png)

#### 问：索引失效的情况

* 有or的时候，即使部分条件带索引也会失效
* 联合索引未使用到左边字段的时候
* 使用like %开头的，%表示任意多个字符
* 索引列存在隐式转换的时候比如类型是字符串，但是写的是数字
* 索引列存在数学运算，id= id+1，abs（id）

#### 问：什么情况下不适用索引

* 数据唯一性比较差的时候，大量重复数据
* 频繁更新的字段，由于频繁更新导致索引也频繁更新，增大数据库的工作量
* 如果字段不出现在where语句后面的，如果where后含IS NULL /IS NOT NULL/ like ‘%输入符%’等条件，不建议使用索引

#### 问：可重复读如何解决幻读（RR）

* 幻读：有两个事务A,B，其中一个事务读到了另外一个事务新增的数据，导致两次读到的数据不一致

* 在可重复读的隔离级别下引入间隙锁解决

* 就是如果主键之间存在间隙，比如有一个连续的主键是1、3、5，那么中间存在2、4，如果一个事务在查询1、3、5这个区间内的数据，就会把这个区间锁住，其他事务就不能对这个区间的数据进行新增，解决幻读的问题

* 间隙锁有可能会导致死锁

* 比如有两个事务，事务A对id为1的记录进行查询，会锁住这一行，事务B对id为2的这一行进行查询也会锁主这一行，让后A又想对id为2的操作，B又想对id为1的进行操作，导致相互等待，进入阻塞。
  * 尽量减少检索条件的范围
  * 尽量控制事务的大小，减少锁定资源的大小和时间
  * 设置超时等待

#### 问： 可重复读的原理

* 使用MVCC（多版本并发控制）。InnoDB为每行记录添加了一个版本号（系统版本号），每当修改数据时，版本号加一。
  在读取事务开始时，系统会给事务一个当前版本号，事务会读取版本号<=当前版本号的数据，这时就算另一个事务插入一个数据，并立马提交，新插入这条数据的版本号会比读取事务的版本号高，因此读取事务读的数据还是不会变。

#### 问： MVCC版本链

* 对于使用`InnoDB`存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列：

- `trx_id`：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的`事务id`赋值给`trx_id`隐藏列。
  - `roll_pointer`：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到`undo日志`中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

#### 问： mysql日志

* 重做日志（redo）

- 确保事务的持久性。
  - 防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
  - 事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。

* 回滚日志（undo）

* 保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
  * 事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性

* 二进制日志（binlog）

- 用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。
  - 用于数据库的基于时间点的还原。

* 事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。

#### 问：mysql查询慢怎么优化

* 恰当的使用索引，
* 对查询语句进行优化，尽量避免全表扫描，where，order by涉及的列上建立索引
* 字段冗余，减少表与表之间的关联
* 简化查询字段，没用的字段不要
* 使用缓存，将常用的数据存到缓存中

#### 问： 如何保证redis和mysql的数据一致性

* **首先尝试从缓存读取，读到数据则直接返回；如果读不到，就读数据库，并将数据会写到缓存，并返回。**
*  **需要更新数据时，先更新数据库，然后把缓存里对应的数据失效掉（删掉）**。
  * 给缓存数据设置失效期，失效期越短，一致性越高

* 并发不高的情况下：

* **读: 读redis->没有，读mysql->把mysql数据写回redis，有的话直接从redis中取；**

* **写: 写mysql->成功，再写redis；**

* 高并发的情况下：

* **读: 读redis->没有，读mysql->把mysql数据写回redis，有的话直接从redis中取；**

* **写：异步话，先写入redis的缓存，就直接返回；定期或特定动作将数据保存到mysql，可以做到多次更新，一次保存；**

### 8. JVM

#### 问： Java中有个String类，如果我们自己写一个java.lang.String类，会出现问题吗

* 会出问题，自定义的String不会被类加载器加载，根据双亲委派的机制，当一个类加载器加载类的时候，自己先不加载，而是逐层向上交由双亲去加载，当双亲中的某个加载器加载成功后，再向下返回成功，如果所有的双亲都和自己无法加载，则报异常。String是核心类，会在根加载器上加载，所以不会加载自定义的String。

#### 问： 垃圾回收机制 todo

### 9. java并发

#### 问：volatile如何实现有序性和可见性

* 内存屏障实现有序性

* 可见性是通过缓存一致性协议实现的
* 每个处理器通过嗅探总线上的数据来检查自己的数据是否过期了，当处理器发现自己缓存行对应的数据被修改，就会将当前缓存行设置为无效，当处理器需要对这个数据进行读取的时候，就会从主内存中读取最新的数据到处理缓存中
  * 当对volatile变量进行写操作的时候，JVM会向处理器发送一条lock前缀指令，将这个缓存中变量写到主内存中
  * 当一个数据写到主内存中时，会导致其他处理器缓存失效，处理器通过嗅探技术保证内部缓存和主内存的数据一致

#### 问：volatile为什么无法保证原子性

* 比如多个线程对一个变量进行自增操作，这个变量名是a++，每个线程进行循环自增a++
* 由于a++不是原子操作
* 在字节码层面又可以分为几个指令
* 首先是从主内存中获取最新的变量值，然后进行自增，现在自增的时候，有可能其他线程已经自增过了，所以有可能自增的是一个陈旧的值，然后再次同步到主内存的值就是一个错误的值

#### 问：Java有哪些同步方案

* 阻塞同步方案——synchronized
* 非阻塞同步方案——CAS
* 无同步方案——如果一个数据需要有很多线程都在使用，看能不能把他限制到一个线程中使用，这样无需同步也能够实现数据不争用，ThreadLocal创建本地变量，每个线程操作的都是自己的变量，就不会出现不安全的情况

#### 问： java并发中的乐观锁悲观锁

* 乐观锁：CAS，每次都不加锁，而是假设没有并发冲突去操作同一变量，如果有并发冲突则导致失败，则重试直到成功
* 悲观锁：假设最坏的情况，每次去拿数据都认为别人会修改，所以每次拿数据的时候都会上锁，这样第二个线程想拿这个数据的时候就会阻塞，直到第一个释放锁后，其他线程再次获得锁之后才能进行访问

#### 问：CAS如何实现原子性

* 如果内存位置与预期原值相匹配，就对其进行更新，如果不匹配，就不做任何操作
* ABA问题，加版本号，每次更新一个值的时候，连同其版本号一起更新，之后版本号和值都和预期的版本号，值相等的情况下才能进行更新操作

#### 问：实现多线程累加

~~~java
public class demo1{
    //static  int cnt = 0;
    static AtomicInteger cnt = new AtomicInteger(0);

public static void inc(){
        cnt.getAndIncrement();
    }
    public static void main(String[] args) throws InterruptedException {

List<Thread> list = new ArrayList<>();
        for (int i = 0; i < 100; i++) {
            my myRunabel = new my();
            Thread t = new Thread(myRunabel);
            t.start();
            list.add(t);
        }
        for (Thread thread : list) {
            thread.join();
        }

System.out.println(cnt);

}

public static class my implements Runnable{

@Override
        public void run() {
            for (int i = 0; i < 100; i++) {
                inc();
            }
        }
    }
}
~~~

~~~java
package vol;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;

public class demo1{
    static  int cnt = 0;
    //static AtomicInteger cnt = new AtomicInteger(0);

public static void main(String[] args) throws InterruptedException {

System.out.println(cnt);

}

public  static class my implements Runnable{

@Override
        public  void run() {
            synchronized (my.class){
                for (int i = 0; i < 1000; i++) {
                    //cnt.getAndIncrement();
                    cnt++;
                    //inc();
                }
            }

}
        public  void inc(){
            cnt++;
        }
    }
}

~~~

### 10. 操作系统

#### 内存

##### 问： 虚拟内存 todo

### 11. 设计模式 todo

谢智宇/java

简介

发行版

贡献者

近期动态

谢智宇/java .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

谢智宇/java