carpe_diems

面试题精简(chatGPT解答不一定全对)

面试题

1.重写和重载有什么区别?
2.hashmap底层数据结构?扩容原理？
3.有String、StringBuffer 和 StringBuilder有什么区别?
4.数组默认长度?
5.每次扩容长度?
6.hashmap什么场景下进化成红黑树?
7.创建线程的方式?
8.线程池有了解吗?
9.线程池默认参数?
10.hashmap元素是头插还是尾插?
11.什么是java类加载?
12.java中类加载器有哪些?
13.乐观锁和悲观锁的区别?如何实现？
14.线程池如何提升性能?
15.使用乐观锁如何实现超卖现象?
16.SQL中幻读和读已提交?
17.redis主要使用场景?
18.如何给给字符串创建索引?
19.SQL事务和分布式事务的区别?
20.Intger能不能用==比较大小?
21.sql隔离级别?
22.并发，如何解决？
- 22.1分布式中的高并发如何解决？
- 22.2.什么是分布式事务？
- 22.3 RedissonClient 分布式锁
23.微服务的中间件
24. mq的作用？
- 24.1 消息持久化
- 24.2.消息确认机制
25.nacos的作用
26.一个包装类型和一个基本类型能够用==来比较吗？
27.sql优化
28.乐观锁超卖
29、基本的数据类型
30.简单说下集合，
- 30.1hashmap的底层
31、HashMap 和 Hashtable 有什么区别？
32、ConcurrentHashMap如何保证同步
33、Stream流的原理，常用方法
34、Mybatis的核心技术
- 34.1 MyBatis的三级缓存
35、多表联查left和right的区别
36、简单说下IOC和AOP
37、缓存击穿和缓存雪崩，怎么解决缓存击穿
38.乐观锁在实际开发中一般用于那种业务场景
39.redis如何实现互斥锁，主要用到那些命令底层是怎么实现的
40.我有两个方法都加了事务，a调b，b新开事务，怎么一定会发生死锁。
41.我定位到一个慢查询的sql，用explan查看也用到了索引，还是最优索引，此时怎么进行优化
42.RabbitMQ如何解决重复消费?
43.哨兵模式下为什么哨兵要是单数?
44 对Spring的IOC和AOP的理解，IOC底层怎么实现?
45.SpringCloud的几大组件 ?
46.对Redis的理解?
47.Redis的String和Hash有什么区别，
48.Mysql的索引类型，引擎区别
49.Mysgl的行锁和表锁的区别
50. Mysql怎么避免死锁
53.为啥jdk8之后hashMap要把链表转为红黑树
54.synchronized和lock的区别
55.线程的生命周期
56.有没有了解JVM
57.数据库的优化
59.sql的优化，引申到索引失效
60.redis的持久化
61.mq消息确认机制
62.SpringCloud的组件
63.如何保证分布式事务的一致性
64.和别的公司对接接口，咋保证数据的安全
65. Redis有三种过期策略：
66.redis基础原理
67. redis内存数据淘汰策略
68. JAVA的异常分类
69.在分布式缓存中，保持数据的一致性是一个重要的问题。
70 依懒注入的方式
71 .不同的数据类型在计算机内存中占用的字节数是不同的。以下是一些常见数据类型在常见编程语言中的字节大小：
72.如何开启慢查询日志
73. 哈希（Hash）和B+树（B+ Tree）

1.重写和重载有什么区别?

重写是指在子类中重新定义父类中已有的方法，以实现子类自己的功能需求。重写要求方法名、参数列表和返回类型都相同，但是方法体可以不同。重写可以实现多态性，即在运行时根据对象的实际类型调用相应的方法。

重载是指在同一个类中定义多个方法，它们具有相同的方法名，但是参数列表不同（参数的个数、类型或顺序）。重载可以根据不同的参数来执行不同的操作，提高了代码的灵活性和可读性。

总结来说，重写是在子类中重新定义父类方法，而重载是在同一个类中定义多个具有相同方法名但参数列表不同的方法。

2.hashmap底层数据结构?扩容原理？

初始化容量为16，达到阈值进行扩容。阈值 = 最大容量 * 负载因子(0.75)，扩容每次2倍，总是2的n次方。

扩容机制：使用一个容量更大的数组替代已有的容量小的数组，transfer()方法将原有的Entry数组的元素拷贝到新的Entry数组里。

3.有String、StringBuffer 和 StringBuilder有什么区别?

String是不可变的字符串对象，每次对String进行操作都会创建一个新的String对象，因此在大量字符串操作时会产生大量的临时对象，对性能有一定影响。

StringBuffer和StringBuilder都是可变的字符串对象，可以对字符串进行修改。区别在于StringBuffer是线程安全的，而StringBuilder是非线程安全的。因为StringBuffer的方法都是使用synchronized关键字进行同步的，所以在多线程环境下使用StringBuffer是安全的，而StringBuilder没有同步措施，所以在单线程环境下使用StringBuilder效率更高。

因此，如果在单线程环境下进行字符串操作，推荐使用StringBuilder；如果在多线程环境下进行字符串操作，推荐使用StringBuffer。

4.数组默认长度?

对于基本数据类型的数组，如int、double、char等，如果没有明确指定长度，那么默认长度为0。

对于引用类型的数组，如String、Object等，如果没有明确指定长度，那么默认长度为null。

5.每次扩容长度?

增加固定长度：如果当前数组已满，那么会创建一个新数组，新数组的长度是旧数组长度加上一个固定的增量（如10）。

增加一定比例：如果当前数组已满，那么会创建一个新数组，新数组的长度是旧数组长度的一定比例（如1.5倍或2倍）。

这样的扩容策略可以保证在大部分情况下，数组的扩容操作不会频繁发生，从而提高性能。同时，这种策略也会造成一定的空间浪费，因为可能会预留一些多余的空间。

需要注意的是，具体的扩容策略可以在一定程度上根据实际需求进行调整，比如可以根据当前数组的大小和元素数量来动态调整扩容增量或比例。

6.hashmap什么场景下进化成红黑树?

当某个哈希桶中的链表长度超过阈值（默认为8）时，会将链表转换为红黑树。这是为了解决哈希冲突导致的链表过长，从而提高查找、插入和删除操作的效率。

当哈希表的容量达到阈值（默认为64）时，会进行扩容操作。在进行扩容时，如果某个哈希桶中的链表长度仍然超过阈值，那么该链表会被转换为红黑树。
当哈希表中的某个哈希桶中的链表长度过长或者哈希表的容量达到一定阈值时，HashMap会将链表转换为红黑树，以提高操作的效率。

它不是线程安全的。它的 key、value 都可以为 null，此外，HashMap 中的映射不是有序的。

7.创建线程的方式?

继承Thread类：创建一个新的类继承Thread类，并重写run()方法来定义线程的执行逻辑。然后通过创建该类的实例来创建线程对象，并调用start()方法启动线程。

class MyThread extends Thread {
    public void run() {
        // 线程执行逻辑
    }
}

public class Main {
    public static void main(String[] args) {
        MyThread thread = new MyThread();
        thread.start();
    }
}

实现Runnable接口：创建一个实现了Runnable接口的类，并实现run()方法来定义线程的执行逻辑。然后通过创建该类的实例，将其作为参数传递给Thread类的构造函数来创建线程对象，并调用start()方法启动线程。

java
class MyRunnable implements Runnable {
    public void run() {
        // 线程执行逻辑
    }
}

public class Main {
    public static void main(String[] args) {
        MyRunnable runnable = new MyRunnable();
        Thread thread = new Thread(runnable);
        thread.start();
    }
}

使用Callable和Future：创建一个实现了Callable接口的类，并实现call()方法来定义线程的执行逻辑。然后通过创建该类的实例，将其作为参数传递给ExecutorService的submit()方法来提交线程任务，并返回一个Future对象，通过该对象可以获取线程的执行结果。

java
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

class MyCallable implements Callable<String> {
    public String call() throws Exception {
        // 线程执行逻辑
        return "线程执行结果";
    }
}

public class Main {
    public static void main(String[] args) {
        ExecutorService executor = Executors.newSingleThreadExecutor();
        MyCallable callable = new MyCallable();
        Future<String> future = executor.submit(callable);
        // 获取线程执行结果
        try {
            String result = future.get();
            System.out.println(result);
        } catch (Exception e) {
            e.printStackTrace();
        }
        executor.shutdown();
    }
}

8.线程池有了解吗?

线程池是一种线程管理的机制，它可以管理和复用线程，提供了一种线程的调度和执行方式，可以有效地控制线程的数量和资源消耗。

使用线程池的好处有以下几点：

降低资源消耗：线程的创建和销毁都是需要消耗系统资源的，使用线程池可以复用线程，减少线程的创建和销毁次数，从而降低资源消耗。
提高响应速度：线程池中的线程是预先创建好的，当有任务需要执行时，可以立即分配线程来处理，提高了响应速度。
提高系统稳定性：线程池可以限制并发线程的数量，避免由于线程过多导致系统资源耗尽，提高系统的稳定性。
Java中的线程池由ThreadPoolExecutor类实现，可以通过Executors工厂类来创建不同类型的线程池，包括FixedThreadPool、CachedThreadPool、ScheduledThreadPool等。

使用线程池可以通过以下步骤进行：

创建线程池对象，可以通过Executors提供的工厂方法创建不同类型的线程池。
创建任务，可以是实现Runnable接口或Callable接口的类。
将任务提交给线程池，通过调用线程池的execute()方法或submit()方法来提交任务。
线程池会从线程池中的线程中选择一个空闲的线程来执行任务。
任务执行完成后，线程会返回线程池，可以继续执行其他任务。

需要注意的是，在使用线程池时应根据实际情况合理配置线程池的参数，如核心线程数、最大线程数、线程空闲时间等，以充分利用系统资源并保证系统的稳定性。

9.线程池默认参数?

Java中的线程池默认参数由ThreadPoolExecutor类的构造方法确定，默认参数如下：

核心线程数（corePoolSize）：默认为0。核心线程是一直存活在线程池中的线程数量，即使它们是空闲的。
最大线程数（maximumPoolSize）：默认为Integer.MAX_VALUE。最大线程数是线程池中允许存在的最大线程数量。
线程空闲时间（keepAliveTime）：默认为0。线程空闲时间是当线程池中的线程数量超过核心线程数时，多余的空闲线程在被终止之前等待新任务的最长时间。
时间单位（unit）：默认为TimeUnit.MILLISECONDS。时间单位是线程空闲时间的单位，可以是毫秒、秒、分钟等。
阻塞队列（workQueue）：默认为一个无界的LinkedBlockingQueue。阻塞队列用于存放等待执行的任务，当线程池中的线程数量达到核心线程数时，新任务会被放入阻塞队列等待执行。
线程工厂（threadFactory）：默认为一个默认的ThreadFactory，用于创建新的线程。
饱和策略（handler）：默认为一个默认的饱和策略，当线程池和阻塞队列都已满时，新任务无法被提交时的处理策略。

需要注意的是，线程池的默认参数可能不适合所有的场景，根据实际需求可以通过自定义ThreadPoolExecutor类的构造方法，或者使用Executors提供的工厂方法来创建自定义的线程池，并设置合适的参数。

10.hashmap元素是头插还是尾插?

HashMap的元素插入是通过头插法（头部插入）的方式进行的。

当HashMap插入一个新元素时，会根据元素的哈希值计算出它在哈希表中的索引位置，然后将该元素插入到对应索引位置的链表的头部。如果该索引位置的链表中已经存在相同哈希值的元素，则新元素会被插入到链表的头部，而原来的元素会被顺次往后移动。

这种头插法的方式可以保证新插入的元素在链表中的位置更靠近头部，从而在查找时可以更快地找到最新插入的元素，提高查找的效率。

需要注意的是，当一个链表中的元素数量超过一定阈值（默认为8）时，HashMap会将该链表转换为红黑树，以提高查找、插入和删除操作的效率。在转换为红黑树后，插入元素的方式会有所不同，红黑树的插入操作是按照红黑树的规则进行的，而不是头插法。

它不是线程安全的。它的 key、value 都可以为 null，此外，HashMap 中的映射不是有序的。

11.什么是java类加载?

Java类加载是指将Java字节码文件加载到内存中，并将其转换为Java虚拟机可以执行的对象的过程。类加载是Java程序运行时的一个重要环节，它负责查找、加载、验证、准备和解析类文件。

类加载过程主要包括以下几个步骤：

加载（Loading）：查找并加载类的字节码文件。类加载器根据类的全限定名（包名+类名）从文件系统、网络等位置查找类文件，并将其读取到内存中。
验证（Verification）：验证类的字节码文件的正确性和安全性。验证阶段会检查类文件的格式、语义和字节码的合法性，防止恶意代码或错误的类文件影响系统的安全和稳定性。
准备（Preparation）：为类的静态变量分配内存并设置默认值。在准备阶段，Java虚拟机会为类的静态变量（即类变量）分配内存空间，并设置默认的初始值。
解析（Resolution）：将符号引用转换为直接引用。解析阶段会将类中的符号引用（如类、方法、字段的引用）转换为直接引用（内存地址），以便后续的方法调用和字段访问。
初始化（Initialization）：执行类的初始化代码，包括静态变量的赋值和静态代码块的执行。在初始化阶段，会执行类的初始化代码，初始化类的静态变量和静态代码块，并且按照程序中定义的顺序执行。

