小米公司面试题
先来看看这次的题目大纲（基本上全部围绕我一直给大家强调的 Java 后端四大件展开）：
- new Integer(10) == new Integer(10) 相等吗 常量池
- String 是可变的吗，为什么要设计为不可变
- 说一下HashMap 数据库结构 和 一些重要参数
- 为什么是2次幂 到什么时候开始扩容 扩容机制流程
- 有哪些线程安全的map，ConcurrentHashMap怎么保证线程安全的，为什么比hashTable效率好
- 说一下为什么项目中使用线程池，重要参数，举个例子说一下这些参数的变化
- 协程和线程和进程的区别
- synchronized 和lock区别
- synchronized锁升级过程
- 公平锁和非公平锁 lock怎么现实一个非公平锁
- 为什么redis快，淘汰策略 持久化
- mysql：聚簇索引和非聚簇索引区别
- 索引怎么设计才是最好的
- 事务传播，protected 和private 加事务会生效吗,还有那些不生效的情况
内容较长，撰写硬核面经不容易，建议大家先收藏起来，我会尽量用通俗易懂+手绘图的方式，让大家不仅能背会，还能理解和掌握。总之，是时候喊出我们那句大言不惭的口号了：让天下没有难背的八股 😂
01、new Integer(10) == new Integer(10) 相等吗 常量池
在 Java 中，使用new Integer(10) == new Integer(10)进行比较时，结果是 false。
这是因为 new 关键字会在堆（Heap）上为每个 Integer 对象分配新的内存空间，所以这里创建了两个不同的 Integer 对象，它们有不同的内存地址。
当使用==运算符比较这两个对象时，实际上比较的是它们的内存地址，而不是它们的值，因此即使两个对象代表相同的数值（10），结果也是 false。
根据实践发现，大部分的数据操作都集中在值比较小的范围，因此 Integer 搞了个缓存池，默认范围是 -128 到 127。
当我们使用自动装箱来创建这个范围内的 Integer 对象时，Java 会直接从缓存中返回一个已存在的对象，而不是每次都创建一个新的对象。这意味着，对于这个值范围内的所有 Integer 对象，它们实际上是引用相同的对象实例。
Integer 缓存的主要目的是优化性能和内存使用。对于小整数的频繁操作，使用缓存可以显著减少对象创建的数量。
可以在运行的时候添加 -Djava.lang.Integer.IntegerCache.high=1000 来调整缓存池的最大值。
引用是 Integer 类型，= 右侧是 int 基本类型时，会进行自动装箱，调用的其实是 Integer.valueOf()方法，它会调用 IntegerCache。
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
IntegerCache 是一个静态内部类，在静态代码块中会初始化好缓存的值。
private static class IntegerCache {
……
static {
//创建Integer对象存储
for(int k = 0; k < cache.length; k++)
cache[k] = new Integer(j++);
……
}
}
02、String 是可变的吗，为什么要设计为不可变
String 是不可变的，这意味着一旦一个 String 对象被创建，其存储的文本内容就不能被改变。这是因为：
①、不可变性使得 String 对象在使用中更加安全。因为字符串经常用作参数传递给其他 Java 方法，例如网络连接、打开文件等。
如果 String 是可变的，这些方法调用的参数值就可能在不知不觉中被改变，从而导致网络连接被篡改、文件被莫名其妙地修改等问题。
②、不可变的对象因为状态不会改变，所以更容易进行缓存和重用。字符串常量池的出现正是基于这个原因。
当代码中出现相同的字符串字面量时，JVM 会确保所有的引用都指向常量池中的同一个对象，从而节约内存。
③、因为 String 的内容不会改变，所以它的哈希值也就固定不变。这使得 String 对象特别适合作为 HashMap 或 HashSet 等集合的键，因为计算哈希值只需要进行一次，提高了哈希表操作的效率。
03、说一下HashMap 数据库结构 和 一些重要参数
JDK 8 中 HashMap 的数据结构是数组+链表+红黑树。
JDK 8 HashMap 数据结构示意图
HashMap的核心是一个动态数组（Node[] table），用于存储键值对。这个数组的每个元素称为一个“桶”（Bucket），每个桶的索引是通过对键的哈希值进行哈希函数处理得到的。
当多个键经哈希处理后得到相同的索引时，会发生哈希冲突。HashMap通过链表来解决哈希冲突——即将具有相同索引的键值对通过链表连接起来。
不过，链表过长时，查询效率会比较低，于是当链表的长度超过 8 时（且数组的长度大于 64），链表就会转换为红黑树。红黑树的查询效率是 O(logn)，比链表的 O(n) 要快。数组的查询效率是 O(1)。
当向 HashMap 中添加一个键值对时，会使用哈希函数计算键的哈希码，确定其在数组中的位置，哈希函数的目标是尽量减少哈希冲突，保证元素能够均匀地分布在数组的每个位置上。
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
当向HashMap 中添加元素时，如果该位置已有元素（发生哈希冲突），则新元素将被添加到链表的末尾或红黑树中。如果键已经存在，其对应的值将被新值覆盖。
当从 HashMap 中获取元素时，也会使用哈希函数计算键的位置，然后根据位置在数组、链表或者红黑树中查找元素。
HashMap 的初始容量是 16，随着元素的不断添加，HashMap 的容量（也就是数组大小）可能不足，于是就需要进行扩容，阈值是capacity * loadFactor，capacity 为容量，loadFactor 为负载因子，默认为 0.75。
扩容后的数组大小是原来的 2 倍，然后把原来的元素重新计算哈希值，放到新的数组中。
HashMap 的性能大大依赖于这三个重要的参数：初始容量（initial capacity）、加载因子（load factor，或者叫负载因子）、阈值（threshold）。
04、为什么是2次幂 到什么时候开始扩容 扩容机制流程
HashMap 的容量是 2 的倍数，或者说是 2 的整数次幂，是为了快速定位元素的下标：
HashMap 在定位元素位置时，先通过 hash(key) = (h = key.hashCode()) ^ (h >>> 16) 计算出哈希值，再通过 hash & (n-1) 来定位元素位置的，n 为数组的大小，也就是 HashMap 的容量。
因为（数组长度-1）正好相当于一个“低位掩码”——这个掩码的低位最好全是 1，这样 & 操作才有意义，否则结果就肯定是 0。
a&b 操作的结果是：a、b 中对应位同时为 1，则对应结果位为 1，否则为 0。例如 5&3=1，5 的二进制是 0101，3 的二进制是 0011，5&3=0001=1。
2 的整次幂（或者叫 2 的整数倍）刚好是偶数，偶数-1 是奇数，奇数的二进制最后一位是 1，保证了 hash &(length-1) 的最后一位可能为 0，也可能为 1（取决于 hash 的值），即 & 运算后的结果可能为偶数，也可能为奇数，这样便可以保证哈希值的均匀分布。
换句话说，& 操作的结果就是将哈希值的高位全部归零，只保留低位值。
假设某哈希值的二进制为 10100101 11000100 00100101，用它来做 & 运算，我们来看一下结果。
我们知道，HashMap 的初始长度为 16，16-1=15，二进制是 00000000 00000000 00001111（高位用 0 来补齐）：
10100101 11000100 00100101
& 00000000 00000000 00001111
----------------------------------
00000000 00000000 00000101
因为 15 的高位全部是 0，所以 & 运算后的高位结果肯定也是 0，只剩下 4 个低位 0101，也就是十进制的 5。
这样，哈希值为 10100101 11000100 00100101 的键就会放在数组的第 5 个位置上。
扩容时机
HashMap 会在存储的键值对数量超过阈值（即容量 * 加载因子）时进行扩容。
默认的加载因子是 0.75，这意味着当 HashMap 填满了大约 75%的容量时，就会进行扩容。
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
默认的初始容量是 16，那就是大于16x0.75=12时，就会触发第一次扩容操作。
扩容的流程
扩容时，HashMap会创建一个新的数组，其容量是原数组容量的两倍。
然后将键值对放到新计算出的索引位置上。一部分索引不变，另一部分索引为“原索引+旧容量”。
在 JDK 7 中，定位元素位置的代码是这样的：
static int indexFor(int h, int length) {
// assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";
return h & (length-1);
}
其实就相当于用键的哈希值和数组大小取模，也就是 hashCode % table.length。
那我们来假设：
- 数组 table 的长度为 2
- 键的哈希值为 3、7、5
取模运算后，键发生了哈希冲突，都到 table[1] 上了。那么扩容前就是这个样子。
数组的容量为 2，key 为 3、7、5 的元素在 table[1] 上，需要通过拉链法来解决哈希冲突。
假设负载因子 loadFactor 为 1，也就是当元素的个数大于 table 的长度时进行扩容。
扩容后的数组容量为 4。
- key 3 取模（3%4）后是 3，放在
table[3]上。 - key 7 取模（7%4）后是 3，放在
table[3]上的链表头部。 - key 5 取模（5%4）后是 1，放在
table[1]上。
7 跑到 3 的前面了，因为 JDK 7 使用的是头插法。
e.next = newTable[i];
同时，扩容后的 5 跑到了下标为 1 的位置。
最好的情况就是，扩容后的 7 在 3 的后面，5 在 7 的后面，保持原来的顺序。
JDK 8 完全扭转了这个局面，因为 JDK 8 的哈希算法进行了优化，当数组长度为 2 的幂次方时，能够很巧妙地解决 JDK 7 中遇到的问题。
JDK 8 的扩容代码如下所示：
Node<K,V>[] newTab = new Node[newCapacity];
for (int j = 0; j < oldTab.length; j++) {
Node<K,V> e = oldTab[j];
if (e != null) {
int hash = e.hash;
int newIndex = hash & (newCapacity - 1); // 计算在新数组中的位置
// 将节点移动到新数组的对应位置
newTab[newIndex] = e;
}
}
新索引的计算方式是 hash & (newCapacity - 1)，和 JDK 7 的 h & (length-1)没什么大的差别，差别主要在 hash 方法上，JDK 8 是这样：
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
过将键的hashCode()返回的 32 位哈希值与这个哈希值无符号右移 16 位的结果进行异或。
JDK 7 是这样：
final int hash(Object k) {
int h = hashSeed;
if (0 != h && k instanceof String) {
return sun.misc.Hashing.stringHash32((String) k);
}
h ^= k.hashCode();
// This function ensures that hashCodes that differ only by
// constant multiples at each bit position have a bounded
// number of collisions (approximately 8 at default load factor).
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
我们用 JDK 8 的哈希算法来计算一下哈希值，就会发现别有洞天。
假设扩容前的数组长度为 16（n-1 也就是二进制的 0000 1111，1X+1X+1X+1X=1+2+4+8=15），key1 为 5（二进制为 0000 0101），key2 为 21（二进制为 0001 0101）。
- key1 和 n-1 做 & 运算后为 0000 0101，也就是 5；
- key2 和 n-1 做 & 运算后为 0000 0101，也就是 5。
- 此时哈希冲突了，用拉链法来解决哈希冲突。
现在，HashMap 进行了扩容，容量为原来的 2 倍，也就是 32（n-1 也就是二进制的 0001 1111，1X+1X+1X+1X+1X=1+2+4+8+16=31）。
- key1 和 n-1 做 & 运算后为 0000 0101，也就是 5；
- key2 和 n-1 做 & 运算后为 0001 0101，也就是 21=5+16，也就是数组扩容前的位置+原数组的长度。
神奇吧？
扩容位置变化
也就是说，在 JDK 8 的新 hash 算法下，数组扩容后的索引位置，要么就是原来的索引位置，要么就是“原索引+原来的容量”，遵循一定的规律。
扩容节点迁移示意图
当然了，这个功劳既属于新的哈希算法，也离不开 n 为 2 的整数次幂这个前提，这是它俩通力合作后的结果 hash & (newCapacity - 1)。
05、有哪些线程安全的map，ConcurrentHashMap怎么保证线程安全的，为什么比hashTable效率好
在 Java 中，有 3 种线程安全的 Map 实现，最常用的是ConcurrentHashMap和Collections.synchronizedMap(Map)包装器。
Hashtable 也是线程安全的，但它的使用已经不再推荐使用，因为 ConcurrentHashMap 提供了更高的并发性和性能。
①、HashTable 是直接在方法上加 synchronized 关键字，比较粗暴。
②、Collections.synchronizedMap 返回的是 Collections 工具类的内部类。
内部是通过 synchronized 对象锁来保证线程安全的。
③、ConcurrentHashMap 在 JDK 7 中使用分段锁，在 JKD 8 中使用了 CAS+节点锁，性能得到进一步提升。
ConcurrentHashMap 8 中的实现
为什么 ConcurrentHashMap 比 Hashtable 效率高
Hashtable 在任何时刻只允许一个线程访问整个 Map，通过对整个 Map 加锁来实现线程安全。
而 ConcurrentHashMap（尤其是在 JDK 8 及之后版本）通过锁分离和 CAS 操作实现更细粒度的锁定策略，允许更高的并发。
static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
Node<K,V> c, Node<K,V> v) {
return U.compareAndSwapObject(tab, ((long)i << ASHIFT) + ABASE, c, v);
}
CAS 操作是一种乐观锁，它不会阻塞线程，而是在更新时检查是否有其他线程已经修改了数据，如果没有就更新，如果有就重试。
ConcurrentHashMap 允许多个读操作并发进行而不加锁，因为它通过 volatile 变量来保证读取操作的内存可见性。相比之下，Hashtable 对读操作也加锁，增加了开销。
public V get(Object key) {
Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
// 1. 重hash
int h = spread(key.hashCode());
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) {
// 2. table[i]桶节点的key与查找的key相同，则直接返回
if ((eh = e.hash) == h) {
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
// 3. 当前节点hash小于0说明为树节点，在红黑树中查找即可
else if (eh < 0)
return (p = e.find(h, key)) != null ? p.val : null;
while ((e = e.next) != null) {
//4. 从链表中查找，查找到则返回该节点的value，否则就返回null即可
if (e.hash == h &&
((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}
06、说一下为什么项目中使用线程池，重要参数，举个例子说一下这些参数的变化
线程池，简单来说，就是一个管理线程的池子。
管理线程的池子
①、频繁地创建和销毁线程会消耗系统资源，线程池能够复用已创建的线程。
②、提高响应速度，当任务到达时，任务可以不需要等待线程创建就立即执行。
③、线程池支持定时执行、周期性执行、单线程执行和并发数控制等功能。
重要参数
线程池有 7 个参数，需要重点关注corePoolSize、maximumPoolSize、workQueue、handler 这四个。
线程池参数
①、corePoolSize
定义了线程池中的核心线程数量。即使这些线程处于空闲状态，它们也不会被回收。这是线程池保持在等待状态下的线程数。
②、maximumPoolSize
线程池允许的最大线程数量。当工作队列满了之后，线程池会创建新线程来处理任务，直到线程数达到这个最大值。
③、keepAliveTime
非核心线程的空闲存活时间。如果线程池中的线程数量超过了 corePoolSize，那么这些多余的线程在空闲时间超过 keepAliveTime 时会被终止。
④、unit
keepAliveTime 参数的时间单位：
- TimeUnit.DAYS; 天
- TimeUnit.HOURS; 小时
- TimeUnit.MINUTES; 分钟
- TimeUnit.SECONDS; 秒
- TimeUnit.MILLISECONDS; 毫秒
- TimeUnit.MICROSECONDS; 微秒
- TimeUnit.NANOSECONDS; 纳秒
⑤、workQueue
用于存放待处理任务的阻塞队列。当所有核心线程都忙时，新任务会被放在这个队列里等待执行。
⑥、threadFactory
一个创建新线程的工厂。它用于创建线程池中的线程。可以通过自定义 ThreadFactory 来给线程池中的线程设置有意义的名字，或设置优先级等。
⑦、handler
拒绝策略 RejectedExecutionHandler，定义了当线程池和工作队列都满了之后对新提交的任务的处理策略。常见的拒绝策略包括抛出异常、直接丢弃、丢弃队列中最老的任务、由提交任务的线程来直接执行任务等。
它们之间的关系如下：
①、corePoolSize 和 maximumPoolSize 共同定义了线程池的规模。
- 当提交的任务数不足以填满核心线程时，线程池只会创建足够的线程来处理任务。
- 当任务数增多，超过核心线程的处理能力时，任务会被加入 workQueue。
- 如果 workQueue 已满，而当前线程数又小于 maximumPoolSize，线程池会尝试创建新的线程来处理任务。
②、keepAliveTime 和 unit 决定了非核心线程可以空闲存活多久。这会影响了线程池的资源回收策略。
③、workQueue 的选择对线程池的行为有重大影响。不同类型的队列（如无界队列、有界队列）会导致线程池在任务增多时的反应不同。
④、handler 定义了线程池的饱和策略，即当线程池无法接受新任务时的行为。决定了系统在极限情况下的表现。
举个例子说一下这些参数的变化
假设一个场景，线程池的配置如下：
corePoolSize = 5
maximumPoolSize = 10
keepAliveTime = 60秒
workQueue = LinkedBlockingQueue（容量为100）
默认的threadFactory
handler = ThreadPoolExecutor.AbortPolicy()
场景一：当系统启动后，逐渐有 10 个任务提交到线程池。
- 前 5 个任务会立即执行，因为它们会占用所有的核心线程。
- 随后的 5 个任务会被放入工作队列中等待执行。
场景二：如果此时再有 100 个任务提交到线程池。
- 工作队列已满，线程池会创建额外的线程来执行这些任务，直到线程总数达到 maximumPoolSize（10 个线程）。
- 如果任务继续增加，超过了工作队列和最大线程数的限制，新来的任务将会根据拒绝策略（AbortPolicy）被拒绝，抛出 RejectedExecutionException 异常。
场景三：如果任务突然减少，只有少量的任务需要执行：
核心线程会一直运行，而超出核心线程数的线程，如果空闲时间超过 keepAliveTime，将会被终止，直到线程池的线程数减少到 corePoolSize。
07、协程和线程和进程的区别
进程说简单点就是我们在电脑上启动的一个个应用，比如我们启动一个浏览器，就会启动了一个浏览器进程。进程是操作系统资源分配的最小单位，它包括了程序、数据和进程控制块等。
线程说简单点就是我们在 Java 程序中启动的一个 main 线程，一个进程至少会有一个线程。当然了，我们也可以启动多个线程，比如说一个线程进行 IO 读写，一个线程进行加减乘除计算，这样就可以充分发挥多核 CPU 的优势，因为 IO 读写相对 CPU 计算来说慢得多。线程是 CPU 分配资源的基本单位。
进程与线程关系
一个进程中可以有多个线程，多个线程共用进程的堆和方法区（Java 虚拟机规范中的一个定义，JDK 8 以后的实现为元空间）资源，但是每个线程都会有自己的程序计数器和栈。
如何理解协程？
协程通常被视为比线程更轻量级的并发单元，它们主要在一些支持异步编程模型的语言中得到了原生支持，如 Kotlin、Go 等。
不过，我们可以使用 CompletableFuture 来模拟协程式的异步执行任务。
class CompletableFutureExample {
public static void main(String[] args) throws ExecutionException, InterruptedException {
// 异步执行任务1
CompletableFuture<Integer> future1 = CompletableFuture.supplyAsync(() -> {
try {
Thread.sleep(1000); // 模拟耗时操作
} catch (InterruptedException e) {
e.printStackTrace();
}
return 10;
});
// 异步执行任务2
CompletableFuture<Integer> future2 = CompletableFuture.supplyAsync(() -> {
try {
Thread.sleep(1000); // 模拟耗时操作
} catch (InterruptedException e) {
e.printStackTrace();
}
return 20;
});
// 合并两个任务的结果并计算
CompletableFuture<Integer> resultFuture = future1.thenCombine(future2, Integer::sum);
// 等待最终结果并打印
System.out.println("结果: " + resultFuture.get());
}
}
在这个示例中，我们创建了两个 CompletableFuture 对象来异步执行两个简单的数值返回任务。这两个任务都会休眠 1 秒钟来模拟耗时计算。
然后我们使用 thenCombine 方法来合并这两个任务的结果。最后，我们通过 get 方法等待最终结果的完成，并打印出来。
08、synchronized 和lock区别
synchronized 是一个关键字，而 Lock 属于一个接口，其实现类主要有 ReentrantLock、ReentrantReadWriteLock。
synchronized和ReentrantLock的区别
①、使用方式不同
synchronized 可以直接在方法上加锁，也可以在代码块上加锁（无需手动释放锁，锁会自动释放），而 ReentrantLock 必须手动声明来加锁和释放锁。
// synchronized 修饰方法
public synchronized void method() {
// 业务代码
}
// synchronized 修饰代码块
synchronized (this) {
// 业务代码
}
// ReentrantLock 加锁
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
// 业务代码
} finally {
lock.unlock();
}
随着 JDK 版本的升级，synchronized 的性能已经可以媲美 ReentrantLock 了，加入了偏向锁、轻量级锁和重量级锁的自适应优化等，所以可以大胆地用。
②、功能特点不同
如果需要更细粒度的控制（如可中断的锁操作、尝试非阻塞获取锁、超时获取锁或者使用公平锁等），可以使用 Lock。
- ReentrantLock 提供了一种能够中断等待锁的线程的机制，通过
lock.lockInterruptibly()来实现这个机制。 - ReentrantLock 可以指定是公平锁还是非公平锁。
- ReentrantReadWriteLock 读写锁，读锁是共享锁，写锁是独占锁，读锁可以同时被多个线程持有，写锁只能被一个线程持有。这种锁的设计可以提高性能，特别是在读操作的数量远远超过写操作的情况下。
Lock 还提供了newCondition()方法来创建等待通知条件Condition，比 synchronized 与 wait()、 notify()/notifyAll()方法的组合更强大。
ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();
09、synchronized锁升级过程
无锁-->偏向锁---> 轻量级锁---->重量级锁。
锁升级方向
大体上省简的升级过程是这样的：
：锁升级简略过程
完整的升级过程是这样的：
synchronized 锁升级过程
①、从无锁到偏向锁：
当一个线程首次访问同步块时，如果此对象无锁状态且偏向锁未被禁用，JVM 会将该对象头的锁标记改为偏向锁状态，并记录下当前线程的 ID。此时，对象头中的 Mark Word 中存储了持有偏向锁的线程 ID。
如果另一个线程尝试获取这个已被偏向的锁，JVM 会检查当前持有偏向锁的线程是否活跃。如果持有偏向锁的线程不活跃，则可以将锁重偏向至新的线程；如果持有偏向锁的线程还活跃，则需要撤销偏向锁，升级为轻量级锁。
②、偏向锁的轻量级锁：
进行偏向锁撤销时，会遍历堆栈的所有锁记录，暂停拥有偏向锁的线程，并检查锁对象。如果这个过程中发现有其他线程试图获取这个锁，JVM 会撤销偏向锁，并将锁升级为轻量级锁。
当有两个或以上线程竞争同一个偏向锁时，偏向锁模式不再有效，此时偏向锁会被撤销，对象的锁状态会升级为轻量级锁。
③、轻量级锁到重量级锁：
轻量级锁通过线程自旋来等待锁释放。如果自旋超过预定次数（自旋次数是可调的，并且自适应的），表明锁竞争激烈，轻量级锁的自旋已经不再高效。
当自旋等待失败，或者有线程在等待队列中等待相同的轻量级锁时，轻量级锁会升级为重量级锁。在这种情况下，JVM 会在操作系统层面创建一个互斥锁（Mutex），所有进一步尝试获取该锁的线程将会被阻塞，直到锁被释放。
10、公平锁和非公平锁 lock怎么现实一个非公平锁
公平锁 FairSync
在公平锁模式下，锁会授予等待时间最长的线程。
非公平锁 NonfairSync
在非公平锁模式下，锁可能会授予刚刚请求它的线程，而不考虑等待时间。
new ReentrantLock() 默认创建的是非公平锁 NonfairSync。
11、为什么redis快，淘汰策略 持久化
Redis 的速度⾮常快，单机的 Redis 就可以⽀撑每秒十几万的并发，性能是 MySQL 的⼏⼗倍。速度快的原因主要有⼏点：
①、基于内存的数据存储，Redis 将数据存储在内存当中，使得数据的读写操作避开了磁盘 I/O。而内存的访问速度远超硬盘，这是 Redis 读写速度快的根本原因。
②、单线程模型，Redis 使用单线程模型来处理客户端的请求，这意味着在任何时刻只有一个命令在执行。这样就避免了线程切换和锁竞争带来的消耗。
③、IO 多路复⽤，基于 Linux 的 select/epoll 机制。该机制允许内核中同时存在多个监听套接字和已连接套接字，内核会一直监听这些套接字上的连接请求或者数据请求，一旦有请求到达，就会交给 Redis 处理，就实现了所谓的 Redis 单个线程处理多个 IO 读写的请求。
Redis使用IO多路复用和自身事件模型
④、高效的数据结构，Redis 提供了多种高效的数据结构，如字符串（String）、列表（List）、集合（Set）、有序集合（Sorted Set）等，这些数据结构经过了高度优化，能够支持快速的数据操作。
Redis 的淘汰策略
当 Redis 所用内存达到 maxmemory 上限时，会触发相应的溢出控制策略。
Redis六种内存溢出控制策略
- noeviction：默认策略，不进行任何淘汰，当内存不足以容纳更多数据时，对写操作返回错误。（但仍然允许删除操作）
- volatile-lru：仅从设置了过期时间的键中使用 LRU 算法淘汰。
- allkeys-lru：从所有的键中使用 LRU（Least Recently Used，最近最少使用）算法淘汰数据。
- allkeys-random：从所有的键中随机淘汰数据。
- volatile-random：仅从设置了过期时间的键中随机淘汰。
- volatile-ttl：从设置了过期时间的键中选择 TTL（Time To Live，存活时间）最短的键淘汰。
Redis 的持久化机制
Redis 支持两种主要的持久化方式：RDB（Redis DataBase）持久化和 AOF（Append Only File）持久化。这两种方式可以单独使用，也可以同时使用。
Redis持久化的两种方式
RDB
RDB 持久化通过创建数据集的快照（snapshot）来工作，在指定的时间间隔内将 Redis 在某一时刻的数据状态保存到磁盘的一个 RDB 文件中。
可通过 save 和 bgsave 命令两个命令来手动触发 RDB 持久化操作：
ave和bgsave
①、save 命令：会同步地将 Redis 的所有数据保存到磁盘上的一个 RDB 文件中。这个操作会阻塞所有客户端请求直到 RDB 文件被完全写入磁盘。
当 Redis 数据集较大时，使用 SAVE 命令会导致 Redis 服务器停止响应客户端的请求。
不推荐在生产环境中使用，除非数据集非常小，或者可以接受服务暂时的不可用状态。
②、bgsave 命令：会在后台异步地创建 Redis 的数据快照，并将快照保存到磁盘上的 RDB 文件中。这个命令会立即返回，Redis 服务器可以继续处理客户端请求。
在 BGSAVE 命令执行期间，Redis 会继续响应客户端的请求，对服务的可用性影响较小。快照的创建过程是由一个子进程完成的，主进程不会被阻塞。是在生产环境中执行 RDB 持久化的推荐方式。
以下场景会自动触发 RDB 持久化：
①、在 Redis 配置文件（通常是 redis.conf）中，可以通过save <seconds> <changes>指令配置自动触发 RDB 持久化的条件。这个指令可以设置多次，每个设置定义了一个时间间隔（秒）和该时间内发生的变更次数阈值。
save 900 1
save 300 10
save 60 10000
这意味着：
- 如果至少有 1 个键被修改，900 秒后自动触发一次 RDB 持久化。
- 如果至少有 10 个键被修改，300 秒后自动触发一次 RDB 持久化。
- 如果至少有 10000 个键被修改，60 秒后自动触发一次 RDB 持久化。
满足以上任一条件，RDB 持久化就会被自动触发。
②、当 Redis 服务器通过 SHUTDOWN 命令正常关闭时，如果没有禁用 RDB 持久化，Redis 会自动执行一次 RDB 持久化，以确保数据在下次启动时能够恢复。
③、在 Redis 复制场景中，当一个 Redis 实例被配置为从节点并且与主节点建立连接时，它可能会根据配置接收主节点的 RDB 文件来初始化数据集。这个过程中，主节点会在后台自动触发 RDB 持久化，然后将生成的 RDB 文件发送给从节点。
AOF
AOF 持久化通过记录每个写操作命令并将其追加到 AOF 文件中来工作，恢复时通过重新执行这些命令来重建数据集。
AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。
AOF 的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）
流程如下：
1）当 AOF 持久化功能被启用时，Redis 服务器会将接收到的所有写命令（比如 SET, LPUSH, SADD 等修改数据的命令）追加到 AOF 缓冲区（buffer）的末尾。
2）为了将缓冲区中的命令持久化到磁盘中的 AOF 文件，Redis 提供了几种不同的同步策略：
- always：每次写命令都会同步到 AOF 文件，这提供了最高的数据安全性，但可能因为磁盘 I/O 的延迟而影响性能。
- everysec（默认）：每秒同步一次，这是一种折衷方案，提供了较好的性能和数据安全性。
- no：不主动进行同步，交由操作系统决定何时将缓冲区数据写入磁盘，这种方式性能最好，但在系统崩溃时可能会丢失最近一秒的数据。
3）随着操作的不断执行，AOF 文件会不断增长，为了减小 AOF 文件大小，Redis 可以重写 AOF 文件：
- 重写过程不会解析原始的 AOF 文件，而是将当前内存中的数据库状态转换为一系列写命令，然后保存到一个新的 AOF 文件中。
- AOF 重写操作由 BGREWRITEAOF 命令触发，它会创建一个子进程来执行重写操作，因此不会阻塞主进程。
- 重写过程中，新的写命令会继续追加到旧的 AOF 文件中，同时也会被记录到一个缓冲区中。一旦重写完成，Redis 会将这个缓冲区中的命令追加到新的 AOF 文件中，然后切换到新的 AOF 文件上，以确保数据的完整性。
4）当 Redis 服务器启动时，如果配置为使用 AOF 持久化方式，它会读取 AOF 文件中的所有命令并重新执行它们，以恢复数据库的状态。
12、mysql：聚簇索引和非聚簇索引区别
聚簇索引不是一种新的索引，而是一种数据存储方式。
聚簇索引和非聚簇索引
在聚簇索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。换句话说，聚簇索引将数据存储与索引部分结合在了一起。
聚簇索引
在非聚簇索引中，索引结构与数据实际存储分离。非聚簇索引的叶子节点不直接包含数据记录，而是包含了指向数据行的指针。
非聚簇索引
在非聚簇索引的叶子节点上存储的并不是真正的行数据，而是主键 ID，所以当我们使用非聚簇索引进行查询时，首先会得到一个主键 ID，然后再使用主键 ID 去聚簇索引上找到真正的行数据，我们把这个过程称之为回表查询。
MyISAM 采用的是非聚簇索引，InnoDB 采用的是聚簇索引。
可以这么说：
- 聚簇索引直接将数据存储在 B+树的叶子节点中，而非聚簇索引的叶子节点存储的是指向数据行的指针。
- 一个表只能有一个聚簇索引，但可以有多个非聚簇索引。
- 聚簇索引改善了顺序访问的性能，但更新主键的成本较高；非聚簇索引适合快速插入和更新操作，但检索数据可能需要更多的磁盘 I/O。
13、索引怎么设计才是最好的
尽管索引能提高查询性能，但不当的使用也会带来一系列问题。在加索引时需要注意以下几点：
①、选择合适的列作为索引
- 经常作为查询条件（WHERE 子句）、排序条件（ORDER BY 子句）、分组条件（GROUP BY 子句）的列是建立索引的好候选。
- 区分度低的字段，例如性别，不要建索引
- 频繁更新的字段，不要作为主键或者索引
- 不建议用无序的值(例如身份证、UUID )作为索引，当主键具有不确定性，会造成叶子节点频繁分裂，出现磁盘存储的碎片化
②、避免过多的索引
- 每个索引都需要占用额外的磁盘空间。
- 更新表（INSERT、UPDATE、DELETE 操作）时，所有的索引都需要被更新。
- 维护索引文件需要成本；还会导致页分裂，IO 次数增多。
③、利用前缀索引和索引列的顺序
- 对于字符串类型的列，可以考虑使用前缀索引来减少索引大小。
- 在创建复合索引时，应该根据查询条件将最常用作过滤条件的列放在前面。
14、事务传播，protected 和private 加事务会生效吗,还有那些不生效的情况
事务的传播机制定义了在方法被另一个事务方法调用时，这个方法的事务行为应该如何。
Spring 提供了一系列事务传播行为，这些传播行为定义了事务的边界和事务上下文如何在方法调用链中传播。
6种事务传播机制
- REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。Spring 的默认传播行为。
- SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行。
- MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
- REQUIRES_NEW：总是启动一个新的事务，如果当前存在事务，则将当前事务挂起。
- NOT_SUPPORTED：总是以非事务方式执行，如果当前存在事务，则将当前事务挂起。
- NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前事务不存在，则行为与 REQUIRED 一样。嵌套事务是一个子事务，它依赖于父事务。父事务失败时，会回滚子事务所做的所有操作。但子事务异常不一定会导致父事务的回滚。
事务传播机制是使用 ThreadLocal 实现的，所以，如果调用的方法是在新线程中的，事务传播会失效。
Spring 默认的事务传播行为是 PROPAFATION_REQUIRED，即如果多个 ServiceX#methodX() 都工作在事务环境下，且程序中存在调用链 Service1#method1()->Service2#method2()->Service3#method3()，那么这 3 个服务类的 3 个方法都通过 Spring 的事务传播机制工作在同一个事务中。
protected 和 private 加事务会生效吗
在 Spring 中，只有通过 Spring 容器的 AOP 代理调用的公开方法（public method）上的@Transactional注解才会生效。
如果在 protected、private 方法上使用@Transactional，这些事务注解将不会生效，原因：Spring 默认使用基于 JDK 的动态代理（当接口存在时）或基于 CGLIB 的代理（当只有类时）来实现事务。这两种代理机制都只能代理公开的方法。
还有哪些不生效的情况
@Transactional 注解属性 propagation 设置错误
- TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行；错误使用场景：在业务逻辑必须运行在事务环境下以确保数据一致性的情况下使用 SUPPORTS。
- TransactionDefinition.PROPAGATION_NOT_SUPPORTED：总是以非事务方式执行，如果当前存在事务，则挂起该事务。错误使用场景：在需要事务支持的操作中使用 NOT_SUPPORTED。
- TransactionDefinition.PROPAGATION_NEVER：总是以非事务方式执行，如果当前存在事务，则抛出异常。错误使用场景：在应该在事务环境下执行的操作中使用 NEVER。
同一个类中方法调用，导致@Transactional 失效
开发中避免不了会对同一个类里面的方法调用，比如有一个类 Test，它的一个方法 A，A 调用本类的方法 B（不论方法 B 是用 public 还是 private 修饰），但方法 A 没有声明注解事务，而 B 方法有。
则外部调用方法 A 之后，方法 B 的事务是不会起作用的。这也是经常犯错误的一个地方。
那为啥会出现这种情况呢？其实还是由 Spring AOP 代理造成的，因为只有事务方法被当前类以外的代码调用时，才会由 Spring 生成的代理对象来管理。
//@Transactional
@GetMapping("/test")
private Integer A() throws Exception {
CityInfoDict cityInfoDict = new CityInfoDict();
cityInfoDict.setCityName("2");
/**
* B 插入字段为 3的数据
*/
this.insertB();
/**
* A 插入字段为 2的数据
*/
int insert = cityInfoDictMapper.insert(cityInfoDict);
return insert;
}
@Transactional()
public Integer insertB() throws Exception {
CityInfoDict cityInfoDict = new CityInfoDict();
cityInfoDict.setCityName("3");
cityInfoDict.setParentCityId(3);
return cityInfoDictMapper.insert(cityInfoDict);
}
这种情况是最常见的一种@Transactional 注解失效场景。
@Transactional
private Integer A() throws Exception {
int insert = 0;
try {
CityInfoDict cityInfoDict = new CityInfoDict();
cityInfoDict.setCityName("2");
cityInfoDict.setParentCityId(2);
/**
* A 插入字段为 2的数据
*/
insert = cityInfoDictMapper.insert(cityInfoDict);
/**
* B 插入字段为 3的数据
*/
b.insertB();
} catch (Exception e) {
e.printStackTrace();
}
}
如果 B 方法内部抛了异常，而 A 方法此时 try catch 了 B 方法的异常，那这个事务就不能正常回滚了，会抛出异常：
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
参考链接
- 1、三分恶的面渣逆袭：https://javabetter.cn/sidebar/sanfene/nixi.html
- 2、二哥的Java进阶之路：https://javabetter.cn
