redis 面试题

1 redis 如何扩容

Redis 的扩容主要分为两种场景，一种是单实例的内存扩容（垂直扩容），另一种是Redis集群的扩容（水平扩容）。

单实例Redis内存扩容（垂直扩容）

硬件升级：
- 垂直扩容通常意味着增加单个Redis服务器的硬件资源，如增加内存、CPU或磁盘空间。
- 如果Redis数据量增长导致内存不足，可以通过购买更大内存的服务器来替换原有服务器，或者在云服务环境下直接升级实例规格。
局限性：
- 单实例Redis的最大容量受限于单台机器的物理内存大小，且无法实现数据分片和负载均衡，所以对于大数据量或高并发访问场景并不适用。

Redis集群扩容（水平扩容）

增加节点：
- Redis Cluster模式下，通过添加新的Redis节点到集群中来实现水平扩容。
- 集群中的每个节点都会分配一部分槽（slot），扩容时可以将部分槽从已有节点迁移到新加入的节点上。
- 扩容步骤包括：
  - 准备新的Redis服务器并安装配置Redis服务。
  - 将新节点加入到集群中，并使用 cluster meet 命令让其与其他节点通信。
  - 使用 cluster addslots 指令为新节点分配槽位。
  - 如果需要迁移数据，使用 cluster setslot <slot> migrating/<importing> <target-node-id> 进行槽位迁移操作。
哨兵模式下的扩容：
- 对于采用Sentinel模式部署的Redis，如果要进行扩容，可能需要创建新的主从结构，然后通过Sentinel重新配置对应的主从关系和服务发现规则。
阿里云等云服务商提供的Redis服务扩容：
- 对于阿里云等云服务商托管的Redis服务，往往提供了更便捷的控制台或API接口来进行在线扩容操作，用户无需关心底层细节，只需简单点击操作即可完成扩容过程，同时云服务商还会自动处理数据迁移等问题。

注意事项

在进行Redis集群扩容时，为了保证服务可用性和数据完整性，必须在业务低峰期执行操作，并确保有足够的监控和回滚计划。
Redis本身的键值对存储不涉及“扩容”概念，但在集群环境下，由于数据分布于多个节点，因此“扩容”指的是增加节点以分散数据存储压力。

2 redis 如何扩展槽位

Redis Cluster中扩展槽位的概念实际上是指在集群扩容时，将已有的槽位（slot）从一个节点迁移到另一个节点的过程。Redis Cluster通过数据分片的方式实现水平扩展，每个键会根据CRC16哈希算法映射到0至16383范围内的槽位上，每个节点负责一部分槽位。

以下是手动扩展槽位的步骤：

添加新节点：首先，在新的服务器上启动一个新的Redis实例，并配置为集群模式。然后使用cluster meet命令将其加入到现有的Redis集群中，让它与其他节点通信。
分配槽位：使用CLUSTER ADDSLOTS <slot> [slot ...]命令将一些槽位分配给新节点。例如，如果要将槽位4000至5460分配给新节点，可以执行：
Code
```
1redis-cli -c -h 新节点IP -p 新节点端口 cluster addslots 4000 4001 4002 ... 5459 5460
```
迁移槽位：如果已有槽位上有数据需要从旧节点迁移到新节点，可以使用以下命令发起迁移流程：
Code
```
1CLUSTER SETSLOT <slot> MIGRATING <目标节点ID>
```
在源节点上执行此命令后，再在目标节点上执行：
Code
```
1CLUSTER SETSLOT <slot> IMPORTING <源节点ID>
```
然后使用MIGRATE命令逐个迁移槽位上的键值对。
监控迁移过程：迁移过程中可以通过CLUSTER NODES命令查看集群状态和迁移进度。
确认迁移完成：当所有指定槽位的数据都成功迁移完毕后，再次使用CLUSTER NODES命令检查各个节点的状态，确保没有遗留的迁移状态。此时，新节点开始处理之前由其他节点负责的那些槽位上的请求。

在整个操作过程中，为了保持服务的可用性，通常会在业务低峰期进行，并且确保有充分的监控和回滚计划。在实际生产环境中，可能还需要结合自动化工具或者云服务商提供的管理界面来更安全、高效地执行这些操作。

3 CRC16哈希算法映射到0至16383范围内的槽位为啥是16383

