进程和线程的同步方法

线程间的通讯方式

线程间的切换和进程间的切换哪个代价大

内核态和用户态

内核态用户态切换

程序在开始运行的时候，内核态和用户态都发生了什么

CPU 调度算法

死锁

五层体系结构

在 TCP/IP 网络模型中共分为 5 层，从上到下分别是

应用层

我们使用的软件都是工作在应用层的，专注于为用户提供应用服务，不考虑如何传输。应用层是工作在用户态，而其他层是内核态。

传输层

传输层是给应用层提供数据传输支持的，在传输层有两个协议

网络层

数据链路层

物理层

OSI 网络模型（七层体系结构）

在 TCP/IP 协议模型的基础上，将应用层拆分成了应用层，表示层和会话层

各层都有哪些常见的协议

• 应用层：HTTP、FTP、TELNET、SMTP、DNS 等
• 传输层：TCP 和 UDP
• 网络层：IP、ICMP、ARP

什么是 HTTP 协议

HTTP 协议全称是 Hyper-Text Transfer Protocl 超文本传输协议，所谓超文本就是超越了普通文本的文本，是文本，图片，音视频等的混合体，所以总的来说，HTTP 协议就是用于在计算机中传输文本、图片、音频和视频等超文本数据的规范。

HTTP 协议具有以下特性：

• 简单
• 灵活易用
• 应用广泛且跨平台
• 无状态
• 明文传输
• 不安全

针对 HTTP 协议明文传输和不安全的缺点，可以使用 HTTPS 来解决，即引入 SSL/TLS 协议，提高安全性。

HTTPS 解决了什么风险

• 窃听风险
• 篡改风险
• 伪装风险

HTTPS 如何解决的

• 混合加密：通过对信息加密避免数据被窃听的风险

在通信建立前采用非对称加密的方式交换会话密钥，之后的数据传输都采用对称加密。因为对称加密本质上就是位运算，而非对称加密采用了大量的数学运算，我们都知道计算机执行位运算的效率要远高于数学运算，所以对于相同文本对称加密的效率远高于非对称加密。

• 摘要算法：提供了数据校验的能力避免被篡改

发送数据时使用摘要算法计算出明文的指纹，并把指纹和明文一起加密成密文发送到对方，对方解密后用相同的摘要算法算出明文的指纹，并和发送时携带的指纹进行比较。

• 身份证书：使用身份证书保证不会被伪装

服务端将自己的公钥注册到数字证书认证机构（CA），CA 用自己的私钥将服务器的公钥进行数字签名，客户端和服务端建立连接时会验证服务端的证书是否有效。

HTTPS 是如何建⽴连接的？其间交互了什么？

HTTPS 协议是在 HTTP 协议上增加了 TLS 的连接过程，TLS 的连接过程涉及四次通信

1. Client Hello

   由客户端向服务端发送建立连接请求，向服务端发送以下内容

   • 客户端支持的 SSL/TLS 协议版本
   • 客户端支持的密码套件
   • 客户端产生的随机数（client-random）

2. Server Hello

   在服务端收到连接请求后，向客户端发送的内容

   • 确认 SSL/TLS 协议版本
   • 确认使用的密码套件
   • 服务端产生的随机数（server-random）
   • 服务端的数字证书

3. 客户端回应

   客户端收到服务端发送来的数字证书，会向 CA 验证证书的有效性，并从证书中取出服务端的公钥，用服务端的公钥加密报文，向服务端发送：

   • 用公钥加密的一个随机数（pre-master key）
   • 加密算法改变通知
   • 客户端握手结束通知

4. 服务端回应

   服务端收到客户端发来的内容后，用私钥解密出 pre-master key，此时服务端和客户端各有三个随机数，通过协商的加密算法计算出本次会话的会话密钥，然后向客户端发送：

   • 加密算法改变通知
   • 服务端握手结束通知

到此整个 SSL/TLS 协议握手结束，接下来客户端和服务端使用计算好的会话密钥进行加密通信。

HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接频繁握手/挥手造成的开销，同时支持了管道传输，可以减少整体响应时间。但 HTTP/1.1 仍存在以下问题：

• 请求头部冗余
• 请求在服务端是按顺序执行的，如果某一个请求执行时间过长，客户端会一直收不到相应，就会造成队头阻塞
• 没有优先级控制
• 只能由客户端主动发送请求

HTTP/2 相比 HTTP/1.1 做出了一些优化

• 压缩头部：如果多个请求的头部较为相似，那么会自动帮你消除重复的部分，这部分采用 HPack 算法实现
• 二进制报文：在 HTTP/1.0 和 HTTP/1.1 中报文都是可读的纯文本，而在 HTTP/2 中采用了二进制格式，减少了收发报文的两端对纯文本的编码过程，提高效率
• 数据流：在 HTTP/2 中的数据包不是按序发送的，同一个连接里连续的数据包可能不属于同一个请求；同时客户端可以指定数据流的优先级，高优先级的数据流会先被服务端响应
• 多路复用：移除了 HTTP/1.1 中的串行请求，不会再出现队头阻塞的现象
• 主动推送：在一定程度上改善了传统的请求-应答工作模式，服务端可以主动推送数据到客户端

在 HTTP/3 中放弃使用 TCP 作为传输层协议，采用了基于 UDP 的 QUIC 作为传输层协议，同时 TLS 版本更新到 1.3，头部压缩算法改为 QPack；最主要的是将因为传输层协议基于 UDP，将以往的 HTTPS 协议的 TCP 三次握手 + TLS 四次握手聚合成了 QUIC 三次握手，大幅提升了请求的连接速度。

TCP 协议

TCP 全称 Transmission Control Protocol，大部分应用使用的传输层协议。TCP 是一个面向连接，可靠的，基于字节流的传输层通信协议。

• 面向连接：一定是一对一的，且需建立连接才能通信
• 可靠的：无论链路中发生任何异常，TCP 都可以保证一个报文顺利的到达对端
• 字节流：无论消息有多大都可以有序的传输，如果出现重复的报文会丢弃

如何唯一确定一个 TCP 连接

通过 TCP 四元祖可以唯一确定一个 TCP 连接

• 源地址
• 源端口
• 目标地址
• 目标端口

其中源地址和目标地址在 IP 报文头部，作用是寻找主机；源端口和目标端口在 TCP 报文头部，作用是找到目标进程

TCP 的三次握手和四次挥手

三次握手

最开始客户端和服务端都处于 CLOSED 状态，首先服务端监听一个端口，随后进入 LISTEN 状态，等待连接。随后开始三次握手：

• 第一次握手：客户端向服务端发送一个含有随机序号（client_isn）且 SYN 标志位被置为 1 的报文，随后客户端进入 SYN_SENT 阶段。
• 第二次握手：服务端收到包含 SYN 标志位的报文后，从中获取客户端发送过来的 client_isn 后，将其 +1，并向客户端发送一个含有服务端随机序号（server_isn）且 SYN/ACK 标志位被置为 1 且确认号为 client_isn + 1 的报文给客户端，并进入 SYN_RCVD 阶段。
• 第三次握手：客户端收到服务端回复的 SYN/ACK 报文后再向服务端发送一个序号为 client_isn + 1 且 ACK 标识位被置为 1 且确认号为 server_isn + 1 的报文，并进入 ESTABLISHED 阶段

