SQL调优是一个很大的概念，但是大致就是从索引优化、代码/业务优化、架构优化几个方向上来做：

• 比如最常说的索引优化：
  1. 我们可以使用覆盖索引避免回表；
  2. 然后就是尽量满足最左匹配原则，避免索引失效；
  3. 还有就是索引也不宜过多，这样写入的时候维护索引的成本就高了，也占磁盘空间，mysql选择索引的时候也会选择困难
• 再从从代码/业务层面的话：
  1. 减少sql次数，不在循环发sql，避免频繁数据库IO
  2. 可以尽量控制事务范围，用小事务避免使用大事务，不在事务中做文件/网络IO操作
  3. 在业务允许的情况下，使用合适的隔离级别，如RR->RC，避免锁等待
  4. 在业务上做优化，比如如果需要查询未加索引的情况时，要求用户必填一个加了索引的字段，先筛选掉一部分数据在逐行查询
• 最后就是架构上来说：
  1. 最容易想到的就是加缓存中间层分担数据库压力，如redis、caffiein、guava
  2. 可以使用读写分离、分库分表（注意数据库主键与业务主键分离）+使用OLAP数据库定时归档减少OLTP数据库的数据量来分担数据库压力
  3. 还可以通过升级数据库版本、采用性能更好的连接池来优化

调优大方向

1. 索引优化：联合索引、覆盖索引、隐式类型转换、控制索引数量
2. 架构优化：读写分离、分库分表、缓存中间层
3. 数据库升级/版本升级：5.7->8.0优化器改进、更好的执行计划
4. 更好的查询引擎/混合架构：使用OLAP分析性数据库，如ClickHouse、Doris、TiDB
5. 并发/锁优化：避免大事务、合理使用隔离级别（RR->RC），避免锁等待
6. 代码优化：不在事务中进行网络IO/文件IO操作、使用短事务、减少SQL次数，避免频繁数据库IO
7. 业务优化：在查询未用索引字段强制必填索引字段先筛选一部分

索引优化技巧

1. 最左前缀原则：联合索引必须从最左边的字段开始使用。
2. 索引覆盖：查询的字段都包含在索引里，避免回表，提高性能。
3. 索引下推：MySQL 5.6+ 提供优化，先在存储引擎层用索引过滤条件，减少回表次数。
4. 控制索引数量：降低写入维护索引成本，避免查询优化器难以选择
5. 索引选择性：读多写少，越散列的字段越适合加索引

你做过哪些具体的优化呢？

像架构的优化太大了，我们最常做的就是对索引和业务的优化

1. 没使用联合索引导致回表的查询慢
   • 比如我记得之前因为刚开始真正的就是到企业工作，之前更多是做的一些比赛和练手的项目，所以对于企业这种模式还是没经验，当时我记得是有一个新的查询功能嘛，然后我当时就是按平时我做练习的一些习惯，在mysql里把数据库语句写好了查出来数据，然后改成xml放到mybatis里，但是其实这种存在的问题就是可能我需要的这些字段没有建立联合索引，所以会导致这个查询效率不高，当时这个接口也确实查询比较慢，就定位到这里，其实当时xml文件上面有之前同时写好的建立了联合索引的<sql>标签，只是当时我没有使用这个标签去查，然后后面我就改成了这个联合索引嘛，然后通过在这个业务层把需要的字段组装成vo再返回给前端嘛，提高了这个查询到效率。
2. 用户查询无索引字段的业务优化
   • 还有就是用户反馈某个查询特别慢，反馈到我们这里，然后要求我们改，当时我们去看了，那个需求就是要查询一个无索引的字段，这个没有索引慢是正常的，当时我们评审了这个是一个就是修改较为频繁的字段，建立索引不合适，会导致写入很慢，但是这个字段又有查询的需求，还要快，当时我们跟产品扯了好久，最后我们就是采取折中的方案，就是你要查询这个没有索引的字段，那你必须填一个建立了索引的字段，这样我们通过有索引的字段先筛掉一部分数据，再对剩下的数据全表扫，可以提升一部分的查询效率

• Consistency 一致性：所有节点在同一时间看到的数据必须一致。
• Availability 可用性：每个请求都能得到响应，不会出现长时间阻塞或错误。
• Partition tolerance 分区容错性：当网络通信出现故障时（如网络丢包、节点之间无法连通），系统仍能继续运作。

在分布式系统中，网络分区无法避免，所以 P 必须保证。那么我们主要在AP/CP模式中做取舍。

CP：保证一致性 + 分区容错，牺牲可用性，适用于需要保证强一致允许响应慢或者直接拒绝请求

AP：保证可用性 + 分区容错，牺牲一致性，保证高可用，响应快但是允许短时数据不一致（我们的项目使用AP）

什么是BASE理论？

• BA（Basically Available-基本可用）：系统在出现故障或网络分区时，允许损失部分可用性，但必须保证核心功能可用

• S（Soft state-软状态）：一定时间内，系统中的数据可以是中间状态、未同步状态，允许临时不一致状态

• E（Eventually consistent-最终一致性）：虽然系统允许短时间不一致，但在乱状态结束后，最终达到数据一致

在实际项目中我们也是遵循BASE理论，基本采用的AP模式保证系统高可用，允许短时的数据不一致。

Seata中有哪些重要角色？

1. TC（Transaction Coordinator）事务协调者：负责整个全局和分支事务事务的状态，协调全局事务的提交和回滚
2. TM（Transaction Manager）事务管理者：定义全局事务范围，开始全局事务、提交/回滚全局事务
3. RM（Resource Manager）资源管理者：管理分支事务处理的资源，与TC交谈，以注册分支事务和报告分支事务的状态，并驱动分支事务的提交/回滚。

Seata有几种模式？

• XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入

• AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式

• TCC模式：最终一致的分阶段事务模式，有业务侵入

• SAGA模式：长事务模式，有业务侵入

Nacos服务名称包括哪几部分？

namespace（命名空间）+group（组名称）+serviceName（服务名称）+cluster（集群名称）

Seata客户端获取TC的cluster名称的方式？

以tx-group-service的值为key到vgroupMapping中查找

什么是2PC、3PC？

• 2PC：两阶段提交
  1. 准备阶段：执行SQL语句但是不提交
  2. 提交/回滚阶段：等到所有节点都返回YES就commit，否则rollback
     • 优点：保证强一致性
     • 缺点：
       1. 同步阻塞，性能差
       2. 单点故障会一直等待
       3. 发出commit命令时可能有参与者没收到导致数据不一致
• 3PC：三阶段提交
  1. 询问提交阶段：询问是否可以提交
  2. 预提交阶段：如果参与者都回复YES，则进入预提交阶段，锁定资源
  3. 提交阶段：通知参与者提交，如果超时由参与者自己决定提交或回滚
     • 改进点：超时参与者可以自己决定提交/回滚，避免单点故障等待问题
     • 仍存在发出commit命令时可能有参与者没收到导致数据不一致的问题

Seata的XA模式是怎么样的？

XA模式基于2PC协议，具有强一致性，但是性能差，依赖数据库支持，适用于银行金融等需要保证强一致的场景

Seata的AT模式是怎么样的？

AT模式第一阶段直接提交，并记录数据快照写入undolog，如果参与者都成功，则提交事务，异步删除undolog；如果有失败，则通过数据快照回复原始数据，性能更好，保证了最终一致性，但是存在脏写的隔离性问题，项目中常用AT模式

AT模式存在什么问题？如何解决的？

AT模式存在的最大问题就是脏写的问题，一阶段直接提交后数据可能被其他事务修改，而二阶段回滚后可能造成数据不一致；

Seata通过全局锁解决了脏写的问题，Seata 自己维护了一个逻辑全局锁，Seata 会向 TC 申请全局锁，如果全局锁冲突则必须等待/失败重试。

加了全局锁性能不就低了，那和XA模式有区别吗？

有区别！在锁粒度上有区别，AT性能更高。

XA模式的锁是数据库的锁，锁定了整行的数据；

而AT模式是Seata自己维护的逻辑锁，只锁定了字段，修改其他字段不影响。

如果其他事务不受Seata管理怎么办呢？

其实Seata不止记录了更新前的数据快照，也记录更新后的数据，回滚时采用一种类似CAS的方式比较数据有没有被修改，如果被修改了就发出异常，这时候就可以人工介入解决。

如果Undo Log写失败了怎么办？

Undo log 写入和业务 SQL 在同一个本地事务中执行，只要业务 SQL 成功，Undo log 一定存在且完整。

Seata的TCC模式是怎么样的？

1. Try（预留资源）：资源的检测和预留，如锁定库存、冻结余额

2. Confirm（确认执行）：完成资源操作业务；要求Try成功Confirm一定要能成功

3. Cancel（取消回滚）：预留资源释放，可以理解为Try的反向操作

• 优点：
  1. 性能好：一阶段直接提交，相较于AT也无需生成快照和全局锁，性能最好
  2. 不依赖数据库事务，依赖手动编码的补偿，可用于不支持事务的数据库
• 缺点：
  1. 有代码侵入，需要编写三份逻辑
  2. 无法保证强一致，只能保证最终一致性，存在软状态
  3. 需要考虑Confirm和Cancel的失败情况，需要做好幂等处理

