面试大纲_V2023

泛型类

泛型接口

泛型方法

泛型数组

1. 如果理解Java中的泛型是伪泛型？

2. 如何证明类型的擦除呢？

Set

List

Queue

TreeMap

HashMap

HashTable

LinkedHashMap

WeakHashMap

说说线程、进程、协程之间的区别？

java线程阻塞调用wait()和sleep()区别和联系，还有函数yield，notify等的作用?

线程的生命周期？

为什么我们调用start（）方法会执行run()，为什么我们不能直接调用run（）？

什么是线程中断？如何正确地中断一个线程？

原子类、CAS、UnSafe

LockSupport

AQS

ReentrantReadWriteLock

StampedLock

ReentrantLock

线程池ThreadPoolExecutor

ForkJoin框架

工具类Executors

Queue

List

Set

Map

Semaphore

CountDownLatch

CyclicBarrier

Phaser

Exchanger

CompletableFuture

Future

什么是ThreadLocal? 用来解决什么问题的?

ThreadLocal是如何实现线程隔离的?

ThreadLocal有什么缺陷？为什么会导致内存泄漏？如何解决？

还有哪些使用ThreadLocal的应用场景?

ThreadLocalMap如何解决value冲突问题?跟HashMap有什么区别？

ThreadLocal能否做到子线程中共享父线程中的数据?InheritableThreadLocal了解过吗？有什么局限性？

FastThreadLocal有了解过吗？

ThreadLocalMap的Key是什么？Entry的key为什么要用弱引用? 四种引用有什么区别说一下？为什么使用弱引用就可以解决内存泄漏问题?

happens-before规则

as-if-serial规则

面试题

JVM中对锁的优化

锁的类型：无锁、偏向锁、轻量级锁、重量级锁

基础使用

重排序规则

重要概念

GC过程

运行时区域

演进过程

分类

双亲委派机制

类加载过程

JVM面试题，看这篇就足够了

1、内存占用

2、吞吐量

3、延迟（停顿时间STW）

新生代：Series New、 ParNew、Parallel Scavenge

老年代：Series Old、Parallel Old 、CMS

为什么分代？

Parallel Scavenge：吞吐量优先

CMS

G1

Shenandoah（Red Hat研发）

设计目标：是将停顿压缩到10ms级别

Shenandoah和G1的区别？Shenandoah相比起G1又有什么改进呢？

Shenandoah GC 是如何实现并发复制的

ZGC

详解现代垃圾回收器Shenandoah和ZGC

七大经典垃圾回收器篇+部分调优

SpringFactoriesLoader

1. 执行静态方法SpringApplication.run

@Configuration

借助@Import，所有符合自动创配条件的Bean都会被注入到IOC容器

@AutoConfigurationPackage

@Import（AutoConfigurationImportSelector.class）

在Bean实例化之前执行

内置的有：PropertyPlaceholderConfigurer

可以在Bean实例化之前对Bean的元信息进行修改

在实例化之后，初始化前后执行

第1级：存储完整对象的singletonObjects

第2级：存储半成品对象的earlySingletonObjects

第3级：存储对象的创建工厂的singletonFactories。

数据拷贝过程仍是阻塞的

轮询数据是否准备好

单线程同时监控多个IO文件描述符是否可以执行IO能力

信号驱动是内核通知何时可以开始IO操作

异步是内核通知IO操作何时完成

工作原理：
1. 遍历一遍socket列表，得到就绪的socket;
2. 进程被唤醒之后，程序不知道哪些socket接受到了数据，就需要再遍历一遍

缺陷

解决了最大并发数限制的问题，其他问题没有解决

效率问题：只管“活跃”的连接

epoll内部使用mmap共享内核和用户部分空间，避免数据来回拷贝

EPOLL内核原理极简图文解读

https://www.cnblogs.com/silyvin/p/12145700.html

1. 数据结构

2. tcp/ip如何通知epoll对应的io就绪

3. epoll_create/epoll_ctl/epoll_wait

4. 水平触发和边缘触发

问题

1. 内核接收数据全过程？

2.如何同时监控多个Socket的数据？

3. epoll设计思想？

程序阻塞到IO操作完成

强调的是：主动等待消息通知

IO操作不会阻塞当前程序运行

强调的是：异步等待消息通知，通过回调、通知等被动获取信息

为什么Netty使用NIO而不是AIO？

面向流