当服务端收到第三次握手的报文后也进入 ESTABLISHED 阶段

注：因为第三次握手时客户端和服务端已经建立连接了，所以第三次握手可以携带数据

四次挥手

参与一条 TCP 连接的两个进程中的任何一个都能终止连接，下面以客户端主动关闭连接为例：

• 第一次挥手：客户端向服务端发送一个 FIN 标识为被置为 1 的报文，并进入 FIN_WAIT_1 状态
• 第二次挥手：服务端收到 FIN 报文后，向客户端发送一个 ACK 标识被置为 1 的报文，并进入 CLOSED_WAIT 阶段
• 第三次挥手：服务端收到 ACK 报文后，向客户端发送一个 FIN 标识为被置为 1 的报文，并进入 LAST_ACK 阶段
• 第四次挥手：当客户端收到第三次挥手的报文后，向客户端发送一个 ACK 标识被置为 1 的报文，并进入 TIME_WAIT 阶段，随后等待 2MSL 的时间进入 CLOSED 状态

当服务端收到第四次挥手的报文后进入 CLOSED 状态

注：主动关闭连接的一侧才有 TIME_WAIT 阶段

为什么是三次握手

使用三次握手的目的：

• 避免历史连接初始化连接
• 同步双方初始化序号
• 避免浪费资源

如果是两次握手则⽆法防⽌历史连接的建⽴，会造成双⽅资源的浪费，也⽆法可靠的同步双⽅序列号。

如果是四次握手是因为三次握⼿就已经理论上最少可靠连接建⽴，所以不需要使⽤更多的通信次数。

为什么是四次挥手

• 客户端发送 FIN 报文时，仅代表客户端没有数据要向服务端发送
• 因为 TCP 是双向连接的，可以互相发送数据。所以当服务端收到 FIN 报文时，此时服务端可能还有数据要发送到客户端，所以先返回 ACK 报文，等所有数据发送结束再向客户端发送 FIN 报文

为什么关闭时需要 2MSL 的延时

MSL 是 Maximum Segment Lifetime 最大报文生存时间，它是任何报文在网络中存在的最长时间，超出此时间的报文都会被丢弃。

2MSL 的合理解释是：⽹络中可能存在来⾃发送⽅的数据包，当这些发送⽅的数据包被接收⽅处理后⼜会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间，⽐如如果被动关闭⽅没有收到断开连接的最后的 ACK 报⽂，就会触发超时重发 FIN 报⽂，另⼀⽅接收到 FIN 后，会重发 ACK 给被动关闭⽅，⼀来⼀去正好 2MSL。

TCP 和 UDP 的区别

TCP 流量控制

如果 TCP 第三次握手的包没收到会怎样

• 第一范式：表中的每一列都不可再拆分
• 第二范式：在第一范式的基础上，表中的每一列都和主键相关
• 第三范式：在第二范式的基础上，表中的每一列都和主键直接相关，不能间接相关

MySQL 常见的存储引擎

存储引擎

存储引擎是在数据库中进行创建、读取、修改和删除数据的底层组件。不同的存储引擎提供不同的存储机制，而且还有许多不同的功能，在 MySQL 中我们可以使用show engines;来查看所支持的存储引擎状况。

MyISAM

MyISAM 是 MySQL 5.5 之前默认的存储引擎，性能高但不支持事务，也不支持外键。

• 高性能读取
• 保存了表内记录条数，使用count时不会查全表
• 只支持表锁，虽然开销小、加锁快，但容易发生冲突

InnoDB

InnoDB 是一个支持事务的存储引擎，是现在 MySQL 的默认存储引擎。

• 支持事务、外键
• 支持行级锁，粒度小，并发处理能力更强

数据库事务

事务是指具有 ACID 特性的一组操作，使用commit来提交一个事务，用rollback来回滚一个事务。

• 原子性（Atomicity）

原子性是指事务被视为不可分割的最小执行单元，简单地说就是一个事务要么全成功，要么全失败，失败时会利用回滚日志（Undo Log）将数据会滚到事务发生之前的状态。

• 一致性（Consistency）

一致性是指在事务执行前后，数据库的完整性约束没有被破坏。

A（100元） 向 B（0元） 转账 100 元，转账前后 A 和 B 两人共 100 元不变

• 隔离性（Isolation）

隔离性是指一个事务所修改的内容在提交之前对其他事务是不可见的，InnoDB 依靠 MVCC 多版本并发控制来保证隔离性。

• 持久性（Durability）

持久性是指当事务提交后，这些修改应该永久性的保存到数据库（文件系统）中，即使系统崩溃，执行结果也不能丢失。当系统发生崩溃时使用重做日志（Redo Log）来恢复数据。

并发情况下会出现哪些问题

丢失修改

是指两个事务同时修改一条记录，可能会造成其中一个事务的结果被另一个覆盖。

脏读

是指在一个事务中读取到了另外一个事务修改未提交的数据。

不可重复读

是指在一个事务中读取到别的事务已提交的修改，此时会造成事务中前后若干次读取的数据不一致。

幻读

和不可重复读比较类似，幻读是指在一个事务中读取到另外一个事务插入或者删除的数据，此时当前事务中前后若干次读取的数据记录条数不一致。

事务的隔离级别有哪些？分别解决了什么问题

有哪些类型的锁

锁是协调多个进程或线程并发访问某一资源的一种机制，在数据库中是用于保证数据并发访问一致性的一种手段。

按锁的粒度分

行锁

行锁的锁定粒度是最小的，只需对操作的当前行进行锁定，能够支持较大的并发量。在 InnoDB 引擎中，只有通过索引检索数据的时候才能使用行锁。

行锁的获取分为两步：

1. 锁住主键索引
2. 锁住非主键索引

因此行锁在并发量大的时候容易出现死锁的问题。

表锁

表锁是粒度最大的一种锁，会对当前操作的整张表加锁，所以不适合高并发场景。在 InnoDB 引擎中，当无法通过索引检索数据的时候会使用表锁。

页锁

页锁是一种锁粒度介于行锁和表锁中间的一种锁，在 MySQL 中仅有 BDB 引擎支持页锁。

按锁的类型分

读写锁

• 互斥锁（X 锁）：又称写锁
• 共享锁（S 锁）：又称读锁

从两个锁的名字就能看出其特点：当一个事务对数据加了写锁，事务本身可以对加了锁的对象读取和修改，但其他事务只能读取不能修改；当一个事务对数据加了读锁，所有事务都可以对其读取，但不能修改。

意向锁

意向锁是一种表级锁，可以更容易地支持多粒度封锁。事务 A 持有表中一条数据的写锁，此时事务 B 想要对表加写锁，此时会发生冲突，所以在事务 B 加写锁之前要对表中记录逐行扫描检测是否有其他的写锁，这样费时又费力；所以引入了意向锁这个概念，一个事务要想获取表中记录的锁，那就必须先获取表的对应意向锁，此时其他事务加锁前只需检测表中是否有其他意向锁即可。

• 意向互斥锁（IX 锁）

事务要想获取某些记录的写锁，必需先获取表的意向互斥锁。

• 意向共享锁（IS 锁）

事务要想获取某些记录的共享锁，必须先获取表的意向共享锁。

锁有哪些算法实现

Record Lock（记录锁）

记录锁就是加在索引记录上的锁，通过索引检索数据时使用的都是记录锁。

Gap Lock（间隙锁）