Redis Cluster使用CRC16算法对键进行哈希以确定其所属的槽位（slot）。虽然CRC16算法可以生成一个16位的哈希值，即有2^16 = 65536种可能的输出，但Redis Cluster并没有使用全部的65536个槽位。

之所以选择16384个槽位而不是65536个，这是因为Redis Cluster设计时有意减少实际需要管理的槽数量，以简化集群管理和数据迁移。16384这个数字在设计上是出于以下几个考虑：

降低复杂度：较少的槽数量意味着当集群规模扩大或缩小时，需要迁移的数据和槽位更少，操作相对简单。
足够分散：尽管不是所有哈希值都能被充分利用，但16384个槽位对于大多数场景来说已经能够提供足够的分散性来平衡节点间的负载。
预留空间：即使不使用所有的哈希值，仍然有足够的余地供未来的扩展需求，比如在集群扩容时可以将新节点加入，并分配一部分未使用的槽位。
易于管理：从实践角度讲，更大的槽数量会增加槽位分配、迁移和重新分布的工作量，而16384个槽位在确保数据均匀分布的同时，也兼顾了集群运维的便捷性。

综上所述，Redis Cluster选择了16384作为槽位数量，它是一个能够在可用性和可管理性之间取得良好平衡的数值。通过取CRC16哈希值对16384求余数，即可将任意长度的键映射到0至16383之间的某个槽位上。

4 redis 为啥使用单线程

Redis 选择单线程模型的原因主要有以下几个方面：

内存操作速度快：
- Redis 是基于内存的数据库，所有的数据操作都在内存中完成，因此速度极快，CPU 的计算能力相对于内存操作来说通常不是瓶颈。
- 单线程执行可以避免多线程并发读写时产生的锁竞争和上下文切换开销。
简单易维护：
- 单线程模型简化了编程模型，使得代码更容易理解和调试，减少了因并发控制带来的复杂性。
高效利用单核CPU：
- 在单核CPU时代，单线程可以充分利用单个核心，并且由于其数据结构简单且大部分操作是O(1)复杂度，单线程足以提供很高的处理性能。
I/O 多路复用技术：
- Redis 使用 I/O 多路复用技术（如epoll、kqueue或select），可以在一个线程内并行处理来自多个客户端的连接请求，即使在高并发场景下也能保持高效的响应能力。
减少锁与死锁问题：
- 由于只有一个线程处理命令，Redis 不需要复杂的锁机制来保证数据一致性，从而消除了由锁引起的性能损失和死锁的可能性。
集群扩展性：
- 当单实例无法满足性能需求时，Redis 提供了集群模式，通过在不同的服务器上运行多个独立的 Redis 实例，每个实例仍然可以使用单线程模型，这样可以通过增加机器数量来实现水平扩展。

虽然早期版本的 Redis 主要依赖单线程模型获得高性能，但随着技术的发展，Redis 也在逐步引入多线程技术以优化特定场景下的性能。例如，Redis 6.0 引入了多线程用于网络IO，而在其他关键路径上仍维持单线程模型，这样的设计既保留了单线程模型的优势，又能够在不影响数据一致性的前提下提升部分性能。

5 多线程切换为啥耗时

多线程切换耗时主要涉及以下几个方面的原因：

上下文切换：
- 当CPU从执行一个线程切换到另一个线程时，需要保存当前线程的CPU寄存器状态（包括程序计数器、堆栈指针等），以便稍后能够恢复执行。同时，还需要加载下一个要执行线程的上下文信息。这个过程称为上下文切换。
- 上下文切换本身就需要一定的时间，尤其是对于非抢占式调度而言，线程必须主动释放CPU控制权才会发生切换；而对于Linux这样的系统采用的是抢占式调度，即使线程没有主动让出CPU，内核也会根据时间片或者其他调度策略强制进行切换。
缓存失效：
- 线程在执行过程中会将数据加载到CPU缓存（L1、L2、L3缓存）中以加速访问。当线程切换后，新线程可能访问完全不同的内存区域，导致之前线程加载的数据对新的线程无用，而新线程所需的数据可能不在缓存中，这就导致了缓存失效和重新加载，从而增加延迟。
锁竞争与同步开销：
- 在多线程并发访问共享资源时，通常需要使用锁机制保证数据一致性。频繁的线程切换可能导致更多的锁获取和释放操作，这些操作本身就带有不小的开销，并且可能会引发线程阻塞等待，进一步浪费CPU时间。
I/O等待与唤醒：
- 如果一个线程因为IO操作被阻塞，操作系统会挂起该线程并调度其他线程运行。当IO操作完成时，操作系统需要将阻塞线程唤醒并重新放入就绪队列，这一系列的操作也是有成本的。
TLB（Translation Lookaside Buffer）刷新：
- 多线程在不同地址空间或虚拟内存区域之间切换时，由于每个线程可能有不同的页表映射，处理器的TLB（用于加速虚拟地址到物理地址转换）可能需要刷新，这也是一种额外的开销。