Stream单向

一个连接一个线程

面向缓冲区

Channel是双向的

一个连接一个线程，Client的IO请求要等OS完成之后再通知服务器启动线程去处理

应用程序写入的字节>缓冲区的大小

应用程序写入的字节<缓冲区的大小

1. 定长解码器FixedLengthFrameDecoder
   

行分隔符解码器LineBasedFrameDecoder

自定义分隔符解码器DelimiterBasedFrameDecoder

所有的IO操作都在同一个NIO线程上完成

缺点

和单线程模型的最大区别：

缺点

和多线程模型的区别是

MainReactor负责客户端连接和认证，并将请求转给SubReactor

SubReactor负责相应通道的IO读写

为什么不用JDK的ByteBuffer?

Netty4#ByteBuf

Netty3#ChannelBuffer

为什么不用JDK的Channel?

SocketChannel

ServerSocketChannel

NioServerBoss

NioWorker

ChannelPipeline

ChannelHandler

1. 创建 ServerSocketChannel 和业务处理线程池。
2. 绑定监听端口，并配置为非阻塞模式。
3. 创建 Selector，将之前创建的 ServerSocketChannel 注册到 Selector 上，监听 SelectionKey.OP_ACCEPT。
4. 循环执行 Selector.select() 方法，轮询就绪的 Channel。
5. 轮询就绪的 Channel 时，如果是处于 OP_ACCEPT 状态，说明是新的客户端接入，调用 ServerSocketChannel.accept 接收新的客户端。
6. 设置新接入的 SocketChannel 为非阻塞模式，并注册到 Selector 上，监听 OP_READ。
7. 如果轮询的 Channel 状态是 OP_READ，说明有新的就绪数据包需要读取，则构造 ByteBuffer 对象，读取数据

1. 创建 NIO 线程组 EventLoopGroup 和 ServerBootstrap。
2. 设置 ServerBootstrap 的属性：线程组、SO_BACKLOG 选项，设置 NioServerSocketChannel 为 Channel，设置业务处理 Handler。
3. 绑定端口，启动服务器程序。
4. 在业务处理 TimeServerHandler 中，读取客户端发送的数据，并给出响应。

那么相比 Java NIO，使用 Netty 开发程序，都简化了哪些步骤呢？ 1. OP_ACCEPT 的处理被简化，因为对于 accept 操作的处理在不同业务上都是一致的。 2. 在 NIO 中需要自己构建 ByteBuffer 从 Channel 中读取数据，而 Netty 中数据是直接读取完成存放在 ByteBuf 中的。相当于省略了用户进程从内核中复制数据的过程。 3. 在 Netty 中，我们看到有使用一个解码器 FixedLengthFrameDecoder，可以用于处理定长消息的问题，能够解决 TCP 粘包读半包问题，十分方便。

正常情况下，selector.select()操作是阻塞的，只有被监听的fd有读写操作时，才被唤醒
但是，在这个bug中，没有任何fd有读写请求，但是select()操作依旧被唤醒

selector.select()通常是阻塞的，但是在Linux2.6的版本中，对于中断的Socket的连接，select()会被唤醒返回0，selectedKeys返回空数组

对Selector的select进行计数，如果在某个周期（默认500ms）内触发N(512)次select=0，则认为触发bug

重建rebuildSelector,将SocketChannel注册到新selector上，并关闭原selector

线程模型差异

发送队列积压

链路总数控制

单个缓冲区上限控制

缓冲区内存释放

NIO消息发送队列长度上限控制

非法引用问题：如果被netty释放，继续访问或释放为发生异常

线程并发安全

整形：加入缓冲区

控制：

PooledByteBuf

Unpooled

ChannelInboundHandler

ChannelOutboundHandler

ChannelDuplexHandler extends ChannelInboundHandlerAdapter implements ChannelOutboundHandler

内置Handler

按公示问题数可分为

角色

推导过程

如何保证Paxos算法的活性？

算法流程

在Leader选举时节点状态

ZAB协议的四个阶段

基于Java的ZAB实现

选举步骤

QA

文献

文献

应用程序AP

资源管理器RM

事务管理器TM

通讯资源管理器CRM

通讯协议CP

JTA事务API

JTS事务服务

JTA规范在DTP模型之上，有多了Application Server

XA事务的优缺点

TCC事务的优缺点

理论层面：2PC、所有参与者必须实现prepare、commit、rollback接口