锁定索引之间的间隙，不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15。

SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;

Next-Key Lock

是记录锁和间隙锁的结合，它锁定一个前开后闭的区间，主要用于解决幻读的问题。

MVCC 多版本并发控制

多版本并发控制（Muti-Version Concurrency Control）是 InnoDB 引擎实现隔离级别的一种具体方式，主要用于实现读已提交和可重复读两种隔离级别。

对于读未提交要求每次读取最新的数据，所以无需MVCC；对于串行化需要对所有事物加锁，单纯使用 MVCC 无法解决。

基本思想

MVCC 利用多版本的思想，使读操作读取旧版本快照，而写操作更新最新的快照，没有互斥关系。在 MVCC 中事务的修改操作会使得记录增加一个快照，为了解决脏读和不可重复读，MVCC 规定只能读取以提交的快照。

原理

MVCC 的多版本指的是多个版本的快照，快照存储在 Undo Log 日志中，利用回滚指针把数据所有版本的快照串起来。MVCC 维护了一个 ReadView 的结构，该结构记录了系统中所有未提交的事务 ID，同时记录这些事务 ID 的最小值和最大值用于判断。

当执行 Select 操作时，会根据数据行快照的事务 ID 和 ReadView 中的事务 ID 进行比较：

• 当前快照事务 ID 小于 ReadView 中事务 ID 的最小值，说明该快照是在当前所有未提交的事务之前修改的，可用
• 当前快照事务 ID 大于 ReadView 中事务 ID 的最大值，说明该快照是在事务启动之后提交的，所以不可用
• 当前快照事务 ID 介于 ReadView 中事务 ID 最大值和最小值之间则要根据隔离级别来判断快照是否可用
  • 读已提交：如果快照事务 ID 在 ReadView 中，说明事务未提交，不可用；反之则可用
  • 可重复读：不可用，因为可用是对所有事务的，此时会造成不可重复读的现象

如果当前快照不可用时，会根据 Undo Log 中的回滚指针找到上一版本的快照，重复上述的判断。

索引的类型

按结构分类

• B+ Tree 索引

• Hash 索引

• Full-Text 索引

在MySQL 5.6 以前的版本，只有 MyISAM 存储引擎支持全文索引；5.6 之后的版本 InnoDB 和 MyISAM 都支持全文索引；只有文本类型的字段才可以使用全文索引。

按存储方式分类

• 聚簇索引：索引树的叶节点包含了全部字段
• 辅助索引：索引树的叶子节点仅记录主键的值而不是地址

按字段分类

• 主键索引
• 普通索引
• 前缀索引：截取字段的前 n 个字符建立的索引
• 覆盖索引：从辅助索引中就可以得到想要的结果

按字段个数分类

• 单列索引
• 组合索引（联合索引）

索引有哪些优缺点

优点：

• 加快查询速度，减少查询时间

缺点：

• 维护索引比较耗时
• 索引会占用额外的空间
• 在增删改的时候要同步修改索引

索引使用的策略及优化

• 全列匹配：当按照索引中所有列精确查找时会成功使用索引。原则上语句中索引的顺序会对是否能匹配上索引有影响，但 MySQL 优化器会自动帮你调整为索引列的顺序。
• 最左匹配原则：在索引<a,b,c> 中使用了 <a,b>，此时可以使用索引
• 使用了索引列的精确匹配，但缺少中间某个索引列：比如在索引<a,b,c> 中仅使用了 <a,c>，此时可以使用索引，但仅有a列可以匹配，c 列仍需全表扫描
• 匹配索引列的前缀：使用 like 字段时如果通配符出现在最前面的时候不能使用索引，通配符仅能出现在后面，例如：like 'xxx%' 可以使用索引，但 like '%xxx' 不可以
• 查询条件中含有函数或者表达式：不能匹配索引
• 出现了隐式类型转换时不能使用索引，比如查询一个 varchar 索引列的时候没有加两侧的单引号，此时不会命中索引
• or 左右两侧必须都为索引列，否则不能使用索引

索引列的选择

• 表记录表较少的时候可以不建立索引
• 索引的选择性较低时不建立索引

索引的选择性是指索引列不重复的字段值数量占中数量的比例

B Tree 和 B+ Tree 索引的区别

• B+ Tree 的非叶子结点不存储数据，只存储节点信息。而 B Tree 的非叶子结点也会存储数据。所以 B+ Tree 单个节点数据量更小，相同 IO 次数下可以找到更多节点。
• B+ Tree 的叶子结点增加了指针，仿佛一整个单链表，非常适合 MySQL 的范围查找

选用 B+ Tree 的原因

• 不使用 Hash 的原因是虽然 Hash 精确查找效率很高，但范围查找效率很糟糕
• 二叉平衡树/红黑树在结点数量大的时候树的深度会很大
• B Tree/B+ Tree 的每一个节点的大小设置为一个页的大小，这样一个节点只需一次磁盘 IO 即可全部载入
• 因为 B+ Tree 的非叶子结点不存储数据，这样在相同大小下可以存储更多子节点信息，这样会大幅提高我们查找的效率
• 同时 B+ Tree 叶子结点之间是有指针的，这样可以大幅增加我们范围查找的效率

为什么InnoDB表必须有主键，并且推荐使用整型的自增主键

• 因为 InnoDB 引擎的数据文件要按照主键聚集，所以必须要有主键。如果不主动指定主键，引擎会帮你创建一个隐藏的主键列。
• 整型的主键更容易排序生成 B+ Tree
• 自增主键可以有效的减少 B+ Tree 的结点分裂，因为直接放到最后即可

MySQL 的日志类型

Redo Log

用来实现和事务持久化相关的日志，由 Redo Log Buffer 和 Redo Log File 两部分组成。Redo Log 随着事务的创建而产生，但事务提交后不一定写入 Redo Log File，因为 Redo Log 要先写入 Redo Log Buffer 然后根据不同的磁盘写入策略（innodb_flush_log_at_trx_commit）在不同的时机写入文件中。

innodb_flush_log_at_trx_commit 字段取值：

• 0：每次事务提交时写入 Redo Log Buffer，每秒从 Redo Log Buffer 写入到磁盘中

• 1：每次事务提交时写入 OS Buffer，同时写入到磁盘

• 2：每次事务提交时写入 OS Buffer，每秒从 OS Buffer 写入到磁盘中

Undo Log

主要用来保证事务的原子性，同时和 MVCC 有着紧密联系。Undo Log 产生于数据修改之前，但并不会在数据修改后删除，而是将 Undo Log 放到一个链表中，是否删除由 Purge 线程决定

BinLog

二进制文件主要用于进行基于时间点的恢复及主从复制环境的建立。BinLog 有三种格式：

• Statement：记录每次执行的 SQL 语句
• Row：记录每行数据的修改
• Mixed：默认情况下采用 Statement 格式，在某些情况会切换到 Row 格式
  • 使用函数或者系统变量时
  • 含有 AUTO_INCREMENT 列时

Slow Query Log

记录执行时间较长的语句，超时时间需自己配置。通过show variables like '%slow_query_log%'可以查看相关参数值。

MySQL 死锁

在 MySQL 中出现死锁的条件

1. 两个及两个以上的事务
2. 每个事务都已经持有锁，并且申请新的锁
3. 锁同时只能被一个事务占有
4. 事务间因为持有锁和申请锁导致彼此循环等待