你是如何在代码中实现TCC的？

1. 首先我们要接口定义三个方法代表 Try/Confirm/Cancel 三步；
2. 然后加上@LocalTCC和@TwoPhaseBusinessAction注解；
3. @TwoPhaseBusinessAction注解传入commit / rollback两个方法名，Try 自己就是被注解的方法；
4. 在Service中实现这个接口；
5. 然后在业务接口加上@GlobalTransactional，就实现了TCC。

1
2
3
4
5
6
7
8
9
10
11
12
13

@LocalTCC
public interface AccountTccAction {

    @TwoPhaseBusinessAction(name = "accountTccAction", 
                            commitMethod = "commit", 
                            rollbackMethod = "rollback")
    boolean prepare(@BusinessActionContextParameter(paramName = "userId") Long userId,
                    @BusinessActionContextParameter(paramName = "amount") BigDecimal amount);

    boolean commit(BusinessActionContext context);

    boolean rollback(BusinessActionContext context);
}

TCC存在什么问题？如何解决？

问题：

1. 幂等性：Confirm和Cancel失败重试，保证不重复执行
2. 空回滚：当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
3. 业务悬挂：对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂。

解决方案：

1. 幂等回滚状态判断：在在执行操作前需要判断状态是不是已经是当前操作过的状态了，如果已经是说明已经处理过一次了，就直接返回。
2. 空回滚冻结记录判断：通常在代码中，我们会在回滚前通过xid查询判断有没有冻结记录，有才执行回滚；如果没有，说明try还没做，我们就会新增一条空回滚的冻结记录，状态为回滚，但不真正回滚。
3. 悬挂冻结记录判断：判断是否已经有过冻结记录，如果为空才执行try；如果不为空，说明Cancel执行过了，直接return拒绝。

Seata的Saga模式是怎么样的？

1. 一阶段：直接提交本地事务

2. 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

• 优点：

  1. 事务参与者可以基于事件驱动实现异步调用，吞吐高

  2. 一阶段直接提交事务，无锁，性能好

  3. 不用编写TCC中的三个阶段，实现简单

• 缺点：

  1. 软状态持续时间不确定，时效性差

  2. 没有锁，没有事务隔离，会有脏写

RocketMQ会默认进行重试（客户端内部进行的，看不见的），默认会重试2次，重试次数可以自己配置；
一般来说 如果重试都失败了，可能就是MQ服务器出现了异常/宕机了，我们还需要再重试了，当然也可以编码，但是通常我们不会这么做，此时这个mq已经不能用了，但是我们要把这个消息保存到 MySQL，XXL-J0B 定时去扫描这个表，然后重新进行发送和消费消息

如何保证顺序消息？

产生乱序的原因：

生产者把消息发送到Topic的时候，默认是存储到了4个队列中，每个队列可能会被不同的消费者或不同的线程进行消费，而我们没法控制消费者或者线程的执行顺序，所以会产生乱序

保证顺序消息的前提：

1. 将一组需要保证顺序的消息放到同一个队列
2. 使用单线程进行消费

你在开发中有没有使用到MQ的事务消息？使用的业务场景是什么？为什么使用事务消息？

使用过，场景是XXX

为了保证消息和本地事务的一致性

事务消息核心：

1. half消息机制: 事务消息发送到MQ后会先被暂存起来(存储到一个特定的事务Topic中) 直到收到生产者发送来的COMMIT 才会把消息推送给消费者
2. 回查机制: MQ如果没有收到生产者发送过来的COMMIT/ROLLBACK 会自动去调用生产者的回调方法检查本地事务执行结果

我使用同步消息加事务注解的方式可以代替事务消息吗？

不可以！因为同步消息如果发生网络错误，无法判断MQ时候收到消息，是为送到就网络故障还是MQ收到消息返回时网络故障；

如果MQ收到消息返回时网络故障，加上事务注解的方法回滚事务，MQ消费了消息，还是会导致数据不一致，所以必须依赖事务消息的半消息+事务回查机制来保证事务

广播模式和集群模式有什么区别？

广播模式就像是个人作业，每个消费者都要做，每个消费者组里的每个消费者都要消费topic里的所有消息；

集群模式就像是小组作业，每个消费者组都要做，一个消费者组里的消费者平分topic里的消息（组内负载均衡）。

RocketMQ的架构是什么样？

• NameServer是RocketMQ的轻量级注册中心
• Broker是消息的核心存储和转发组件
• Producer负责生成消息并发送到指定的Topic
• Consumer负责从Broker拉取并处理消息

消息是如何传递的？

1. Producer发送消息到Broker的指定Topic和Queue。
2. Broker存储消息（根据刷盘和复制策略），并维护消息的索引。
3. Consumer从Broker拉取消息，按订阅规则处理。
4. NameServer持续提供路由支持，确保Producer和Consumer能动态发现Broker。
5. 如果Broker集群包含Master和Slave，消息会在主从间复制以提高可靠性；Consumer可从Master或Slave（视配置）消费消息。

NameServer 集群之间会相互通信吗？

不会，每个 NameServer 独立记录 Broker 和 Topic 的信息（比如哪个 Broker 存了哪些 Topic）。它们之间不聊天，每个 NameServer 自己维护一份完整的数据副本。

Broker 会连接到每个 NameServer 吗，还是只连接到一个 NameServer 就可以了？

Broker 会 连接到所有 NameServer

如果 Broker 崩溃了，NameServer 如何感知？

Broker 会每隔一段时间（30秒）向所有的 NameServer 发送一次心跳包，如果 NameServer 在一段时间（默认 120s）没有收到某个 Broker 的心跳，就认为该 Broker 已崩溃，会从路由表中移除它。

Broker 集群之间会相互通信吗？

不会直接相互通信，只有主从关系主节点会把消息复制到从节点

一个 Topic 可以存储在多个 Broker 上吗？存储的数据是相同的还是不同的？

一个 Topic 可以存储在多个 Broker 上。存储的数据 通常是不同的，因为 Topic 的消息被分成多个队列（Queue），分散在不同 Broker 上。

一个消费者可以同时监听多个 Topic 吗？

可以

具体实现得看消费者如何定义，如果是一台服务器为一个消费者，那么可以通过多个类监听同一个topic，通过tag来区分不同；如果一个类为一个消费者，那么只能通过传统的API方式订阅多个topic

你们RocketMQ项目用的什么集群架构？

我们项目用的是多主多从的主从架构。Master 处理读写，Slave 处理读不可写，除非Slave角色更换成了Master，复制 Master 数据做备份。

如果 Master 宕机了，Slave 会进行 Master 角色转换吗？

我记得在之前的版本，是不能自动切换的，从节点可以继续读，但是不能写了，只能手动配置更换主节点；

但是在5.0+之后好像就可以支持自动切换了

主从同步的具体过程？

从节点主动先主节点发送同步请求，请求携带offset偏移量，告诉主节点从哪里返回数据给我，也就是就是继续从上一次同步的位置继续同步；

收到主节点返回的数据后从节点会将数据存储到CommitLog中，同时更新自己的offset。

主从同步的两种方式？

1. 同步复制：主节点和从节点要同时保存成功，才会给生产者返回响应；可靠性高，但性能相对较低
2. 异步复制：主节点保存成功就立即给生产者返回响应，从节点可能还没有进行保存；性能高，但可能存在数据丢失风险

消息的存储过程是怎样的？

回答重点：

1. 消息实际存储在 CommitLog 中，ConsumeQueue 中只存储了消息在 CommitLog 中的偏移量
2. 消费者监听的 Topic 队列实际是监听的 ConsumeQueue（每个Topic中的每个队列都会对应一个ConsumeQueue），通过 ConsumeQueue 中的偏移量去CommitLog中找实际消息
3. CommitLog 不止发给了 ConsumeQueue，还发给了 IndexFile 方便通过消息ID快速查找

Producer 发送消息到 Broker 之后，Broker 使用同步或者异步的方式将消息持久化，保存到 CommitLog 中，当消息持久化到 CommitLog 之后，消息就不会丢失，可以根据 CommitLog 来进行消息重发。

生产者发送消息给MQ，MQ会把这些消息一股脑的都存储在CommitLog中，没有区分Topic和队列，然后CommitLog存储完消息后会把这个消息的大小 、消息存储在CommitLog中的偏移量(存在CommitLog中的物理位置)、消息标签的hash值都转发给ConsumeQueue；

每个Topic中的每个队列都会对应一个ConsumeQueue，消费者在对Topic进行监听的时候，其实的对ConsumeQueue进行监听，然后从ConsumeQueue中获取要消费的消息，但是消息存储在CommitLog中，

因为ConsumeQueue中有这个消息存储在CommitLog中的位置，所以可以根据这个位置直接定位到CommitLog中把消息取出来。

同时CommitLog在存储消息之后还会向IndexFile中转发这个消息的Key和消息ID，以后我们就可以直接通过这个消息ID快速查找这个消息在CommitLog中的位置。

RocketMQ为什么这么快 / 性能为什么这么高？

首先MQ会把这个消息顺序写到commitlog中 ，然后再通过consumerqueue去索引消息可以快速从commitlog中定位到消息；

MQ还使用了mmap的这种零拷贝技术 实现了MQ内存和操作系统内存的映射 减少了数据往应用层内存拷贝的次数。