综上所述，过多的线程切换会导致CPU花费大量时间在管理线程而不是实际执行任务上，从而降低了系统的整体性能。因此，在设计多线程应用时，应合理设置线程数量，并尽可能减少不必要的线程交互和同步，以降低上下文切换的频率和开销

6 zset 实现原理

Redis 中的有序集合（Sorted Set，简称ZSet）是一种同时包含成员（member）和分数（score）的数据结构，其内部实现原理基于两种数据结构的结合：压缩列表（ZipList）和跳跃表（SkipList），并且根据数据量和成员长度动态选择合适的数据结构。

压缩列表（ZipList）：当ZSet中元素数量较小且每个元素大小较小时（例如成员是短字符串），Redis会选择使用ZipList作为底层实现。ZipList是一个连续存储多个元素的高效内存结构，可以理解为一种变长数组，它不仅存储了元素值，还额外存储了每个元素对应的分数信息。在ZipList中，元素按照score排序，查询、插入和删除操作的时间复杂度并非始终为O(log N)，而是接近于O(1)或者随着列表增长渐进到O(N)。
跳跃表（SkipList）：当ZSet中的元素数量增加或成员较大时，Redis会转而使用跳跃表作为底层实现。跳跃表是一种随机化的数据结构，能够以近似O(log N)的时间复杂度完成插入、删除和查找等操作，即使是在大量数据下也能保持良好的性能。在跳跃表中，每个元素（由成员和分数组成）会被插入到多个层级的链表中，高层级的链表通过指针连接较低层级的节点，从而形成一个多层次的索引结构，便于快速定位元素。

跳跃表的优点在于它实现了高效的范围查询功能，即可以根据分数范围获取集合中的成员子集，这在排行榜、时间序列数据存储等场景中非常有用。

综上所述，Redis ZSet的核心实现机制就是将成员与分数成对存储，并利用优化的数据结构确保数据有序的同时，支持高效的增删查改操作。在实际运行过程中，Redis会根据当前ZSet集合的大小自动进行数据结构的选择和转换，以达到空间效率和时间效率的最佳平衡。

zset 什么情况下使用 ziplist

Redis中的有序集合（ZSet）在特定条件下会使用ziplist作为底层存储结构。具体来说，当ZSet满足以下两个条件时，Redis会选择ziplist进行存储：

元素数量较少： ZSet中的元素个数（成员和分数对的总数）少于128个。
元素大小较小：每个元素的成员值和分数所占用的字节长度都小于64字节。

这两个条件是为了保证ziplist能够以紧凑、连续的内存空间高效地存储数据，并且由于ziplist是顺序存储，对于小规模的数据集，访问、插入和删除操作可以具有接近O(1)的时间复杂度。随着ZSet中元素数量或单个元素大小的增长，一旦超过上述限制，Redis会自动将ZSet的编码方式转换为更适用于大量数据和复杂查询场景的跳跃表（SkipList）。

7 分布式锁的实现方法

分布式锁的实现方法主要有以下几种：

1. 基于数据库实现分布式锁

原理：在数据库中创建一个专门用于表示锁状态的表，其中包含一个唯一索引列（如lock_key）。当需要获取锁时，通过插入一条记录来代表加锁，并设置一个合理的过期时间以防止死锁。其他线程尝试加锁时，由于唯一索引的存在而无法插入相同的记录，从而达到互斥的目的。
优缺点：
- 优点：利用现有数据库系统，部署简单，易于理解和实现。
- 缺点：性能相对较低，尤其是在高并发场景下，数据库可能会成为瓶颈；另外，依赖于数据库事务的一致性保证，设计不当可能导致锁的争用和死锁问题。