如何避免出现死锁

• 合理设计索引，尽可能使语句利用索引
• 避免大事务
• 以固定的顺序访问表和行
• 尽量按主键查找记录
• 在高并发的系统中不要显示加锁，例如 select xxx from for update

MySQL 主从复制

主从复制是指数据可以从数据库的主节点复制到一个或多个从节点中，可以给数据库提供一个有效的备份方式，同时可以有效的缓解数据库的压力。

实现原理

1. 主库将变更内容写入 binlog
2. 从库启动一个 IO 线程向主库请求 binlog，主库根据从库提交的偏移量发送 binlog
3. 从库获取到 binlog 后写入到 Relay Log（中继日志）
4. 从库启动 SQL 线程根据 Relay Log 中的内容进行重放

同步模式

• 异步模式：MySQL 默认的同步模式，主库在执行完客户端的请求后直接响应客户端，不管 binlog 有没有成功同步到从库
• 半同步模式：主库在执行完客户端的请求等至少收到一个从库返回的确认信息再响应客户端
• 全同步模式：主库在执行完客户端的请求等收到所有从库返回的确认信息再响应客户端
• 并行模式：从库启动多个线程分别读取 Relay Log 中不同数据库的日志，并行重放

主要用途

• 热备
• 读写分离
• 高可用

如何解决主从复制的延时

• 分库，降低主库的压力
• 并行复制

MySQL 的内连接、左连接、右连接

• 内连接：保留两张表完全匹配的结果集
• 左连接：返回左边所有的行，无论右边是否有
• 右连接：返回右边所有的行，无论左边是否有

JVM 是 Java Virtual Machine 的缩写，意为 Java 虚拟机，一种可以运行 Java 编译后生成的字节码的虚拟机。有了 JVM 可以使我们不用修改代码就能运行在各个操作系统上。众所周知在 C/C++ 中是需要开发人员手动管理内存的申请以及释放，稍有不慎就造成了内存泄露或者内存溢出，而 JVM 提供的自动内存管理机制极大的简化了我们的开发过程。

而 JVM 不只有一种，大家都可以按照《Java虚拟机规范》开发自己的虚拟机，常见的虚拟机有：

• HotSpot VM
• JRockit VM
• Sun Classic VM
• J9 VM
• Exact VM

其中HotSpot 是使用最广泛的虚拟机

注：JVM 可以运行任何符合规范的字节码文件，不仅限于 Java 语言编译后的字节码，其他语言可以参照规范自己实现编译器编译。

Java 内存区域

上面提到的 JVM 内存管理机制本质上就是在程序运行的过程中把内存分成若干不同的区，这就是 Java 内存区域。

先来看这两块不属于 JVM 的内存区域

• 本地内存

是随着 JVM 进程一起从操作系统申请的内存空间，也就是运行 JVM 所使用的内存。

• 直接内存

直接内存是 NIO（New Input/Out）使用 Native 函数库开辟的内存空间，通过堆中的 DirectByteBuffer 与该内存空间进行操作。

上面两块内存区域不受 Java 堆的大小限制，只与机器的内存相关，但如果配置不当，也会使程序出现 OOM 异常。

以下是由 JVM 所管理的内存区域，也就是运行时数据区（Run-Time Data Areas）

线程共享的内存区域

• 堆

堆是随 JVM 启动而创建的内存区域，是 JVM 所管理的最大的一块内存区域，几乎所有的对象实例和数组都在该区域分配内存，同时也是会触发垃圾回收机制的内存空间。

• 方法区

方法区是一个用于存储被 JVM 加载的类型信息、常量、静态变量、即时编译后的代码缓存等数据。在《Java 虚拟机规范》中提到方法区逻辑上属于堆的一部分，但在具体实现上通常不会在此区域进行垃圾回收或者压缩操作，所以在 HotSpot 虚拟机实现的时候选则用永久代（PermGen）作为方法区的实现。

不过选择使用永久代实现方法区会使得程序更容易发生内存溢出的现象，所以从 JDK 1.7 开始逐步使用元空间（Meta Space）替换永久代作为方法区的实现，并把方法区移到了本地内存中。

• 运行时常量池

运行时常量池是分配在方法区中的一块空间。主要用于存储 Class 文件中的常量池表（Constant Pool Table），也就是编译期生成的各种字面量与符号引用，这部分内容在类加载后创建。

线程私有的内存区域

• 程序计数器

程序计数器可以理解为当前线程所执行的字节码的行号指示器，字节码解释器就是通过修改程序计数器的值来决定下一条要执行的字节码指令，像程序中的分支、跳转、循环和异常恢复等都是依赖程序计数器来完成的。

在多线程中应用中，为了线程切换能够恢复到正确的位置，每个线程都有一个互相独立、互不影响的程序计数器。

当一个线程执行的是 Java 方法，此时程序计数器的值指向的是正在执行的字节码指令地址；而当执行的是 Native 方法时，程序计数器的值为空（Undefined）

注：该区域是唯一一个不会出现 OOM 的内存区域

• 虚拟机栈

每个线程内部都有一个虚拟机栈，随线程的创建而创建。虚拟机栈内部存储着若干栈帧，每执行一个方法，就会对应创建一个栈帧，用于记录局部变量表、操作数栈、动态连接和方法出口等信息。每一个方法调用到结束的过程，就对应一个栈帧在虚拟机栈中入栈到出栈的过程。

如果线程请求栈的深度大于虚拟机所允许的最大上限时，会抛出StackOverflowError异常。

• 本地方法栈

本地方法栈和虚拟机栈功能类似，只不过记录的是 Native 方法。

方法区和永久代的区别

方法区是《Java 虚拟机规范》中所提及的一个规范，并没有规定如何实现，而永久代就是依据这一规范实现的。可以理解为方法区是接口，永久代实现了方法区这一接口，是具体的实现类。也就是说永久代只是 HotSpot 虚拟机根据《Java 虚拟机规范》中所描述的方法区规范实现出来的一个概念，在其他的虚拟机中不存在永久代这个概念。

为什么要用元空间替换永久代

1. 在 JDK 1.8 合并 HotSpot 虚拟机和 JRockit 虚拟机时，JRockit 中不存在永久代的概念，所以顺势删除了永久代
2. 永久代在方法区内部，受 JVM 整体内存大小受影响，相比之下放在本地内存的元空间不受 JVM 内存大小影响，只受系统内存空间影响，可以加载更多的类

对象的创建过程

1. 类加载检查

当虚拟机遇到 new 指令的时候会先去常量池中检查对应类的符号引用是否存在，并检查类是否已经加载过。如果没有，会先去执行对应的类加载过程。

2. 分配内存

当通过类加载检查后，会为这个类分配内存空间，一个类所需的内存空间在加载结束时就已经确定了，内存分配的过程就是在剩余的内存空间中找到一块放的下空间的过程。

内存的分配方式有两种：

• 指针碰撞

当内存空间“规整”时使用，原理就是有一个指针指在已用过的内存和未使用的内存中间，当需要分配内存的时候，指针向后偏移所需的空间大小即可。

• 空闲列表

当内存空间不怎么“规整”时，可能没办法直接找到合适的内存空间用于分配，所以虚拟机内部维护了一份可用空间的列表，内存分配的过程就是在列表上找到足够大的内存空间分配给对象实例。