消息的刷盘机制？

• 同步刷盘
  1. 生产者发送消息
  2. Broker接收消息
  3. 消息写入PageCache（内存映射文件）
  4. 立即调用force()方法强制刷盘
  5. 等待数据真正写入磁盘
  6. 刷盘完成后返回响应给生产者
• 异步刷盘
  1. 生产者发送消息
  2. Broker接收消息
  3. 消息写入PageCache（内存映射文件）
  4. 立即返回响应给生产者（不等待刷盘）
  5. 后台线程异步执行刷盘
  6. 定时或达到阈值时批量刷盘
     • 触发条件：
       • 时间间隔：默认500ms执行一次
       • 脏页数量：达到一定阈值
       • 系统要求：操作系统内存压力时主动刷盘
       • 正常关机：内存中数据会写入磁盘

同步/异步的消息、刷盘、复制之间的关系

同步消息：发送消息 等着返回 执行后续代码

异步消息：发送消息 执行后续代码 执行回调

同步刷盘：接收消息 写入磁盘 返回响应

异步刷盘：接收消息 返回响应 写入磁盘

同步复制：主服务器接收消息 同步从服务器 返回响应

异步复制：主服务器接收消息 返回响应 同步从服务器

要达到最高可靠性，使用 同步消息发送 + 同步刷盘 的组合。

要达到最高吞吐量，使用 异步消息发送 + 异步刷盘 的组合。

在实际生产中，RocketMQ 默认的配置通常是：异步刷盘（Async Flush） + 主从异步复制（ASYNC_MASTER），兼顾性能和可靠性。

触发再平衡的时机？

当消费者组变化（如新消费者加入、旧消费者下线、Queue 数变化）时，立即触发再平衡

RocketMQ消息发送失败的重试策略？

==消息重试只在集群消费 (Clustering) 模式下生效！==

无序消息：采用阶梯式延时投递，最大重试16次（可配置）。消费失败的会存入一个重试Topic（有就添加，没有就创建），并将消息转为延时消息，到时间后会作为一条新的普通消息，重新自动投递到对应消费者组的重试 Topic 队列，消费者自动订阅了这条队列进行二次消费

有序消息：有序消息为了保证顺序，会阻塞后续消息，无限次不断重新投递给消费者

处理方式：加强监控，及时通知开发人员

• 无序消息：RocketMQ 采用延时投递的方式进行重试，并使用阶梯式重试间隔来避免瞬时故障对系统造成持续压力

  1. **消费失败：**当一条无序消息被消费者消费失败后会通知 Broker进行消息重试。
  2. 创建重试Topic： Broker 检查该消费者是否有重试Topic %RETRY% + consumerGroupName如果没有则自动创建，该重试Topic的名称是固定格式且是懒加载，只有出现重试消息时才会创建，且会被消费者组自动订阅，每个消费者组对应自己的重试Topic。
  3. 时间调度： Broker 将重试消息转化为延迟消息，根据重试次数选择对应的延迟等级，并将重试消息存入内部的延迟 Topic（SCHEDULE_TOPIC_XXXX）的队列中。
  4. 定时轮询： Broker 的定时器线程扫描 SCHEDULE_TOPIC_XXXX 。
  5. 到期投递： 当消息到期时，定时器线程将其取出，并将消息作为一条新的普通消息，投递到重试 Topic (%RETRY% + consumerGroupName) 的某个队列中。
  6. 消费者拉取： 消费者因为自动订阅了%RETRY% + consumerGroupName，从而拉取到消息进行二次消费。
  • 最大重试次数： 默认是 16 次（可配置）。

• 有序消息：为了保证同一个Sharding Key（如订单 ID）下的消息消费顺序，严格按照发送顺序进行

  1. 阻塞重试： 有序消息在消费失败后，Broker 不会进行延时投递。它会无限次地、立即、不断地将失败消息重新投递给当前的消费者，每次重试间隔通常为 1 秒（具体取决于版本和配置）。
  2. 消费阻塞： 由于顺序性的要求，只要该消息没有消费成功，该队列 (Queue) 后续的所有消息都会被阻塞，无法被投递给任何消费者。

• 处理建议：对顺序消息的消费情况设置严格告警。在消费者代码中对异常进行严格包裹处理，如果出现消息消费失败的情况，要及时记录消息或者通知开发人员。

什么是死信队列？

死信机制是消息重试的最终兜底方案。当一条无序消息在达到最大重试次数(默认16次)后仍然消费失败，RocketMQ 会将其转移到死信队列 (Dead Letter Queue, DLQ)。一个死信队列对应一个消费组，该消费组内所有 Topic 产生的死信消息都会被收集到这一个 DLQ 中。一旦消息进入 DLQ，它将永远不会被原来的消费者组（GroupID）正常消费到。死信消息默认有保留时间，超时后会被系统自动清理。

如何处理死信队列？

用户可以创建独立的消费者组订阅死信Topic，将死信消息记录到日志、发送警报给开发人员、存储到数据库，或者人工审核后重新发送到原来的Topic。

RocketMQ 如何保证消息不丢失（消息的可靠性）

生产者：如果消息发送失败，MQ会默认进行2次重试，如果还是发送失败，我们可以捕获MQ返回的异常然后把消息进行其他位置的存储(Redis/MySQL)，最后再人为干预处理这些发送失败的消息。

Broker：消息到达MQ后会先存储中内存中，我们可以配置同步刷盘将消息立即存储到硬盘，同时也可以配置主从到同步复制，让消息中从服务器中也存储一份。

消费者：如果消费者消费失败消息会自动进行重试，如果达到重试次数会进入到死信，我们可以去写个消费者监听这个死信队列，然后处理死信消息。

RocketMQ 如何保证消息的顺序性

首先我们要保证顺序必须知道为什么会产生乱序：多个顺序消息在进行发送的时候，默认是会轮询存储到不同的队列中，每个队列可能是有不同的消费者实例或者是不同的线程进行消费的，我们不能保证多个实例或者多个线程的消费顺序。

那我们保证顺序的就是：把消息放到一个队列中，并用单线程消费

RocketMQ 消息堆积了怎么解决

发生消息堆积首先想到的就是增加消费者暂时解决或缓解问题，再排查是否有消息有耗时操作（如IO/大量计算/大量数据排序等），再评估消费者个数。

RocketMQ 如何保证高可用性

NameServer：部署多个NameServer集群，多节点独立运行，互不依赖。

Broker集群：采用多 Master 多 Slave的主从架构，配置主从复制，实现自动故障转移。

RocketMQ 如何保证幂等性 / 确保消息不会被重复消费

有些操作天然就是幂等性的，比如MySQL中的删除操作，执行多次同一个SQL语句，对数据库影响是一致的；如果消费逻辑中就都是幂等性的操作，其实可以不用去做非幂等性的措施。

对于非幂等性的操作来说，我们要进行处理，防止一个消息被重复消费多次，记录每次消费过的消息ID，存储到Redis/MySQL中，再每次消费前先查询是否已经被消费过；

如果消费操作是操作数据库的，我们可以根据业务自动判断查询数据库中是否已经操作过这个数据了，如果是更新的，可以使用乐观锁

RocketMQ 消息存储过程是什么

消息生产者发送消息给MQ的Broker，Broker会先把消息存储到内存（Page Cache），如果配置的是同步刷盘，消息会立即存储到磁盘，如果配置的是异步刷盘，消息不会立即存储磁盘

消息中存储到磁盘的时候，先直接存储到Commit Log中，同时Commit Log还会向ConsumerQueue和Index File做两次转发，ConsumerQueue会记录消息在CommitLog中存储的位置信息，Index File会记录消息的Key和消息的ID，同时还会记录消息在CommitLog中存储的位置信息。

RocketMQ 的架构是怎么样的

Name Server：记录Broker中的Topic的信息，多个Name Server之间不会进行通信，依靠Broker进行数据同步

Broker： 存储消息的，启动会向Name Server进行注册，同时还会向Name Server发送心跳

Producer： 发送消息的，会先从Name Server根据Topic获取Broker的信息，然后发送消息给Broker

Consumer：接收消息的，会先从Name Server根据Topic获取Broker的信息，然后从Broker接收消息

RocketMQ延时消息不同版本的实现方式？

• 在4.x版本是通过延时级别实现的，消息会先放进一个系统延迟队列里，Broker 后台线程定时扫描，到期后再投递到真实主题，精度是秒级，默认18个级别，从1s-2h（1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h）

• 在5.x版本改为采用时间轮机制实现，可以设置任意毫秒级的投递时间，延时精度更高、性能更好，也没有固定档位限制

我主要使用的是 Redis的缓存和它的分布式锁功能

Redis 为什么快？

1. 基于内存操作：内存的速度远高于访问磁盘的速度
2. 单线程 + I/O 多路复用：避免了多线程带来的锁竞争、上下文切换的开销。
3. 高效的底层数据结构和编码：使用内存紧凑的 ziplist (压缩列表) 来存储数据，以节省内存空间。
4. 非阻塞操作：对于耗时的操作（如持久化），会交由子进程去处理，主进程继续响应客户端请求

数据持久化的方式？