开源实现：Atomikos

存在问题：
1、#2协调者挂了，事务悬挂；
2、#2参与者挂了，其他参与者是commit还是rollback？
3、2PC的主要实现都在DB（依赖DB是否支持XA协议），而微服务通常是在服务层面实现一致性；

核心思想：将远程分布式事务拆分成一系列的本地事务

案例

采用方式

适用场景

常见问题

缺点

支持事务MQ

支持非事务MQ

通用性TCC

异步确认型TCC

补偿型TCC

案例

常见问题

AT/FMT模式

核心思想：拆分长事务为多个短事务，Soga工作流引擎负责协调

使用前提

Saga提供ACD保证

常见问题

案例

缺点：不具备可重入性

可重入锁

Redission同时支持RedLock

1. 崩溃恢复

2. 时钟跳跃

3. GC STW、缺页故障、网络延迟

RedLock是建立在一个Time可信模型上

1. 获取开始时间；
2.去各节点获取锁；
3.再次获取时间；
4. 计算获取锁的时间，检查获取锁的时间是否小于锁的过期时间；
5. 如果小于，持有锁

1. 会不会阻塞？

2. 是否可重入？

缺点

瑜伽案例

缺点

优点

优点

缺点

适用场景

1. 在数据量比较少的时候，会进行表锁，而不是行锁

2. 需要占用DB连接

3. 依赖数据库，避免单点，如果有主从同步的话，还会有数据不一直情况

容易引发羊群效应

1. Client创建create类似/lockpath/{hostname}-读写类型-序号的临时有序节点
2. Client创建完之后，通过getChildren获取节点下所有子节点，并且对所有节点注册Watch监听。
3. 确定本次创建的节点序号在所有节点中的顺序
a. 对于读请求，
ⅰ. 如果没有比自己更小的子节点，后者比自己更小的子节点都是读请求，则获取锁
ⅱ. 如果比自己更小的节点中有写请求，那么等待；
b. 对于写请求，
ⅰ. 如果自己不是最小的节点，则等待；
4. 等待监听通知后，重复步骤1

改进后的分布式锁：
1. Client调用create创建一个/lockpath/{hostname}-读写类型-序号的临时有序节点。
2. Client调用getChildren获取所有子节点列表，这里不注册Watch监听
3. 确定本次创建的节点序号在所有节点中的顺序
a. 如果是读请求，向比自己小的写请求注册Watch监听
b. 如果是写请求，向比自己小的最后一个节点注册Watch监听
4. 等待监听后，继续执行步骤2。

依靠心跳session来维护锁的持有状态

缓存》ZK》=数据库

ZK》缓存》数据库

ZK》缓存》数据库

Publisher

MQ

Consumer

基于主从（非分布式，Kafka是分布式）

普通集群模式--无高可用性

镜像集群模式（高可用）

副本机制

Publisher弄丢了？

MQ弄丢了？(Leader挂了，Follower还没来得及同步数据的情况下)

Consumer弄丢了？

exactly once

at least once

at most once

broker注册

topic注册

生产者负载均衡

消费者负载均衡

分区和消费者的关系

消费者注册

顺序写+页缓存

零拷贝

定时异步批量写

Push

Poll

写入方式

消息路由

一、自动分配策略

二、手动分配策略

三、自定义分配策略

触发时机：

Rebalance过程-消费者组协调器发起Rebalance请求-消费者组协调器将消费者分配给新的分区-消费者开始消费新分配的分区

Rebalance的影响-消费者停止消费-消费者重新分配分区-消费者重复消费-消费者消息丢失

Rebalance的优化-增加分区数，减少Rebalance次数-均匀分配分区，减少Rebalance时间-启用自动提交，减少重复消费-增加消息的TTL，减少消息丢失

分析原因

如何解决？

默认all

direct

message

execution

connection

fix 固定大小线程池 core200 max 200 队列synchronus 回绝Abort

cache 缓存线程池，空闲一分钟自动删除

limit：池中的线程数只增长不会收缩，目的是为了避免收缩时突然大流量引起的性能问题。

eager：当core满了，当currentThread<max，则创建线程；当currentThread>max,放入阻塞队列，放不下pa

dubbo剖析：一 服务发布