具体采用哪种方式取决于虚拟机内存空间是否“规整”，而内存空间是否规整又取决于使用的垃圾回收算法是“标记-整理”还是“标记-清除”。

当虚拟机使用 Seial、ParNew等带有“整理”功能的垃圾回收器时，系统采用指针碰撞的方法分配内存，简单又高效；而当使用 CMS 这种基于“清除”的垃圾回收器时，就只能采用空闲列表的方式分配内存。

内存分配过程中会伴随着并发的问题，通常虚拟机有两种方式保证线程安全：

• CAS + 重试：CAS 是一种乐观锁，也就是虚拟机会在分配内存过程中不加锁，如果发生冲突，那就重试到成功为止，虚拟机用这种方式保证内存分配的原子性。
• TLAB：本地线程分配缓冲（Thread Local Allocation Buffer），是指预先在每个线程内部分配一小块内存空间，如果哪个线程需要分配内存，就在哪个线程的 本地缓冲区中分配，只有当线程的本地缓冲区用完了需要分配新的缓冲区时才同步锁定。

3. 初始化“零”值

在分配到内存空间之后，要将对象中除对象头以外的值赋予默认值，保证了对象的字段可以不赋值就被使用。

4. 设置对象头

当对象初始化“零”值之后，虚拟机会对对象进行必要的设置，比如对象是哪个类的实例、类的元数据信息、类的 GC 分代年龄、以及是否启动偏向锁等，这些信息存储在对象头中。

5. 执行 init 指令

到这里，从虚拟机的角度来说，一个对象以经创建完成，但从程序的角度来看，init 指令还没有执行，所以 new 指令后往往是 init 指令，执行完 init 指令，一个对象才算真正的创建完成。

对象的访问

访问堆中对象主流的方式有两种：

• 句柄：在堆中开辟一块空间用于存储句柄池，reference 中存储的是对象的句柄地址，而句柄对象中包含了对象的对象实例地址和对象类型地址。
• 直接指针：Java 栈上的 reference 中存储的直接就是对象的地址，这样节省了一次指针定位的开销

垃圾收集（Garbage Collection）

在 Java 内存区域中，程序计数器、虚拟机栈和本地方法栈随着线程创建而创建，随线程销毁而释放，这几个区域的内存分配具有确定性。

而在堆中，内存的分配具有严重的不确定性，一个接口的不同实现类需要的内存空间可能不一致，一个方法所执行的不同分支所需要的内存空间也可能不一样，只有在运行过程中我们才能知道到底需要创建多少对象，这部分内存的分配是动态的，越多的对象被创建就需要越多的内存。

可内存空间不是无限的，所以我们需要一种机制，帮我们在内存中找到那些可以被回收的对象并释放所占用的内存空间，保证程序的稳定运行。

如何判断对象可以回收

判断对象可以回收通常有两种办法：

引用计数法

从名字就可以看出引用计数法的原理，给每个对象开辟一个额外的内存空间用于存储引用计数器，每当对象有被引用时，引用计数器 + 1反之则 -1。这种方法简单高效，但也面临着一些问题，所以主流的虚拟机都没有使用该方法管理内存空间，比如引用计数法无法解决对象之间循环引用的问题。

public class ReferenceCountingGC {

    public Object instance = null;

    public static void circularReference() {
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        // 让两个对象互相引用对方
        objA.instance = objB;
        objB.instance = objA;
        objA = null;
        objB = null;
        // 此时两个对象互相引用对方，但两个对象都不能为其他对象访问，此时就产生了循环引用
    }
}

可达性分析

可达性分析是通过一系列称为“GC Root”的对象出发，根据引用关系向下寻找，寻找过的路径被称为引用链，如果某个对象到 GC Roots 之间没有任何引用链，或者从图论的角度来看，GC Root 到这个对象不可达时，就说明该对象是不可能再被引用的。

如上图所示，Object1-3 就是引用可达的对象，而 Object4-6 虽然互相有引用，但 GC Root 到这些对象之间没有任何的引用链，所以是引用不可达的。

在 Java 中，可以被称为 GC Root 的对象有：

• 在虚拟机栈栈帧中本地变量表的对象，比如方法的参数、局部变量、临时变量等
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• Native 方法引用的对象
• 被 Synchronized 关键字持有的对象

对象的引用类型

在 Java 中共有四种引用类型：

• 强引用（Strongly）：在代码中普遍存在的引用类型，比如 Object obj = new Object()，只要强引用关系在，垃圾回收器永远不会回收。
• 软引用（Soft）：描述一些有用但非必需的对象，在内存空间发生溢出前会把这些对象标记为下次回收的对象，使用SoftReference类实现软引用。
• 弱引用（Weak）：也是描述一些有用但非必需的对象，但这些对象会在下一次回收时被回收掉，使用WeakReference类实现弱引用。
• 虚引用（Phantom）：最弱的一种引用关系，无法通过虚引用获得任何对象，虚引用唯一的作用就是当对象被回收的时候会收到来自系统的通知，使用PhantomReference类实现虚引用。

以上四种引用强度依次减弱

方法区的回收

在《Java 虚拟机规范》中指出，方法区可以不实现垃圾回收，但不意味着在方法区没有垃圾回收。只不过与堆相比，方法区的垃圾回收效果甚微，性价比通常是比较低的。

在方法区主要回收两类对象：

• 废弃的的常量：比如曾经创建了一个“java”的字符串常量，但现在没有任何一个字符串的值是“java”，此时“java”这个常量就算是废弃的常量，在下次方法区的垃圾回收时回被释放掉。
• 不再使用的类型

判断一个类型是否属于不再使用的类型要同时满足以下三个条件：

• 该类型的所有实例都已经被回收
• 加载该类型的类加载器已经被回收
• 该类的 Class 对象没有在任何地方被引用，即无法通过反射在访问到该类的方法

Java 虚拟机允许满足上面三个条件的类型进行回收，但并不一定会被回收。

垃圾收集算法

分代收集理论

现在的垃圾收集器大多遵循“分代收集”理论进行设计，它建立在三条假说之上：

• 弱分代假说：即大多数的对象的生命周期都很短

• 强分代假说：经历过越多次的回收的对象越不容易被释放

• 跨代引用假说：跨代引用的现象只是极少数

正是因为上面的假说才奠定了多数垃圾收集器一致的设计原则：Java 堆应该被划分成多个区域，根据对象的年龄（经历过垃圾收集的次数）放置到不同的区域。

从分代收集的理论看现代的虚拟机，大多都将堆分成两部分：新生代（Young Generation）和老年代（Old Generation）。在新生代区域中，每次发生垃圾收集会有大量对象被释放，只会留下少数对象，而这少数对象会逐步"升级"到老年代中。

标记-清除算法

最早出现的垃圾收集算法，思想就是标记内存中可以被释放的内存空间，然后再统一释放这些内存空间；也可以反过来标记不用被释放的内存，然后释放未被标记的内存空间。

后续出现的垃圾收集算法都是以标记-清除算法为基础，优化其缺点产生的。它的主要缺点有：

• 执行效率不稳定：在面对大量对象时，标记和清除这两个过程执行效率会随着对象数量增长和降低。
• 内存碎片化：标记、清除过后会产生大量不连续的内存空间，导致接下来分配大对象的时候可能没有足够的空间从而引发一次不必要的 GC。

标记-复制算法

半区复制