• RDB (Redis Database): 快照形式，在一个时间点将数据保存到磁盘。
  • 优点: 体积小，恢复快
  • 缺点: 有可能导致数据的丢失，在创建子进程时候可能会导致主进程的瞬间阻塞
• AOF (Append Only File): 日志形式，记录 Redis 执行的每个写命令。
  • 优点：
    • 高可靠性：配置为 always 时零数据丢失；everysec 时仅 1 秒丢失。
    • 易恢复：AOF 是可读的协议格式，便于手动编辑。
    • 抗损坏：追加式，电源故障仅影响最后命令，易修复。
    • 后台重写：不中断服务，文件保持紧凑。
  • 缺点：
    • 文件大小：比 RDB 大（即使重写后），尤其对相同数据集。
    • 性能：always 策略下 I/O 开销高，恢复慢（需回放所有命令）。
• 混合持久化（Redis 4.0+）：为了结合 RDB 和 AOF 的优势，Redis 引入了混合持久化；
  • 工作方式： 在进行 AOF 重写时，子进程先将内存中的数据以 RDB 格式写入到新 AOF 文件的开头。接着，再将重写期间发生的增量命令以 AOF 格式追加到 RDB 数据的后面。
  • 优势： 启动时，先加载 RDB 部分（快），再执行 AOF 部分（保证数据最新），兼顾了启动速度和数据完整性。

RDB的持久化过程？

回答重点：

1. 压缩二进制文件
2. 子线程操作，创建子线程阻塞主线程
3. 共享内存，写时复制COW受影响页
4. 创建临时文件，完成后重命名

RDB 是通过生成一个经过压缩的二进制文件（.rdb 文件），来保存某个时间点的数据库状态（快照）。

主进程在接收到持久化命令或达到触发条件，会执行fork()操作，创建子线程（此时会阻塞主线程，父子线程共享同一内存区域）；

在RDB期间，如果主线程有写请求，通过COW机制复制受影响的页（降低内存开销），从而可以继续处理；

子线程会将内存数据集写入一个临时 RDB 文件（防止意外导致原dump文件损坏），全部写完后子进程调用操作系统的 rename() 将临时文件重命名为正式的RDB文件（如 dump.rdb），子进程退出并通知父进程。

AOF的执行过程？

在客户端发送写命令后，主进程会将命令格式化为AOF格式后追加到AOF缓冲区，根据配置的策略，使用 fsync 系统调用将缓冲区数据刷到磁盘，确保持久性。

AOF 有哪些策略（fsync 策略）？

• always：每次写命令都进行 fsync 同步(刷盘)。最高可靠性，但性能最低（支持组提交以优化并行写）。

• everysec（默认）：每秒进行一次 fsync 同步。高性能，崩溃时最多丢失 1 秒数据。

• no：由操作系统决定何时同步。最高性能，但数据丢失风险高。

什么是 AOF 文件重写？

随着时间推移，AOF 文件会变得越来越大，因为其中包含很多重复的、过期或无效的命令。为了消除冗余命令，会生成一个新的最小的 AOF 文件来替换原来的AOF文件，还原当前内存数据库状态。

重写不是读取旧的 AOF 文件，而是直接读取内存中的当前数据，用最少的命令来重建数据。

AOF 重写执行过程？

回答重点：

1. 创建子线程，通过数据快照写入新文件
2. 新命令同时写入两个缓冲区
3. AOF缓冲区同步到旧的AOF文件中
4. AOF重写缓冲区追加到写完的新AOF文件的末尾
5. 原子性地替换文件

当触发AOF重写条件时，主进程会fork一个子进程。这时子进程会创建一个新的AOF文件（防止发生意外破坏旧文件）。

此时主进程继续处理客户端的命令，接收到的新命令会同时写入 AOF缓冲区（主进程用，原来就有）和 AOF重写缓冲区（子进程用），AOF缓冲区的内容会被同步到旧的AOF文件中。

子进程将数据库快照重写完毕后，会通知主进程然后主进程会将 AOF重写缓冲区 中的所有内容追加到子进程生成的那个临时的新AOF文件的末尾（这样，新AOF文件就包含了重写开始时的内存快照数据 + 重写期间的所有新数据，与当前数据库状态完全一致），然后 原子性地用新的AOF文件替换旧的AOF文件。

AOF 重写触发条件?

同时满足：

最小触发大小: 默认值是 64MB

增长率阈值: 默认值是 100%

Key过期后的删除策略？

Redis 支持三种过期删除策略：定时删除、惰性删除 和 定期删除。这些策略不是互斥的，而是结合使用（默认惰性 + 定期）。

Redis 为每个数据库维护一个额外的字典（过期时间字典），避免扫描所有键，全局字典太大，过期时间字典中只含过期键。

三种删除策略的区别？

• 定时删除：为每个设置过期时间的 Key 创建一个定时器。时间一到，定时器立即触发删除。

  • 优点：保证 Key 在过期后立即被删除，内存释放及时。

  • 缺点：对 CPU不友好，需要大量创建和管理定时器，且在大量 Key 同时过期时，会瞬间占用大量 CPU 资源

• 惰性删除：不主动删除过期键，而是在访问键时判断是否过期，如果过期则删除并返回 nil，这是一种被动策略。

  • 优点：节省 CPU 资源，仅在必要时检查，不需要周期性扫描。

  • 缺点：如果过期键长期不被访问，会一直占用内存直到内存满（然后依赖淘汰策略）。

• 定期删除：Redis 会周期性地（默认每秒 10 次）随机从过期时间字典中抽取一批 Key（默认为 20 个），检查并删除已过期的 Key，如果删除的过期 Key 数量超过总抽样 Key 数量的 25%（即 5 个），则认为过期 Key 较多，会再次重复此过程，直到比例低于 25% 或达到最大运行时间限制（默认 25 毫秒）。

  • 优点：平衡了 CPU 和内存，定期清理，避免惰性删除的内存积累，对主线程阻塞几乎可以忽略。

  • 缺点：不能保证立即删除；随机采样，可能遗漏一些键。如果过期键爆发式增加，可能清理不及时，导致内存压力。

内存满了之后的淘汰策略？

淘汰范围：

• 全部 Key（allkeys-xxx）：从所有键中淘汰，包括永久键。
• 过期 Key（volatile-xxx）：仅从设置了过期时间的键中淘汰。

算法：

• LRU（Least Recently Used）：最近使用时间最远，优先淘汰最久未访问的键。
• LFU（Least Frequently Used）：最近使用次数最少，优先淘汰访问频率最低的键。
• Random：随机淘汰。
• TTL：优先淘汰 TTL 最小的键（即将过期）。

• 不淘汰策略 （默认）：

  • noeviction：当内存不足时，对于新的写入操作会直接拒绝并返回错误。读取操作仍然正常执行。

• 全 Key 淘汰策略：

  • allkeys-lru：从所有 Key 中，选择最近最少使用的 Key 进行淘汰。

  • allkeys-lfu：从所有 Key 中，选择最不经常使用的 Key 进行淘汰。

  • allkeys-random：从所有 Key 中，随机选择 Key 进行淘汰。

• 过期 Key 淘汰策略：

  • volatile-lru：从设置了过期时间的 Key 中，选择最近最少使用的 Key 进行淘汰。
  • volatile-lfu：从设置了过期时间的 Key 中，选择最不经常使用的 Key 进行淘汰。
  • volatile-random：从设置了过期时间的 Key 中，随机选择 Key 进行淘汰。
  • volatile-ttl：从设置了过期时间的 Key 中，选择剩余生存时间（TTL）最短的 Key 进行淘汰。

String底层是怎么实现的？

1. int编码: 当存储的是整数, 且可以用long表示时使用
2. embstr编码: 当存储的字符串长度≤44字节时使用
3. raw编码(SDS): 当字符串长度>44字节时使用

SDS相比C字符串有什么优势?

1. **O(1)**获取长度 - 有len字段​
2. 减少内存重分配次数 - 空间预分配和惰性释放​
3. 二进制安全 - 可存任意数据
4. 防止缓冲区溢出 - 自动扩容

Hash什么时候用ziplist, 什么时候用hashtable?

ziplist使用条件(同时满足):

• 键值对数量 ≤ 512

• 所有键值长度 ≤ 64字节

不满足任一条件就转为hashtable

List为什么不直接用链表或数组?

纯链表: 内存不连续,CPU缓存不友好

纯数组: 插入删除效率低

quicklist结合两者优点:

• 用ziplist保证内存连续性

• 用双向链表保证插入删除效率

set在什么情况下用 intset?

Set的所有元素都是整数，且数量≤512时；

一旦添加非整数或超过512个,就转为hashtable

什么是跳表？

跳表是一个分级别的数据结构, 最底层的那个级别存储了所有的元素, 每往上一层这个数据就会减少；

在进行数据存储的时候, 先存储在最底层, 然后往上存储, 上一层存储的概率是25%, 每往上一层都会乘以0.25，最高到32层；

查询的时候是从上往下进行查询, 因为上层的数据比较少, 相对于是索引结构, 可以快速定位到目标数据。

ZSet为什么要同时用skiplist和dict?

skiplist: 提供有序性,支持范围查询ZRANGE

dict: 提供O(1)的ZSCORE查询快速获取分数

两个结构配合使用,各取所长，内存通过指针共享,不会浪费