0. Spring在启动的时候，会通过DefaultNamespaceHandlerResolver解析meta-inf/spring.handlers  1. 通过NamespaceHandlerSupport和DubboBeanDefintionParser实现解析XML标签为ServiceBean
2. Spring容器加载完成，会发布ContextRefreshEvent事件，ServiceBean监听该事件然后调用export()暴露服务，将Bean的属性转成URL参数。
3. ServiceBean通过JavassistProxyFactory创建Invoker;
4. Protocol在export之前会调用拦截器，如果是register会去注册中心注册服务；
5. 最终有ServiceConfig维护所有发布的Exporter与服务URL到本地内存

Dubbo原理和源码解析之服务引用

dubbo剖析：二 服务引用

https://www.jianshu.com/p/7f3871492c71

1、引用配置及配置初始化
该部分以Spring配置及ReferenceBean为入口，主要在ReferenceConfig中进行。

ReferenceConfig依赖RegistryProtocol完成了 "服务引用者注册"、"服务提供者订阅"和"Invoker创建" 的工作；
ReferenceConfig依赖JavassistProxyFactory完成了 "代理对象生成" 的工作；

2、注册中心订阅 & Invoker生成与获取
该部分主要由RegistryDirectory和FailfastCluster实现。

通过ReferenceConfig调用RegistryDirectory的subscribe方法，触发了对服务提供者url的订阅及监听，在监听过程中RegistryDirectory借助DubboProtocol完成了Invoker的创建工作，并保存了服务引用url和Invoker的关系；
通过ReferenceConfig调用FailfastCluster的join方法，完成了对Invoker对象的获取；


3、生成代理对象
该部分主要由JavassistProxyFactory完成。

以ReferenceConfig调用JavassistProxyFactory的getProxy方法为入口，传入Invoker；
新创建了InvokerInvocationHandler，并使用dubbo自己的动态代理工具Proxy最终生成代理对象T ref；

1. DubboBeanDefintionParser解析reference;

Adaptive注解在类上和方法上有什么区别？

Activate：自动激活条件的标记

在类上：该类会直接作为默认实现

在方法上：接口方法要有一个URL入参，根据URL入参选择具体的实现调用

如果出现故障，则切换备份

默认

常用与读模式

如果出现故障，则立即报错

常用于非幂写等

如果出现故障，则可以忽略

常用与不重要的接口，如记录日志

失败了后台自动记录请求，然后定时重发

适用于写消息队列

并行调用多个Provider，只要一个成功就返回

适用于实时性比较高的读操作，但是会浪费更多资源

广播所有实例，有一个报错，则抛出异常

只调用一个可用的实例，如果没有则抛出异常

合并结果集

Dubbo用的是Spring的showdownHook；Spring使用的JVM的shudownHook；

kill -9是强制下线

kill -15是优雅下线

磁盘存储

单机并发连接有限制。 to many connectiions

索引高度增加，查询变慢。

通用是一些流水表、用户表等才考虑分库分表，如果是一些配置类的表，则完全不用考虑，因为不太可能到达这个量级。

传输单位：报文/消息Message

传输单位：段Segment

传输单位：包Packet

传输单位：帧 Frame

1XX：指示信息，表示请求已接收，还需要后续操作。实际使用较少。

2XX 成功

3XX 重定向

4XX 客户端错误

5XX 服务端错误

host

accept：客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式

accept-encoding：客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

user-agent：告诉服务器，client用的os、浏览器版本

connection：最常用于客户端要求服务器使用「HTTP 长连接」机制。

content-length

content-type

content-encoding

HTTP缓存有哪些实现方式？

什么是强制缓存？

什么是协商缓存?

无状态

明文

不安全

相比HTTP/1.0提升了什么？

做了哪些优化？

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别

做了哪些优化？

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

TCP三次握手过程是怎么样的？

为什么是3次握手？不是2次、4次？

什么是 SYN 攻击？如何避免 SYN 攻击？

什么是 TCP 半连接和全连接队列

TCP协议如何保证可靠性？

流量控制和拥塞控制的区别

经典的拥塞算法有哪几个部分？

拥塞避免的实现技术？

TCP四次挥手过程是怎么样的？

2次握手会有什么问题？

TCP四次握手可以变成3次吗？

为什么挥手要4次？

关于TIME_WAIT的问题

关于CLOSE_WAIT的问题

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP重传、滑动窗口、流量控制、拥塞控制

如何优化TCP

如何理解TCP是面向字节流的协议？