主要解决了“标记-清除”算法的执行效率不稳定。它将内存空间分成相等的两份，每次分配空间时只在其中一个空间分配，当这一半空间用完时，把存活的对象复制到“另一半”空间中，释放掉可以释放的内存空间。这种算法简单高效，但有个致命的缺点：可用的内存空间被减少了一半。

IBM 曾研究过新生代中的对象，发现 98% 的对象在第一次垃圾回收时就被释放掉了，因此现在的商用虚拟机大多都优先采用这种算法回收新生代，只不过并不是按照 1:1 分配的。

Appel 式回收

Appel 式回收是将新生代分为一个较大的 Eden 区以及两个较小的 Survivor 区，每次分配内存时仅使用 Eden 区和其中的一个 Survivor 区。发生垃圾回收时，把 Eden 和 Survivor 中存活的对象都丢到另一个 Survivor 区中，并清空 Eden 和已使用的 Survivor 区。

标记-整理算法

“标记-整理”算法和“标记-清除”算法类似，都会先标记内存中可以被释放的空间，但标记-整理算法不会直接释放这些空间，而是让存活的对象都向内存空间的一端移动，然后再清理哪些可以被释放的空间。

垃圾收集器

新生代可用

• Serial 收集器：一个单线程的采用标记-复制算法的垃圾收集器，在其工作时会暂停所有的用户线程，但简单而高效（没有多线程交互的开销）。
• ParNew 收集器：和 Serial 收集器类似，不过时垃圾收集是多线程工作，也需要暂停所有用户线程，同样采用了标记-复制算法。
• Parallel Scavenge 收集器

老年代可用

• Serial Old 收集器：Serial 的老年代收集器，不同的是采用标记-整理收集算法。
• Parallel Old 收集器
• Concurrent Mark Sweep（CMS）收集器：从名字就能看出来是基于标记-清除算法实现的。CMS 收集器是一个追求最短的回收停顿时间的垃圾收集器而且 CMS 的工作线程可以与用户线程并行。

“全年龄”可用

• Garbage First 收集器：和其他收集器针对收集特定的新生代或者老年代不同，Garbage First 收集器将整个堆内存划分成若干个大小相等的独立区域（Region），每个 Region 都可以根据需求变成新生代的 Eden 区、Survivor 区或者是老年代，无论是新创建的对象还是存活了很长时间的对象都能有很好的收集效果。

JDK 默认的垃圾回收算法

• 在 JDK 5 中新生代默认使用的是 Serial（串行化复制收集），老年代默认的是 Serial Old（串行化标记整理）
• 在 JDK 7/8 中新生代默认使用 Parallel Scavenge（一个注重吞吐量的垃圾回收算法），老年代（8中的元空间）默认的是 Parallel Old
• 在 JDK 9 中默认使用 G1（全区垃圾收集）

JVM 调优

什么时候要调优

• 堆内存持续上涨
• Full GC 频繁
• GC 时间过长
• 出现 OOM
• 系统吞吐量下降

调优的原则

• 大多数应用不需要调优
• 多数导致 GC 的问题都是代码问题
• 减少对象的创建
• 减少使用大对象和全局变量

调优的目标

• GC 低频率， GC 低停顿
• 低内存占用
• 高吞吐量

调优涉及到的参数

• -Xms：初始化堆内存大小
• -Xmx：堆内存最大大小
• -Xmn：新生代大小
• -XX:SurvivorRatio：Eden 区与每个 Survivor 区域的比值
• -XX:+DisableExplicitGC：禁止显示触发 GC
• -XX:CMSInitiatingOccupancyFraction：老年代回收阈值
• -XX:ConcGCThreads：CMS 回收器线程数
• -XX:ParallelGCThreads：新生代并行收集器线程数
• -XX:CMSFullGCsBeforeCompaction：经过多少次 Full GC，CMS 才会整理内存空间

堆内存设置的参考依据

默认初始化堆内存大小设置为总内存的 $1/64$，默认堆内存最大大小 $1/4$。

通常设置初始化堆内存大小和堆内存最大大小相等，建议为最大可用内存的 80%。

怎么选择合适的垃圾回收算法

• 调整堆内存大小，让 JVM 自动选择
• 如果内存小于 100，选择串行化
• 单核且没有停顿时间要求，选择串行化
• 要求响应时间，选择并发收集器

为什么替换

我部署的服务虽然不多，但部分服务必须 HTTPS，比如 Bitwarden。所以我就通过 Let‘s Encrypt 申请了泛域名证书，于是我所有的服务就都支持了 HTTPS 。但是 Let‘s Encrypt 的证书有效期只有 3 个月，想要继续使用就要定期更新。其实在机器上写个定时任务，周期性续期证书就没问题了，但是我发现我每次更新下来的证书都带有个可爱的后缀-1/-2/-3...，这样子也不是不能搞，但是太麻烦了。

最近网上冲浪🏄‍♂️的时候发现了这个工具，它最吸引我的有两点：

1. 在 Web UI 中配置就能实现和 Nginx 一样的功能
2. 支持 Let’s Encrypt 在线申请

本着折腾的原则，我决定在我的机器上部署一个🔨

替换过程记录

• 关闭原有的 Nginx

因为为了保持和原来的体验一致，那么肯定是要在 :80/:443端口进行反代，所以一定要关闭原有的 Nginx。因为我所有的服务都是 Docker 部署的，所以关闭命令很简单

docker stop nginx

• 部署 Nginx Proxy Manager

参考官网教程

• 在 Web UI 中配置

通过http://localhost:81访问后台配置页面

点击 Proxy Hosts => Add Proxy Host 即可配置反向代理，规则参照原 Nginx 配置文件配置（这里支持泛域名配置）

点击 Save 就完成了第一个域名的配置，此时访问我们的配置的域名，请求就会被发送发位于 198.168.0.2:5000 的服务上。

配置 SSL 证书（可选）

在 SSL Certificates 选项卡中点击 Add Certificate 按钮，可以选择上传自己已有的证书，也可以选择从 Let’s Encrypt 重新申请，这里选择重新申请。

Nginx Proxy Manager 支持无侵入式的 DNS 验证方式申请证书，而且支持多家 DNS 服务商。

如上图，输入域名（支持泛域名）按要求填写自己的 DNS 服务商的 Token/Key 之类的，点击 Save 就完成了第一张证书的申请，接下来就把证书配置到刚刚配置好的 Proxy Host 上吧。

回到 Host 管理，选择要配置的服务，切换到 SSL 选项卡，选择刚申请的域名即可完成配置。

到这里就完成了一个支持 HTTPS 的服务的配置，重复上面的操作（如果申请的泛域名证书后续则不用继续申请证书，只要保证在证书的有效范围即可）就可以完成全站的替换。

为什么要用缓存

使用缓存的原因要从以下两个场景来分析：

• 高性能

如果没有缓存，所有得数据都是从磁盘/硬盘读取（数据库本质上也是从文件读取），此时的读写效率会比较慢。如果将数据存储读写速度超快的内存中就不会有这样的问题，所以要使用缓存

• 高可用/高并发

在高并发的场景下，如果没有缓存，大量涌入的请求会导致数据库宕机。如果把部分数据转移到效率更高的内存中，此时部分请求不会请求到数据库，这样减小了数据库系统的压力，同时提高了相应速度

有哪些缓存中间件？为什么选用 Redis