2. 基于缓存实现分布式锁（如Redis）

原理：使用Redis的原子操作命令如SETNX（set if not exists）和EXPIRE来实现锁的获取和释放。线程在Redis中尝试设置一个具有特定key和超时时间的值，如果设置成功则获得锁；解锁时删除该key或再次使用原子操作更新锁状态。
优缺点：
- 优点：Redis是内存数据库，执行速度非常快，且原生支持多种适合实现分布式锁的原子指令，能够有效避免死锁并提高并发性能。
- 缺点：对Redis服务的可用性和稳定性要求较高，若Redis服务器宕机可能影响整个分布式锁服务。

3. 基于ZooKeeper实现分布式锁

原理：ZooKeeper提供了一种临时有序节点的功能，可以用来实现分布式锁。通常的做法是在指定路径下创建临时有序节点，第一个创建成功的客户端认为获得锁，之后的客户端检查当前序列号最小的节点是否为自己的节点，如果不是，则监听前一个节点，等待其释放锁后自己获得锁。
优缺点：
- 优点：ZooKeeper具备强一致性，能确保锁的互斥性、可重入性和最终一致性，且能自动处理节点失效情况下的锁释放。
- 缺点：相比基于缓存方案，ZooKeeper的网络开销较大，写入性能不如内存数据库 Redis；同时，需要维护ZooKeeper集群的稳定性和可用性。

在实际应用中，选择哪种方式实现分布式锁取决于具体的业务场景和系统的架构需求，综合考虑性能、可靠性和运维成本等因素。

8 Java 本地缓存的实现框架

Java本地缓存的实现框架主要包括以下几种：

Guava Cache
- Guava是Google开发的一个开源库，其中包含了用于构建本地缓存的功能。它提供了简单易用的API，支持自动加载、过期策略、最大容量限制以及移除通知等功能。
Caffeine
- Caffeine是基于Guava Cache设计的高性能本地缓存库，适用于Java 8及以上版本。相比Guava Cache，Caffeine利用了Java 8的新特性进一步优化了性能和内存管理，例如使用LoadingCache接口提供自动加载功能，并且通过改进的并发控制算法提升了并发访问时的吞吐量。
Ehcache
- Ehcache是一个广泛使用的Java缓存库，既支持本地缓存也支持分布式缓存。它具有丰富的配置选项，如不同的淘汰策略（LRU、LFU等）、缓存数据持久化和与Hibernate等ORM框架集成的能力。
JCS (Java Caching System)
- JCS是一个灵活的可扩展的Java缓存框架，支持多级缓存、集群缓存以及多种缓存失效策略。它可以轻松地与其他Java应用程序集成，并提供了更复杂的缓存管理功能。
自定义缓存实现
- 开发者也可以根据自身需求自行实现简单的本地缓存机制，比如使用ConcurrentHashMap配合定时任务进行清理或者结合软引用、弱引用等Java内存模型特性来实现缓存功能。
Spring Cache抽象层
- Spring Framework提供了对缓存的支持，可以整合上述各种缓存实现作为其底层存储，通过注解方式简化缓存操作，使开发者能够以统一的方式来处理不同类型的缓存框架。

这些框架在不同场景下有各自的优势，选择合适的框架取决于项目的需求、性能要求、易用性等因素。

9 Caffeine 如何确保同一时刻只有一个线程去执行数据加载操作

Caffeine 通过内部设计的同步机制来确保同一时刻只有一个线程去执行数据加载操作。在 LoadingCache 接口中，当缓存项缺失时，Caffeine 会自动触发 CacheLoader 的加载逻辑，并且在这个过程中利用了 Future 的概念以及内部的同步机制，保证了数据加载操作的原子性和并发安全。

具体来说，在缓存未命中时，调用 get(key) 或者 get(key, loader) 方法会触发如下过程：

锁的获取与释放：
- 在处理缓存未命中的情况时，Caffeine 内部会以某种方式（例如使用某个共享锁）来阻止其他线程对同一个键值进行重复的数据加载请求。
Future 和异步加载：
- 对于异步加载场景，Caffeine 使用 Future 来表示正在进行的数据加载任务，仅允许一个 Future 负责加载特定 key 的数据。后续对相同 key 的请求将会等待该 Future 完成并返回结果。
内置同步策略：
- Caffeine 的实现中采用了高效的并发控制算法，比如信号量或者更复杂的无锁数据结构来管理正在加载或已加载完成的任务队列，从而避免多个线程同时尝试加载同一条数据。
单一线程执行：
- 当缓存未命中且需要加载数据时，无论是在同步还是异步场景下，都只会有一个线程实际执行 CacheLoader.load(key) 方法从外部数据源（如数据库）加载数据。