TCP协议有什么缺陷？

TCP协议如何保证可靠性？

建立应用层协议，通过重传机制来实现数据的可靠传输。例如，TFTP（Trivial File Transfer Protocol）和DNS（Domain Name System）协议都是基于UDP协议的应用层协议，它们使用重传机制来确保数据的可靠传输。

使用ACK机制。发送端发送数据时，接收端需要返回一个确认（ACK）消息，表示已经收到了数据。如果发送端在一定时间内没有收到ACK消息，就会认为数据丢失，触发重传机制。这种方法可以确保数据的可靠传输，但会增加额外的网络流量。

使用序号机制。发送端给每个数据包分配一个唯一的序号，接收端在接收到数据包后需要返回一个确认消息，并将序号作为回应。发送端在一定时间内没有收到确认消息，就会触发重传机制。这种方法可以确保数据的可靠传输，并可以处理乱序到达的数据包。

使用超时机制。发送端在发送数据包后会设定一个超时时间，如果在超时时间内没有收到ACK或确认消息，就会触发重传机制。这种方法可以应对网络延迟较大的情况，但会增加额外的延迟。

需要注意的是，UDP协议本身并没有提供可靠传输的机制，因此在实现可靠传输时需要注意应用层协议的设计和实现。

当调用一次 channel.read 或 stream.read 后，会由用户态切换至操作系统内核态来完成真正数据读取，而读取又分为两个阶段，分别为：

用户线程进行 read 操作时，需要等待操作系统执行实际的 read 操作，此期间用户线程是被阻塞的，无法执行其他操作

同步I/O和异步I/O描述的是一个程序如何等待一个I/O操作完成。同步I/O是指程序会一直等待I/O操作完成后才会继续执行下一步操作，而异步I/O则是在I/O操作完成之前，程序可以继续执行其他操作。

阻塞I/O和非阻塞I/O则是描述操作系统内核如何处理I/O请求的方式。阻塞I/O是指应用程序会一直被阻塞，直到I/O操作完成，而非阻塞I/O是指应用程序不会被阻塞，而是立即返回一个错误码或者空值，告诉应用程序I/O操作未完成，应用程序可以立即执行其他操作。

通常情况下，同步I/O和阻塞I/O是一起使用的，而异步I/O和非阻塞I/O则是一起使用的。例如，同步I/O通常使用阻塞I/O方式，因为应用程序需要等待I/O操作完成。而异步I/O通常使用非阻塞I/O方式，因为应用程序不需要等待I/O操作完成。

存储器

CPU Cache： L1 Cache 通常分为 dCache（数据缓存） 和 iCache（指令缓存），L3 Cache 则是多个核心共享的

内存：随机访问延时 100 纳秒

硬盘 SSD HDD

缓存一致性的问题具体是怎么发生的呢？

如何解决？

CPU架构

CPU读写单位

CPU伪共享问题

避免伪共享的方法？

中断是系统用来响应硬件设备请求的一种机制。

为了避免由于中断处理程序执行时间过长，而影响正常进程的调度，Linux 将中断处理程序分为上半部和下半部：

系统调用：用户态进程 主动 要求切换到内核态的一种方式。

中断

异常

用户态进程：应用程序

内核态进程：内核本身的进程

创建

就绪

运行

阻塞

终止

管道：半双工，只能单向。

信号

消息队列

共享内存

信号量

套接字Socket

守护进程

孤儿进程：一个进程的父进程已经终止或者不存在，但是该进程仍在运行。

僵尸进程：子进程已经终止，但是其父进程仍在运行，且父进程没有调用 wait()或 waitpid()等系统调用来获取子进程的状态信息，释放子进程占用的资源，导致子进程的 PCB 依然存在于系统中，但无法被进一步使用。这种情况下，子进程被称为“僵尸进程”。避免僵尸进程的产生，父进程需要及时调用 wait()或 waitpid()系统调用来回收子进程。

互斥锁：Java 中的 synchronized 关键词和各种 Lock 都是这种机制。

信号量

屏障

事件Event：Wait/Notify：通过通知操作的方式来保持多线程同步，还可以方便的实现多线程优先级的比较操作。

创建NEW

就绪READY

运行RUNNING

阻塞WAITING

结束TERMINATED

1. 效率高，不需要上下文切换。

2. 不需要多线程的锁机制。因为只有一个线程，不存在同时写变量冲突。