自己实现的分布式锁有什么问题？Redisson是如何解决这些问题的？

redis分布式锁的基本原理是SETNX（只有当key在redis中不存在才存储成功，存在则返回失败）

Redis如何解决锁自动续期问题？

通过看门狗机制

1. 默认锁过期时间30秒​
2. 获取锁成功后，Redisson会启动一个后台线程（看门狗）
3. 每隔10秒检查一次你的这个锁还在不在，如果不在说明你自己手动释放了
4. 如果还在，说明 业务还在执行，自动重置30秒
5. 业务完成后，停止续期

前提：你在使用Redisson去获取分布式锁的时候不要去设置过期时间，如果你自己设置了过期时间，看门狗就失效了

主从复制的过程？

1. Slave节点会主动向Master节点发送同步数据的请求
   • 如果是第一次同步 发送的命令是 psync2 ? -1 ?代表的是第一次同步 -1代表的是同步所有数据
   • 如果不是第一次同步 发送的命令是 psync2 主节点的runid 上一次同步到的偏移量位置 offset
2. Master节点收到Slave的同步数据请求后 如果是第一次同步 会将自己内存中的数据 生成RDB文件 同时把自己的runid和自己当前复制缓冲区中的偏移量信息都返回给Slave
3. Slave收到Master返回的同步数据 然后进行RDB的恢复 同时保存Master的runid和offset
4. Slave还会定期向Master发送同步数据的请求 psync2 runid offset
5. Master接收同步数据请求后会进行判断
   • 先判断Slave传递过来的runid 是不是自己的runid
     • 如果是自己的runid 再去对比offset
     • 如果不是自己的runid 会再次进行全量复制
   • 然后判断offset是否在当前的复制缓冲区内
     • 如果在就直接从offset的位置开始 返回到最新的数据 同时把最新的offset返回给Slave
     • 如果不在说明Slave已经长时间没有给Master进行数据同步了 复制缓冲区中的数据已经丢失了部分 会再次触发全量复制
6. 定期重复第4步和第5步

什么情况会触发全量复制？

1. 第一次同步时
2. runid不一致
3. offset不在复制缓冲区内

哪些情况下会导致频繁的全量复制？

1. Master重启或故障（run_id变化）
2. 网络不稳定或中断（偏移量失效）
3. 复制积压缓冲区过小（写操作覆盖缓冲区）
4. Slave重启或新增（无历史偏移量）
5. 数据量大或写频繁（缓冲区溢出，RDB传输慢）
6. 配置不当（缓冲区限制低、版本不兼容）

什么是哨兵模式？

如果Master节点发生故障, 哨兵会实现自动故障转移, 在Slave中选举出新的Master

脑裂问题及解决方案？

在哨兵或集群模式下，主节点与哨兵间网络出现中断，导致在不同网络分区的哨兵错误判断主节点下线而重新选举主节点，待网络恢复后存在两个主节点的情况（两者可同时写入，导致数据不一致）

解决方案：

1. 通过配置参数来限制原主节点写入权限（允许写入主节点的最小从节点数量、主从节点最大允许的延迟）
2. 调整哨兵判断下线时间，增加判断下线所需的哨兵数量
3. 做好日志监控报警

缓存击穿、穿透、雪崩问题及解决方案？

缓存一致性（MySQL和Redis）的解决方案？

Canal监听binlog：部署Canal工具监听MySQL binlog日志，解析变更事件后异步更新或删除Redis缓存，实现近实时同步。

读写分离+最终一致性：读从Redis，写到MySQL后通过MQ（如Kafka）通知消费者更新Redis；结合TTL设置缓存过期，确保最终一致性。

延时双删：更新DB后，先删除缓存，业务处理后延迟几秒（如500ms）再删一次缓存，确保读请求在延迟期内加载新数据。可以使用消息队列（如RabbitMQ）实现延迟删除。

先更新DB，后删除缓存：写操作时先更新MySQL，再删除对应Redis缓存（而非更新缓存），读时缓存miss则从DB加载。避免脏读，但需处理并发问题。

一个进程可包含多个线程

创建线程有几种方式？分别适用什么场景？

1. 继承 Thread 类，重写run()方法：在无需返回值时使用
2. 实现 Runnable 接口，实现run()方法：在需要返回值时使用
3. 实现 Callable 接口 + Future，实现call()方法：在需要抛出异常时使用

线程有哪些状态？

新建（New）：线程刚创建，未调用start()。
就绪（Runnable）：调用start()后，等待 CPU 调度（包含 “运行中” 状态）。
阻塞（Blocked）：等待 synchronized 锁释放时进入。
等待（Waiting）：调用wait()、join()、park()等，需被唤醒（无超时）。
超时等待（Timed Waiting）：调用wait(time)、sleep(time)等，超时后自动唤醒。
终止（Terminated）：run()执行完毕或异常终止。

什么是线程上下文切换？

当 CPU 从一个线程切换到另一个线程时，需保存当前线程的状态并加载新线程的状态，这个过程称为上下文切换（CPU将自己的时间片分给不同的的线程来执行任务）

频繁切换会消耗 CPU 资源，影响性能

什么是线程安全问题？

多个线程并发访问共享资源时，因执行顺序不确定（如指令重排、线程调度差异），导致最终结果与预期不符的问题。

导致线程不安全的原因主要有三个：原子性、可见性、有序性。

什么是原子性问题？

原子性指一个或多个操作要么全部执行，要么全部不执行，非原子操作在多线程下可能被打断，导致数据不一致。

解决方式：加锁

synchronized的加锁范围有哪些？分别锁的是什么对象？

修饰实例方法：锁当前对象（this），同一对象的多个同步方法互斥。
修饰静态方法：锁当前类的 Class 对象（如Xxx.class），所有实例共享该锁。
修饰代码块：锁括号中的对象（如synchronized(obj) { … }），可指定任意对象作为锁。

什么是死锁问题？如何检测死锁问题？如何避免死锁？

• 死锁问题：两个或者两个以上的线程持有资源，并且互相等待对方手里资源的这一种现象叫做死锁

• 排查死锁：

  1. 使用jps+jstack命令
  2. 使用arthas

• 避免死锁：

  1. 顺序加锁
  2. 设置锁超时时间

synchronized锁升级是怎么样的？

无锁：初始状态，无线程竞争。

偏向锁：第一个线程获取锁，记录线程id，此时为偏向锁。

轻量级锁：出现多个线程获取锁，但不发生实际竞争时（交替加锁，不在同一时刻竞争同一把锁），升级为轻量级锁。

重量级锁：发生实际竞争时，升级为重量级锁。

什么是悲观锁和乐观锁？都有哪些具体的实现？

悲观锁：认为竞争必然发生，操作前就先加锁，如synchronized、ReentrantLock。

乐观锁：认为竞争少，先操作，操作完后进行比较，发生冲突重试，如CAS。

什么是CAS？底层是基于什么实现的？

CAS (Compare-And-Swap、比较并且交换) 。

Java底层实际是调用Unsafe类提供的native方法实现的，底层通过CPU保证原子性。

什么是ABA问题？如何解决？

问题：变量值从 A→B→A，CAS 会误认为值未变，导致错误更新。

解决：引入版本号，更新时版本号+1

什么是可见性问题？怎么能解决可见性问题？

问题：一个线程修改共享变量后，其他线程不能立即看到最新值

解决：

1. 对变量加volatile修饰
2. 加synchronized锁

什么是有序性问题？怎么能解决有序性问题？

问题：因指令重排导致的程序执行顺序与代码顺序不一致，进而导致多线程逻辑错误

解决：

1. 对变量加volatile修饰
2. 加synchronized锁

volatile如何保证可见性以及有序性？能保证原子性吗？

volatile通过内存屏障保证可见性和有序性，但不能保证原子性，原子性可以通过加锁保证。

volatile和synchronized有什么区别？

• volatile：

  1. 可以保证可见性和有序性，但不能保证原子性；
  2. 加在变量上；
  3. 性能开销影响较小。

• synchronized：

  1. 可见性、有序性、原子性都能保证；
  2. 加在方法或代码块上；
  3. 性能开销影响大。

sleep(long n) 和 wait(long n) 有什么区别？

如何创建线程池？线程池的7个参数分别是什么，作用分别是什么？

通过ThreadPoolExecutor构造函数创建，核心参数：

1. corePoolSize：核心线程数（长期存活，即使空闲）。
2. maximumPoolSize：最大线程数（核心 + 非核心线程的上限）。
3. keepAliveTime：非核心线程的空闲存活时间。
4. unit：keepAliveTime的时间单位（如TimeUnit.SECONDS）。
5. workQueue：任务等待队列（核心线程满时存放任务）。
6. threadFactory：创建线程的工厂（可自定义线程名、优先级等）。
7. handler：拒绝策略（任务满时如何处理新任务）。

为什么不推荐使用 Executors 工具类创建线程池？

都会导致OOM

（FixedThreadPool/SingleThreadPool：使用无界队列（LinkedBlockingQueue）；CachedThreadPool：最大线程数为Integer.MAX_VALUE）

任务提交到线程池后，执行流程是怎么样的？