因此，即使有多个线程同时请求同一份未缓存的数据，Caffeine 能够确保这些请求被有效地合并为一次实际的数据加载操作。

信号量或者更复杂的无锁数据结构

在Caffeine的设计中，确实使用了信号量（Semaphore）和其他高效的数据结构来确保并发安全和控制数据加载操作。不过，对于“同一时刻只有一个线程去执行数据加载操作”的具体实现，Caffeine并没有直接公开使用信号量作为同步机制的文档说明。实际上，Caffeine采用了自定义的无锁数据结构以及精心设计的算法来优化缓存加载逻辑。

Caffeine的主要作者Ben Manes曾在其博客中提到过一些内部实现细节，例如，它使用了一种称为BoundedBuffer的无锁队列结构来管理等待中的加载任务。这个队列有大小限制，并且在添加新任务时会自动丢弃超出限制的任务，从而避免内存溢出等问题。

此外，在处理缓存未命中的加载请求时，Caffeine巧妙地利用原子变量、CAS操作等技术，保证了在同一时间仅有一个加载任务被执行，其他任务则被放入等待队列或者合并到正在进行的加载任务中。

总之，虽然没有明确指出使用信号量，但Caffeine通过高度优化的并发控制算法和无锁数据结构实现了高效的缓存加载过程，有效避免了多个线程同时执行数据加载操作的问题。

10 Java 支持的锁

Java中支持多种锁机制来实现线程间的同步和并发控制。以下是一些主要的锁类型：

内置锁（Intrinsic Locks / Monitor Locks）
- synchronized关键字：这是Java最基础的锁机制，基于对象的内置监视器（Monitor）。当一个线程进入synchronized修饰的方法或代码块时，它会自动获取该对象的监视器锁，其他试图访问同一对象监视器锁的线程将被阻塞，直到锁被释放。
ReentrantLock（可重入锁）
- java.util.concurrent.locks.ReentrantLock 是JDK 5引入的显式锁，提供了比synchronized关键字更多的功能，如公平锁、非公平锁的选择，以及支持中断请求和超时等待。
ReentrantReadWriteLock（读写锁）
- java.util.concurrent.locks.ReentrantReadWriteLock 提供了一种读写分离的锁策略，允许多个读线程同时访问资源，但在写操作发生时，所有读写线程都会被阻塞。
StampedLock（版本戳锁）
- java.util.concurrent.locks.StampedLock 是一种更复杂的锁，允许读写模式之间的灵活切换，并提供乐观读取和悲观读取两种方式。
Semaphore（信号量）
- 不是传统意义上的锁，但可以用于限制同时访问特定资源的线程数。信号量是一种计数信号，通过增加和减少许可来协调多个线程对共享资源的访问。
Condition
- java.util.concurrent.locks.Condition 是与锁相关的条件队列，每个锁都关联了至少一个条件队列，允许线程在满足某个条件时等待或者被唤醒。
LockSupport.park() 和 unpark()
- 提供低级别的线程阻塞和唤醒机制，可以构建自定义的锁和其他同步工具类。
原子变量类（Atomic Variables）
- 不属于传统的锁范畴，但提供了无锁编程的可能性。例如，java.util.concurrent.atomic 包中的原子整数、原子引用等类，能够保证多线程环境下的原子性操作，通常用于替代需要使用锁的情况以提高性能。
偏向锁/轻量级锁/重量级锁
- 这是Java虚拟机（JVM）内部对于synchronized锁的一种优化策略，根据线程竞争情况动态地在不同的锁状态之间转换。
公平锁与非公平锁
- 公平锁保证线程按照申请锁的顺序进行排队；而非公平锁则不保证这种顺序，可能会导致“插队”现象，从而获得更高的吞吐量，但也可能造成“饥饿”。

以上就是Java中常见的一些锁机制，选择哪种锁取决于具体的并发场景需求和性能考量。