互斥：资源只能被一个进程占用，不能被共享。

请求和保持：一个进程申请资源时，保持已占有的资源不放。

不剥夺：已分配的资源不能被强制性地从进程中剥夺。

循环等待：若干个进程之间形成一种循环等待资源的关系。

预防。通过破坏死锁产生的四个必要条件之一，来预防死锁的产生。比如，资源一次性分配、资源有序分配、资源类型抽象、进程抢占等。

避免。通过对进程的资源请求进行安全性检测，只要检测到当前请求可能引起死锁，就不予分配。比如，银行家算法、资源分配图算法等。

检测。及时发现死锁的发生，并采取相应的措施，比如终止某些进程、回收某些资源等。

解除。当死锁发生时，通过恰当地回收一些资源，使得死锁的进程可以继续执行。比如，采用撤销进程、回滚事务等方法。

概念：虚拟内存是一种计算机内存管理技术，它将计算机硬盘空间作为扩展内存使用，使得应用程序能够访问比物理内存更大的地址空间。

作用&优缺点

没有虚拟内存有什么问题？(参考虚拟内存提供的能力回答这个问题)

物理地址：内存地址寄存器中的地址

虚拟地址：程序所使用的内存地址

内存管理单元MMU（Memory Management Unit，内存管理单元）

MMU 将虚拟地址翻译为物理地址的主要机制有 3 种:

1. 连续内存管理

2. 非连续内存管理

分段管理通过 段表（Segment Table） 映射虚拟地址和物理地址。

翻译过程

不一定。段表项可能并不存在：

分页管理通过 页表（Page Table） 映射虚拟地址和物理地址。

翻译过程

不一定。存在页缺失。

多级页表属于时间换空间的典型场景，利用增加页表查询的次数减少页表占用的空间。

快表：为了提高虚拟地址到物理地址的转换速度，操作系统在 页表方案 基础之上引入了 转址旁路缓存(Translation Lookasjde Buffer，TLB，也被称为快表) 。

TLB 属于 (Memory Management Unit，内存管理单元) 内部的单元，本质上就是一块高速缓存（Cache），缓存了虚拟页号到物理页号的映射关系，你可以将其简单看作是存储着键（虚拟页号）值（物理页号）对的哈希表。

当物理内存不足时，操作系统需要选择一些页面从物理内存中移除，以便为新的页面腾出空间。页面置换算法的目标是最小化页面置换的次数，从而提高系统的性能。

页面置换算法

哪一种页面置换算法实际用的比较多？

缺页率：在一段时间内发生缺页的次数与总访问次数的比率，缺页率越低，表示页面置换算法的性能越好

页面置换次数：指在一段时间内发生页面置换的次数，页面置换次数越低，表示页面置换算法的性能越好

页面访问时间：指访问一个页面所需的时间，页面访问时间越短，表示页面置换算法的性能越好。

1. 段式地址映射。

2. 页式地址映射。

都是非连续内存管理的方式。

都采用了地址映射的方法，将虚拟地址映射到物理地址，以实现对内存的管理和保护。

分页机制以页面为单位进行内存管理，而分段机制以段为单位进行内存管理。页的大小是固定的，由操作系统决定，通常为 2 的幂次方。而段的大小不固定，取决于我们当前运行的程序。

页是物理单位，即操作系统将物理内存划分成固定大小的页面，每个页面的大小通常是 2 的幂次方，例如 4KB、8KB 等等。而段则是逻辑单位，是为了满足程序对内存空间的逻辑需求而设计的，通常根据程序中数据和代码的逻辑结构来划分。

分段机制容易出现外部内存碎片，即在段与段之间留下碎片空间(不足以映射给虚拟地址空间中的段)。分页机制解决了外部内存碎片的问题，但仍然可能会出现内部内存碎片。

分页机制采用了页表来完成虚拟地址到物理地址的映射，页表通过一级页表和二级页表来实现多级映射；而分段机制则采用了段表来完成虚拟地址到物理地址的映射，每个段表项中记录了该段的起始地址和长度信息。

分页机制对程序没有任何要求，程序只需要按照虚拟地址进行访问即可；而分段机制需要程序员将程序分为多个段，并且显式地使用段寄存器来访问不同的段。

先来先服务

短作业优先

时间片轮转

最短剩余时间优先

多级反馈队列调度

优先级调度

1. 先来先服务 FCFS