类加载是Java虚拟机的核心功能之一，它通过类加载器（ClassLoader）来实现。Java虚拟机提供了多个类加载器，包括启动类加载器、扩展类加载器和应用程序类加载器，它们按照一定的层次关系负责加载不同位置的类文件。

12.java中类加载器有哪些?

在Java中，有以下几种类加载器：

Bootstrap ClassLoader：也称为引导类加载器，是JVM自带的类加载器，负责加载Java的核心类库，如rt.jar等。
Extension ClassLoader：也称为扩展类加载器，负责加载Java的扩展类库，如jre/lib/ext目录下的jar包。
System ClassLoader：也称为系统类加载器，负责加载应用程序的类库，即classpath下的类。
自定义类加载器：可以通过继承ClassLoader类来自定义类加载器，实现特定的类加载需求，如从网络或数据库中加载类。

其中，Bootstrap ClassLoader是由C++实现的，而其他的类加载器都是由Java实现的。类加载器之间存在父子关系，子类加载器可以访问父类加载器加载的类，而父类加载器无法访问子类加载器加载的类。

13.乐观锁和悲观锁的区别?如何实现？

乐观锁和悲观锁是并发编程中常用的两种锁机制，它们的区别如下：

悲观锁：悲观锁假设并发访问时会发生冲突，因此在访问共享资源时会先将其锁定，阻止其他线程的访问，待操作完成后才释放锁。悲观锁适用于多写少读的场景，如数据库中的行锁、表锁等。悲观锁的缺点是在并发量高的情况下，可能会导致大量线程阻塞，影响系统性能。
乐观锁：乐观锁假设并发访问时不会发生冲突，因此在访问共享资源时不会加锁，而是在更新操作时通过比较版本号或时间戳等方式判断是否发生冲突。如果发生冲突，则需要重新获取数据并重新执行更新操作。乐观锁适用于多读少写的场景，如缓存、无锁数据结构等。乐观锁的优点是无需加锁，减少了线程的阻塞，提高了系统的并发性能，但如果冲突频繁发生，会导致大量的重试操作。

总的来说，悲观锁是一种保守的锁机制，假设并发访问时会发生冲突，因此加锁来保证数据的一致性；而乐观锁是一种乐观的锁机制，假设并发访问时不会发生冲突，通过版本控制等方式来保证数据的一致性。选择使用哪种锁机制要根据实际场景和需求来决定。

14.线程池如何提升性能?

线程池是一种管理和复用线程的机制，通过有效地管理线程的创建、调度和销毁，可以提升系统的性能。以下是线程池如何提升性能的几个方面：

重用线程：线程池可以重复使用已经创建的线程，避免了线程的频繁创建和销毁，减少了系统开销。通过线程的复用，可以减少线程创建和销毁的时间开销，提高系统的响应速度。
控制并发数量：线程池可以根据系统的负载情况和资源限制来动态调整线程的数量。可以通过设置核心线程数、最大线程数、队列容量等参数来控制线程池的并发度，避免过多的线程竞争和资源浪费，提高系统的稳定性和吞吐量。
防止资源耗尽：线程池可以通过设置任务队列来缓冲任务，避免任务过多导致系统资源耗尽。当任务到达线程池时，如果线程池已满，则可以将任务放入队列中等待执行，避免任务的丢失和系统的负载过高。
线程管理：线程池可以提供对线程的管理功能，包括线程的创建、销毁、监控和统计等。通过线程池可以对线程进行统一管理，方便监控线程的状态和性能指标，优化线程的执行和资源利用。

总的来说，线程池通过重用线程、控制并发数量、防止资源耗尽和线程管理等方式，提供了一种高效的线程调度和管理机制，可以提升系统的性能和稳定性。使用线程池可以避免线程频繁创建和销毁的开销，减少线程竞争和资源浪费，优化系统的资源利用和响应速度。

15.使用乐观锁如何实现超卖现象?

使用乐观锁可以有效地避免超卖现象的发生。具体实现步骤如下：

在数据库表中添加一个version字段，用于记录数据的版本号。
当有用户购买商品时，首先查询该商品的库存数量和版本号。
在更新库存之前，比较查询到的库存数量和当前要购买的数量是否大于等于0，并且比较版本号是否一致。
如果满足条件，则更新库存数量，并将版本号加1，同时返回购买成功。
如果不满足条件，则返回购买失败。

通过乐观锁的方式，可以保证在多个并发请求同时修改库存时，只有一个请求能够成功更新库存，其他请求会因为版本号不一致而失败。这样可以有效避免超卖现象的发生。

16.SQL中幻读和读已提交?

并发事务引发的问题;(事务完成之后才能提交) 一下距离为两个事务中各有三步操作

脏读一个事务读取到另一个事务中没有提交的数据(一个事务中有多个操作没有执行完,就没有提交) 事务B查询读取到的是原来的数据,而不是修改之后的数据.

幻读 :一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现了幻影’

不可重复读一个事务先后读取同一条数据, 但是两次读取的数据不同查询的数据不同

解决并发事务的问题:事务的隔离级别：

17.redis主要使用场景?

缓存：Redis是一个高性能的缓存数据库，可以将常用的数据存储在内存中，以提高读写性能，并减轻后端数据库的压力。
队列系统：Redis可以作为一个消息队列系统，支持发布订阅模式，多个客户端可以通过订阅相同的频道来接收消息。
计数器：Redis支持对整数进行原子操作，可以用于实现计数器功能，如网站的PV/UV统计、商品的库存计数等。
分布式锁：Redis提供了分布式锁的功能，可以用于解决多个进程/线程对共享资源的并发访问问题。
实时排行榜：Redis的有序集合可以用于实现实时排行榜功能，如游戏中的积分排行榜、热门文章排行榜等。
社交网络应用：Redis的数据结构可以很好地支持社交网络应用的开发，如关注/粉丝关系、好友关系等。
地理位置应用：Redis的地理位置数据类型可以用于存储地理位置信息，如附近的人功能、地理位置搜索等。
分布式缓存：Redis支持数据分片和复制，可以构建分布式缓存集群，提供高可用性和高性能的缓存服务。
消息系统：Redis的发布订阅功能可以用于构建简单的消息系统，如实时聊天、通知推送等。
网络应用：Redis的高性能和低延迟特性使其非常适合用于构建网络应用，如在线游戏、实时聊天等。

18.如何给给字符串创建索引?

在MySQL中，可以使用索引来加快字符串类型的数据的查询速度。以下是在MySQL中为字符串创建索引的步骤：

创建表时定义字符串字段为可索引的类型，如VARCHAR、CHAR等。例如，创建一个名为mytable的表，包含一个名为mystring的字符串字段：
```
CREATE TABLE mytable (
  id INT PRIMARY KEY,
  mystring VARCHAR(100)
);
```
使用CREATE INDEX语句创建索引。在创建索引时，可以指定要创建索引的字段，以及索引的名称。例如，创建一个名为idx_mystring的索引：
```
CREATE INDEX idx_mystring ON mytable (mystring);
```
注意：如果表中已经存在数据，创建索引可能会花费一些时间，因为需要对现有数据进行索引构建。
使用EXPLAIN命令或查询计划工具来验证索引是否生效。例如，执行以下查询：
```
EXPLAIN SELECT * FROM mytable WHERE mystring = 'example';
```
如果查询计划中出现Using index或Using where; Using index，则表示索引生效。

需要注意的是，创建索引会占用一定的存储空间，并在插入、更新和删除数据时会有一定的性能开销。因此，需要根据具体的业务需求和数据量来决定是否创建索引，并选择合适的字段和索引类型。此外，还可以使用前缀索引、全文索引等技术来优化字符串字段的索引。
给字符串前边部分创建索引

19.SQL事务和分布式事务的区别?

SQL事务和分布式事务是两个不同的概念，它们有以下主要区别：

范围：SQL事务是在单个数据库实例中进行的一组操作的逻辑单元，而分布式事务涉及多个独立的数据库实例或系统之间的操作。
参与者：SQL事务通常涉及一个数据库实例中的多个表的操作，而分布式事务涉及多个数据库实例或系统之间的协调。
一致性：SQL事务的一致性是在单个数据库实例中保持的，而分布式事务的一致性是在多个数据库实例或系统之间保持的。
隔离性：SQL事务的隔离性是在单个数据库实例中实现的，而分布式事务的隔离性需要考虑多个数据库实例或系统之间的隔离性。
可靠性：分布式事务需要考虑网络通信、节点故障等因素，因此对于分布式事务的可靠性要求更高。
事务管理：SQL事务可以使用数据库的内置事务管理机制，如ACID特性和事务日志来确保事务的原子性、一致性、隔离性和持久性。而分布式事务需要使用分布式事务管理器来协调多个参与者的操作，保证整个分布式事务的一致性。

需要注意的是，分布式事务的实现比较复杂，需要考虑数据的一致性、并发控制、故障恢复等问题。常见的分布式事务管理协议包括两阶段提交（2PC）、三阶段提交（3PC）、TCC（Try-Confirm-Cancel）等。在分布式系统中，保证分布式事务的一致性和可靠性是一个挑战性的问题。

20.Intger能不能用==比较大小?

看是否在-127-128之间，如果在的话是可以比较的；如果不在
在Java中，"=="运算符用于比较两个对象的值。然而，在比较值在-128到127之外的整数对象时，Java会为每个值创建新的Integer对象。这意味着尽管"a"和"b"的值相同（都是300），它们实际上是指向内存中不同的对象。

21.sql隔离级别?

22.并发，如何解决？

在并发编程中，可以采取以下方法来解决并发问题：

使用同步机制：使用synchronized关键字或者Lock接口来确保在同一时间只有一个线程可以访问特定的代码块或方法。这可以避免多线程之间的竞争条件和数据不一致性问题。
使用线程安全的数据结构：Java提供了许多线程安全的数据结构，如ConcurrentHashMap、ConcurrentLinkedQueue等。这些数据结构在多线程环境下可以安全地进行读写操作，避免了数据竞争和数据不一致的问题。
使用原子操作：Java提供了一些原子类，如AtomicInteger、AtomicLong等，可以保证特定操作的原子性，避免多线程之间的竞争条件。
使用线程池：使用线程池来管理线程的创建和销毁，可以提高线程的复用性和性能，并且可以控制并发线程的数量，避免资源耗尽的问题。
使用并发工具类：Java提供了一些并发工具类，如CountDownLatch、Semaphore、CyclicBarrier等，可以帮助协调和控制多个线程之间的执行顺序和并发访问。
使用volatile关键字：使用volatile关键字可以保证线程之间的可见性，避免数据的脏读和写入问题。
使用线程间通信机制：使用wait、notify、notifyAll等方法来实现线程之间的通信和协作，确保线程按照预期的顺序执行。
使用并发编程框架：使用像Java的Fork/Join框架、Java并发包中的Executor框架等高级并发编程框架，可以简化并发编程的复杂性，并提供更高级的并发控制和优化。

这些方法可以帮助解决并发编程中可能遇到的竞争条件、数据不一致性、死锁等问题，并提高程序的性能和可靠性。但是，正确地处理并发问题需要深入了解并发编程的原理和技术，并根据具体情况选择合适的方法。

22.1分布式中的高并发如何解决？

在分布式系统中，解决高并发问题需要考虑以下几个方面：

水平扩展：通过增加服务器节点来扩展系统的处理能力，将请求分发到多个节点上进行并行处理。这可以通过负载均衡器来实现，将请求均匀地分发到不同的节点上，从而提高系统的并发处理能力。
分布式缓存：使用分布式缓存来减轻数据库的压力，提高系统的读取性能。将经常被访问的数据缓存在分布式缓存中，避免每次请求都需要查询数据库，从而提高系统的响应速度和吞吐量。
异步处理：将一些耗时的操作和请求进行异步处理，减少请求的等待时间。通过消息队列或异步任务队列等机制，将请求放入队列中，由后台线程或其他节点来处理，从而提高系统的并发处理能力。
数据库优化：对数据库进行优化，如使用索引、分库分表、读写分离等，以提高数据库的读写性能和并发处理能力。同时，可以考虑使用分布式数据库或数据库集群来分担数据库的负载。
分布式事务：在分布式系统中，保证数据的一致性和事务的正确性是一个挑战。可以使用分布式事务管理机制来实现跨多个节点的事务一致性，如使用分布式事务框架或基于消息的事务机制。
缓存预热和热点数据处理：在系统启动或数据更新时，预先加载常用的数据到缓存中，避免冷启动时的性能问题。同时，对于热点数据，可以采用缓存策略，如缓存击穿、缓存雪崩等的处理机制，以保证系统的稳定性和性能。
排队和限流：使用排队和限流机制来控制系统的并发请求量，避免系统被过多的请求压垮。通过设置请求的排队机制和限制每秒钟的请求数量，可以保护系统免受过多请求的影响。