11 ReentrantLock 公平锁、非公平锁

java.util.concurrent.locks.ReentrantLock 是Java中的一种可重入锁，它提供了公平锁（Fair Lock）和非公平锁（Non-Fair Lock）两种模式供开发者选择。

公平锁（Fair Lock）：

公平锁在分配资源时遵循FIFO（First In First Out，先进先出）原则，即等待最久的线程将优先获得锁。当一个线程释放锁后，会唤醒等待队列中最前面的线程来获取锁。
使用公平锁可以避免“饥饿”问题，即即使有多个线程竞争锁，每个线程最终都能获得执行的机会。
但是，公平锁的吞吐量通常低于非公平锁，因为它需要维护等待线程的顺序，增加了上下文切换的开销。

非公平锁（Non-Fair Lock）：

非公平锁在锁的获取上并没有明确的顺序要求，允许“插队”，也就是说，被唤醒的线程可能会立即尝试获取锁，而不一定等待时间最长的线程先获取。
在高并发场景下，非公平锁由于其无序性，可能导致更好的整体吞吐量，因为线程一旦有机会就会尝试获取锁，从而减少了线程上下文切换的频率。
然而，非公平锁可能导致某些线程长时间得不到执行，存在“饥饿”的可能性。

在创建 ReentrantLock 对象时，可以通过构造函数指定锁是否为公平锁：

Java

1ReentrantLock lock = new ReentrantLock(true); // 创建公平锁
2ReentrantLock lock = new ReentrantLock(); // 默认创建非公平锁

第一行代码中的 true 参数表示创建公平锁，不传入或传入 false 则创建非公平锁。

12 Java aqs

java.util.concurrent.locks.AbstractQueuedSynchronizer（简称AQS）是Java并发包中一个用于构建锁和同步器框架的基础抽象类。AQS的设计思想是通过一个volatile的int状态变量以及一个FIFO队列来管理线程的阻塞与唤醒，从而实现对共享资源的高效控制。

主要特性：

状态变量：
- AQS内部维护了一个volatile int类型的成员变量state，用来表示同步状态。获取锁就是尝试改变这个状态，释放锁则是恢复这个状态。
FIFO等待队列：
- 当多个线程争抢资源失败时，AQS会将当前线程构造成一个节点加入到一个FIFO等待队列中，该队列基于双向链表实现。当同步状态改变（即锁被释放）时，AQS会选择合适的节点并将其对应的线程唤醒。
自旋+CAS：
- AQS使用CAS（Compare and Swap）操作来保证对状态变量修改的原子性，并结合自旋等待机制减少上下文切换带来的开销。
可重入：
- AQS支持可重入的概念，即同一个线程可以重复获取同一个锁。
子类化扩展：
- 通过继承AQS并实现其protected方法，开发者可以便捷地创建出如ReentrantLock、Semaphore、CountDownLatch等复杂的同步组件。

总之，AQS提供了一种高效的、可伸缩的框架，使得开发人员能够基于此设计出各种不同功能的同步器，它在Java并发编程中扮演了核心角色。

aqs 如何实现可重入

AbstractQueuedSynchronizer（AQS）在实现可重入锁时，采用了一种线程本地计数的方式。具体实现机制如下：

内部状态计数器： AQS内部维护一个原子整型变量state，这个变量的值代表了当前持有锁的线程对锁的重入次数。
获取锁（acquire）：
- 当线程尝试获取锁时，首先会检查当前线程是否已经持有该锁。如果是，则将state计数器加1，表示进行了重入；如果不是，则需要进入排队等待。
- 在ReentrantLock中，如果当前线程已经是锁的持有者，它会在内部增加重入次数，并且成功返回，无需再次竞争锁资源。
释放锁（release）：
- 当线程调用unlock方法释放锁时，AQS会先检查当前线程是否为锁的所有者，确认后则递减state计数器。
- 只有当state计数器归零时，才意味着锁真正被释放，同时AQS会从等待队列中唤醒一个等待的线程来继续获取锁。
线程标识与同步队列管理：
- AQS还使用了一个ThreadLocal变量来保存每个线程持有的锁次数信息，确保同一个线程多次获取同一把锁时，不会被自己阻塞。
- 通过记录每个线程的状态和维护一个FIFO等待队列，确保了在多线程环境下锁的正确分配和回收。