2. 最短寻道时间优先算法 SSTF

3. 扫描算法 SCAN

4. 循环扫描 C-SCAN

5. 边扫描边观察 LOOK

6. 均衡循环扫描 C-LOOK

最佳页面置换算法OPT -- 而该算法无法实现，只是理论最优的页面置换算法

1. FIFO置换算法：一般只需要通过一个 FIFO 队列即可需求。不过，它的性能并不是很好

2. 时钟页面置换算法（CLOCK）

3. FIFO

4. LRU最近最少使用算法

5. LFU最不经常使用算法

string

list

hash

set

sorted set(zset)

其他数据结构

dict

sds

quicklist

ziplist

skiplist

为什么设计内外部数据结构？

基础数据结构robj(RedisObject)

三种写回磁盘策略？

优点？

缺点？

面试题

默认；二进制数据快照；适用于备份；对全量数据快照

对哪些数据做快照？ 

优点？

缺点？

面试题

配置项：aof-use-rdb-preamble yes

RDB以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作

如果设置过期时间? 

如何判定key已过期？

过期删除策略有哪些？

Redis过期策略是什么？

为什么需要内存淘汰策略？

内存淘汰策略有哪些？内存淘汰策略是如何工作的？

如何选择内存淘汰策略？

LRU和LFU的区别？

内存用完了会怎么样？

原子性：事务中的所有命令要么全部执行，要么全部回滚。

一致性【不具备】：Redis 的事务机制并不会自动保证数据的一致性。如果在事务执行过程中有其他客户端对事务中涉及的键进行修改，事务会继续执行而不会回滚。因此，一致性需要在应用层面进行处理。

隔离性【不具备】：Redis 的事务机制默认情况下是没有隔离级别的概念的，多个事务之间可以并发执行，彼此之间不会产生相互干扰。但是，在事务执行期间，如果有其他客户端修改了事务中的键，事务可能会受到影响。

持久性：Redis 的事务机制在 EXEC 命令执行后，事务中的修改会立即生效，不需要像普通命令一样显式地进行持久化操作。Redis 使用写时复制（copy-on-write）技术，将事务中的修改写入磁盘，保证了持久性。

优点：

缺点：

面试题

基于主从复制实现主从节点故障转移。社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群。

特点：1、哨兵的任务是：监控、提醒、自动故障转移；2、过半机制

优点：能实现自动故障转移

缺点

哨兵进程的工作原理？（自动故障转移机制？）

哨兵如何选定新主库？

面试题

Master可读可写、Slave只写，最少6个节点（三主三从）

优点：

缺点：

工作原理是什么？如何处理数据分片和故障转移？

面试题

特点：集成了哨兵。

优点

缺点：1.不支持事务 2.不支持部分指令

面试题

实践

IO多路复用机制

单线程。只是IO是单线程。

基于内存实现

高效的数据结构

合理的数据编码

合理的线程模型

虚拟内存映射

什么是BigKey?

危害？

对持久化有什么影响？

如何避免？

在Cache Aside模式中，为什么使用删除缓存而不是更新缓存？

在Cache Aside模式中，为什么先更新DB，而不是先删除Cache？

在CacheAside模式中，如果选择先删除缓存，再更新数据库，那如何解决一致性问题呢？

那么 Cache-Aside 存在数据不一致的可能吗？

双写的情况下，先操作数据库还是先操作缓存？

延迟双删

4中模式流程详解

热Key问题

BigKey问题？

缓存雪崩

缓存穿透

缓存击穿

连接器->分析器->优化器->执行器->存储引擎

WAL：Write-Ahead Logging先写日志，再写磁盘

逻辑日志redo log ： 保证crash-safe， innodb特有

物理日志bin log

如何保证2个日志文件的一致性？

from->join->on->where->group by-> having-> select -> distinct-> order -> limit

InnoDB架构图

Buffer Pool

Log Buffer

Change Buffer

Doublewrite Buffer 双写缓冲区

B+树

表空间组成

问题：通常一颗B+树可以存放多少行数据？B+树一层有多少分支？（假设一行记录1kb,一颗层高为3的B+树，大约能存放多少行记录）

问题2：InnoDB为什么选择B+树而不是B树？（为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？）

全文索引

哈希索引

B+树索引

1. 考虑如何创建有效的索引

2. 【高频】索引失效场景?

3. 索引统计信息