1. 提交任务，若核心线程数未满，创建核心线程执行任务。
2. 核心线程满，任务加入等待队列。
3. 等待队列满，若未达最大线程数，创建非核心线程执行任务。
4. 达到最大线程数，执行拒绝策略。

线程池的拒绝策略有哪些，默认是哪一种？

直接抛异常（默认） / 直接丢弃 / 丢弃最老的任务 / 交由提交任务的线程执行

• AbortPolicy（默认）：抛RejectedExecutionException异常。
• CallerRunsPolicy：让提交任务的线程自己执行（减缓提交速度，适用于轻量任务）。
• DiscardPolicy：直接丢弃新任务（无提示）。
• DiscardOldestPolicy：丢弃队列中最旧的任务，再尝试提交新任务。

ThreadLocalMap是什么？其Key和Value分别是什么？

ThreadLocal的静态内部类，类似 HashMap（但结构更简单），用于存储线程本地变量。

• Key：ThreadLocal对象（弱引用，避免 ThreadLocal 对象未被引用时的内存泄漏）。
• Value：线程私有变量（强引用）。

为什么执行了ThreadLocal的set方法后要执行remove方法？不执行会有什么后果吗？

ThreadLocalMap 的 Key（ThreadLocal 对象）被设计为弱引用，当该 ThreadLocal 对象失去所有外部强引用后，垃圾回收时会回收 Key。此时 Key 变为 null，但对应的 Value 因被 Entry 强引用而无法释放。若线程长期存活（如线程池场景）且未主动调用 remove() 清理，残留的 Value 会持续累积，最终导致内存泄漏甚至内存溢出（OOM）

什么是AQS？有哪三个核心？

AQS（AbstractQueuedSynchronizer）：抽象队列同步器，是 Java 并发工具（如 ReentrantLock、Semaphore）的基础框架。

核心：state变量，CLH队列（双向链表，先进先出），CAS操作

ReentrantLock 锁和 synchronized 锁有什么区别？

synchronized 是JVM级别的锁，但是 ReentrantLock 是Java 层面的锁（底层是基于AQS实现的）

中公超多

Semaphore有什么特点？适用于什么场景？底层是怎么实现的？

• 特点：控制同时访问资源的线程数（基于 “许可” 机制）。
• 场景：限流（如限制并发请求数）、资源池控制（如限制数据库连接数）。
• 底层实现：基于 AQS（state 表示可用许可数。acquire()减少许可，release()增加许可）

CountdownLatch有什么特点？适用于什么场景？底层是怎么实现的？

• 特点：让主线程等待多个子线程完成后再执行（倒计时门闩）。
• 场景：线程同步协作，主线程等待所有任务线程初始化完成后再开始工作。
• 底层实现：基于 AQS（state 为初始计数。子线程调用countDown()减 1，主线程调用await()等待 state=0）

CyclicBarrier有什么特点？适用于什么场景？

• 特点：让多个线程到达 “屏障点” 后再一起继续执行（可重用）。
• 场景：分阶段任务（如多线程分块处理数据，所有线程完成后再汇总）。

不直接跑在操作系统上，而是跑在 JVM 上。

JDK和JRE有什么区别？

• **JRE（Java Runtime Environment）**Java 程序的运行环境：只有JVM+核心类库（如 java.lang.*、java.util.*）
• **JDK（Java Development Kit）**Java 开发工具包：JRE+开发工具（编译器（javac）、打包工具（jar）、诊断工具（jconsole、jmap、jstack 等））

类的加载流程是怎样的？

1. 加载：从磁盘本地文件加载到JVM内存
2. 链接
   • 验证：检查字节码是否符合JVM规范
   • 准备：为静态变量赋默认值（数值型为0，布尔为false，引用为null）
   • 解析：将符号引用替换为直接引用（内存地址）
3. 初始化：执行静态代码块
4. 使用
5. 卸载

有哪几种类加载器？

1. 启动类加载器（Bootstrap ClassLoader）：负责加载核心类库（如java.lang.*、java.util.*）
2. 扩展类加载器（Extension ClassLoader）：负责加载 扩展目录（$JAVA_HOME/lib/ext） 下的类库
3. 应用类加载器（Application ClassLoader）：负责加载 classpath 下的类（我们自己写的代码、第三方依赖）
4. 自定义类加载器（Custom ClassLoader）：开发者可自己继承 ClassLoader，实现特殊的加载逻辑

什么是双亲委派机制？

类加载后由下向上请求，由上向下加载，这种方式主要是为了保证核心类库的安全，同时避免重复加载同一个类；

当一个类加载器（ClassLoader）收到“加载某个类”的请求时，它不会自己立刻去加载，而是先把请求交给它的“父加载器”去尝试。如果父加载器能找到并加载，就用父加载器的结果。如果父加载器找不到，才由自己来加载。

为什么有时候要打破双亲委派？

比如在 Tomcat 或者 SPI 这种场景下，因为父加载器加载不到我们应用里的类，或者我们需要不同Web 应用要有自己独立的类空间（避免类冲突），这时候就需要自定义类加载器，不走默认的委派规则。

如何打破双亲委派？

比如Tomcat主要通过WebAppClassLoader重写loadClass方法，优先加载当前应用类，仅对核心类委托父类加载的方式，打破了双亲委派的“父类优先”原则，满足了Web容器的特殊需求

如何判断两个class对象是否相同

1. 类的完整类名必须一致，包括包名
2. 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同

JVM 内存结构（运行时数据区）有哪些？

1. 堆：存放几乎所有对象实例和数组
2. 虚拟机栈：每个线程执行 Java 方法时都会创建一个栈帧，用来存储局部变量、操作数栈、返回地址等
3. 方法区：存储类的结构信息（类元数据）、静态变量、常量池、方法字节码等，JDK8前叫永久代（堆内存），JDK8之后改叫元空间（本地内存）
4. 程序计数器：记录当前线程正在执行的字节码指令地址
5. 本地方法栈：为 JVM 调用本地（Native）方法服务

栈帧是什么，里面有哪些东西？

虚拟机栈是由一系列 栈帧（Stack Frame） 组成的，每次调用一个方法，就会在栈里压入一个新的栈帧；方法执行完毕，就会弹出对应的栈帧

1. 局部变量表（Local Variables）：存放方法的参数和方法体内定义的局部变量
2. 操作数栈（Operand Stack）：用于方法执行中的各种运算（加减乘除）、临时存放数据、方法返回值
3. 动态链接（Dynamic Linking）：存放指向运行时常量池的引用，用于支持将符号引用 →转为直接引用
4. 方法出口（Return Address）：记录方法调用后返回的位置

常见的垃圾回收算法以及他们的优劣势？

1. 标记-清除：从 GC Roots 出发，标记所有存活的对象，清理掉没有被标记的对象（垃圾）
   • 优点：实现简单，不需要额外内存
   • 缺点：会产生大量内存碎片
2. 标记-整理：先标记存活对象，把所有存活对象往一端移动，然后清理边界以外的垃圾
   • 优点：没有内存碎片
   • 缺点：移动对象时需要调整引用，成本高
3. 复制算法：将内存分为两块，只使用一块，GC时将存活对象复制到另一块
   • 优点：没有内存碎片，复制效率高
   • 缺点：会浪费一半内存
4. 分代收集：新生代使用复制算法，老年代使用标记-清除/标记-整理算法
   • 优点：结合各算法优势，提高效率
   • 缺点：需要分区管理，增加实现复杂度

怎么判断一个对象是不是垃圾？

1. 引用计数法：每个对象维护一个“引用计数器”，有一个地方引用它时 +1，引用失效时 -1；当计数器 = 0，就认为对象可以回收。
   • 优点：实现简单，判断效率高
   • 缺点：存在循环引用的问题
2. 可达性分析算法：从一组 GC Roots（栈、静态变量、常量池、本地方法引用）出发，沿引用链往下找，能找到的对象存活（可达），找不到的就是垃圾（不可达）
   • 优点：解决了循环引用的问题

GC Roots有哪些？

1. 线程栈里的局部变量（方法里 new 的对象）
2. 类的静态变量
3. 本地方法（JNI）里引用的对象

有哪些引用类型？

1. 强引用：GC 永远不会回收它（对象一定存活）
2. 软引用：GC 会根据内存情况决定是否回收软引用对象（内存紧张才回收）
3. 弱引用：GC 一发现弱引用对象就会回收，不管内存是否够用（一遇 GC 就回收）
4. 虚引用：不能通过虚引用获取对象（get() 永远返回 null）（可以看作已经回收了）

什么情况对象从新生代进入老年代？

1. 存活年龄达到阈值（默认15）
2. 大对象直接进入老年代（可通过参数控制）
3. survivor区空间不足放不下
4. 动态年龄判断，同龄对象占空间超过一半，则小于等于该年龄的对象都会提前进入老年代

内存泄漏与内存溢出的区别？

• 内存泄露：无用对象太多，无法被GC回收，导致内存被垃圾占满了，等于是占着茅坑不拉屎（如ThreadLocal没有remove()）
• 内存溢出：有用对象太多，内存被用完了，属于是茅坑被占满了，没位置了（如递归没有控制边界）

G1为什么支持大内存回收低延迟的？

因为G1把堆划分成多个独立的小区域（Region），采用按 Region 回收 + 并行 + 并发标记 + 按收益优先回收的方式，实现了可预测的停顿时间控制。