总之，AQS通过维护一个关于锁拥有者的计数器和每个线程自身的重入次数信息，巧妙地实现了可重入锁的功能，使得同一个线程在没有释放之前可以重复获取相同的锁而不受阻塞。

13 springboot 启动过程

Spring Boot 的启动过程主要包括以下几个核心步骤：

加载SpringApplication类
- 应用程序通常从main方法开始，创建一个SpringApplication实例。主配置类（带有@SpringBootApplication注解的类）作为参数传入。
初始化环境
- SpringApplication会构建一个ApplicationContext所需的Environment对象，该对象包含了应用程序运行时的所有环境属性，包括命令行参数、系统属性和应用.properties或.yml文件中的配置信息。
注册监听器和回调
- 在此阶段，Spring Boot会注册一些默认的事件监听器，这些监听器会在整个上下文生命周期中触发相应的事件处理逻辑。
准备ApplicationContext
- SpringApplication通过调用createApplicationContext()方法创建合适的ApplicationContext实现，通常是AnnotationConfigServletWebServerApplicationContext或者AnnotationConfigApplicationContext，具体取决于是否是web应用。
扫描组件并自动配置
- Spring Boot利用ComponentScan注解对主配置类及其子包进行组件扫描，发现所有标记了@Component、@Service、@Repository、@Controller等注解的类，并将其加入到bean容器中。
- 同时，它会根据classpath下的jar包依赖和spring.factories文件来决定哪些自动配置类应该生效。这些自动配置类会基于条件注解(@Conditional)检查当前环境和已存在的bean来动态地添加额外的bean定义到上下文中。
刷新ApplicationContext
- 创建好ApplicationContext后，会调用其refresh()方法来完成Bean的实例化、依赖注入以及初始化等工作。这一步骤也包括执行ApplicationRunner和CommandLineRunner接口的实现类。
启动嵌入式Web服务器
- 如果是Web应用，Spring Boot会根据项目中的依赖自动配置并启动一个嵌入式的Web服务器，如Tomcat、Jetty或Undertow等。在服务器启动过程中，会绑定端口，加载Servlet容器，以及设置各种Web相关的过滤器、监听器和拦截器。
启动完成后通知监听器
- 当所有的bean初始化完毕且嵌入式服务器启动成功后，会触发一系列的启动完成事件，供任何已经注册的SmartLifecycle beans执行相关操作。
应用程序准备好接受请求
- 最终，Spring Boot应用完全启动，等待接收HTTP或其他类型的客户端请求。

这个启动流程确保了Spring Boot应用能够快速地自配置并启动服务，极大地简化了开发人员的工作量。

14 java 实现覆盖第三方包的方法

在Java中，直接覆盖第三方包中的方法并不是标准做法。但是，如果你需要修改或替换某个第三方库的行为，有以下几种策略可以实现：

继承与重写：如果第三方类提供了扩展点（即没有标记为final的类，并且有非final的方法），你可以创建一个子类并重写你需要改变行为的方法。

Java

1// 假设ThirdPartyClass是第三方包中的类
2public class ThirdPartyClass {
3    public void someMethod() { ... }  // 需要被覆盖的方法
4}
5
6// 创建你的自定义类，继承ThirdPartyClass
7public class CustomThirdPartyClass extends ThirdPartyClass {
8    @Override
9    public void someMethod() {
10        // 在这里提供你自己的实现
11    }
12}

然后，在你的应用中使用CustomThirdPartyClass而不是原来的ThirdPartyClass。

装饰器模式（Decorator Pattern）：当不能或者不希望直接修改第三方类时，可以通过装饰器模式来包装第三方类，并在包装类中提供自定义的行为。

Java

1public class ThirdPartyClassDecorator implements ThirdPartyInterface {
2    private final ThirdPartyClass decorated;
3
4    public ThirdPartyClassDecorator(ThirdPartyClass original) {
5        this.decorated = original;
6    }
7
8    @Override
9    public void someMethod() {
10        // 在调用原始方法前/后的自定义逻辑
11        beforeSomeMethod();
12        decorated.someMethod();
13        afterSomeMethod();
14    }
15
16    private void beforeSomeMethod() { ... }
17    private void afterSomeMethod() { ... }
18}