通过以上措施，可以提高分布式系统的并发处理能力，保证系统在高并发场景下的稳定性和性能。同时，需要根据具体的业务需求和系统架构选择合适的解决方案。

22.2.什么是分布式事务？

分布式事务是指在分布式系统中，涉及多个独立的事务处理单元（例如数据库、消息队列等），同时参与一个全局事务的处理过程。分布式事务的目标是确保在分布式环境下的多个事务操作的一致性和隔离性。

在传统的单机数据库事务中，通过ACID（原子性、一致性、隔离性和持久性）属性来保证事务的正确执行。然而，在分布式环境下，由于涉及多个独立的事务处理单元，传统的ACID属性难以直接应用于全局事务。

分布式事务解决的核心问题是：如何确保多个参与者（事务处理单元）在执行各自的本地事务后，要么全部提交，要么全部回滚，以保持全局事务的一致性。以下是一些常见的分布式事务解决方案：

两阶段提交（Two-Phase Commit，2PC）：2PC是一种同步协议，涉及一个协调者和多个参与者。在第一阶段，协调者向所有参与者发送事务准备请求，并等待参与者的响应。在第二阶段，如果所有参与者都准备好了，协调者发送提交请求；否则，协调者发送回滚请求。2PC的主要问题是阻塞和单点故障。
三阶段提交（Three-Phase Commit，3PC）：3PC是对2PC的改进，引入了超时机制来解决阻塞问题。在第一阶段，协调者询问参与者是否准备好提交；在第二阶段，协调者发送提交请求或回滚请求；在第三阶段，协调者等待参与者的确认。3PC减少了2PC的阻塞问题，但仍存在单点故障的问题。
补偿事务（Compensating Transaction）：补偿事务是一种基于业务逻辑的补偿机制，用于在分布式系统中恢复事务的一致性。当某个参与者出现故障或事务失败时，补偿事务会执行一系列逆向操作来回滚或修复之前的事务操作。补偿事务的实现较为复杂，但可以提供更好的可扩展性和容错性。
基于消息的事务（Message-based Transaction）：基于消息的事务使用消息队列来处理分布式事务。事务参与者将事务请求发送到消息队列中，由一个或多个消费者处理该请求。消息队列可以提供事务消息的可靠传递和顺序处理，从而保证分布式事务的一致性。

分布式事务的选择取决于具体的业务需求和系统架构。每种解决方案都有其优缺点，需要根据系统的可靠性、性能和一致性要求进行权衡和选择。

22.3 RedissonClient 分布式锁

引入依赖

        <!--redisson-->
        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
        </dependency>

定义接口

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface GlobalLock {
    String prefix() default "";
    String key();
    int time() default 10;
    TimeUnit unit() default TimeUnit.SECONDS;
}

具体逻辑


/**
 1. 切面类
 */
@Component
@Aspect
public class GlobalLockAdvice {
    /**
     * 对指定包下指定类的方法增强
     * 对加了指定注解方法增强
     * @return
     */
    @Autowired
    private RedissonClient redissonClient;

    @Around("@annotation(com.tianji.promotion.annoation.GlobalLock)")
    public Object globalLock(ProceedingJoinPoint proceedingJoinPoint) {
        //proceedingJoinPoint获取切入点所有信息，切入点方法，切入点方法参数，调用切入点方法
        //1.获取切入点
        MethodSignature signature = (MethodSignature) proceedingJoinPoint.getSignature();
        Method method = signature.getMethod();
        //2.获取切入点上面GlobalLock注解，获取注解中属性值
        GlobalLock annotation = method.getAnnotation(GlobalLock.class);
        String prefix = annotation.prefix();
        String key = annotation.key();
        int time = annotation.time();
        TimeUnit unit = annotation.unit();
        //解析springel表达式
        ExpressionParser parser = new SpelExpressionParser();
        EvaluationContext context = new StandardEvaluationContext();
        //获取切入点中形参名称
        Object[] args = proceedingJoinPoint.getArgs();
        Parameter[] parameters = method.getParameters();
        int argsLength = args.length;
        for (int i = 0; i < argsLength; i++) {
            context.setVariable(parameters[i].getName(),args[i]);
        }
        Expression expression = parser.parseExpression(key);
        String value = expression.getValue(context, String.class);
        //3.定义key
        String redisKey = prefix + value;
        //4.创建分布式锁
        RLock lock = redissonClient.getLock(redisKey);
        //5.加锁
        try {
            boolean b = lock.tryLock(time, unit);
            if(b) {
                //6.成功
                //6.1.调用切入点
                Object proceed = proceedingJoinPoint.proceed();
                return proceed;
            }

        } catch (Throwable e) {
            e.printStackTrace();
        } finally {
            //6.2.释放锁
            lock.unlock();
        }
        throw new RuntimeException("请稍后重试");
    }
}

增强方法

/**
 * 
 * 用户领取优惠券的记录，是真正使用的优惠券信息 前端控制器
 * 
 *
 * @author liuwen
 * @since 2023-09-08
 */
@RestController
@RequestMapping("/user-coupons")
public class UserCouponController {
    @Autowired
    private IUserCouponService userCouponService;

    /**
     * 领取优惠券  用户在优惠券列表页可以领取优惠券  实现接口根据id给用户添加一个优惠券
     * 注意校验优惠券发放时间  库存  每人限领数量
     * @param id
     */
    @PostMapping("/{id}/receive")
    @GlobalLock(prefix = "lock",key = "#id")
    public void createUserCoupon(@PathVariable("id") Long id) {
        userCouponService.createUserCoupon(id);
    }