什么情况触发Full GC？

• 老年代空间不足 + Major GC 失败
• 方法区/元空间溢出
• System.gc() 调用
• 大对象晋升失败
• 空间担保机制

空间分配担保机制是什么？

空间担保机制指的是在触发 Minor GC 前，JVM 会先检查老年代的可用空间是否足够存放新生代中可能晋升的对象，如果不够，就提前触发一次 Full GC 来“担保”空间安全，避免内存溢出。

cms的垃圾回收流程？

1. 初始标记：标记 GC Roots 能直接关联到的对象，需要STW
2. 并发标记：从初始标记的对象出发，并发地遍历整个对象图，找到所有可达对象
3. 重新标记：修正并发标记期间因为用户线程运行而导致的标记遗漏，需要STW
4. 并发清除：清除掉未被标记的垃圾对象，释放空间，可能产生内存碎片

cms垃圾回收哪几步需要stw？

初始标记和重新标记

字符串实现1.8和1.9的区别？

1.8使用字符数组char[]，1.9使用字符数组byte[]

HikariCP：最轻量、最快，Spring Boot 默认，推荐优先使用

Druid：阿里巴巴开源，性能稍逊，但功能丰富，尤其是监控、统计、SQL 防注入，适合对 安全性和运维监控 要求高的项目（牺牲少量性能换取了监控功能）

C3P0 / DBCP：曾经流行，现在基本不推荐用，除非是老项目

sql的执行流程简单说一下

1. 连接器：MySQL内部的连接池
2. 查询解析器：将SQL语句解析成语法树（类似于编译器）
3. 预处理器：预处理检查表/列是否存在，是否有权限，并将表别名解析为表名
4. 查询优化器：将解析后的SQL转换为执行计划，决定走不走索引，走哪个索引，表连接顺序
5. 执行器：根据优化器生成的执行计划，调用存储引擎 API，逐步取出数据并返回给客户端

常用的存储引擎和区别说一下

MEMORY：将数据存储在内存中，用于高速读写操作，数据在服务器重启或表被重建时会丢失

MyISAM：不支持事务、外键、行级锁，只支持表级锁，采用非聚簇索引，会存储表的总行数

InnoDb：支持事务、外键、行级锁，也支持表级锁，采用聚簇索引和非聚簇索引，但不会存储表的总行数

什么是mysql的索引，索引的底层结构是什么

索引是帮助MySQL高效获取数据的排好序的数据结构，底层数据结构是b+树

mysql页是什么？

InnoDB 存储的最小单位是 页（Page），默认大小 16KB

索引是什么意思？

是帮助MySQL高效获取数据的排好序的数据结构

b+树和b树有什么区别？

b树所有节点都存储数据，b+树只有叶子节点存储数据，可以保证树高只有2~4层，提高查询速度；并且MySQL的b+树叶子节点使用双向链表连接，提高范围查询速度

mysql有哪些索引？

数据结构角度：B+树索引、Hash索引、全文索引

物理存储角度：聚簇索引、非聚簇索引

索引类型：主键索引、唯一索引、普通索引、联合索引、全文索引

聚簇索引是什么意思？

索引结构包含所有数据的索引，InnoDB中的主键索引就属于聚簇索引。

回表是什么意思？

在使用非聚簇索引时，为了取到具体数据，则需要通过PK(主键索引)回到聚集索引里去查询数据。这个就叫回表查询。扫描了2次索引树。所以效率相对较低。

索引覆盖是什么？

当一次 SQL 查询所需的所有列，都能从索引中直接获取，而不用回表到数据页（表里）取数据时，这个查询就叫做覆盖索引查询。

索引下推是什么？

索引下推是 MySQL 5.6 引入的一种优化技术，在 存储引擎层 就提前利用索引里已有的字段来判断 WHERE 条件，筛掉不满足的记录，减少回表次数

索引为什么不能过多？

1. 写操作开销增大，需要维护索引
2. 占用存储空间
3. 优化器选择困难

主键索引为什么建议用自增id

为了避免页分裂。

因为主键id存储了全量数据，会导致每页存储数据少而页很多，从中间插入时需要改变的页也会更多。

什么是页分裂？

B+Tree 的页满了，又要在中间插入新记录时，MySQL 会：

1. 把原页拆成两个页；
2. 移动部分数据到新页；
3. 更新上层索引指针。

问题：写入性能下降（涉及大量内存和磁盘操作）。

最左前缀原则是什么？

只要查询条件从联合索引的最左边列开始，且各列在条件中连续出现（顺序可以颠倒），MySQL 就能把索引利用到。一旦跳过了某一列，右边所有列都无法再走索引。

“带头不能少，中间不能断，范围后面全完蛋。”

什么是索引合并？

当一个查询条件涉及多个不同索引时，MySQL 优化器可以 同时使用多个索引，再把结果集 合并，从而避免全表扫描。

什么是事务？

一组操作要么全部成功，要么全部失败

事务的特性是什么？

ACID

原子性（Atomicity）：事务是最小执行单位，要么全做，要么全不做。

一致性（Consistency）：事务执行前后，数据库必须从一个一致状态到另一个一致状态。

隔离性（Isolation）：多个事务并发时，互不干扰。

持久性（Durability）：事务一旦提交，修改就永久保存，不会因宕机丢失。

mysql怎么保证数据一致性的？

MySQL 对数据一致性的保证是 ACID 特性协同作用的结果：

• 原子性通过 undo log 确保操作的完整性；
• 隔离性通过锁和 MVCC 控制并发干扰；
• 持久性通过 redo log 保证提交后的数据安全；
• 最终通过这些机制，使数据库从一个一致状态（事务开始前）可靠地过渡到另一个一致状态（事务提交后）。

mysql事务并发会有哪些问题？

• 脏读：事务 A 读取到事务 B 未提交的修改（若 B 回滚，A 读取的数据是 “脏数据”）。
• 不可重复读：事务 A 多次读取同一数据，期间事务 B 修改并提交了该数据，导致 A 两次读取结果不一致。（修改导致两次读取的不一致）
• 幻读：事务 A 按条件查询数据，期间事务 B 插入 / 删除了符合条件的新数据，导致 A 再次查询时结果集增多 / 减少（类似 “幻觉”）。（增删导致的两次读取不一致）

mysql的事务特性分别是怎么实现的？

• 原子性 → undo log；
• 一致性 → 原子性 + 隔离性 + 持久性协同；
• 隔离性 → 锁机制（当前读）+ MVCC（快照读 + ReadView）；
• 持久性 → redo log。

mysql的隔离级别有哪些？

mysql默认的隔离级别有哪些？

• 读未提交（Read Uncommitted）：事务可读取其他未提交事务的修改。
• 读已提交（Read Committed）：事务只能读取其他已提交事务的修改。
• 可重复读（Repeatable Read）（默认）：事务中多次读取同一数据的结果一致（即使其他事务修改并提交）。
• 串行化（Serializable）：事务串行执行，完全避免并发问题。

不同的隔离级别分别解决了什么问题？

• 读未提交（Read Uncommitted）：什么问题都没解决
• 读已提交（Read Committed）：解决了脏读
• 可重复读（Repeatable Read）（默认）：解决了脏读、不可重复读以及部分幻读
• 串行化（Serializable）：解决所有问题，但是性能低

什么是mvcc？

MVCC（多版本并发控制）是一种并发控制手段。它通过undolog版本链+readView读视图实现，允许读写操作不冲突（读不加锁，写不阻塞读），从而提高并发性能。

readView是什么？

ReadView（读视图）是 MVCC 中用于判断数据版本可见性的逻辑结构，包含 4 个核心字段：

• m_ids：当前活跃事务 ID 集合列表。
• min_trx_id：活跃事务中最小的 ID。
• max_trx_id：下一个将分配的事务 ID。
• creator_trx_id：创建该 ReadView 的事务 ID。

作用：通过比较数据版本的事务 ID 与 ReadView 的字段，判断当前事务能否看到该版本。

可见性判断规则：

• 比最小活跃事务ID小，一定读
• 比最大活跃事务ID大，一定不读
• 在最大最小之间的：
  • 在活跃列表（未提交），不读
  • 不在列表（已提交），读

什么是快照读和当前读？他们的区别是什么？

• 快照读：读取数据的历史快照（非最新版本），不加锁，性能高。例如普通SELECT语句。
• 当前读：读取数据的最新版本，且会加锁（防止其他事务修改）。例如SELECT ... FOR UPDATE、INSERT、UPDATE、DELETE等。

区别：快照读依赖 MVCC，无锁冲突；当前读依赖锁机制，会阻塞其他事务的写操作。

不同隔离级别下生成readView的时机？

• 读未提交：不生成 ReadView，直接读取最新版本。
• 读已提交：每次执行 SELECT 时生成新的 ReadView（因此能看到其他事务已提交的修改）。
• 可重复读：事务中第一次执行 SELECT 时生成 ReadView，后续复用（因此多次读结果一致）。
• 串行化：不依赖 MVCC，通过锁机制实现，无需生成 ReadView。

可重复读怎么解决不可重复读的？

可重复读级别下，事务首次执行SELECT时生成 ReadView，后续所有查询复用该 ReadView。即使其他事务修改数据并提交，当前事务仍通过最初的 ReadView 判断可见性，因此多次读取结果一致，避免了不可重复读。