1. 什么情况会选错？

2. 选错的怎么处理？

什么是回表？怎么减少回表次数？

什么是索引下推？什么是覆盖索引？

聚簇索引和非聚簇索引有什么区别？

如何进行SQL调优？

慢SQL如何排查？

InnoDB为什么推荐使用自增ID作为主键？

索引失效如何排查？

区分度不高的字段建索引一定没用吗？

SQL执行计划分析的时候，要关注哪些信息？

用了索引还是很慢，可能是什么原因？

order by 是如何实现的？

设计索引的时候有哪些原则？

如何解决热点数据更新？

MySQL是如何保证唯一性索引的唯一性的？

全局锁Global Lock

表级锁

行锁

自动锁

显示锁

共享锁（S锁）

排他锁（X锁）

乐观锁

悲观锁

如何利用锁进行并发控制？

没有事务会产生锁吗？事务和锁之间有什么关系？

什么是共享锁和排他锁？它们有什么区别？

行锁锁的到底是什么？如果innodb表中没有主键和唯一性索引，会产生行锁吗

InnoDB加索引会锁表吗?

为什么 InnoDB 选择临键锁作为行锁的默认算法？

在RR隔离级别下，普通的select，没有使用事务会加锁吗？

什么是意向锁？

如何避免死锁？（怎么解决热点行更新导致的性能问题？）

发生了死锁如何处理？

如何提高MySQL的并发性能和避免锁竞争？

MySQL只操作同一条记录，也会发生死锁吗？

读未提交

读已提交

可重复读

序列化

脏读

幻读

不可重复读

原子性

一致性

隔离性

持久性

事务基础

基本概念

通过Undo Log和版本链实现数据多版本。

通过锁实现并发控制

ReadView（读视图）

MVCC是如何实现的？如何理解MVCC? MVCC如何处理并发读取和写入？

MVCC为什么只在RC、RR级别生效？

什么是脏读、幻读、不可重复读？InnoDB如何解决脏读、不可重复读和幻读的？

MySQL中的事务隔离级别？

Innodb的RR到底有没有解决幻读？

当前读和快照读有什么区别？

MySQL执行大事务会存在什么问题？

Mysql的主键一定是自增的吗？

MySQL事务两阶段提交过程是怎么样的？为什么要两阶段提交？是先接binlog还是先写redolog?

基于Gossip的Mysql Cluster

基于AP的Galera

基于Paxos的MGR(MySql Group Replica)组复制

主从复制

MMM（Master-Master Replication for MySQL）双主多从

MHA（Master High Avaliable）多主多从

MySQL高可用集群方案

mysql5.7集群方案对比

MySQL集群之五大常见的MySQL高可用方案（转）

客户端方案

代理方案

索引：聚簇和非聚簇，myiasm有3个文件：frm\myd\myi  innodb有2个文件：frm\idb

锁

事务

外键

Mysql 5.5之后默认innodb

IO瓶颈

CPU瓶颈

通用域

核心域

支撑域

洋葱模型

六边形模型

请求QPS

存储量

目前互联网网页总数大概45亿。

长度：7位。如果是数字+大小写字母，62^7远大于45亿。

正确答案：一对多

如果一个长网址与一个短网址一一对应，那么在数据库中，仅有一行数据，无法区分不同的来源，就无法做数据分析了

正确答案：分布式ID生成器

最容易想到的办法是哈希，先hash得到一个64位整数，将它转化为62进制整，截取低7位即可。但是哈希算法会有冲突，如何处理冲突呢，又是一个麻烦。这个方法只是转移了矛盾，没有解决矛盾，抛弃。

以短网址为 primary key, 长网址为value, 可以用传统的关系数据库存起来，例如MySQL, PostgreSQL，也可以用任意一个分布式KV数据库，例如Redis, LevelDB。

正确答案是302重定向

限制IP的单日请求总数，超过阈值则直接拒绝服务。

光限制IP的请求数还不够，因为黑客一般手里有上百万台肉鸡的，IP地址大大的有，所以光限制IP作用不大。

可以用一台Redis作为缓存服务器，存储的不是 ID->长网址，而是 长网址->ID，仅存储一天以内的数据，用LRU机制进行淘汰。这样，如果黑客大量发同一个长网址过来，直接从缓存服务器里返回短网址即可，他就无法耗光我们的ID了。

令牌桶

漏斗

滑动窗口