常见的缓存中间件有 Memcached 和 Redis。和 Redis 一样 Memcached 也是基于内存以键值对存储的高性能数据库，但由于二者之间的区别我们通常使用 Redis 而不是 Memcached。

• Redis 有着更丰富的数据结构和特性，Memcached 仅支持字符串
• Redis 支持数据持久化
• Memcached 可以利用多核性能更高，而 Redis 只能使用单核
• Redis 支持分布式

利用了多核的 Memcached 性能更高，如果仅需要一个高性能的缓存时选择 Memcached 准没错，但相比之下 Redis 更可靠，所以通常选用 Redis。

为什么 Redis 是单线程的

因为 Redis 是完全基于内存存储，所以 CPU 不会成为瓶颈，如果引入多线程会带来频繁的上下文切换以及锁的操作，这必然会对性能造成损耗，所以 Redis 是单线程的。

• 纯内存操作
• 避免上下文切换
• IO 多路复用

也正是因为上面的三点让单线程的 Redis 也能有如此高的性能。

Redis 有哪些数据结构

Redis 有 5 种基本数据类型

• String 字符串类型

String 类型是 Redis 中最重要且最常用的数据类型。Redis 是基于 C 语言开发的，因为 C 语言中的字符串不是二进制安全的，所以 Redis 使用了一种 Simple Dynamic String（简单动态字符串，简称 SDS）数据结构改良了 C 语言中的字符串（使用单独的字段记录字符串的长度）。

C 语言中的字符串是以 \0 截断，如果字符串本身含有 \0 ，那么字符串就会在不该被截断的位置截断导致出现错误，这种情况下是不能用于存储二进制文本，比如图像、音频和视频等文件，此时被称为是非二进制安全，而 Redis 的 SDS 则避免了这个问题。

• Hash 散列表

和 Java 中的散列表一样存储的是键值对（K - V结构），散列表有两种底层数据结构：ZipList（压缩列表）和 HashTable （哈希表），当以下满足以下两种情况时时以 ZipList 存储：

- 散列表中所有的键/值的大小都不超过64字节时
- 散列表中键值对的个数不超过512个的时候

• List

一种列表，每个节点都包含一个字符串。其底层数据结构和 Hash 一样，在数据不多或者数据不大的情况下是 ZipList 存储；当无法满足时采用 LinkedList 存储

• Set

和 List 一样可以存储若干字符串，但在 Set 内部通过维护一张只有 Key 的散列表来保证元素不会重复，但元素之间的顺序无法保证。Set 的底层有两种数据结构：HashTable 和 InSet，当以下满足以下两种情况时时以 InSet 存储：

- 集合中元素的个数不超过512个的时候
- 集合中元素可以用整型表示

• ZSet

和 Hash 类似存储键值对，但 ZSet 的键叫做 Member（成员），值叫做 Score （分数，浮点数）；同时又和 Set 一样内部元素不允许重复。ZSet 底层同样有两种数据结构：ZipList 和 [ Dict（字典） + SkipList（跳跃表）]，当以下满足以下两种情况时时以 ZipList 存储：

- 有序集合中所有的元素的大小都不超过64字节时
- 有序集合中元素的个数不超过128个的时候

同时也有 4 种高级数据类型

• HyperLogLog

一种基数估算算法，主要用于统计一组数据中不重复的数据的个数。该算法存在一定误差，但占用空间小，可统计数量高达 $2^{64}$ 个

• Geo

用来存储地理位置信息，实现原理是 Geo Hash

• Bitmap

位图，利用比特位来映射某个元素的状态，是 Redis 基于字符串实现的功能

• Stream

可持久化的消息队列

Redis 的使用场景

• 缓存

• 分布式锁（set nx ex / lua 脚本）

• 计数器（利用 incr 命令实现）

• 附近的人（Geo）

• 消息队列（rpush + blpop/lpush + rlpop）

• 延迟队列（ZSet）

什么是缓存雪崩、击穿和穿透

• 雪崩

雪崩是指在一瞬间大量的 Key 过期导致大量请求涌入数据库造成的系统崩溃，可以通过在设置过期时间时增加小随机数的方法来避免雪崩

• 击穿

击穿和雪崩类似，不过击穿指的是一个热点 Key 过期导致的崩溃，可以利用互斥锁让只有一个请求到数据库查询并回填缓存

• 穿透

穿透是指不断请求缓存中没有的 Key 导致的问题，可以通过对请求参数的校验来避免或者使用布隆过滤器

Redis 有哪些内存淘汰策略

因为机器的内存是有限的，所以 Redis 是不可以不停的往里写入的，当 Redis 使用量已经达到最大内存时会触发淘汰机制，会根据配置的不同策略删除不同的 Key

Redis 的持久化方法

因为内存中的数据在机器重新启动的时候会全部丢失，所以 Redis 会周期性的进行内存数据的持久化。Redis 的持久化策略有两种：

• RDB

RDB 是对当前内存中所有数据的一个快照，即保存了当前所有数据的状态。 RDB 的工作原理是 fork 一个子进程出来（此时会阻塞主线程），Redis 进程和子进程共享内存，快照操作在子进程中完成，并不会影响 Redis 线程继续处理命令，如果 Redis 内存占用比较高又频繁改动的时候，最多可能会导致 Redis 使用了双倍的内存。

• AOF

与 RDB 全盘备份不同，AOF 是把每个命令在执行成功后写入缓存中，再根据配置的触发策略将缓存中的内容写入文件中

• 混合持久化

混合持久化是 Redis 4.0 以后新加入的方式，是将上面两种持久化方式结合起来，先利用 RDB 保存系统的快照，在保存快照的同时产生的新的命令以 AOF 的方式记录，最终将二者结合起来一并写入文件中

Redis 的持久化策略该如何选择

• 如果缓存中的数据丢失不重要的时候选择不持久化
• 如果允许丢失较长时间的数据，那么选择 RDB，对性能影响小
• 如果对数据丢失比较敏感，那么只能选择 AOF
• 如果在主从分离的环境下，关闭主节点的持久化（提高性能），开启子节点的 RDB

有哪些方式保证 Redis 的高可用

• 主从模式

避免单节点的 Redis 发生故障，将 Redis 中的数据全量复制到其他节点上。此时 Redis 有两种角色：主节点（Master）和从节点（Slave），在主节点上可以进行读写操作，而在从节点上只能进行读操作。主从模式下主要是为了分担主节点的读的压力，并提供容灾恢复的能力

• 哨兵模式（Sentinel）

在主从模式下如果主节点发生故障，此时的 Redis 是无法进行更新操作的，需要手动修改从节点为主节点才能恢复全部功能。针对这个问题，在 Redis 2.8 中引入了哨兵（Sentinel）机制。由 n 个哨兵（n $\geq$ 3, n 为奇数）监控主节点，当发现主节点挂掉后会自动的在可用的从节点中选举出一个新的主节点，保证 Redis 能够正常对外提供服务

• 集群模式（Cluster）

以上两种模式，每个 Redis 节点都保存着全量的数据，比较浪费空间。所以在 Redis 3.0 中引入了集群（Cluster）模式。若干个 Redis 节点组成一个集群，每个 Redis 节点都保存着部分数据；每个节点都互相连通，只需连接到任一节点，即可访问全部节点的数据。为了保证高可用，集群中的每个 Redis 都可以有多个子节点，也就是形成了小范围的主从复制，如果主节点挂了，可以选举任一子节点成为主节点，如果主节点连通其子节点一起挂掉，此时集群无法正常对外提供服务