  /**
     *兑换码兑换优惠券
     * 需求：实现接口根据兑换码给用户添加一张优惠券
     * @param code
     */
    @PostMapping("/{code}/exchange")
    @GlobalLock(prefix = "lock",key = "#code")
    public void exchangeCouponToCode(@PathVariable("code") String code){
        userCouponService.exchangeCouponToCode(code);
    }

23.微服务的中间件

Rabbit MQ

24. mq的作用？

RabbitMQ是一个开源的消息队列中间件，它的作用是实现不同应用程序之间的异步消息传递。

具体来说，RabbitMQ的作用包括：

异步通信：RabbitMQ充当了应用程序之间的中间人，可以实现异步通信模式。通过将消息发送到RabbitMQ，发送方不需要等待接收方的响应，从而实现解耦和提高系统的可伸缩性。
应用解耦：RabbitMQ允许不同的应用程序之间进行松耦合的通信。发送方只需要将消息发送到RabbitMQ的消息队列中，接收方可以根据自己的需求从队列中获取消息进行处理，而不需要直接与发送方进行通信。
消息持久化：RabbitMQ支持消息的持久化，即使在消息发送后，如果接收方不可用，消息也不会丢失。消息可以被持久化到磁盘上，并在接收方重新可用时重新发送。
负载均衡：RabbitMQ支持将消息发送到多个消费者之间进行负载均衡。它可以根据预设的规则将消息分发给多个消费者，确保每个消费者都能平均处理消息。
消息确认机制：RabbitMQ提供了消息确认机制，确保消息在被消费者处理后得到确认。这样可以保证消息不会丢失，并且消费者可以在处理消息时进行错误处理和重试。
可靠性和可恢复性：RabbitMQ提供了多种机制来保证消息的可靠性和可恢复性。例如，消息持久化、消息确认机制、备份队列等，都可以确保消息在各种故障情况下不会丢失，并且系统可以在故障恢复后继续正常工作。

总的来说，RabbitMQ提供了一个可靠、可扩展和灵活的消息传递机制，使得不同应用程序之间可以进行异步通信，实现松耦合的系统架构。它在分布式系统、微服务架构和事件驱动架构等场景下具有广泛的应用。

24.1 消息持久化

消息持久化是指在消息队列中将消息保存到持久化存储介质（例如磁盘）中，以确保消息在发送和接收过程中不会丢失。消息持久化是一种可靠性保证机制，尤其在消息传递过程中可能发生故障的情况下非常重要。

消息持久化通常涉及以下几个方面：

消息发送时的持久化：在消息发送者发送消息时，将消息标记为持久化。这意味着当消息到达消息队列时，它将被写入持久化存储介质，而不仅仅是存储在内存中。这样即使在发送后，如果消息队列或消息代理发生故障，消息也不会丢失。
消息存储的持久化：消息队列将持久化的消息存储在持久化存储介质（如磁盘）中，以确保消息在故障情况下的可靠性。持久化存储介质通常具有更好的持久性和容错性，可以在系统故障后进行恢复，并保证消息的可靠传递。
消息消费时的持久化：在消息消费者接收到消息并处理完后，将消息标记为已经处理。这样可以确保消息在消费者故障或重启后不会被重复处理。通过消息确认机制，消费者可以告知消息队列已经成功处理消息，然后消息队列可以安全地删除该消息。

消息持久化的好处包括：

可靠性：通过将消息存储到持久化存储介质中，即使在消息传递过程中出现故障，消息也不会丢失，可以在故障恢复后继续处理。
可恢复性：持久化存储介质可以在系统故障后进行恢复，确保消息的可靠传递。这对于关键业务应用程序非常重要。
容错性：通过持久化存储介质的使用，即使消息代理或消息队列本身发生故障，消息也可以在故障恢复后继续传递。

需要注意的是，消息持久化会增加系统的开销和延迟，因为消息需要写入磁盘。因此，在设计系统时需要权衡可靠性和性能之间的平衡，并根据实际需求选择是否使用消息持久化。

24.2.消息确认机制

消息确认机制是指在消息传递过程中，确保消息被正确接收和处理的一种机制。它可以确保消息在发送后不会丢失，并且接收方可以对消息进行确认，以确保消息的可靠性传递。

消息确认机制通常包括以下几个要素：

发送方确认：发送方在发送消息后等待接收方的确认。如果接收方成功接收并处理了消息，则发送方可以得到确认，继续发送下一个消息。如果接收方未能及时确认，发送方可以进行重试或采取其他措施。
接收方确认：接收方在成功接收和处理消息后，向发送方发送确认。这可以是一个简单的应答，也可以是一个包含状态信息的响应。接收方的确认可以告知发送方消息已经成功处理，可以安全地删除该消息，或者可以触发其他后续操作。
重试机制：如果发送方未收到接收方的确认，或者接收方未能成功处理消息，发送方可以进行重试。重试机制可以确保消息在传递过程中的可靠性，并在出现故障时进行恢复。

消息确认机制的好处包括：

可靠性：通过消息确认机制，可以确保消息在传递过程中不会丢失。发送方可以得到接收方的确认，以确保消息已被正确接收和处理。
错误处理：接收方可以根据消息的处理结果发送相应的确认信息。如果消息处理失败，接收方可以发送失败的确认，以触发发送方的重试或其他错误处理机制。
可恢复性：如果消息在传递过程中发生故障，消息确认机制可以帮助系统进行恢复。发送方可以根据接收方的确认进行重试，并确保消息被正确处理。

需要注意的是，消息确认机制需要在发送方和接收方之间进行协作，因此在设计和实现时需要考虑到消息确认的逻辑和处理方式。不同的消息中间件和协议可能有不同的消息确认机制实现方式，开发人员需要根据具体的需求和技术选择合适的机制。

25.nacos的作用

Nacos（全称为"Naming and Configuration Service"）是一个开源的服务发现、配置管理和服务管理平台。它提供了一系列的功能和特性，用于帮助开发人员构建和管理微服务架构。

Nacos的作用包括：

服务注册与发现：Nacos提供了服务注册与发现的功能，可以让微服务实例注册自己的信息（如IP地址、端口号等），并且能够动态地发现其他微服务实例的位置和状态。这样可以实现微服务之间的通信和协作。
配置管理：Nacos可以集中管理微服务的配置信息，包括应用程序的配置文件、动态配置参数等。它提供了一个统一的配置中心，可以动态修改和更新配置，而无需重启应用程序。
服务路由与负载均衡：Nacos支持服务路由和负载均衡的功能，可以根据不同的规则和策略将请求路由到不同的微服务实例上，以实现负载均衡和高可用性。
服务健康监测：Nacos可以监测微服务实例的健康状态，包括实例的存活状态、性能指标等。通过健康监测，可以及时发现和处理故障，保证系统的稳定性和可靠性。
动态配置刷新：Nacos支持动态配置刷新的功能，可以实时更新配置信息，并通知到使用该配置的微服务实例，从而实现配置的动态更新和刷新。
分布式系统的协调与管理：Nacos提供了一些分布式系统的协调与管理功能，例如分布式锁、分布式一致性算法等，可以帮助解决分布式系统中的一些常见问题。

总的来说，Nacos是一个功能强大的服务发现、配置管理和服务管理平台，为微服务架构提供了一些重要的基础设施和工具。它可以帮助开发人员构建和管理微服务应用程序，提高系统的可靠性、可扩展性和可维护性。

26.一个包装类型和一个基本类型能够用==来比较吗？

在Java中，包装类型和基本类型不能直接使用"“来比较。这是因为”"运算符在比较两个对象时，比较的是对象的引用地址，而不是对象的值。

当使用"=="运算符比较包装类型和基本类型时，会发生自动拆箱（将包装类型转换为基本类型）的过程。然后，基本类型之间的比较是按照它们的值来进行的。

例如，比较一个Integer包装类型和一个int基本类型：

Integer a = 10;
int b = 10;
System.out.println(a == b); // true

在这个例子中，Integer类型的包装对象a会自动拆箱为int类型，然后比较的是两个int类型的值，因此结果为true。

但是，当包装类型和基本类型的值不相等时，"=="运算符的结果可能会出乎意料：

Integer a = 10;
int b = 20;
System.out.println(a == b); // true or false?

在这个例子中，尽管a和b的值不相等，但由于自动拆箱后比较的是两个int类型的值，结果取决于具体的数值和Java虚拟机的实现。因此，结果可能是true也可能是false。

为了比较包装类型和基本类型的值，应该使用包装类型的equals()方法进行比较：

Integer a = 10;
int b = 10;
System.out.println(a.equals(b)); // true

equals()方法会比较两个对象的值，而不仅仅是比较引用地址。因此，这种方式可以正确地比较包装类型和基本类型的值。

27.sql优化

SQL优化是指通过改变SQL语句、调整数据库结构或者优化数据库配置等方式，提高数据库的性能和效率。

以下是一些常见的SQL优化技巧：

使用合适的索引：在经常查询的字段上创建索引，可以大大提高查询的速度。但是过多的索引也会影响插入和更新操作的性能，所以需要权衡选择适当的索引。
避免全表扫描：尽量避免使用不带条件的SELECT语句，这会导致数据库进行全表扫描，消耗大量资源。可以通过添加WHERE条件、使用LIMIT限制结果集大小等方式来避免全表扫描。
使用合适的数据类型：选择合适的数据类型可以减小数据库存储空间，提高查询速度。例如，使用整型代替字符型存储数字，使用日期类型代替字符串存储日期等。
合理使用连接：在多表查询时，使用合适的连接方式（如INNER JOIN、LEFT JOIN等）可以减少数据集的大小，提高查询性能。
优化查询语句：避免使用不必要的子查询、避免使用SELECT *，只查询需要的字段，可以减少数据传输和处理的时间。
分析执行计划：通过分析SQL的执行计划，可以了解SQL语句的执行情况，找到性能瓶颈，并进行相应的优化。
控制事务的粒度：合理控制事务的粒度，减少事务的持有时间，可以提高并发性能。
定期维护数据库：定期进行数据库的备份、数据清理、索引重建等维护操作，可以保持数据库的良好性能。

除了上述的技巧，还有一些其他的优化方法，如使用缓存、分库分表、垂直切分、水平切分等，根据具体情况选择合适的优化方法。同时，SQL优化也需要结合具体的数据库系统和应用场景进行综合考虑。

28.乐观锁超卖

乐观锁是一种并发控制机制，它通过在数据上添加一个版本号或时间戳来实现。当多个线程同时操作同一个数据时，乐观锁允许多个线程同时读取数据，但在更新数据时会进行版本号或时间戳的比较，如果版本号或时间戳不一致，则表示数据已被其他线程修改，当前线程的更新操作会被拒绝。

乐观锁可以用来解决超卖问题，即多个线程同时进行某个资源的抢购或减库存操作，避免出现超卖的情况。以下是一种使用乐观锁解决超卖问题的简单实现：

在数据库中增加一个版本号或时间戳字段，用于记录数据的版本信息。
当进行抢购或减库存操作时，首先读取数据库中的当前版本号或时间戳。
在进行更新操作时，将读取到的版本号或时间戳与当前最新的版本号或时间戳进行比较。
如果两者一致，则表示数据没有被其他线程修改，可以进行更新操作，并将版本号或时间戳加1或更新为当前时间。
如果两者不一致，则表示数据已被其他线程修改，当前线程的更新操作会被拒绝，可以进行重试或给用户返回抢购失败的提示。

使用乐观锁可以在一定程度上避免超卖问题，但需要注意的是，乐观锁并不能完全解决并发冲突问题，如果并发量过大或者业务逻辑复杂，可能需要采用其他更强大的并发控制机制，如悲观锁、分布式锁等来解决超卖问题。

29、基本的数据类型

在大多数编程语言中，常见的基本数据类型包括：

整型（Integer）：用于存储整数值，如byte、int、long、short等。
浮点型（Floating-point）：用于存储带有小数点的数值，如float、double等。
字符型（Character）：用于存储单个字符，如char。
字符串型（String）：用于存储字符序列，如String。
布尔型（Boolean）：用于存储逻辑值，如boolean。

30.简单说下集合，

map collection顶层接口
集合是一种数据结构，用于存储一组无序且唯一的元素。集合中的元素之间没有顺序关系，每个元素都是独立的，并且集合中不允许存在重复的元素。

集合的特点包括：

无序性：集合中的元素没有固定的顺序，无论元素的插入顺序如何，都不会影响集合的整体结构。
唯一性：集合中的元素是唯一的，不允许存在重复的元素。当尝试向集合中添加已经存在的元素时，集合不会发生改变。

集合常见的操作包括：

添加元素：向集合中添加一个新元素。
删除元素：从集合中移除指定的元素。
判断元素是否存在：检查集合中是否包含指定的元素。
获取集合的大小：获取集合中元素的个数。
遍历集合：按照某种方式依次访问集合中的每个元素。

集合可以用于解决很多实际问题，例如去重、查找元素是否存在、对比两个集合的差异等。在编程语言中，常见的集合实现包括数组、列表、集合类等。不同的编程语言提供了不同的集合实现，并且可能有不同的操作和特性。

30.1hashmap的底层

底层原理:1.底层先创建出长度为16的数组，table
2.添加每个元素时，先通过hashCode()方法获取该元素的hash值，结合数组长度计算元素存储的位置
3.判断该位置元素是否为null，如果为null直接存储，不为null：再调用元素的equlas()方法比较值
4.值相等：不存。值不相等：1.8将新元素挂载在老元素下面，以链表形式
5.如果该链表长度>8,并且数组长度>=64，会将该链表转为红黑树结构
6. 当数组存满到16*0.75=12时，就自动扩容，每次扩容原先的两倍）一模一样

31、HashMap 和 Hashtable 有什么区别？

相同点:

1、HashMap和Hashtable都实现了Map接口

2、都可以存储key-value数据

不同点：

1、HashMap可以把null作为key或value，Hashtable不可以

2、HashMap线程不安全，效率高。Hashtable线程安全，效率低。

32、ConcurrentHashMap如何保证同步

ConcurrentHashMap使用了锁分段技术来保证同步。具体来说，ConcurrentHashMap将整个数据结构分为多个段（Segment），每个段都是一个独立的HashTable，每个段都有自己的锁来控制并发访问。当一个线程要对ConcurrentHashMap进行读写操作时，首先需要获取对应段的锁，而不是整个ConcurrentHashMap的锁。这样可以使得多个线程可以同时对不同的段进行并发操作，提高了并发性能。

在读操作时，ConcurrentHashMap不需要加锁，多个线程可以同时进行读操作。而在写操作时，只有对应段的锁会被加锁，其他段的锁不会受到影响，这样可以实现部分并发写操作。这种方式在并发度较高的情况下，可以有效地提高性能。

此外，ConcurrentHashMap还使用了volatile关键字来保证内存可见性，确保对数据的修改能够被其他线程及时看到。

总的来说，ConcurrentHashMap通过锁分段技术和volatile关键字来保证同步，实现了高效的并发访问。

33、Stream流的原理，常用方法

Stream流是Java 8引入的一种处理集合数据的新方式。它主要的特点是可以对集合进行一系列的操作，如过滤、映射、排序等，而这些操作可以通过链式调用的方式来组合，从而实现更加简洁和灵活的代码编写。

Stream流的原理主要包括以下几个步骤：

获取数据源：可以是集合、数组、I/O通道等。
数据转换：对数据源进行一系列的转换操作，如过滤、映射、排序等，每个转换操作都会生成一个新的Stream流。
执行操作：对转换后的Stream流进行终结操作，如forEach、reduce、collect等，这些操作会产生最终的结果。

Stream流的常用方法可以分为两大类：中间操作和终结操作。

中间操作：
**- filter()：过滤元素，根据指定的条件保留符合条件的元素。

map()：对元素进行映射转换，将每个元素根据指定的规则转换为另一个元素。
sorted()：对元素进行排序，可以指定自定义的排序规则。
distinct()：去除重复元素。
limit()：限制元素的数量。
skip()：跳过指定数量的元素。**

终结操作：
**- forEach()：对每个元素执行指定的操作。

collect()：将Stream流中的元素收集到一个集合中。
reduce()：将Stream流中的元素逐个进行归约操作，得到一个最终的结果。
count()：返回Stream流中的元素数量。
anyMatch()、allMatch()、noneMatch()：判断Stream流中的元素是否满足指定的条件。**

除了上述常用方法外，Stream流还提供了其他一些操作，如flatMap()、max()、min()、findFirst()、findAny()等。

通过使用Stream流，我们可以更加简洁和灵活地处理集合数据，提高代码的可读性和可维护性。

34、Mybatis的核心技术

MyBatis的核心技术包括以下几个方面：

SQL映射：MyBatis通过XML文件或注解的方式将SQL语句与Java方法进行映射，实现了SQL与Java代码的分离，提高了代码的可维护性和可读性。
参数映射：MyBatis支持将Java对象与SQL语句的参数进行映射，可以通过占位符或命名参数的方式传递参数，提供了灵活的参数传递方式。
结果映射：MyBatis支持将SQL查询结果与Java对象进行映射，可以通过XML文件或注解的方式定义结果映射规则，提供了灵活的结果映射方式。
缓存机制：MyBatis支持一级缓存和二级缓存的使用，一级缓存是SqlSession级别的缓存，二级缓存是Mapper级别的缓存，可以有效减少数据库访问次数，提高系统性能。
插件机制：MyBatis提供了插件机制，可以通过自定义插件来扩展MyBatis的功能，例如可以在SQL执行前后进行拦截，实现日志记录、权限控制等功能。
动态SQL：MyBatis支持动态SQL语句的构建，可以根据不同的条件动态生成SQL语句，提供了灵活的SQL构建方式。
批量操作：MyBatis支持批量插入、更新和删除操作，可以通过一次数据库访问实现多条数据的操作，提高了系统的性能。

总的来说，MyBatis的核心技术主要包括SQL映射、参数映射、结果映射、缓存机制、插件机制、动态SQL和批量操作等，这些技术使得MyBatis成为一款功能强大且灵活易用的持久层框架。

34.1 MyBatis的三级缓存

MyBatis的三级缓存是指在MyBatis中存在三个级别的缓存机制，分别是一级缓存、二级缓存和三级缓存。

一级缓存：
一级缓存是指SqlSession级别的缓存，它默认开启。当执行相同的SQL语句时，SqlSession会将查询结果缓存到内存中，下次执行相同的SQL语句时，直接从缓存中获取，避免了再次查询数据库的开销。一级缓存的作用范围是在同一个SqlSession内。
二级缓存：
二级缓存是指Mapper级别的缓存，它默认是关闭的。开启二级缓存后，多个SqlSession可以共享同一个Mapper的缓存数据。当执行查询操作时，如果缓存中存在相同的查询结果，直接从缓存中获取，避免了再次查询数据库的开销。二级缓存的作用范围是在同一个Mapper的不同SqlSession之间。
三级缓存：
三级缓存是指全局级别的缓存，它默认是关闭的。开启三级缓存后，多个SqlSessionFactory可以共享同一个缓存数据。三级缓存的作用范围是在不同的SqlSessionFactory之间。

需要注意的是，一级缓存和二级缓存是基于对象的缓存，因此需要确保对象的唯一性，否则可能会出现数据不一致的问题。同时，对于更新操作（insert、update、delete），MyBatis会自动清空相应的缓存，保证缓存数据的一致性。

35、多表联查left和right的区别

左连接（left join）和右连接（right join）是多表联查中常用的两种连接方式，它们之间的区别如下：

左连接（left join）：
左连接是以左表为基准进行连接的，左表中的所有记录都会被包含在结果集中，而右表中符合条件的记录会被匹配出来，不符合条件的则用NULL填充。换句话说，左连接会返回左表中的所有记录以及与之匹配的右表记录。
右连接（right join）：
右连接是以右表为基准进行连接的，右表中的所有记录都会被包含在结果集中，而左表中符合条件的记录会被匹配出来，不符合条件的则用NULL填充。换句话说，右连接会返回右表中的所有记录以及与之匹配的左表记录。

总结：
左连接和右连接的本质区别是以哪个表为基准进行连接，左连接以左表为基准，右连接以右表为基准。在实际应用中，选择使用左连接还是右连接取决于查询的需求和数据的结构，需要根据具体情况来确定使用哪种连接方式。

36、简单说下IOC和AOP

1、Spring是一个开源框架，主要是为简化企业级应用开发而生。可以实现EJB可以实现的功能，Spring是一个IOC和AOP容器框架。

① 控制反转(IOC)：Spring容器使用了工厂模式为我们创建了所需要的对象，我们使用时不需要自己去创建，直接调用Spring为我们提供的对象即可，这就是控制反转的思想。将对象的创建和依赖关系的管理交给容器来完成，而不是由程序员显式地创建和管理对象。在IOC中，对象的创建和依赖关系的维护由容器负责，程序员只需要通过配置文件或注解来描述对象的创建和依赖关系。

② 依赖注入(DI)：Spring使用Java Bean对象的Set方法或者带参数的构造方法为我们在创建所需对象时将其属性自动设置所需要的值的过程就是依赖注入的基本思想。

③ 面向切面编程(AOP)：在面向对象编程(OOP)思想中，我们将事物纵向抽象成一个个的对象。而在面向切面编程中，我们将一个个对象某些类似的方面横向抽象成一个切面，对这个切面进行一些如权限验证，事物管理，记录日志等公用操作处理的过程就是面向切面编程的思想。

2、在Spring中，所有管理的都是JavaBean对象，而BeanFactory和ApplicationContext就是Spring框架的那个IOC容器，现在一般使用ApplicationContext，其不但包括了BeanFactory的作用，同时还进行了更多的扩展。

37、缓存击穿和缓存雪崩，怎么解决缓存击穿

缓存穿透：

概述：指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。

解决方案：

1、查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短

2、布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对DB的查询

缓存击穿：

概述：对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。

解决方案：

1、使用互斥锁：当缓存失效时，不立即去load db，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，

否则重试get缓存的方法

2、永远不过期：不要对这个key设置过期时间

缓存雪崩：

概述：设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。

解决方案：

将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
14、Redis集群
在Redis中提供的集群方案总共有三种：

1、主从复制

保证高可用性
实现故障转移需要手动实现
无法实现海量数据存储

2、哨兵模式

保证高可用性
可以实现自动化的故障转移
无法实现海量数据存储

3、Redis分片集群

保证高可用性
可以实现自动化的故障转移
可以实现海量数据存储

38.乐观锁在实际开发中一般用于那种业务场景

乐观锁在实际开发中一般用于以下业务场景：

并发写场景：当多个用户或多个线程同时对同一数据进行写操作时，乐观锁可以用于确保数据的一致性。通过在更新数据时比较版本号或时间戳，如果版本号或时间戳不匹配，则表示数据已被其他用户或线程修改，可以进行相应的处理，如抛出异常或重新尝试更新。
数据冲突检测：在某些业务场景中，需要对多个用户或多个线程对同一数据进行修改的情况进行冲突检测。乐观锁可以通过比较数据的某些属性来检测数据是否发生冲突，如果发生冲突，则可以进行相应的处理，如合并数据或通知用户冲突。
基于版本的控制：在某些场景中，需要对数据的历史版本进行管理和控制。乐观锁可以通过版本号或时间戳来实现对数据版本的管理，每次更新数据时增加版本号或更新时间戳，可以方便地进行版本控制和回滚操作。
乐观并发控制：在某些并发控制场景中，需要在不阻塞其他操作的情况下进行并发控制。乐观锁可以通过在更新数据时进行乐观假设（假设没有其他并发操作），并在提交时检测是否发生了并发操作，如果发生了并发操作，则可以进行相应的处理。

总之，乐观锁适用于多个用户或多个线程同时对同一数据进行读写操作的场景，通过乐观地假设没有并发冲突，并在提交时进行冲突检测和处理，可以保证数据的一致性和并发性。

39.redis如何实现互斥锁，主要用到那些命令底层是怎么实现的

在Redis中实现互斥锁主要使用了以下命令：SETNX、EXPIRE和DEL。

SETNX命令：SETNX命令用于设置一个键的值，当且仅当该键不存在时才会设置成功。在实现互斥锁时，可以将锁作为一个键，将客户端的标识作为值，使用SETNX命令来尝试获取锁。如果SETNX命令返回1，表示获取锁成功；如果返回0，表示锁已被其他客户端持有，获取锁失败。
EXPIRE命令：为了防止锁被长时间持有，可以使用EXPIRE命令为锁设置一个过期时间。在获取锁成功后，使用EXPIRE命令设置锁的过期时间，确保在一定时间后锁会自动释放。
DEL命令：当客户端完成对锁的操作后，可以使用DEL命令来主动释放锁。通过删除锁的键，将锁释放给其他客户端使用。

底层实现方面，Redis使用单线程的事件循环模型，保证了命令的原子性。在执行SETNX命令时，Redis会将命令放入队列，并逐个执行，确保多个客户端同时执行SETNX命令时只有一个能够成功设置键值对。同时，Redis还提供了持久化机制和主从复制机制来保证数据的持久性和高可用性。

需要注意的是，Redis的互斥锁实现并不是完全可靠的，存在一些问题，如死锁和误删锁等。因此，在实际应用中，需要根据具体场景进行合理的使用和处理。

40.我有两个方法都加了事务，a调b，b新开事务，怎么一定会发生死锁。

在你描述的情况下，方法a调用方法b，并且方法b在调用时又新开了一个事务，这样就会导致嵌套事务的情况。在Redis中，嵌套事务并不被支持，新开的事务会覆盖外层的事务，因此内层事务中的操作不会受到外层事务的影响。

如果在方法b中对同一个键进行了写操作，并且在方法a和方法b之间有其他客户端对该键进行了修改，那么在执行方法b的事务时，会因为乐观锁机制的存在，发现键已被修改而导致事务失败。此时，Redis会自动进行重试，但由于方法a中的事务还未执行完毕，方法b的事务无法完成，从而导致死锁的发生。

为了避免这种死锁情况的发生，可以考虑对方法a和方法b进行重构，避免嵌套事务的使用，或者在方法b中不再新开事务。另外，还可以使用WATCH命令来监视相关的键，在事务执行前检查键是否被修改，如果被修改则中断事务，避免死锁的发生。

41.我定位到一个慢查询的sql，用explan查看也用到了索引，还是最优索引，此时怎么进行优化

要进一步优化慢查询的SQL，即使已经使用了最优索引，可以考虑以下几个方面：

索引优化：确保所使用的索引是最佳的选择，可以通过分析查询语句和数据访问模式，重新设计索引以提高查询性能。可以考虑创建覆盖索引，即包含查询需要的所有列的索引，减少表的访问次数。

查询重写：尝试重写查询语句，以获得更高效的执行计划。可以通过使用JOIN语句代替子查询、使用UNION ALL代替UNION、使用EXISTS代替IN等方法来优化查询。

数据库参数调整：根据具体的数据库系统，可以调整一些数据库参数来优化查询性能。例如，可以调整查询缓存大小、连接池大小、并发连接数等参数。

数据库结构调整：如果可能的话，可以考虑调整数据库的结构，例如分区表、垂直切分或水平切分等方式，以提高查询性能。

缓存优化：如果查询结果是相对稳定的，可以考虑使用缓存来提高查询性能。可以使用缓存工具或数据库内置的缓存功能，将查询结果缓存起来，减少对数据库的访问。

硬件优化：如果查询性能问题无法通过软件优化解决，可以考虑升级硬件，例如增加内存、使用更快的存储设备等。

在进行优化时，可以使用性能分析工具，例如MySQL的EXPLAIN语句、Percona Toolkit等，帮助定位查询的瓶颈所在，并根据具体情况进行相应的优化

42.RabbitMQ如何解决重复消费?

RabbitMQ 提供了一些机制来解决重复消费的问题：

消息的去重：可以使用消息的唯一标识符来判断是否重复消费。在消费消息之前，可以先检查是否已经处理过该消息的标识符，如果已经处理过，则可以跳过该消息。

消息的幂等性：可以设计消费者的逻辑，使得多次处理同一条消息的效果与处理一次相同。这样即使消息被重复消费，也不会对系统产生影响。

消息的应答机制：RabbitMQ 支持消息的应答机制，即消费者在处理完消息后发送应答给 RabbitMQ，告知消息已经处理完成。如果消费者在处理消息过程中发生异常或者失败，可以选择不发送应答，RabbitMQ 将会将该消息重新分发给其他消费者进行处理。

消息的过期时间：可以为消息设置过期时间，当消息超过一定时间未被消费者消费时，RabbitMQ 将会将该消息标记为过期，不再分发给消费者。

消息的幂等性处理：可以在消费者端使用一些技术，如数据库的唯一约束、分布式锁等，来保证消息的幂等性。

消息的去重策略：可以在消费者端记录已经处理过的消息的标识符，当新的消息到来时，先检查是否已经处理过该消息的标识符，如果已经处理过，则可以跳过该消息。

43.哨兵模式下为什么哨兵要是单数?

在兵模式下，哨兵通常是单数的原因有以下几点：

效率问题：在兵模式下，哨兵的主要任务是监控和管理主节点的状态，当主节点出现故障时，哨兵会进行故障转移，选举新的主节点。如果哨兵的数量是偶数，可能会导致选举过程中出现平局的情况，进而增加了选举的复杂性和时间。

高可用性：在兵模式下，哨兵的目标是提供高可用性的服务。当主节点出现故障时，哨兵会自动选举新的主节点，保证系统的正常运行。如果哨兵的数量是偶数，可能会导致选举过程中出现平局，进而降低了系统的可用性。

决策问题：在兵模式下，哨兵需要进行决策，如选举新的主节点、判断主节点是否正常等。如果哨兵的数量是偶数，可能会导致决策过程中出现分歧，增加了决策的复杂性。

44 对Spring的IOC和AOP的理解，IOC底层怎么实现?

1、Spring是一个开源框架，主要是为简化企业级应用开发而生。可以实现EJB可以实现的功能，Spring是一个IOC和AOP容器框架。

① 控制反转(IOC)：Spring容器使用了工厂模式为我们创建了所需要的对象，我们使用时不需要自己去创建，直接调用Spring为我们提供的对象即可，这就是控制反转的思想。

45.SpringCloud的几大组件 ?

springcloud五大组件：

1、注册中心组件（服务治理）：Netflix Eureka；

2、负载均衡组件：Netflix Ribbon，各个微服务进行分摊，提高性能；

3、熔断器组件（断路器）：Netflix Hystrix，Resilience4j ；保护系统，控制故障范围；

4、网关服务组件：Zuul，Spring Cloud Gateway；api网关，路由，负载均衡等多种作用；

5、配置中心：Spring Cloud Config，将配置文件组合起来，放在远程仓库，便于管理；

46.对Redis的理解?

Redis（Remote Dictionary Server）是一个开源的内存数据库，也被称为数据结构服务器。它支持多种数据结构，如字符串、哈希、列表、集合、有序集合等，并提供了丰富的操作命令。

以下是对Redis的几个重要特点和应用场景的理解：

高性能：Redis将数据存储在内存中，因此具有非常高的读写性能。它采用了多种优化技术，如使用异步I/O、基于事件驱动的架构等，以提供高吞吐量和低延迟的数据访问能力。
数据持久化：Redis支持两种数据持久化方式，分别是RDB（Redis Database）快照和AOF（Append Only File）日志。RDB快照是将内存中的数据定期写入磁盘，AOF日志是将每个写操作追加到文件中。这两种方式可以保证数据在服务器重启后的持久性。
缓存：Redis常用于作为缓存层，将热点数据存储在内存中，以提高读写性能和减轻后端数据库的压力。它支持设置过期时间和LRU（Least Recently Used）等淘汰策略，可以灵活地控制缓存数据的生命周期。
消息队列：Redis的发布/订阅机制可以用于构建简单的消息队列系统。发布者可以将消息发布到指定的频道，订阅者可以订阅感兴趣的频道并接收相应的消息。这种机制可以实现解耦和异步通信。
分布式锁：Redis提供了分布式锁的功能，用于在分布式环境下实现资源的互斥访问。通过使用Redis的原子命令和Lua脚本，可以实现高效可靠的分布式锁。

总之，Redis是一个功能丰富且高性能的内存数据库，可以用于缓存、消息队列、分布式锁等多种应用场景。它的简单易用性和高效性使其成为许多互联网公司和开发者的首选工具。

47.Redis的String和Hash有什么区别，

Redis的String和Hash是两种不同的数据结构，用于存储数据的方式也有所不同。

String：String是Redis最基本的数据类型，它是一个二进制安全的字符串，可以存储任何类型的数据。String类型可以用于存储简单的字符串值，也可以用于存储数字值，甚至可以存储序列化的对象。String类型的操作非常简单，可以进行常见的字符串操作，如获取、设置、追加、递增、递减等。
Hash：Hash是一种键值对集合，类似于其他编程语言中的Map或Dictionary。Hash类型适用于存储对象，可以将对象的各个属性存储在不同的字段中，方便读取和修改。在Redis中，Hash类型的字段是一个字符串与一个值之间的映射关系。Hash类型可以用于存储用户信息、商品信息等复杂数据结构。

区别：

存储方式：String类型存储的是一个简单的值，而Hash类型存储的是多个字段和值的集合。
访问方式：String类型可以直接通过键来获取值，而Hash类型需要通过键和字段来获取值。
数据结构：String类型的值是一个二进制安全的字符串，而Hash类型的值是一个键值对集合。
功能：String类型可以进行常见的字符串操作，如获取、设置、追加、递增、递减等，而Hash类型可以进行字段的增删改查操作。
应用场景：String类型适用于存储简单的值，如计数器、缓存等；而Hash类型适用于存储复杂的对象，如用户信息、商品信息等。

总的来说，String类型适用于存储简单的值，而Hash类型适用于存储复杂的对象。选择使用哪种类型取决于数据的结构和使用场景。

48.Mysql的索引类型，引擎区别

在MySQL中，有多种索引类型和引擎可以选择，下面是索引类型和引擎的区别：

索引类型：

B-tree索引：B-tree索引是MySQL默认的索引类型，适用于大多数场景。它适用于全值匹配、范围查询和排序等操作，可以加快数据的查找速度。
哈希索引：哈希索引适用于等值查询，它将索引值进行哈希计算后存储在哈希表中，可以快速定位到对应的记录。但是，哈希索引不支持范围查询和排序等操作。
全文索引：全文索引适用于对文本进行全文检索，它可以根据关键词在文本中的出现频率进行相关度排序。

引擎：

InnoDB引擎：InnoDB是MySQL的默认存储引擎，支持事务和行级锁，适用于高并发的读写操作。它使用B+树索引来加速查询，支持外键约束和崩溃恢复等功能。
MyISAM引擎：MyISAM是MySQL的另一种存储引擎，不支持事务和行级锁，适用于读操作较多的场景。它使用B-tree索引来加速查询，支持全文索引和压缩等功能。
Memory引擎：Memory引擎将数据存储在内存中，适用于对速度要求较高的操作。它使用哈希索引来加速查询，但是数据存储在内存中，重启服务会导致数据丢失。

总结：
索引类型决定了索引的功能和适用场景，可以根据具体的查询需求选择不同的索引类型。引擎决定了数据的存储方式和支持的功能，可以根据应用场景选择适合的存储引擎。需要根据具体的业务需求和性能要求来选择索引类型和引擎。

49.Mysgl的行锁和表锁的区别

Mysgl的行锁和表锁是两种不同的锁机制，其区别如下：

范围：行锁是对数据库表中的行进行加锁，而表锁是对整个数据库表进行加锁。
并发性：行锁具有更好的并发性能，因为它只锁定需要修改的行，其他行可以同时被访问和修改。而表锁会锁定整个表，其他事务无法同时对表进行修改。
粒度：行锁的粒度更细，只锁定需要修改的行，可以最大程度地减少锁冲突。而表锁的粒度更粗，会锁定整个表，可能导致其他事务等待锁释放。
锁冲突：行锁只会造成行级别的锁冲突，只有需要修改的行被锁定，其他行不受影响。而表锁会造成表级别的锁冲突，其他事务无法同时对表进行修改。
锁开销：行锁的开销相对较小，因为只锁定需要修改的行。而表锁的开销相对较大，因为需要锁定整个表。

综上所述，行锁相对于表锁具有更好的并发性能和粒度控制，但在某些特定场景下，表锁可能更适合。使用行锁还是表锁需要根据具体的业务需求和并发访问情况来决定。

50. Mysql怎么避免死锁

要避免Mysql中的死锁，可以采取以下几种方法：

保持事务的简短和简单：长时间运行的事务更容易引发死锁。尽量将事务的执行时间缩短，减少死锁的可能性。
统一事务访问顺序：如果多个事务都需要访问相同的资源，可以约定一个统一的访问顺序，按照相同的顺序获取锁，避免死锁的发生。
使用合适的事务隔离级别：不同的事务隔离级别对锁的使用有所不同。根据业务需求，选择合适的隔离级别，可以减少死锁的概率。
尽量减少锁的持有时间：尽量在需要修改数据时才获取锁，尽快释放锁，减少锁的持有时间，可以减少死锁的发生。
使用索引优化查询：合理使用索引可以提高查询效率，减少锁的竞争，降低死锁的风险。
分解大事务：将大事务拆分成多个小事务，可以减少事务的冲突，降低死锁的概率。
监控和处理死锁：通过Mysql的日志或者死锁监控工具，及时发现和处理死锁，避免死锁的持续发生。

综上所述，通过控制事务的执行时间、统一访问顺序、优化查询和合理使用事务隔离级别等方法，可以有效地避免Mysql中的死锁问题。

53.为啥jdk8之后hashMap要把链表转为红黑树

在JDK 8之前，HashMap使用的是数组+链表的方式来解决哈希冲突。然而，当链表长度过长时，会导致查找效率降低，因为链表的查找时间复杂度是O(n)，其中n是链表的长度。

为了解决这个问题，JDK 8引入了红黑树作为链表的替代结构，当链表长度超过一定阈值（默认为8）时，会将链表转换为红黑树。红黑树是一种平衡二叉搜索树，它的查找、插入和删除操作的时间复杂度都是O(log n)，相比于链表，红黑树的性能更好。

通过将链表转换为红黑树，可以在一定程度上提高HashMap的性能，尤其是在有大量元素的桶中。而且，红黑树的平衡性能也能够保证在最坏情况下，查找、插入和删除操作的时间复杂度仍然是O(log n)。

需要注意的是，并不是所有的链表都会被转换为红黑树，只有当链表长度超过一定阈值时，才会进行转换。而在删除操作或者红黑树节点数量减少到一定程度时，也会将红黑树转换回链表结构，以节省内存空间。

综上所述，HashMap在JDK 8之后将链表转换为红黑树的目的是为了提高查找、插入和删除的性能，尤其是在元素数量较多的桶中。

54.synchronized和lock的区别

synchronized和Lock是Java中用于实现线程同步的两种机制，它们有以下区别：

使用方式：synchronized是Java内置的关键字，通过在方法或代码块上加上synchronized关键字来实现同步。而Lock是一个接口，需要通过其实现类（如ReentrantLock）来创建锁对象，并在代码中显式地调用lock()和unlock()方法来实现同步。
锁的获取和释放：synchronized关键字在获取锁时会自动获取，并在代码块执行完毕后自动释放锁。而Lock需要手动调用lock()方法获取锁，并在合适的地方调用unlock()方法释放锁。
锁的灵活性：synchronized是非公平锁，多个线程争抢锁时，无法控制哪个线程能够获取到锁。而Lock可以选择公平锁或非公平锁，可以通过构造函数或方法来指定。
锁的可重入性：synchronized是可重入锁，同一个线程可以多次获取同一个锁，而不会出现死锁。Lock也是可重入锁，但需要手动控制。
条件变量的支持：Lock提供了条件变量（Condition），可以方便地实现线程的等待和唤醒操作，而synchronized没有直接对应的功能。
性能：在低并发的情况下，synchronized的性能可能更好，因为它是Java内置的关键字，底层由JVM直接支持。而在高并发的情况下，Lock的性能可能更好，因为它提供了更细粒度的控制和灵活性。

综上所述，synchronized是一种简单易用的内置锁机制，适用于大部分的同步需求；而Lock提供了更多的灵活性和功能，适用于复杂的同步场景，但使用时需要手动管理锁的获取和释放。

55.线程的生命周期

线程的生命周期可以分为以下几个阶段：

新建（New）：当创建一个线程对象时，线程处于新建状态。
就绪（Runnable）：当调用线程的start()方法后，线程进入就绪状态。处于就绪状态的线程已经具备了运行的条件，但还未获得CPU执行权。
运行（Running）：当线程获得CPU执行权后，进入运行状态，开始执行run()方法中的代码。
阻塞（Blocked）：线程在运行时，可能由于某些原因（如等待I/O操作完成、等待获取锁等）而被阻塞。当满足某些条件后，线程将解除阻塞状态。
等待（Waiting）：线程通过调用Object的wait()方法、Thread的join()方法或LockSupport的park()方法等，进入等待状态。等待状态的线程需要其他线程的唤醒才能继续执行。
超时等待（Timed Waiting）：线程通过调用Thread的sleep()方法、Object的wait(long)方法、Thread的join(long)方法或LockSupport的parkNanos()方法等，进入超时等待状态。在指定的时间内，线程会自动唤醒。
终止（Terminated）：线程执行完run()方法中的代码或者发生异常而终止后，进入终止状态。

需要注意的是，线程的状态可以相互转换，例如一个线程可以从就绪状态转换到运行状态，又可以从运行状态转换到阻塞状态或等待状态。线程的状态转换是由操作系统的调度器和Java虚拟机共同协调完成的。

56.有没有了解JVM

是的，我了解JVM（Java虚拟机）。JVM是Java程序的运行环境，它负责将Java字节码（.class文件）转换为机器码并执行。以下是关于JVM的一些重要概念：

类加载器（Class Loader）：负责将字节码文件加载到内存中，并生成对应的Class对象。
运行时数据区域（Runtime Data Areas）：JVM将内存划分为不同的区域，包括方法区、堆、虚拟机栈、本地方法栈和程序计数器等。
方法区（Method Area）：用于存储已加载的类信息、常量、静态变量、即时编译器编译后的代码等。
堆（Heap）：用于存储对象实例，是Java程序中动态分配内存的区域。
虚拟机栈（VM Stack）：每个线程在运行时会创建一个对应的虚拟机栈，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
本地方法栈（Native Method Stack）：用于执行本地方法（非Java代码）。
程序计数器（Program Counter）：记录当前线程执行的字节码指令地址。
垃圾回收（Garbage Collection）：JVM提供自动内存管理机制，通过垃圾回收器回收无用的对象，释放内存空间。
即时编译（Just-In-Time Compilation）：JVM在运行时将字节码转换为机器码的过程，提高代码的执行效率。
类加载机制（Class Loading）：JVM使用双亲委派模型加载类，通过ClassLoader加载器层次结构查找和加载类。

JVM是Java平台的核心组件，它提供了跨平台的特性，使得Java程序可以在不同的操作系统和硬件平台上运行。了解JVM的工作原理和机制对于理解Java程序的运行和性能优化非常重要。

57.数据库的优化

数据库优化是指通过各种手段和技术来提高数据库的性能和效率，以满足业务需求和用户体验。下面列举一些常见的数据库优化技术和方法：

数据库设计优化：
- 合理设计表结构，避免冗余和重复数据。
- 选择合适的数据类型，减少存储空间和提高查询效率。
- 建立适当的索引，加快查询速度。
- 使用分区表或分表技术，提高查询和操作的效率。
- 正确选择主键和外键，保证数据完整性和一致性。
查询优化：
- 编写高效的SQL语句，避免全表扫描、多表关联等性能低下的操作。
- 使用合适的索引，加速查询和排序操作。
- 避免使用过多的子查询和复杂的连接操作。
- 合理使用缓存，减少数据库的访问次数。
- 使用批量操作和分页查询，减少网络传输和数据库负载。
硬件和配置优化：
- 根据数据库的负载情况，合理配置硬件资源，包括CPU、内存、磁盘等。
- 调整数据库的参数和配置，包括缓冲区大小、并发连接数、日志等。
- 使用RAID技术提高磁盘性能和容错能力。
- 使用数据库集群和分布式架构，提高可用性和扩展性。
数据库性能监控和调优：
- 定期监控数据库的性能指标，包括CPU利用率、内存使用、磁盘IO等。
- 使用性能分析工具，分析慢查询和瓶颈，找出优化的方向。
- 根据实际情况调整数据库的配置和参数，优化SQL语句和索引。
- 针对特定的业务场景，进行针对性的优化和调整。

需要注意的是，数据库优化是一个持续的过程，需要根据实际情况进行不断地监控、分析和调整。同时，不同的数据库系统和版本可能有不同的优化方法和技巧，需要根据具体的数据库系统来选择合适的优化策略。

59.sql的优化，引申到索引失效

SQL优化是指通过调整SQL语句、数据库设计和索引等方式，提高数据库查询和操作的性能。而索引失效是指数据库查询中使用了索引，但由于某些原因导致索引无法发挥作用，从而降低了查询的性能。

索引失效的原因有多种，下面列举了一些常见的情况：

数据库查询条件中使用了函数，如使用了字符串函数、日期函数等，这会导致索引失效。因为在查询时，数据库需要对每一条记录进行函数计算，无法使用索引进行加速。
数据库查询条件中使用了运算符，如使用了“!=”、“<>”、“NOT IN”等，这也会导致索引失效。因为这些运算符会导致数据库无法使用索引进行加速。
数据库查询条件中使用了OR操作符，如使用了“OR”连接多个条件，这会导致索引失效。因为OR操作符会导致数据库无法使用索引进行加速。
数据库表中的数据分布不均匀，导致索引失效。例如，某个索引的值只有两个，这时使用该索引查询时效果不明显，数据库可能会选择全表扫描。

为了避免索引失效，可以采取以下措施：

尽量避免在查询条件中使用函数和运算符，尽量将条件写成简单的比较操作，这样数据库可以使用索引进行加速。
尽量避免使用OR操作符，可以将OR条件拆分成多个子查询，然后使用UNION操作符将结果合并。
对于数据分布不均匀的情况，可以考虑重新设计索引或者使用分区表等方式来改善。
定期分析数据库的查询执行计划，找出索引失效的原因，并进行相应的调整。

总之，索引失效是数据库查询性能下降的常见原因之一，通过合理的SQL优化和索引设计，可以避免或者减少索引失效，提高数据库查询性能。
慢查询日志以及explain查看sql语句的执行时间以及使用到的索引

60.redis的持久化

Redis是一个内存数据库，它的数据通常是存储在内存中的。然而，为了保证数据的持久性和可靠性，Redis提供了两种持久化方式：RDB持久化和AOF持久化。

RDB持久化：
- RDB持久化是将Redis的数据以快照的形式保存到磁盘上的一个二进制文件中。
- RDB持久化可以通过配置文件中的save选项来设置自动触发的时间点，也可以通过命令手动执行。
- RDB持久化适合用于备份、灾难恢复和数据迁移等场景。
- RDB持久化的缺点是在发生故障时可能会丢失最后一次快照之后的数据。
AOF持久化：
- AOF持久化是将Redis的写操作以日志的形式追加到一个文件中。
- AOF持久化可以通过配置文件中的appendonly选项来开启。
- AOF持久化记录了Redis的操作命令，因此在恢复时可以按照顺序重新执行命令来还原数据。
- AOF持久化的缺点是文件大小可能会比较大，恢复速度相对较慢。

Redis还提供了混合持久化的方式，即同时使用RDB持久化和AOF持久化。可以通过配置文件中的相关选项来设置。

在实际应用中，可以根据需求和场景选择适合的持久化方式。如果对数据的完整性要求较高，可以选择AOF持久化；如果对数据的实时性要求较高，可以选择RDB持久化；如果对数据的可靠性和实时性都有要求，可以选择混合持久化。同时，还可以通过设置不同的触发条件和策略来控制持久化的频率和方式。

RDB（Redis Database）持久化是Redis的一种数据持久化方式，它将Redis的数据以快照的形式保存到磁盘上的一个二进制文件中。下面是RDB持久化的底层原理：

触发条件：RDB持久化可以通过配置文件中的save选项来设置自动触发的时间点，也可以通过命令手动执行。当满足触发条件时，Redis会执行RDB持久化操作。
快照生成：当RDB持久化触发时，Redis会fork出一个子进程，由子进程负责生成快照。生成快照的过程中，Redis会将当前数据集的副本写入到一个临时文件中。
写入过程：在生成快照的过程中，Redis会阻塞所有的写操作，以确保快照的一致性。所有的写操作都会被缓存起来，等待快照生成完成后再执行。
文件保存：当快照生成完成后，Redis会用新的快照文件替换掉旧的快照文件，以保证数据的完整性。同时，Redis还可以通过设置不同的文件名来实现多个快照文件的备份和历史版本的恢复。
恢复过程：在Redis启动时，会检查是否存在RDB文件，如果存在，则会读取RDB文件并将数据加载到内存中，完成数据的恢复。

RDB持久化的优点是生成的快照文件紧凑且易于备份，恢复速度相对较快。但缺点是在发生故障时可能会丢失最后一次快照之后的数据。

需要注意的是，RDB持久化是一个全量备份的过程，因此在数据量较大时可能会对性能产生影响。为了减少持久化对性能的影响，可以通过合理设置触发条件、使用压缩算法和多线程等方式进行优化。

61.mq消息确认机制

RabbitMQ消息确认机制指的是在消息传递过程中，发送方发送消息后，接收方需要对消息进行确认，以确保消息被正确地接收和处理。RabbitMQ的消息确认机制分为两种：

生产者确认机制：生产者发送消息后，需要等待RabbitMQ服务器的确认消息，以确保消息已经被成功地发送到RabbitMQ服务器。如果RabbitMQ服务器没有收到消息或者消息发送失败，生产者会收到一个确认消息，从而可以进行重发或者其他处理。

消费者确认机制：消费者接收到消息后，需要向RabbitMQ服务器发送确认消息，以告诉服务器已经成功地接收并处理了该消息。如果消费者没有发送确认消息，RabbitMQ服务器会认为该消息没有被正确地处理，从而会将该消息重新发送给其他消费者进行处理。

在RabbitMQ中，消息确认机制是通过ACK机制来实现的。ACK代表Acknowledgement，即确认消息。当消息发送方发送消息后，接收方需要向消息发送方发送ACK消息，以表示已经成功地接收和处理了该消息。如果消息发送方没有收到ACK消息，就会认为该消息没有被正确地处理，从而进行重发或者其他处理。

总之，RabbitMQ的消息确认机制可以保证消息的可靠性，从而提高系统的稳定性和可靠性。

62.SpringCloud的组件

springcloud五大组件：

1、注册中心组件（服务治理）：Netflix Eureka；

2、负载均衡组件：Netflix Ribbon，各个微服务进行分摊，提高性能；

3、熔断器组件（断路器）：Netflix Hystrix，Resilience4j ；保护系统，控制故障范围；

4、网关服务组件：Zuul，Spring Cloud Gateway；api网关，路由，负载均衡等多种作用；

5、配置中心：Spring Cloud Config，将配置文件组合起来，放在远程仓库，便于管理；

63.如何保证分布式事务的一致性

保证分布式事务的一致性是分布式系统设计中的一个重要挑战。以下是几种常见的保证分布式事务一致性的方法：

两阶段提交（Two-Phase Commit, 2PC）：
- 2PC是一种经典的分布式事务协议，它通过协调者和参与者的角色来保证事务的一致性。
- 在2PC中，协调者首先询问所有参与者是否可以提交事务，然后根据参与者的响应决定是否进行提交或回滚操作。
- 2PC的优点是简单易用，能够保证事务的一致性，但缺点是存在阻塞和单点故障的问题。
补偿事务（Compensating Transaction）：
- 补偿事务是一种基于补偿操作的分布式事务处理方法。
- 在补偿事务中，每个参与者在执行事务操作之前，会注册一个补偿操作。如果事务失败，协调者会向参与者发送补偿请求，参与者执行相应的补偿操作来回滚事务。
- 补偿事务的优点是简单可靠，能够容忍部分错误，但缺点是需要设计和实现补偿操作，增加了开发和维护的复杂性。
基于消息的最终一致性（Eventual Consistency）：
- 基于消息的最终一致性是一种松散的一致性模型，通过异步消息传递来解决分布式事务问题。
- 在该模型中，每个参与者在执行事务操作后，将操作结果发布为消息，并由消息中间件异步传递给其他参与者。参与者根据接收到的消息来更新自己的状态，最终达到一致性。
- 基于消息的最终一致性的优点是高性能和可扩展性，但缺点是无法即时保证一致性，需要根据业务需求进行权衡。

除了以上方法外，还可以使用分布式事务协调器（如XA协议）或采用分布式事务处理框架（如TCC事务模型）等方式来保证分布式事务的一致性。选择合适的方法需要根据实际业务需求、系统规模和可用技术等因素进行综合考虑。同时，需要注意分布式事务的性能和可靠性之间的权衡，避免过度依赖分布式事务导致性能下降。

64.和别的公司对接接口，咋保证数据的安全

与其他公司对接接口时，确保数据的安全是非常重要的。以下是一些常见的方法和措施，可以帮助保证数据的安全：

使用安全的通信协议：确保与其他公司之间的通信使用安全的协议，如HTTPS。HTTPS通过SSL/TLS加密通信，可以防止数据在传输过程中被窃听或篡改。
身份认证与授权：在接口对接过程中，进行身份认证和授权是保证数据安全的重要步骤。使用安全的认证机制，如OAuth、API密钥、数字证书等，确保只有授权的用户或系统可以访问接口。
数据加密：对于敏感数据，可以在存储和传输过程中进行加密。可以使用对称加密或非对称加密算法来对数据进行加密，确保即使数据泄露也无法被解读。
防止攻击：采取一些防护措施来防止常见的攻击，如跨站脚本攻击（XSS）、SQL注入、CSRF攻击等。对输入数据进行合理的验证和过滤，确保数据的完整性和安全性。
监控与日志记录：建立完善的监控系统和日志记录机制，及时发现异常情况和安全事件。通过监控和日志分析，可以及时响应和处理安全问题。
安全审计与合规性：定期进行安全审计，检查接口对接过程中的安全性。确保符合相关的合规性要求和数据保护法规。
安全培训与意识：加强员工的安全意识和培训，提高对数据安全的重视程度。通过培训和教育，帮助员工识别和应对安全威胁。

总之，确保与其他公司对接接口的数据安全，需要综合考虑通信安全、身份认证、数据加密、防止攻击、监控与日志、安全审计与合规性、安全培训等多个方面的措施。这样可以有效降低数据泄露和安全风险，保护数据的机密性、完整性和可用性。

65. Redis有三种过期策略：

定期删除：Redis默认使用的是定期删除策略。在这种策略下，Redis会每隔一段时间（由配置参数hz决定，默认为10）随机选择一些设置了过期时间的键进行删除。这种策略的优点是对CPU友好，缺点是可能会导致过期键的删除不及时。
惰性删除：当客户端访问一个过期键时，Redis会检查键是否过期，如果过期则删除键并返回空结果。这种策略的优点是能够保证过期键的及时删除，缺点是对CPU不友好。
定期删除与惰性删除结合：Redis实际上是将定期删除和惰性删除结合起来使用的。定期删除策略可以保证过期键的删除，而惰性删除策略则可以减轻定期删除策略的压力。这种策略的优点是综合了前两种策略的优点，缺点是CPU开销较大。

可以通过配置参数maxmemory-policy来设置Redis的过期策略，默认为volatile-lru，即使用定期删除和惰性删除结合的策略。还可以通过配置参数maxmemory-samples来设置每次定期删除操作中随机选择的键的数量，默认为5。
优缺点
每一种过期策略都有其优点和缺点，下面是每种过期策略的优缺点：

定期删除策略：
- 优点：对CPU友好，删除操作分散在多个时间点进行，不会对CPU造成过大的负担。
- 缺点：可能会导致过期键的删除不及时，部分过期键可能会在下次定期删除之前一直存在。
惰性删除策略：
- 优点：能够保证过期键的及时删除，不会出现过期键在内存中一直存在的情况。
- 缺点：对CPU不友好，每次访问过期键都需要进行过期检查，可能会增加CPU的负担。
定期删除与惰性删除结合策略：
- 优点：综合了前两种策略的优点，既能保证过期键的删除，又能减轻定期删除策略的压力。
- 缺点：CPU开销较大，需要进行定期删除和惰性删除两种操作，可能会对CPU造成较大的负担。

选择适合的过期策略取决于具体的应用场景和需求。如果对实时性要求较高，可以使用惰性删除策略；如果对CPU友好性要求较高，可以使用定期删除策略；如果兼顾实时性和CPU友好性，可以使用定期删除与惰性删除结合策略。此外，还可以根据实际情况进行调优，如调整定期删除的频率和每次删除的键数量等。

66.redis基础原理

Redis（Remote Dictionary Server）是一个开源的内存数据库，它以键值对的形式存储数据，并支持多种数据结构。Redis的基础原理如下：

内存存储：Redis将数据存储在内存中，这使得它具有非常高的读写性能。Redis还可以将数据持久化到磁盘上，以便在重启后恢复数据。
单线程模型：Redis采用单线程模型，所有的读写操作都是在一个线程中完成的。这样可以避免多线程的竞争和锁的开销，提高了数据访问的效率。
基于事件驱动的异步IO：Redis使用事件驱动的异步IO模型，通过监听文件描述符上的事件来处理客户端请求。这样可以在单线程中同时处理多个客户端请求，提高了并发性能。
数据结构支持：Redis支持多种数据结构，包括字符串、列表、集合、有序集合、哈希等。每种数据结构都有相应的操作命令，可以对数据进行增删改查等操作。
持久化机制：Redis提供了两种持久化机制，即RDB（Redis Database）和AOF（Append Only File）。RDB是将当前数据集的快照保存到磁盘上，而AOF是将写操作追加到文件中。这两种机制可以根据需要选择，用于数据的持久化和恢复。
主从复制：Redis支持主从复制机制，可以将主节点上的数据复制到多个从节点上。主节点负责写操作，而从节点负责读操作，这样可以提高系统的读写性能和可用性。
高可用性：Redis提供了哨兵机制和集群机制来实现高可用性。哨兵机制通过监控主节点的状态来自动进行主从切换，而集群机制可以将数据分片存储在多个节点上，提供更高的可扩展性和容错性。

通过以上的基础原理，Redis实现了高性能、高可用性和丰富的数据结构，成为了一个非常流行的缓存和数据库解决方案。

67. redis内存数据淘汰策略

Redis使用内存数据淘汰策略来处理内存不足的情况，以保证系统的稳定性。以下是Redis内存数据淘汰策略的几种常见方式：

LRU（Least Recently Used）：最近最少使用策略。Redis会优先淘汰最近最少被访问的键，即最近一段时间内没有被读写的键。
LFU（Least Frequently Used）：最不经常使用策略。Redis会优先淘汰访问次数最少的键，即一段时间内被访问次数最少的键。
Random：随机淘汰策略。Redis会随机选择一些键进行淘汰，这种策略相对简单，但不保证淘汰的键是最少使用的。
TTL（Time To Live）：过期时间策略。当键设置了过期时间时，Redis会根据过期时间来淘汰键。过期时间较早的键会被优先淘汰。
Maxmemory-policy：Redis还提供了一种自定义的淘汰策略，通过设置maxmemory-policy参数来指定。可以根据需求自定义淘汰策略，如根据键的权重、访问时间等进行淘汰。

需要注意的是，Redis的内存数据淘汰策略通常只在内存不足时才会触发，即当内存使用达到maxmemory设置的阈值时，Redis会根据淘汰策略来选择需要淘汰的键。同时，淘汰策略也可以通过配置参数maxmemory-policy来进行调整。

68. JAVA的异常分类

在Java中，异常分为三个主要的类别：检查异常（Checked Exception）、运行时异常（RuntimeException）和错误（Error）。

检查异常（Checked Exception）：
- 这些异常在代码编译时会被检查，必须在代码中进行捕获或声明抛出。
- 检查异常一般表示外部条件或资源不可用、无效的输入等情况，需要在代码中进行适当的处理。
- 例如：IOException、SQLException等。
运行时异常（RuntimeException）：
- 这些异常在代码编译时不会被检查，可以选择捕获或声明抛出，但不是强制要求。
- 运行时异常通常表示程序逻辑错误、非法参数传递等情况，可以通过改进代码来避免。
- 例如：NullPointerException、ArrayIndexOutOfBoundsException等。
错误（Error）：
- 这些异常表示严重的系统错误或资源耗尽等情况，一般无法通过代码来恢复。
- 错误一般不需要捕获或声明抛出，通常由JVM或底层系统自动处理。
- 例如：OutOfMemoryError、StackOverflowError等。

在Java中，异常处理使用try-catch-finally语句块来捕获和处理异常。对于检查异常，必须在代码中显式地捕获或声明抛出；对于运行时异常，可以选择捕获或声明抛出，但不是强制要求；而对于错误，一般不需要进行处理。异常处理的目的是优雅地处理异常情况，提高程序的健壮性和可靠性。

69.在分布式缓存中，保持数据的一致性是一个重要的问题。

由于分布式缓存中的数据可能分布在多个节点上，因此需要采取一些措施来确保数据的一致性。

以下是几种常见的分布式缓存数据一致性的方法：

缓存失效策略：可以通过设置适当的缓存失效时间来保证数据的一致性。当数据发生更新时，可以将缓存失效，下次请求时重新从数据库或其他数据源获取最新数据。
读写操作的顺序：在进行写操作之前，先进行读操作，以确保获取到最新的数据。这样可以避免在写操作之前读到过期的数据。
缓存更新策略：当数据发生更新时，需要及时更新缓存。可以采用同步更新或异步更新的方式，确保缓存中的数据与数据库中的数据保持一致。
分布式锁：使用分布式锁来确保在更新缓存时只有一个线程或节点进行操作，避免并发更新导致数据不一致。
事件驱动的更新：使用发布-订阅模式或消息队列来实现数据的更新通知。当数据发生更新时，通过发布消息的方式通知其他节点更新缓存。
版本控制：为每个缓存数据引入版本号或时间戳，当更新数据时，更新版本号或时间戳。在读取缓存数据时，比较版本号或时间戳，如果不一致则重新从数据源获取最新数据。
一致性哈希算法：使用一致性哈希算法来分配缓存数据到不同的节点，当节点发生变化时，尽量保持数据的分布不变，从而减少数据迁移和一致性问题。

以上方法可以根据具体的应用场景和需求选择和组合使用，以实现分布式缓存数据的一致性。需要根据具体情况权衡一致性和性能，选择适合的方案。

70 依懒注入的方式

依赖注入（Dependency Injection）是一种设计模式，其目的是将对象的创建和它所依赖的对象的创建解耦，从而提高代码的可测试性、可维护性和可扩展性。

依赖注入有三种常见的方式：

构造函数注入（Constructor Injection）：通过构造函数将依赖的对象传递给被依赖的对象。在被依赖对象的构造函数中声明依赖的对象作为参数，并保存为成员变量。这种方式可以保证依赖关系在对象创建时就被建立。
属性注入（Property Injection）：通过属性或者setter方法将依赖的对象注入到被依赖的对象中。在被依赖对象中声明一个属性或者setter方法来接收依赖的对象。这种方式可以在对象创建后动态地注入依赖。
接口注入（Interface Injection）：通过接口的方法将依赖的对象注入到被依赖的对象中。被依赖对象实现一个接口，在接口中声明一个方法来接收依赖的对象。这种方式在对象创建后动态地注入依赖，并且可以在运行时更改依赖。

依赖注入的方式可以根据具体的需求和框架选择合适的方式来实现。无论使用哪种方式，依赖注入都可以提高代码的灵活性和可维护性，使得对象之间的关系更加清晰和解耦。

71 .不同的数据类型在计算机内存中占用的字节数是不同的。以下是一些常见数据类型在常见编程语言中的字节大小：

布尔类型（bool）：通常占用1个字节。
字符类型（char）：通常占用1个字节。
整数类型：
- 字节类型（byte）：通常占用1个字节。
- 短整数类型（short）：通常占用2个字节。
- 整数类型（int）：通常占用4个字节。
- 长整数类型（long）：通常占用8个字节。
浮点数类型：
- 单精度浮点数类型（float）：通常占用4个字节。
- 双精度浮点数类型（double）：通常占用8个字节。
指针类型（pointer）：在32位系统上通常占用4个字节，在64位系统上通常占用8个字节。
结构体类型（struct）：根据结构体的成员变量类型和对齐规则，占用的字节数可能会有所不同。
数组类型：根据数组元素类型和数组长度，占用的字节数会有所不同。

需要注意的是，不同的编程语言和不同的编译器可能会有一些差异，上述字节大小仅供参考。在实际开发中，可以使用sizeof运算符或者编程语言提供的类型大小查询函数来获取具体的字节大小。

72.如何开启慢查询日志

找到数据库的配置文件：根据你使用的数据库类型，找到对应的配置文件。通常，MySQL的配置文件是my.cnf，PostgreSQL的配置文件是postgresql.conf，Oracle的配置文件是init.ora等。

打开配置文件：使用文本编辑器打开数据库的配置文件。

找到慢查询日志相关的配置项：在配置文件中，查找与慢查询日志相关的配置项。具体的配置项名称会因数据库类型而有所不同，以下是一些常见的配置项名称：

MySQL：

slow_query_log：设置为1或者ON，表示开启慢查询日志。
slow_query_log_file：指定慢查询日志文件的路径和名称。
修改配置项：根据需要，修改相应的配置项的值。将慢查询日志相关的配置项设置为适当的值，如开启慢查询日志、设置慢查询阈值、指定日志文件路径等。

保存配置文件：保存修改后的配置文件。

重启数据库：重启数据库，使配置文件的修改生效。

查看慢查询日志：等待一段时间后，可以查看慢查询日志文件，其中记录了执行时间超过阈值的查询语句和相关信息。

需要注意的是，不同的数据库类型和版本可能会有一些差异，上述步骤仅供参考。在实际操作中，可以参考数据库的官方文档或者搜索相关教程来获取具体的配置方法。

73. 哈希（Hash）和B+树（B+ Tree）

哈希（Hash）和B+树（B+ Tree）加粗样式都是常见的数据结构，用于在计算机中存储和管理数据。它们在不同的场景下具有不同的特点和适用性。

哈希是一种将数据映射到固定大小的散列值（哈希值）的技术。哈希表是基于哈希函数实现的数据结构，它使用哈希函数将键映射到存储位置。哈希表具有快速的插入、删除和查找操作，平均情况下的时间复杂度为O(1)。然而，哈希表不适用于范围查询，因为哈希函数的映射是无序的，所以无法按照键的顺序进行检索。

B+树是一种平衡的树型数据结构，用于组织和管理有序数据。B+树具有以下特点：

所有的数据都存储在叶子节点上，非叶子节点仅用于索引。
叶子节点之间按照顺序连接，方便范围查询。
B+树具有较高的填充因子，减少了I/O操作。
B+树的高度相对较低，因此查找效率高。

B+树适用于需要范围查询的场景，例如数据库索引。B+树的查询时间复杂度为O(log n)，其中n是数据的大小。B+树还适用于磁盘存储，因为它的节点大小通常与磁盘块大小相匹配，减少了磁盘读取的次数。

在选择哈希或B+树时，需要根据具体的需求和场景进行权衡。如果需要快速的插入、删除和查找操作，并且不需要范围查询，可以选择哈希。如果需要范围查询和高效的磁盘存储，可以选择B+树。有时候，也可以将哈希和B+树结合使用，例如使用哈希索引加速B+树的查找。

面试题精简(chatGPT解答不一定全对)

面试题

1.重写和重载有什么区别?

2.hashmap底层数据结构?扩容原理？

3.有String、StringBuffer 和 StringBuilder有什么区别?

4.数组默认长度?

5.每次扩容长度?

6.hashmap什么场景下进化成红黑树?

7.创建线程的方式?

8.线程池有了解吗?

9.线程池默认参数?

10.hashmap元素是头插还是尾插?

11.什么是java类加载?

12.java中类加载器有哪些?

13.乐观锁和悲观锁的区别?如何实现？

14.线程池如何提升性能?

15.使用乐观锁如何实现超卖现象?

16.SQL中幻读和读已提交?

17.redis主要使用场景?

18.如何给给字符串创建索引?

19.SQL事务和分布式事务的区别?

20.Intger能不能用==比较大小?

21.sql隔离级别?

22.并发，如何解决？

22.1分布式中的高并发如何解决？

22.2.什么是分布式事务？

22.3 RedissonClient 分布式锁

23.微服务的中间件

24. mq的作用？

24.1 消息持久化

24.2.消息确认机制

25.nacos的作用

26.一个包装类型和一个基本类型能够用==来比较吗？

27.sql优化

28.乐观锁超卖

29、基本的数据类型

30.简单说下集合，

30.1hashmap的底层

31、HashMap 和 Hashtable 有什么区别？

32、ConcurrentHashMap如何保证同步

33、Stream流的原理，常用方法

34、Mybatis的核心技术

34.1 MyBatis的三级缓存

35、多表联查left和right的区别

36、简单说下IOC和AOP

37、缓存击穿和缓存雪崩，怎么解决缓存击穿

38.乐观锁在实际开发中一般用于那种业务场景

39.redis如何实现互斥锁，主要用到那些命令底层是怎么实现的

40.我有两个方法都加了事务，a调b，b新开事务，怎么一定会发生死锁。

41.我定位到一个慢查询的sql，用explan查看也用到了索引，还是最优索引，此时怎么进行优化

42.RabbitMQ如何解决重复消费?

43.哨兵模式下为什么哨兵要是单数?

44 对Spring的IOC和AOP的理解，IOC底层怎么实现?

45.SpringCloud的几大组件 ?

46.对Redis的理解?

47.Redis的String和Hash有什么区别，

48.Mysql的索引类型，引擎区别

49.Mysgl的行锁和表锁的区别

50. Mysql怎么避免死锁

53.为啥jdk8之后hashMap要把链表转为红黑树

54.synchronized和lock的区别

55.线程的生命周期

56.有没有了解JVM

57.数据库的优化

59.sql的优化，引申到索引失效

60.redis的持久化

61.mq消息确认机制

62.SpringCloud的组件

63.如何保证分布式事务的一致性

64.和别的公司对接接口，咋保证数据的安全

65. Redis有三种过期策略：

66.redis基础原理

67. redis内存数据淘汰策略

68. JAVA的异常分类

69.在分布式缓存中，保持数据的一致性是一个重要的问题。

70 依懒注入的方式

71 .不同的数据类型在计算机内存中占用的字节数是不同的。以下是一些常见数据类型在常见编程语言中的字节大小：

72.如何开启慢查询日志

73. 哈希（Hash）和B+树（B+ Tree）

你可能感兴趣的:(java,开发语言,微服务,面试)