使用代理（Proxy）： Java自带的动态代理机制（如java.lang.reflect.Proxy）允许你在运行时创建一个对象，这个对象可以在调用方法前后执行额外的操作。

Java

1import java.lang.reflect.InvocationHandler;
2import java.lang.reflect.Method;
3import java.lang.reflect.Proxy;
4
5public class CustomInvocationHandler implements InvocationHandler {
6    private final ThirdPartyClass target;
7
8    public CustomInvocationHandler(ThirdPartyClass target) {
9        this.target = target;
10    }
11
12    @Override
13    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
14        if ("someMethod".equals(method.getName())) {
15            // 在调用目标方法前添加操作
16            beforeSomeMethod();
17        }
18
19        Object result = method.invoke(target, args);
20
21        if ("someMethod".equals(method.getName())) {
22            // 在调用目标方法后添加操作
23            afterSomeMethod();
24        }
25
26        return result;
27    }
28
29    private void beforeSomeMethod() { ... }
30    private void afterSomeMethod() { ... }
31
32    public ThirdPartyInterface createProxy() {
33        Class<?>[] interfaces = new Class<?>[]{ThirdPartyInterface.class};
34        return (ThirdPartyInterface) Proxy.newProxyInstance(
35                ThirdPartyClass.class.getClassLoader(),
36                interfaces,
37                this);
38    }
39}
40
41// 使用示例
42ThirdPartyInterface customProxy = new CustomInvocationHandler(new ThirdPartyClass()).createProxy();
43customProxy.someMethod();

依赖注入和替换策略：如果是在Spring框架等支持依赖注入的环境中，可以利用依赖注入容器对组件进行替换或自定义配置。
使用SPI（Service Provider Interface）：若第三方包提供了SPI接口，可以根据SPI规范编写自己的实现类，并通过系统属性或配置文件指定使用自定义实现。
修改源码重新打包：这种情况仅在你有权访问源代码并且有充分理由这样做时才考虑。将第三方库的源代码下载到本地，修改对应方法的实现，然后重新编译、打包成新的jar文件供项目使用。

总之，在大多数情况下，首选的是避免直接修改第三方包的源码，而是通过封装、扩展或依赖注入等方式间接地改变其行为。

依赖注入和替换策略

在支持依赖注入（Dependency Injection，DI）的框架如Spring中，可以通过配置或编程方式来替换第三方包的服务实现。以下是在Spring框架下使用依赖注入进行第三方服务替换的基本步骤：

接口定义与实现：首先，确保你了解要替换的第三方服务所使用的接口。例如，假设有一个名为ThirdPartyService的接口和一个默认实现DefaultThirdPartyService。

Java

1public interface ThirdPartyService {
2    void doSomething();
3}
4
5// 第三方提供的默认实现
6public class DefaultThirdPartyService implements ThirdPartyService {
7    @Override
8    public void doSomething() {
9        // 第三方库默认行为...
10    }
11}
12
13// 自定义实现
14public class CustomThirdPartyService implements ThirdPartyService {
15    @Override
16public void doSomething() {
17    // 自定义的行为逻辑...
18}

配置Bean替换：在Spring应用的配置类或者XML配置文件中，将自定义实现声明为Bean，并通过@Primary注解标记为主要实现，使其优先于其他候选实现被注入到依赖此接口的组件中。

Java

1@Configuration
2public class AppConfig {
3
4    @Bean
5    @Primary
6    public ThirdPartyService thirdPartyService() {
7        return new CustomThirdPartyService();
8    }
9}

或者，在XML配置文件中：

Xml

1<beans xmlns="http://www.springframework.org/schema/beans"
2    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3    xsi:schemaLocation="http://www.springframework.org/schema/beans
4        http://www.springframework.org/schema/beans/spring-beans.xsd">
5
6    <bean id="thirdPartyService" class="com.example.CustomThirdPartyService" primary="true"/>
7</beans>

自动装配时指定候选Bean：如果有多个相同类型的Bean存在，可以使用@Qualifier注解来明确指定需要注入哪个Bean。

Java

1@Service
2public class MyService {
3
4    private final ThirdPartyService thirdPartyService;
5
6    @Autowired
7    public MyService(@Qualifier("customThirdPartyService") ThirdPartyService thirdPartyService) {
8        this.thirdPartyService = thirdPartyService;
9    }
10
11    // ...
12}