如何保证缓存和数据库的数据一致性

只要在系统中同时使用了缓存和数据库，那么一定会面临数据的一致性问题。合理的设置缓存的过期时间只能保证最终一致性，但我们追求的是更快的一致性，此时就要在修改数据库的同时对缓存中的数据一并修改，针对缓存和数据库的先后修改顺序，共有 4 中方案：

• 先修改缓存，再修改数据库
• 先修改数据库，再修改缓存
• 先删除缓存，再修改数据库
• 先修改数据库，再删除缓存

修改缓存还是删除缓存

先说结论，通常情况下都选择删除缓存而不是更新缓存。

因为在对一个写多读少的数据修改的时候，可能短时间内会修改很多次，但只会读取一次，此时就没有必要浪费时间在每次修改数据库后再更新到缓存中，只需等待着唯一的一次读数据时缓存回填即可。

接下来再讨论删除缓存的情况：

• 先删除缓存，再修改数据库

在并发量不高的情况下没有什么问题，就算是第一步删除缓存成功，第二步写数据库失败也不会产生脏数据，但如果系统并发量较高，先删除了缓存，此时数据库的更新还没有提交，此时又来了一个请求，从数据库中读取到的还是旧的数据，再将旧数据写入缓存就会造成数据不一致的问题

• 先修改数据库，再删除缓存

如果第一步写数据库成功，第二步删除缓存失败，这样会产生脏数据，其实如果不考虑操作失败的情况下，这种方案是最靠谱的方案，但在极小概率的情况下仍然会产生脏数据：

1. 缓存中的 Key 失效
2. 请求 A 从数据库中读取值准备写入缓存
3. 此时请求 B 修改数据库的值，并删除缓存
4. 请求 A 将旧值写入缓存中

不过实际情况下，出现的概率极小，因为要满足缓存失效的瞬间有两个并发的请求，一个读，一个写这样的条件才有可能出现。

针对上面的情况，可以采用延时双删的方案，即在执行完原流程后休眠若干时间（根据自己项目情况配置）再删除缓存，这样最多也就只有若干时间的数据不一致

• 利用包管理工具yum安装
• 从官网下载并安装

一、利用包管理工具安装

1. 修改yum源为阿里源（如已修改可跳过）

• 备份系统自带源

mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup

• 下载阿里源并替换

wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

2. Redis 的安装和配置

• 配置 Fedora 软件仓库

yum install -y epel-release

• 安装 Redis

yum install -y redis

• Redis 服务相关命令

# 启动
systemctl start redis
# 查看状态
systemctl status redis
# 配置开机自启
systemctl enable redis
# 关闭
systemctl stop redis
# 取消开机自启
systemctl disable redis

Redis 服务配置文件位置 /etc/systemd/system/redis.service
通过 yum 安装的 Redis 配置文件默认使用的是 /etc/redis.conf 这个配置文件

二、从官网下载并安装

通过 yum 方式安装的 Redis 版本较低，如果对新功能有追求的话可以选择从官网手动安装

1. 下载 && 安装 && 编译

确保系统中安装了 gcc 编译器，如果未安装的话变异过程中会出现错误

yum install -y gcc

如果已经安装了 gcc，那么直接开始下面的步骤

# 下载稳定版的 Redis
wget http://download.redis.io/redis-stable.tar.gz
# 解压
tar xvzf redis-stable.tar.gz
cd redis-stable
# 编译，这里不直接用 make 是将 Redis 命令直接配置到环境变量中方便后续使用
sudo make install

接下来，耐心等待编译结束。当看到以下画面的时候，就说明已经编译成功了

到这里， 我们就可以用redis-server命令启动 Redis 服务啦～

2. 配置 Redis 服务

• 先确定要使用的配置文件（可跳过）

cp redis.conf /etc

• 配置服务

# 创建文件
touch /etc/systemd/system/redis.service
# 写入内容
tee /etc/systemd/system/redis.service <<"EOF"
[Unit]
Description=redis-server
After=network.target

[Service]
Type=forking
# redis-server 后面跟的是指定的配置文件，使用绝对路径
ExecStart=/usr/local/bin/redis-server /etc/redis.conf
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF

接下来就可以利用上面提到的 Redis 服务相关命令 来操作 Redis 服务的启动/停止

HashMap 的底层数据结构

数组 + 链表。结合了数组和链表二者的优点，利用数组可以在计算键的 hash 值以后快速的定位到所属位置，而当发生 hash 冲突（即两个键的 hash 值相等）时，又可以将元素以链表的形式存储。在 JDK 1.8 以后当链表的长度超过 8 且数组长度大于 64 以后会转变为红黑树。

HashMap 的工作原理

• 根据 HashMap 的底层结构可以知道，要想确定一个键值对（K/V）的位置要对 K 进行 hash 运算，再结合当前数组长度确定一个下标
• 如果计算出的下标没有元素（未发生 hash 冲突），那就依据当前的键值对构造一个 Node 放入数组中
• 如果发生 hash 冲突时，先判断二者的 K 是否相等，如果相等说明是同一个元素，此时更新键值对的值即可
• 如果 K 不相等，那就将当前元素插入到链表当中（JDK 1.7 是头插，1.8 是尾插）
• 插入元素后判断当前数组的长度是否大于 capacity * loadfactor，如果大于，会对整个数组进行扩容，新的数组长度为 2 * capacity，之后对 HashMap 中的所有 K 重新进行 hash，确定在新数组中的位置

Hash 算法的实现

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

计算 K 的 hashCode 的高16位异或低16位的值，让高16位的值参与了 hash 运算，而且减少了 hash 冲突的概率

如何确定 table 的容量？loadFactor 又是什么？

• table 数组的长度由 capacity 决定，默认值是16，最大值是 1 « 30
• loadFactor 是负载因子，用于规定 table 数组是否需要扩容。默认的负载因子是 0.75

为什么 HashMap 的底层数组长度为何总是 $2^n$

• 如果不考虑这个问题的话，根据 hash 值计算下标通常是 hash % length，此时数组长度为多少都可以。但是数组的长度决定了 HashMap 的存取效率，于是开发人员就发现了当 length 为 $2^n$时 hash & （length - 1）= hash % length，因为位运算效率要比求模运算效率高，所以数组长度就一直保持在 $2^n$
• 当使用了上述的计算公式时，如果数组长度不为 $2^n$ 时，length - 1 转换成2进制时最后一位为 0，在进行 & 运算时会造成空间浪费；而当长度为2的n次方时，计算的结果可以均匀的分配到数组的每一个位置

JDK1.7 和 JDK1.8 中的 HashMap 有什么不同

• 底层数据结构不同，1.7 中是数组 + 链表，而在 1.8 中当链表的长度大于 8 且数组长度大于 64 时会转变为红黑树（小于 6 时会重新变回链表）
• 在发生 hash 冲突时，1.7 中是插入到链表的头部，而 1.8 则是插入链表尾部

为什么 HashMap 是线程不安全的

• put/get 操作并不是原子操作，多线程中可能会覆盖其他线程写入的值
• 在 1.7 中头插法会修改链表元素的位置，导致产生环。当获取有环的元素时会造成死循环，在 1.8 中修改为尾插来避免这个问题