mysql的锁有哪些类型

表锁、行锁

共享锁、排他锁

意向锁

记录锁、间隙锁、临键锁

普通索引的行锁是怎么加锁的？

数据更新的流程是怎么样的？

1. 缓冲池：先看buffer pool中有没有这条数据，如果有就直接取出来，如果没有，从磁盘加载到buffer pool再操作
2. undo log日志：更新前考虑到可能回滚，所以先写一份旧值到undolog
3. 更新缓冲池数据：将内存中的数据改为新值，此时数据页和磁盘数据不一致，被标记为脏页
4. 记录redo log：先写入redo log buffer，然后按照策略刷盘（定时刷新/事务提交/log buffer写满）
5. 写入binlog：记录了所有对数据库进行更改的逻辑操作，可以实现数据库故障的数据恢复
6. 两阶段提交：通过两阶段提交最终保证事务的持久性与一致性
   • 如果一阶段redolog未刷盘就发生故障，回滚事务
   • 如果一阶段redolog刷盘但undolog未刷盘，也回滚事务
   • 如果一阶段redolog和undolog都刷盘，只有二阶段redolog未写入，依旧认为数据完整，提交事务
7. 异步线程刷盘：通过后台的异步IO线程，会在之后某个时间里，随机的把内存buffer pool中的修改后的脏数据给刷回到磁盘上的数据文件里去

mysql的bufferpool是什么？

Buffer Pool 就是 MySQL 的“内存缓存”，把常用的数据和索引页放在内存里，减少磁盘读写。（Buffer Pool 是内存里的临时副本）

redolog是什么和binlog有什么区别？

redolog是物理日志，binlog是逻辑日志

什么是逻辑日志，什么是物理日志？

• 逻辑日志：记录操作的逻辑含义（如 “将 id=1 的 name 改为 ‘abc’”），与存储格式无关，可读性强。例如 Binlog。
• 物理日志：记录数据页的物理变化（如 “数据页 0x123 的偏移量 100 处值改为 0x55”），依赖存储格式，恢复速度快。例如 Redo Log。

bufferpool的内部结构是怎么样的？

• 缓存页（Page）：默认 16KB，与磁盘数据页大小一致，用于存储数据 / 索引。
• 描述信息：每个缓存页对应一个控制块，记录页的元数据（如页地址、表空间 ID、LRU 链表指针等）。
• 链表结构：
  • Free 链表：未使用的缓存页列表。
  • LRU 链表：管理缓存页的 “冷热”，热点数据（频繁访问）在前端，冷数据在后端，淘汰时从后端移除。
  • Flush 链表：已修改但未刷盘的缓存页（脏页）列表，等待刷盘。

mysql对数据页冷热分离是怎么做的？

新加载的数据页一律放在冷数据区的链表头部，等至少 1s 之后再次访问，才会被提升到热区头部

冷数据区37%，热数据区63%（约为6 ：4）

mysql行格式是什么，什么是空值列表？

行格式规定一行数据在磁盘和内存中的存储布局。

空值列表是用一个紧凑的标记来记录，这样能大幅节省存储空间，在 COMPACT 行格式中，是用 二进制 bit 位 来标记。

有没有做过mysql的调优，怎么做的？

SQL调优是一个很大的概念，但是大致就是从索引优化、代码/业务优化、架构优化几个方向上来做：

• 比如最常说的索引优化：
  1. 我们可以使用覆盖索引避免回表；
  2. 然后就是尽量满足最左匹配原则，避免索引失效；
  3. 还有就是索引也不宜过多，这样写入的时候维护索引的成本就高了，也占磁盘空间，mysql选择索引的时候也会选择困难
• 再从从代码/业务层面的话：
  1. 减少sql次数，不在循环发sql，避免频繁数据库IO
  2. 可以尽量控制事务范围，用小事务避免使用大事务，不在事务中做文件/网络IO操作
  3. 在业务允许的情况下，使用合适的隔离级别，如RR->RC，避免锁等待
  4. 在业务上做优化，比如如果需要查询未加索引的情况时，要求用户必填一个加了索引的字段，先筛选掉一部分数据在逐行查询
• 最后就是架构上来说：
  1. 最容易想到的就是加缓存中间层分担数据库压力，如redis、caffiein、guava
  2. 可以使用读写分离、分库分表（注意数据库主键与业务主键分离）+使用OLAP数据库定时归档减少OLTP数据库的数据量来分担数据库压力
  3. 还可以通过升级数据库版本、采用性能更好的连接池来优化

mysql8.0对比5.7有哪些提升？

隐藏索引、窗口函数、更强的 JSON 支持，在线ddl

explain怎么使用，关注哪些字段

在SQL语句前加EXPLAIN关键字就可以看执行计划，主要关注possible_keys（可能用到的索引），key（实际用到的索引），type（用到了哪种索引） ，还有就是Extra（额外信息，提示索引覆盖、索引下推、产生了条件过滤临时表等）

• 单列集合（Collection）
  • List：有序、可重复的集合（如 ArrayList、LinkedList）。
  • Set：无序、不可重复的集合（如 HashSet、TreeSet）。
• 双列集合（Map）
  • 代表一组键值对（Key-Value）的映射关系，键不可重复。（如HashMap、TreeMap、LinkedHashMap）

主要类特点：

• ArrayList：动态数组，随机访问快，插入删除慢。
• LinkedList：双向链表，插入删除快（尤其是中间位置），随机访问慢。
• HashSet：底层依赖HashMap，无序，查询快。
• TreeSet：基于红黑树，元素有序（自然排序或自定义排序）。
• HashMap：数组 + 链表 / 红黑树，无序，查询、插入效率高。
• TreeMap：基于红黑树，key 有序，支持范围查询。

List和Set分别有什么特点？

• List：
  • 有序（元素插入顺序与遍历顺序一致）。
  • 可重复（允许元素值相同）。
  • 支持通过索引访问（get(int index)）。
  • 允许存储多个null元素。
• Set：
  • 无序（HashSet）或有序（TreeSet按 key 排序，LinkedHashSet按插入顺序）。
  • 不可重复（元素需重写equals()和hashCode()保证唯一性）。
  • 无索引，不支持随机访问。
  • 最多允许一个null元素（HashSet）。

ArrayList 和 LinkedList有什么区别？

ArrayList的扩容机制？

• 初始容量：默认 10（无参构造），也可通过构造函数指定初始容量。
• 扩容触发：当添加元素后，size超过当前容量时触发。
• 扩容逻辑：
  1. 计算新容量：默认是原容量的 1.5 倍（oldCapacity + (oldCapacity >> 1)）。
  2. 若新容量仍不足（如添加大量元素），直接扩容至所需容量。
  3. 通过Arrays.copyOf()复制原数组元素到新数组，替换原数组引用。

说下 HashMap的put流程及扩容机制？

• 扩容机制：
  1. 新容量为原容量的 2 倍（保证容量为 2 的幂）。
  2. 重新计算每个节点的新下标（JDK1.8 中通过hash & oldCapacity判断，0 则下标不变，1 则下标 = 原下标 + oldCapacity）。
  3. 将原数组元素迁移至新数组（链表拆分或红黑树拆分）。

HashMap的扩容如何触发？

• 当put元素后，size（键值对数量）超过阈值（capacity * loadFactor，默认负载因子 0.75）时触发。
• 特殊情况：若链表长度超过 8 且数组容量 < 64，会先扩容而非转为红黑树。

HashMap 在 JDK 1.7 和 JDK 1.8 中有什么区别？

CopyOnWriteArrayList有什么特点？

CopyOnWriteArrayList 采用的是写时复制的技术，适用于读多写少的场景，读操作不需要加锁，当时读取到的数据可能不是最新的数据。

ConcurrentHashMap在JDK1.8中是如何保证put流程和初始化流程线程安全的？

• 初始化：
  • 通过 CAS 操作保证线程安全。当table为null时，多个线程竞争初始化，CAS 成功的线程执行初始化（设置容量），失败的线程自旋等待。
• put 流程：
  1. 计算 hash 和下标，若数组未初始化则触发初始化。
  2. 若下标位置为空，通过 CAS 插入节点（无锁）。
  3. 若下标位置为MOVED（正在扩容），帮助扩容（多线程协同扩容）。
  4. 否则，对该位置的头节点加synchronized锁，执行插入（链表或红黑树）。
  5. 插入后更新元素数量（通过baseCount或CounterCell，CAS 更新避免锁竞争）。

ConcurrentHashMap在JDK1.8中和JDK1.7中分别是怎么保证线程安全的？哪个效率好？

• JDK 1.7：
  • 采用分段锁（Segment）：每个 Segment 是独立的 HashMap，自带ReentrantLock。
  • 不同 Segment 的操作互不干扰，锁粒度为 Segment。
• JDK 1.8：
  • 取消分段锁，采用CAS + synchronized：对数组槽位的头节点加锁（锁粒度为单个节点）。
  • 无竞争时用 CAS，有竞争时才加锁，效率更高。
• 效率对比：JDK 1.8 效率更高。原因是锁粒度更细（节点级），减少锁竞争，且 CAS 操作在低并发时无需阻塞，性能更优。