一、平常对SQL优化的了解

1.索引优化

• 创建索引：为常用的查询字段创建索引，可以显著提高查询速度。例如，为订单金额的字段创建索引，可以加速按订单金额的排序操作。

• 优化索引：定期维护索引，避免索引碎片化，保持索引性能。

• 使用覆盖索引：通过创建覆盖索引，可以避免回表操作，进一步提高查询效率。

2.查询语句优化

• 避免使用SELECT *：只查询需要的字段，减少不必要的数据传输和处理。

• 使用有效的WHERE子句：通过精确的条件过滤不需要的记录，减少数据库需要处理的数据量。

• 优化JOIN操作：合理使用JOIN，避免不必要的JOIN操作，减少查询的复杂度。

• 使用LIMIT限制返回数据量：在只需要部分数据的情况下，使用LIMIT限制返回的数据量，提高查询效率。

3.数据表优化

• 优化数据表结构：减少冗余数据，提高查询效率。例如，使用范式化设计减少数据冗余。

• 使用分区表：对于大表，可以使用分区表来提高查询效率。

4.数据库设计优化

使用合适的数据库范式和反范式：根据业务需求选择合适的数据库范式和反范式，平衡数据冗余和查询效率。

5.缓存优化

• 使用缓存技术：通过缓存频繁查询的数据，减少数据库的负担，提高查询效率。

6.硬件和操作系统优化

• 优化硬件和操作系统配置：例如增加内存、优化操作系统等，提高数据库的性能和稳定性。

二、数据库索引有哪些

1.主键索引

• 主键索引是一种特殊的唯一性索引，它用于确保表中每行数据的唯一性。

• 在创建表时，通常会为一个或多个列指定主键索引，以便在检索或更新行时快速定位数据。

• 一个表只能有一个主键索引。

2.唯一性索引

• 唯一性索引用于确保表中某列或某些列的唯一性，这些列可以包括表的主键列。

• 如果在创建唯一性索引时出现重复值，将会导致错误。

• 一个表可以有多个唯一性索引。

3.聚集索引

• 聚集索引是指按照表的主键顺序对表进行排序的索引。

• 在物理存储上，聚集索引决定了表中数据行的存储顺序。

• 一个表只能有一个聚集索引。

4.非聚集索引

• 非聚集索引是除聚集索引以外的任何索引。

• 非聚集索引使用的是一种另外的数据结构，可以让多个索引分别指向相同的数据行。

• 一个表可以有多个非聚集索引。

5.全文索引

• 全文索引是一种特殊的索引，用于对文本数据进行搜索和排序。

• 全文索引使用的是一种全文搜索技术，可以查找文本中的特定单词、短语或其他词组。

6.组合索引

• 组合索引是指基于多个列创建的索引。

• 它可以提高查询效率，并且在查询时可以更快地定位数据。

• 组合索引需要根据实际查询情况来设计，以最大限度地提高查询效率。

7.B+树索引

• B+树索引是最常见的索引类型之一，适用于范围查询和排序操作。

• 在B+树索引中，数据是有序排列的，这有助于加快查询速度。

8.哈希索引

• 哈希索引适用于等值查询，通过哈希函数将键映射到存储位置，实现快速查找。

• 哈希索引不支持范围查询和排序操作。

9.空间索引

• 空间索引用于处理地理空间数据，如点、线和多边形。

• 它有助于加快对地理空间数据的查询和处理速度。

10.函数索引

• 函数索引是基于数据库表中某一列的值通过函数计算得到的索引。

• 它有助于加快对计算结果的查询速度。

三、索引合并和索引下推了解过吗

是的，索引合并（Index Merge）和索引下推（Index Condition Pushdown，ICP）是MySQL数据库中的两种优化技术，它们旨在提高查询效率，减少不必要的数据访问。

索引合并（Index Merge）： 索引合并是MySQL从5.1版本开始引入的一种优化机制。在此机制下，MySQL查询优化器可以在某些特殊情况下同时使用多个索引，而不是仅限于使用一个索引。当查询条件可以分解为多个子条件，并且每个子条件都可以单独使用一个索引时，MySQL会扫描这些索引并将结果集合并。索引合并有以下几种形式：

• 取交集（Intersect）：仅返回所有索引中都存在的记录。

• 取并集（Union）：返回至少在一个索引中存在的记录。

• 排序后取并集（Sort-Union）：对并集结果进行排序后再返回。

索引下推（Index Condition Pushdown，ICP）： 索引下推是MySQL 5.6版本引入的一项优化技术。其主要思想是将原本在服务器层进行的过滤条件推送到存储引擎层进行，从而减少存储引擎层返回给服务器层的数据量。在执行查询时，MySQL会尝试将过滤条件推送到索引中，这样就可以在读取索引条目时立即过滤掉不满足条件的记录，减少回表（读取完整的数据行）的次数。

两者的主要区别在于：

• 索引合并是在多个索引之间进行操作，利用多个索引来优化查询。

• 索引下推是在单个索引内部进行操作，通过优化索引的使用来减少数据访问量。

这两项技术都是MySQL查询优化器为了提高查询性能而采用的方法，它们能够减少磁盘I/O操作，降低查询响应时间，特别是在处理大量数据时。

四、索引最左前缀匹配法则

索引最左前缀匹配法则”是数据库索引优化中的一个重要原则，指的是在联合索引中，查询条件必须从联合索引的最左列开始连续匹配，才能有效利用索引。这个原则有助于数据库系统更有效地利用索引来加速查询操作。

五、索引的优劣势

索引的优势

1.提高查询速度

• 索引类似于书的目录，可以快速定位到需要的数据行，从而显著提高查询速度。

• 特别是对于涉及大量数据的查询，索引能够显著减少查询时间。

2.增强排序和分组操作

• 索引不仅可以加速查询，还可以优化排序和分组操作。

• 当对某一列进行排序或分组时，如果该列上有索引，数据库系统可以更快地完成任务。

3.提高连接操作的效率

• 在数据库中进行表连接操作时，如果连接字段上有索引，可以显著提高连接效率。

• 索引可以帮助数据库系统快速找到连接字段匹配的行。

4.优化数据库性能

• 通过合理使用索引，可以显著降低数据库的I/O操作次数，从而提高整体性能。

• 索引可以减少磁盘扫描的次数，降低数据库的负载。

索引的劣势

1.增加存储开销

• 索引需要占用额外的存储空间，特别是当表中的数据量很大时，索引所占用的空间也会相应增加。

• 这可能会导致数据库系统的整体存储空间需求增加。

2.增加维护成本

• 当对表进行插入、删除或更新操作时，需要同时更新相关的索引。

• 这会增加数据库系统的维护成本，并可能影响这些操作的性能。

3.可能导致索引失效

• 在某些情况下，如使用函数或表达式对索引列进行操作时，可能会导致索引失效。

• 这意味着数据库系统将无法利用索引来加速查询，从而可能导致查询性能下降。

4.过度索引可能导致性能问题

• 如果为表中的每一列都创建索引，可能会导致性能问题。

• 过多的索引会增加数据库系统的负担，降低写入和更新操作的性能。

六、有无实际SQL优化经验

索引优化案例

• 在一个电商系统中，用户经常根据商品名称进行搜索。最初，商品表没有为商品名称列创建索引，导致查询速度很慢。

• 后来，我为商品名称列创建了索引，并重新执行了查询。结果，查询速度显著提高，从原来的几秒钟缩短到了几百毫秒。

七、Join怎么提高查询性能？怎么建索引能够让查询效率最大呢

1.使用合适的索引

• 确保参与JOIN的列都有合适的索引，这是提高JOIN操作性能的关键。索引可以显著减少数据库在JOIN操作中进行全表扫描的需求，从而加快连接速度。

2.选择合适的JOIN类型

• 根据查询需求，选择合适的JOIN类型，如INNER JOIN、LEFT JOIN、RIGHT JOIN等。不同的JOIN类型会对查询性能产生影响。例如，在左表数据量小、右表数据量大时，使用LEFT JOIN可能更合适。

3.限制JOIN操作的数据量

• 在JOIN操作前，先对表进行过滤，减少参与JOIN的数据量。这可以通过在JOIN操作前添加WHERE子句来实现，从而减轻JOIN操作的负担。

4.使用子查询或临时表

• 在某些情况下，将JOIN操作分解为子查询或使用临时表可以提高性能。通过将一部分查询结果先存储到子查询或临时表中，然后再与主表进行JOIN，可以降低查询的复杂度。

5.优化JOIN顺序

• 根据查询条件和数据分布，选择合适的JOIN顺序。这可以通过分析查询执行计划来实现，从而找出最优的JOIN顺序以减少查询开销。

6.使用EXPLAIN分析查询计划

• 使用EXPLAIN语句来分析JOIN查询的执行计划，找出可能存在的问题和优化空间。通过了解MySQL是如何执行查询的，包括使用了哪些JOIN算法、是否使用了索引等，可以对查询进行进一步的优化。

如何建索引让查询效率最大

1.为经常查询的列创建索引

• 如果某个字段经常用来做查询条件，那么为该字段创建索引可以显著提高查询速度。这包括WHERE子句中的条件列、JOIN操作中的连接列等。

2.考虑索引的选择性

• 选择性高的列更适合创建索引。选择性是指列中不同值的数量与总行数的比例。比例越高，选择性越好，索引的效果也越明显。

3.使用联合索引

• 对于经常一起查询的多个列，可以考虑创建联合索引。联合索引可以覆盖多个列，从而在一次查询中利用多个索引列来提高查询性能。但需要注意索引列的顺序，遵循最左前缀匹配原则。

4.避免索引失效

• 在创建索引后，需要避免索引失效的情况。例如，在WHERE子句中对索引列使用函数或进行表达式计算会导致索引失效。此外，还需要注意索引列的数据类型一致性，避免因为数据类型不匹配而导致索引无法使用。

5.定期维护索引

• 随着数据的增删改操作，索引可能会变得不再高效甚至影响查询性能。因此，需要定期维护索引，包括重建索引、优化索引等。这可以通过数据库提供的索引维护工具来实现。

八、JDK8的并行流了解吗

一、并行流的基本概念

并行流是一种利用多线程来加速处理集合数据的机制。它通过将数据分割成多个小块，并在多个线程上并行执行操作，从而提高处理速度。在Java中，可以使用parallel方法将顺序流转换成并行流。

二、并行流的获取方式

并行流可以通过以下两种方式获取：

1. 直接获取并行流

   • 使用parallelStream方法，直接获取并行流。例如，对于一个List集合，可以调用list.parallelStream() 来获取并行流。

2. 将串行流转成并行流

   • 使用parallel方法，将现有的串行流转换成并行流。例如，对于一个串行流stream，可以调用stream.parallel() 来获取并行流。

三、并行流与串行流的效率对比

并行流并不一定总是比串行流快，其性能取决于多种因素：

1. 数据大小

   • 当数据量较小时，由于线程切换和同步的开销，串行流可能更快。只有当数据量较大时，并行流的优势才会显现。

2. 源数据结构

   • 不同的源数据结构对并行流的性能有不同影响。例如，ArrayList和数组支持随机读取，因此更容易被分割成多个小块进行并行处理；而LinkedList等不支持随机读取的数据结构则可能不适合并行流处理。

3. CPU核数

   • 可用的CPU核数越多，并行流能够利用的计算资源就越多，从而可能获得更高的性能提升。

4. 单元处理开销

   • 如果流中每个元素的处理开销很大，那么并行流带来的性能提升就会更明显。

四、并行流的使用注意事项

1. 线程安全问题

   • 并行流在处理过程中可能会使用多个线程，因此需要确保操作的数据结构是线程安全的。例如，在并行流中使用Collectors.toSet() 收集元素时，由于HashSet是线程安全的，因此可以安全地使用；而使用ArrayList等非线程安全的数据结构时，则需要格外小心。

2. 避免不必要的并行化

   • 并非所有情况都适合使用并行流。例如，对于小数据集或处理开销很小的操作，串行流可能更快且更简单。因此，在使用并行流之前，应仔细评估其必要性。

3. 合理设置线程池

   • 在某些情况下，可能需要自定义线程池来管理并行流中的线程。这可以通过设置系统属性java.util.concurrent.ForkJoinPool.common.parallelism 来实现，该属性定义了并行流中线程池的大小。

九、JDK相关的并发工具类了解吗？

是的，JDK提供了丰富的并发工具类，这些工具类集中在java.util.concurrent 包及其子包中。以下是一些常用的并发工具类：

1.Executor框架

• ExecutorService：用于管理线程的执行，可以创建线程池来执行任务。

• Executors：提供了一系列工厂方法来创建不同类型的线程池。

2.Future和Callable

• Callable：代表一个返回结果的计算任务。

• Future：用于表示异步计算的结果。

3.同步器

• CountDownLatch：允许一个或多个线程等待一组事件的完成。

• CyclicBarrier：允许一组线程相互等待，直到所有线程都到达某个公共屏障点。

• Semaphore：控制对某个资源的访问数量。

4.阻塞队列

• BlockingQueue：支持线程安全的队列操作。

• ArrayBlockingQueue：基于数组的阻塞队列，具有固定的大小。

• LinkedBlockingQueue：基于链表的阻塞队列，可以指定容量，也可以不指定，默认为Integer.MAX_VALUE。

• PriorityBlockingQueue：基于优先级的阻塞队列，元素按照优先级顺序出队。

5..原子变量

• AtomicInteger、AtomicLong等：提供原子操作，如原子增加、减少等，适用于轻量级的线程同步。

6.锁

• ReentrantLock：可重入锁，与synchronized相比提供了更高的灵活性和可控制性。

• ReadWriteLock：读写锁，允许多个线程同时读取，但写入时需要独占访问。

7.并发集合

• ConcurrentHashMap：线程安全的哈希表。

• CopyOnWriteArrayList：适用于读多写少的场景，写操作会复制整个底层数组。

8.线程安全集合

• Collections.synchronizedList 、Collections.synchronizedMap 等：将普通集合包装成线程安全的集合。

十、多线程有哪些类可以实现？ 线程池了解哪些？

1.继承Thread类

• 通过创建一个新的类继承自java.lang.Thread 类，并重写其run方法，可以创建一个新的线程。在这个run方法中定义线程要执行的任务。

2.实现Runnable接口

• 通过实现java.lang.Runnable 接口，并重写其run方法，可以创建一个可运行的线程任务。然后，可以通过new Thread(Runnable target)来创建一个新的线程，并将这个可运行的任务传递给线程。

3.实现Callable接口

• java.util.concurrent.Callable 接口类似于Runnable接口，但它允许任务返回一个结果并可能抛出一个异常。要实现一个Callable任务，需要实现其call方法，该方法可以返回一个结果并声明可能抛出的异常类型。然后，可以使用java.util.concurrent.FutureTask 类来包装Callable任务，并通过new Thread(FutureTask<V> task)来创建一个新的线程。

4.使用线程池

• 线程池是一种更高级的线程管理方式，它通过复用线程来减少线程的创建和销毁开销，从而提高性能。Java中的线程池主要通过java.util.concurrent.Executor 接口及其实现类来实现。常用的线程池实现类包括ThreadPoolExecutor和Executors工厂类提供的各种便捷方法（如newFixedThreadPool、newCachedThreadPool、newSingleThreadExecutor、newScheduledThreadPool等）。

十一、JDK8并行流底层Fork/Join和Future机制了解过吗

是的，JDK8的并行流（parallel streams）底层使用了Fork/Join框架和Future机制来实现并行计算。

Fork/Join框架： Fork/Join框架是一个用于并行执行任务的框架，它利用分而治之的策略将一个大任务分割成若干个小任务，然后递归地将小任务分割成更小的任务，直到无法再分割为止。这些小任务会在多个线程上并行执行，最后将结果合并起来得到最终结果。

Fork/Join框架中的关键类包括：

• ForkJoinPool：管理并行任务的执行，它是一个线程池，负责执行ForkJoinTask。

• ForkJoinTask：代表一个可以并行执行的任务，所有并行流操作最终都会被转换成ForkJoinTask。

• RecursiveTask：代表一个有返回值的并行任务，它的compute()方法会返回一个结果。

• RecursiveAction：代表一个没有返回值的并行任务，它的compute()方法不返回任何结果。

Future机制： Future机制用于表示异步计算的结果。在并行流中，每个ForkJoinTask都可以看作是一个异步任务，而并行流操作的结果通常是通过Future对象来获取的。

在并行流中，当你提交一个任务给ForkJoinPool时，ForkJoinPool会负责调度这个任务，并在某个线程上执行它。一旦任务开始执行，你就可以通过Future对象来获取任务的执行结果。

Fork/Join框架和Future机制的结合使得并行流能够在多个线程上并行执行任务，并且能够有效地管理线程之间的协作和数据共享。通过这些机制，并行流能够充分利用多核处理器的优势，提高大数据集处理的效率。

十二、对JVM的了解？垃圾回收器对哪个比较熟悉？

JVM（Java Virtual Machine）是Java程序的运行环境，它提供了一个平台无关的执行环境，使得Java程序可以在任何安装了JVM的平台上运行。

1. Serial收集器：单线程收集器，简单高效，适用于客户端模式。

2. Parallel Scavenge收集器：多线程收集器，专注于最大化吞吐量，适合后台处理任务。

3. Serial Old收集器：Serial收集器的老年代版本，单线程，使用标记-整理算法。

4. ParNew收集器：Parallel Scavenge收集器的多线程版本，专门用于新生代，是唯一能与CMS收集器配合使用的新生代收集器。

5. CMS（Concurrent Mark Sweep）收集器：以获得最短回收停顿时间为目标，使用标记-清除算法，主要用于老年代。

6. G1（Garbage-First）收集器：面向大内存多处理器环境的垃圾收集器，将堆内存分割成多个独立区域，并优先回收垃圾最多的区域。

十三、G1内存分布了解吗

1. Region分区

• 基本单位：G1将堆内存划分为多个大小相同的独立区域（Region），每个Region是一个连续的虚拟内存范围。这是G1内存管理的基本单位。

• 数量与大小：JVM最多可以有2048个Region。Region的大小可以在JVM启动时通过-XX:G1HeapRegionSize参数设置，默认值是堆内存的1/2048。例如，如果堆大小为4096MB，则每个Region的大小为2MB。Region的大小可以在1MB到32MB之间调整，但必须是2的幂。

2. 逻辑分代

• 年轻代（Young Generation）：包括Eden区和两个Survivor区（S0和S1）。在G1中，这些区域不再是由连续的内存块组成，而是由多个Region的集合来逻辑上表示。默认情况下，年轻代占堆内存的5%，但这个比例可以通过-XX:G1NewSizePercent参数设置。在系统运行过程中，JVM会根据需要动态地为年轻代分配更多的Region，但最多不会超过堆内存的60%，这个上限可以通过-XX:G1MaxNewSizePercent参数调整。

• 老年代（Old Generation）：在G1中，老年代也是由多个Region的集合来逻辑上表示。当年轻代中的对象经过多次垃圾收集仍然存活时，它们会被晋升到老年代。

• 永久代/元空间（PermGen/Metaspace）：在Java 8及以后的版本中，永久代被元空间所替代。G1垃圾收集器也适用于元空间的管理，但元空间并不属于堆内存的一部分，而是使用本地内存。

3. Humongous区

• 巨型对象（Humongous Objects）：在G1中，如果一个对象的大小超过了Region大小的50%，则被视为巨型对象。巨型对象默认会被直接分配在老年代，但G1为巨型对象专门划分了一个Humongous区。Humongous区用于存放短期存在的巨型对象，以避免它们直接占用老年代的空间，从而减少Full GC的开销。如果单个Humongous区无法容纳一个巨型对象，G1会寻找连续的Humongous区来存储它。

4. 内存分布的动态性

• 区域功能的动态变化：在G1中，一个Region的区域功能（即它属于年轻代还是老年代）是可以动态变化的。例如，一个Region在某一次垃圾收集时可能属于年轻代，但在下一次垃圾收集时可能就变成老年代了。

5. 内存回收策略

• 优先处理垃圾较多的区域：G1垃圾收集器会根据各个Region中垃圾回收的价值（即垃圾占用的空间大小）来维护一个优先级列表。在每次垃圾收集时，G1会优先处理那些垃圾较多的Region，以减少应用程序的暂停时间。

G1垃圾收集器在内存分布上采用了一种灵活且高效的设计。通过将堆内存划分为多个大小相同的Region，并结合逻辑分代和巨型对象处理机制，G1能够在满足低延迟要求的同时保持高吞吐量。

十四、Spring、SpringBoot挑点擅长的讲讲

Spring框架

核心特性

1. 轻量级：从大小和开销两方面而言，Spring都是轻量的。完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布，并且Spring所需的处理开销也是微不足道的。

2. 控制反转（IoC）：Spring通过控制反转技术促进了松耦合。当应用了IoC，一个对象依赖的其他对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。

3. 面向切面（AOP）：Spring支持面向切面的编程，允许通过分离应用的业务逻辑与系统级服务（例如审计和事务管理）进行内聚性的开发。应用对象只实现它们应该做的业务逻辑，而系统级关注点（如日志或事务支持）则由框架负责。

4. 容器：Spring包含并管理应用对象的配置和生命周期，是一种容器。程序员可以配置每个bean如何被创建、如何相互关联等。

SpringBoot框架

核心特性

1. 简化配置：SpringBoot使用了约定优于配置的理念，通过自动配置和默认配置减少了繁琐的XML配置和代码编写，开发者可以更专注于业务逻辑的实现。

2. 快速搭建：SpringBoot提供了一键式的快速搭建功能，内置了Tomcat等常用插件，开发者只需要添加少量的依赖和配置即可快速搭建起一个应用程序。

3. 微服务支持：SpringBoot提供了丰富的功能和工具，支持构建分布式微服务架构，方便实现服务治理、负载均衡、容错等功能。

总结

Spring和SpringBoot都是Java领域非常流行的框架，它们在各自的领域内都发挥着重要的作用。Spring作为一个全面的、企业应用开发一站式的解决方案，提供了丰富的功能和灵活的配置方式；而SpringBoot则通过简化配置、快速搭建和微服务支持等特点，进一步提高了开发效率和应用的可用性。

十五、Spring启动干了哪些事情，比方说IOC，干了哪些事情到能提供给使用方去使用

1. 加载配置文件

• Spring会读取项目中的配置文件（如applicationContext.xml 或Java配置类），这些配置文件中包含了Bean的定义、AOP的配置、事务管理等关键信息。

2. 创建IoC容器

• Spring使用IoC（控制反转）的设计模式，其核心是一个IoC容器（也称为应用上下文，ApplicationContext）。在启动时，Spring会创建这个容器，用于管理Bean的生命周期和依赖关系。

3. 实例化Bean

• Spring根据配置文件中的定义，通过反射机制实例化每个被声明的Bean对象。这些Bean可以是POJO（Plain Old Java Object）、服务类、数据库访问类等。

4. 处理Bean的依赖注入

• Spring的IoC容器负责处理Bean之间的依赖关系。它会根据Bean的定义和依赖注入的方式（如构造函数注入、Setter方法注入或注解注入），将所需的依赖注入到相应的Bean对象中。

5. 初始化Bean

• Spring提供了Bean初始化和销毁的方法，这些方法可以在Bean实例化后和销毁前被调用。开发者可以通过配置文件或注解来定义这些方法。

6. 处理AOP（面向切面编程）

• Spring的AOP模块允许开发者在不更改业务逻辑代码的情况下，添加额外的处理逻辑（如日志记录、事务管理等）。在启动时，Spring会处理与AOP相关的配置，以便在运行时应用这些切面。

7. 加载其他必要的组件和配置

• Spring启动过程中还会加载其他必要的组件和配置，如JDBC事物管理、ORM框架集成（如Hibernate、MyBatis等）等，这些组件和配置为开发者提供了更加丰富的功能支持。

8. 准备好应用上下文

• 当上述所有任务完成后，Spring会准备好应用上下文，此时开发者就可以通过应用上下文来获取所需的Bean和服务了。

9. 提供给使用方

• 最终，Spring通过其强大的IoC容器和一系列启动过程中完成的任务，为开发者提供了一个易于使用、功能强大的应用开发环境。开发者可以通过应用上下文轻松地获取所需的Bean和服务，从而实现业务逻辑的开发和部署。

十六、Bean从创建到销毁的过程

1. 创建：Spring容器根据配置创建Bean的实例。

2. 填充属性：Spring容器将配置中定义的属性值注入到Bean中。

3. 初始化：容器调用Bean的初始化方法，Bean准备就绪使用。

4. 使用：应用程序开始使用这个Bean，Bean现在可以处理请求并执行其业务逻辑。

5. 销毁：当Bean不再需要时，容器会进行清理工作。对于单例Bean，这个阶段发生在容器关闭时；对于多例Bean，则可能发生在请求结束时或Bean被显式销毁时。

6. 清除：容器执行清理工作，如调用Bean的销毁方法。

十七、在BeanFactory里面的一个Map，这个Map有关注过吗，用什么？HashMap可以吗？

这个Map通常被称为singletonObjects。这个Map在Spring框架中扮演着至关重要的角色，因为它存储了所有单例模式的Bean实例。

对于这个Map的实现，Spring框架默认使用的是ConcurrentHashMap，而不是HashMap。使用ConcurrentHashMap的原因是因为BeanFactory可能在多线程环境中使用，ConcurrentHashMap提供了线程安全的Map操作，确保了在高并发环境下对Bean实例的访问和修改是安全的。

ConcurrentHashMap相对于HashMap的优势在于：

1. 线程安全：ConcurrentHashMap是线程安全的，它允许多个线程并发访问Map而不需要额外的同步。

2. 分段锁：ConcurrentHashMap使用分段锁技术，它将Map分成多个段，每个段有自己的锁，这样可以在并发环境下提供更高的吞吐量。

3. 迭代器弱一致性：ConcurrentHashMap的迭代器提供弱一致性，这意味着迭代器在创建后不会抛出ConcurrentModificationException，但可能会反映Map的并发修改。

在Spring框架中，singletonObjects是存储单例Bean的缓存，它确保了每个Bean的实例只被创建一次，并且在容器中是全局可访问的。这个Map的线程安全性对于确保Spring应用程序在多线程环境中的正确行为至关重要。

十八、Springcloud有了解吗

Spring Cloud是一个基于Spring Boot的微服务开发工具集，它提供了一系列的框架和工具，帮助开发者构建分布式系统的应用程序。旨在简化分布式系统的开发、部署和管理。

十九、Redis了解吗？项目中的实际使用

是的，我了解Redis，它是一个开源的、基于键值对的内存数据结构存储系统，常用于高性能、读写频繁的场景，如缓存、会话存储、消息队列等。Redis支持多种数据类型，包括字符串、列表、集合、散列、有序集合等，并且提供了丰富的原子操作。

在实际项目中，Redis可以用于以下场景：

1. 缓存：Redis常用作数据库的缓存层，可以存储热点数据，减少数据库的访问压力，提高系统性能。

2. 会话管理：在Web应用中，Redis可以用来存储用户的会话信息，实现会话共享。

3. 消息队列：Redis的列表和发布/订阅功能可以用来实现简单的消息队列系统。

4. 计数器：Redis的原子操作可以用来实现高效的计数器，适用于高并发的计数场景。

5. 排行榜：Redis的有序集合可以用来实现排行榜功能，如用户积分、游戏排名等。

6. 分布式锁：Redis可以用来实现分布式锁，保证在分布式系统中数据的一致性和完整性。

7. 限流：Redis的计数器和过期功能可以用来实现限流，防止系统过载。

8. 延迟队列：Redis的有序集合和过期功能可以用来实现延迟队列，用于处理需要在特定时间执行的任务。

9. 数据共享：Redis可以作为数据共享的中间件，不同应用可以通过Redis共享数据。

10. 实时分析：Redis的高性能读写能力使其适用于实时数据分析场景。

在实际使用Redis时，需要注意：

• 数据持久化：虽然Redis是内存数据库，但它提供了数据持久化的功能，可以将内存中的数据保存到磁盘上。

• 内存管理：Redis的内存管理非常重要，需要合理配置最大内存限制和过期策略。

• 连接管理：合理配置连接池参数，如最大连接数、最小空闲连接数等，以提高系统性能。

• 安全性：配置密码认证、防火墙等安全措施，防止未授权访问。

• 高可用性：可以使用Redis Sentinel或Redis Cluster来实现高可用性，确保系统的稳定运行。

二十、Redis的分布式锁

Redis的分布式锁是一种在分布式系统环境下，通过Redis来实现多个节点对共享资源进行互斥访问的同步机制。

1、分布式锁的基本概念

在分布式系统中，由于节点可能位于不同的机器甚至不同的地理位置，传统的锁机制（如Java中的synchronized或ReentrantLock）无法直接应用。因此，需要一种跨进程的锁机制来控制对共享资源的访问，这就是分布式锁的由来。

2、Redis实现分布式锁的原理

Redis实现分布式锁的核心思想是利用Redis的某些原子性操作来实现锁的获取和释放。以下是两种常见的实现方式：

1. 使用SETNX和EXPIRE命令

   • SETNX：SETNX（Set if Not Exists）命令用于在key不存在时设置值。如果key已经存在，则命令执行失败。这个命令可以确保在同一时间只有一个客户端能够获得锁。

   • EXPIRE：EXPIRE命令用于为key设置过期时间。这是为了避免死锁的情况，即使锁的持有者因为某些原因崩溃而没有释放锁，锁也会在一定时间后自动释放。

   然而，这种方式存在一个问题：SETNX和EXPIRE命令是分两步执行的，不是原子操作。如果客户端在执行SETNX命令后崩溃，那么EXPIRE命令可能不会被执行，导致锁无法自动释放。

2. 使用SET命令

   Redis提供了SET命令的扩展参数，可以一次性完成设置key和过期时间的操作。这种方式避免了SETNX和EXPIRE命令之间可能出现的竞态条件。例如，可以使用以下命令：

   SET lock_key unique_value NX PX 30000 

   这条命令表示：如果lock_key不存在，则设置lock_key的值为unique_value，并且设置过期时间为30000毫秒（即30秒）。NX参数表示仅在key不存在时设置值，PX参数表示设置key的过期时间（以毫秒为单位）。

4、分布式锁的使用场景

Redis的分布式锁可以应用于各种需要控制并发访问的场景，如：

• 分布式系统中的库存扣减、订单处理等场景。

• 秒杀、抢购等高并发场景，通过分布式锁来限制同一时间对共享资源的访问量。

• 分布式任务调度系统中，通过分布式锁来确保同一任务在同一时间只有一个节点在执行。

5、Redis分布式锁的注意事项

1. 锁的续期：如果业务逻辑的执行时间可能超过锁的过期时间，需要在业务逻辑执行过程中定期续期锁，以防止锁自动释放。

2. 释放锁的安全性：在释放锁时，需要确保只有锁的持有者才能释放锁。通常的做法是在设置锁时保存一个唯一的标识符（如线程ID或UUID），在释放锁时检查这个标识符是否与当前线程的标识符一致。

3. Redisson等第三方库：除了直接使用Redis命令实现分布式锁外，还可以使用如Redisson等第三方库来简化分布式锁的实现和使用。这些库通常提供了更丰富的功能和更好的性能。

二十一、了解rabbitMQ外其它的消息队列吗

Kafka

• 概述：Kafka最初由LinkedIn开发，是一个分布式流处理平台，用于构建实时数据管道和流应用。

• 特点：

  • 高吞吐量和低延迟，适合处理大量实时数据和高并发的场景。

  • 持久化日志，消息按顺序存储，确保消息的顺序性和一致性。

  • 高可用性和分布式架构，支持分布式部署和水平扩展。

• 适用场景：实时数据处理、大数据分析、日志收集等。

---

一、对公司标准的预期

我希望除了在工作中能够很好地运用自己的知识和技术外,还能对提高我的技术水平,促进公司与自己的良性提高。

公司能提供一个相对自由的环境,在这个环境能,我能自主的运用自己的专长,完成工作目标。

希望同事之间关系融洽，互帮互助

二、给一个表的name字段建立索引，然后select * from table where name is null走索引吗

• 在MySQL中，如果索引字段设置为可以为空（NULL）的情况下，使用isnull进行查询时，是可以使用到索引的，但也存在一些特殊情况。

• 当执行SELECT * FROM table WHERE name IS NULL;时，如果表中的数据量较小或者数据库的优化器认为全表扫描更快，可能不会使用索引。但在一般情况下，是可以使用索引的。然而，如果name字段上有其他限制条件或者与其他操作（如函数操作等）混合时，索引可能会失效。

三、索引里面除了它的顺序会决定能不能走索引外，还有没有其他的因素决定，最重要的因素。

1. 索引类型

• B树索引：适用于大多数查询场景，特别是范围查询和排序操作。

• 哈希索引：适用于等值查询，提供快速的相等搜索，但不支持范围查询和排序功能。

• 全文索引：适用于文本数据的搜索，能够加速复杂文本查询的速度。

• 位图索引：适合处理包含大量重复值或NULL值的列，对于低基数字段特别有效。

2. 索引列的选择性

索引列的选择性是指索引列的不同值与总行数的比值。选择性越高，索引的效果越好。通常选择性在30%~90%之间为最佳。选择性低的列（如性别字段，只有“男”和“女”两个值）可能不适合建立索引，因为索引的选择性不高，查询时可能仍然需要扫描大量行。

3. 查询条件

查询条件中是否包含索引列以及索引列的使用方式会影响索引的使用。如果查询条件不满足索引列的顺序或索引列被用于函数计算等，索引可能会失效。

4. 数据分布

数据的分布情况也会影响索引的使用。例如，如果表中大部分行都是NULL值，那么对于NULL值的查询可能不适合使用B树索引，因为B树索引通常不会为NULL值创建索引项。

5. 数据库优化器的决策

数据库优化器会根据查询的成本、索引的选择性、数据的分布以及统计信息等多个因素来决定是否使用索引。优化器的决策是一个复杂的过程，它旨在找到执行查询的最优路径。

6. 索引的维护代价

过多的索引会增加插入、更新和删除操作的开销。因此，在选择索引时需要权衡索引带来的查询性能提升与数据修改操作的开销。

7. 系统资源

系统的硬件资源（如CPU、内存、磁盘速度）也会影响索引的使用。例如，在内存不足的情况下，数据库系统可能会选择不使用某些索引以避免额外的内存开销。

最重要的因素

在这些因素中，索引列的选择性、查询条件以及数据库优化器的决策可能是最重要的。索引列的选择性决定了索引的效率和必要性；查询条件决定了索引是否能够被利用；而数据库优化器的决策则是一个综合考量的结果，它基于索引的选择性、数据的分布、查询的成本以及系统资源等多个因素来做出最优的查询执行计划。

四、MySQL索引检索的过程中，会用到二分查找吗？在哪个过程用到

MySQL中最常用的索引结构是B+Tree。在B+Tree索引的检索过程中，会用到类似二分查找的思想。

MySQL在索引检索过程中利用了B+Tree结构的有序性，通过类似二分查找的思想来快速定位数据所在的磁盘块（节点），从而提高查询效率。

五、常见的设计模式，像责任链模式有用到过吗？在哪些场景有用到

责任链模式通过解耦请求与处理，使得系统更加灵活和可扩展。通过动态地添加或删除处理节点，可以轻松地调整系统的处理逻辑，而无需修改现有的代码结构。同时，责任链模式也使得请求的处理过程更加清晰和易于维护。

场景：

1.权限校验

• 在用户登录或访问受限资源时，需要进行一系列的权限校验。这些校验步骤可以看作责任链中的不同节点，依次进行验证，直到所有验证都通过或某个验证失败为止。例如，可能需要校验用户是否存在、密码是否正确、用户是否锁定、用户是否被禁用等。

2.数据校验和转换

• 在数据接收或发送过程中，可能需要对数据进行一系列的校验和转换操作。这些操作可以看作责任链中的不同节点，依次对数据进行处理，直到数据满足要求或处理完成。

3.消息过滤

• 在消息传递系统中，可能需要对消息进行一系列的过滤操作，如过滤垃圾邮件、过滤敏感词汇等。这些过滤操作可以看作责任链中的不同节点，依次对消息进行过滤，直到消息满足要求或所有过滤器都遍历完。

---

一、RabbitMQ了解吗,优点，缺点

RabbitMQ是一个开源的消息代理软件，它实现了高级消息队列协议（AMQP）1.0标准，也支持其他协议如MQTT、STOMP等。RabbitMQ被广泛用于在分布式系统中进行异步消息传递，它可以可靠地传递消息，即使是在复杂的路由场景下。

RabbitMQ的优点：

1. 消息可靠性：RabbitMQ提供了多种消息传递模式，包括事务消息、持久化消息等，确保消息不会丢失。

2. 高可用性：RabbitMQ支持集群部署，可以提供高可用性和负载均衡。

3. 多协议支持：RabbitMQ支持多种消息协议，可以与不同语言和平台的应用程序集成。

4. 灵活的路由：RabbitMQ支持多种交换机类型（如Direct、Topic、Fanout、Headers），可以根据消息的属性进行灵活的路由。

5. 消息确认机制：RabbitMQ提供了消息确认机制，确保消息被正确处理。

6. 消息队列：RabbitMQ支持消息队列，可以存储消息并在消费者准备好后进行消费。

7. 监控和管理：RabbitMQ提供了丰富的监控和管理工具，可以方便地监控和管理消息队列。

RabbitMQ的缺点：

1. 复杂性：RabbitMQ的配置和使用相对复杂，需要一定的学习和配置成本。

2. 资源消耗：在高负载情况下，RabbitMQ可能会消耗较多的系统资源，如内存和CPU。

3. 单点故障：在单节点部署的情况下，RabbitMQ存在单点故障的风险。

4. 延迟：虽然RabbitMQ提供了高可靠性的消息传递，但在某些情况下，消息传递可能会有一定的延迟。

5. 学习和维护成本：对于开发者和运维人员来说，学习和维护RabbitMQ需要一定的成本。

二、如何保证MQ的数据可靠性

保证MQ（消息队列）的数据可靠性是一个涉及多个方面的任务。以下是一些关键措施，可以帮助确保MQ的数据可靠性：

1. 数据持久化

• 交换机持久化：在配置交换机时，应将其设置为持久化模式。这样，即使MQ服务重启，交换机的配置也不会丢失。

• 队列持久化：同样，队列也需要配置为持久化模式，以确保队列的元数据在MQ服务重启后能够恢复。

• 消息持久化：将消息持久化到磁盘上，可以防止消息在服务重启或崩溃时丢失。在发送消息时，应设置消息的持久化属性。

2. Lazy Queues（惰性队列）

• 惰性队列是一种特殊的队列模式，它接收到消息后不会立即加载到内存中，而是直接存储在磁盘上。当消费者需要消费消息时，才会从磁盘中读取并加载到内存。这样可以避免在消费者不活跃时浪费内存资源，并进一步提高消息的持久化可靠性。

• 从RabbitMQ的3.6.0版本开始引入了Lazy Queues模式，并在3.12版本之后成为所有队列的默认格式。

3. 生产者确认机制

• 启用生产者确认机制后，MQ会在消息成功持久化后才向生产者发送确认回执（ACK）。这可以确保生产者在发送消息后能够知道消息已经被正确处理。

• 为了减少IO次数并提高性能，MQ通常会批量持久化消息，这可能会导致ACK有一定的延迟。因此，建议生产者确认全部采用异步方式。

4. 消费者确认机制

• 消费者在处理完消息后，需要向MQ发送确认回执（ACK）。这可以确保MQ知道消息已经被成功处理，从而可以安全地删除消息或进行其他后续操作。

• 如果消费者在处理消息时失败，可以选择重新发送消息（nack）或拒绝消息（reject）。对于需要保证幂等性的业务场景，需要特别注意处理重复消息的问题。

5. 集群和镜像队列

• 通过部署MQ集群和配置镜像队列，可以提高系统的高可用性和容错性。即使某个MQ节点出现故障，其他节点仍然可以继续处理消息。

• 镜像队列可以将消息复制到多个节点上，从而进一步提高消息的可靠性。

6. 监控和报警

• 定期对MQ进行监控和日志分析，可以及时发现潜在的问题并采取相应的措施。例如，监控队列长度、消息处理时间等指标，可以帮助发现消息积压或处理延迟等问题。

• 配置报警机制，在MQ服务出现异常或达到预设阈值时及时通知相关人员进行处理。

7. 数据备份和恢复

• 定期对MQ的数据进行备份，以防止数据丢失。备份可以存储在本地磁盘、远程服务器或云存储等位置。

• 在需要时，可以使用备份数据快速恢复MQ服务，以减少因数据丢失带来的损失。

三、分布式的事务一致性如何保证

分布式锁：

• 分布式锁可以用来保证在分布式系统中对共享资源的互斥访问。

• 通过分布式锁，可以确保在同一时间只有一个节点能够修改共享资源

消息队列

• 消息队列可以用来解耦分布式系统中的各个组件，并通过消息传递来实现数据的一致性。

• 消息队列可以保证消息的顺序性和可靠性，从而保证数据的一致性。

四、Springboot中的核心注解了解吗

1.@SpringBootApplication：

• 这是Spring Boot最最核心的注解，用在Spring Boot的主类上，标识这是一个Spring Boot应用，用来开启Spring Boot的各项能力。

• 实际上，@SpringBootApplication注解是@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan这三个注解的组合。

• 使用@SpringBootApplication注解，可以简化Spring Boot应用的配置，避免了繁琐的XML配置文件。

2.@SpringBootConfiguration：

• 这是Spring Boot框架中的一个注解，用于标识一个类是Spring Boot的配置类。

• 它是@Configuration注解的派生注解，在@Configuration注解的基础上添加了一些特定的功能。

• 标识配置类：使用@SpringBootConfiguration注解标识的类会被Spring Boot识别为配置类，Spring Boot会根据配置类的内容来进行相应的自动配置。

• 综合性注解：SpringBootConfiguration是一个综合性注解，包含了@Configuration、@ComponentScan和@EnableAutoConfiguration等注解的功能。因此，使用@SpringBootConfiguration注解可以简化配置类的编写，减少重复的注解。

• 自动配置：在Spring Boot中，使用@SpringBootConfiguration注解的类通常会与@EnableAutoConfiguration注解一起使用，实现自动配置的功能。

3.@EnableAutoConfiguration：

• 这是Spring Boot框架中的一个重要注解，用于启用Spring Boot的自动配置机制。

• 当使用@EnableAutoConfiguration注解时，Spring Boot会根据项目的依赖和配置来自动配置和加载相应的Bean。

• 自动配置：通过@EnableAutoConfiguration注解，Spring Boot会根据classpath中的依赖和项目中的配置来自动完成一系列的自动配置工作。它会根据约定和条件，自动加载和配置Spring Boot所需的各种Bean。

• 简化配置：使用@EnableAutoConfiguration注解可以大大简化Spring Boot应用的配置工作。Spring Boot会根据项目的依赖自动完成大部分配置，省去了繁琐的XML配置和手动配置的过程。

• 条件装配：@EnableAutoConfiguration注解会使用Spring Boot的条件注解机制来进行条件装配。它会根据项目的依赖和配置，判断是否满足条件来决定是否自动配置相关的Bean。

4.@ComponentScan：

• 这是Spring Boot框架中的一个注解，用于启用组件扫描功能。

• 它会自动扫描并加载符合条件的组件，包括@Controller、@Service、@Repository等。

• 默认情况下，@SpringBootApplication注解已经包含了@ComponentScan注解的功能，因此通常不需要显式使用@ComponentScan注解。但是，如果需要自定义组件扫描的路径或其他属性，可以使用@ComponentScan注解来覆盖默认值。

五、Yml,yaml,proprities了解吗

1.YML和YAML是两种非常相似的配置文件格式，它是一种直观的数据序列化格式，易于人类阅读，同时易于被计算机解析。应用于配置文件、数据序列化、API设计等领域。在Spring Boot等现代Java框架中，YAML已成为一种主流的配置文件格式。

2.Properties是一种传统的配置文件格式，主要用于在Java应用程序中设置属性。它采用键值对（key=value）的形式来存储配置信息。尽管Properties文件存在局限性，但由于其简单性和易用性，它仍然在一些简单的配置场景中被广泛使用。然而，在需要表示复杂数据结构的场合，YAML等更先进的配置文件格式通常更受欢迎。

六、sql优化，索引优化，什么情况下会导致索引失效

1、索引使用不当

1. 覆盖索引未利用：当查询的所有列都包含在索引中时，称为覆盖索引。如果查询不能利用覆盖索引，索引可能不会被使用。

2. 索引选择性不足：具有低选择性的索引意味着索引区分度不高，即索引列的值重复率较高。这样的索引可能不会被查询优化器所选择。

3. 索引列未被使用：如果查询中没有使用到索引列，索引将不会起到作用，查询将变为全表扫描。

4. 查询字段非组合索引最左字段：对于组合索引，查询条件必须从最左列开始，并且中间不可跳列。若违反最左前缀法则，索引失效。

2、数据类型与函数操作

1. 数据类型不匹配：当查询条件中的数据类型与索引列的数据类型不匹配时，索引可能失效。例如，索引列为字符串类型，而查询条件中使用了数字类型，这会导致隐式类型转换，从而使索引失效。

2. 函数或运算操作：在查询条件中对索引列进行函数操作或运算会导致索引失效。例如，对索引列使用UPPER()、LEFT()等函数，或对索引列进行加减乘除等运算操作。

3、查询条件设计不合理

1. 范围查询右边的列：在组合索引中，如果查询条件包含范围查询（如<、>、BETWEEN等），则范围查询右边的列无法使用索引。

2. 使用LIKE进行模糊查询：当LIKE模糊查询以通配符%开头时，索引会失效。因为数据库无法预知通配符后面的内容，从而无法有效利用索引。如果仅是尾部以%模糊匹配，索引通常不会失效。

3. 使用特定操作符：某些操作符如!=、<>、NOT IN、NOT EXIST、IS NOT NULL等可能导致索引失效，因为这些操作符通常需要进行全表扫描来查找匹配的数据。

4、数据库与索引状态

1. 索引碎片化：随着数据的插入、更新和删除，索引可能会变得碎片化，影响查询性能。此时需要重新组织或重建索引。

2. 高并发更新操作：当多个并发的更新操作同时对同一索引进行修改时，可能会导致索引失效，因为数据库会频繁地对索引进行锁定和解锁操作。

5、其他因素

1. 数据量过小：当数据表中的数据量非常小的时候，使用索引可能会比全表扫描更慢，因为索引的查找和读取开销可能会超过全表扫描的成本。

2. 数据分布不均匀：如果表中的数据分布不均匀，即某些列的值重复率非常高，那么使用索引进行查找可能会导致大量的磁盘读取，从而降低查询性能。

七、redis和mysql你是怎么使用的，mq你是怎么使用的

MQ的使用

消息队列（MQ）是一种用于在分布式系统中传递消息的中间件。我通常使用MQ来处理以下场景：

1. 异步通信：在分布式系统中，服务之间需要进行异步通信以避免阻塞和等待。例如，当用户下单时，订单服务可以将订单信息发送到MQ中，由其他服务异步处理如库存扣减、支付通知等。

2. 解耦：使用MQ将服务之间的依赖关系解耦，使得服务可以更加独立地运行和扩展。例如，当某个服务需要调用另一个服务的功能时，可以通过MQ发送消息来实现，而不需要直接依赖对方的服务接口。

3. 削峰填谷：在高峰时段，通过MQ将请求进行缓冲和排队，以避免系统过载。在低谷时段，再逐步处理这些请求，从而平衡系统的负载。

4. 可靠传输：MQ通常具有可靠的消息传输机制，如消息持久化、确认机制等，可以确保消息在传输过程中的可靠性和完整性。这使得MQ在需要保证消息可靠传输的场景中非常有用。

八、mq怎么保证消息的顺序执行

1、使用单个队列

将所有相关的消息都发送到同一个队列中，这样可以保证消息按照发送的顺序排列。消费者可以按照顺序从队列中读取消息进行处理。这种方法简单直观，但可能会成为性能瓶颈，尤其是在处理大量消息时。

2、设置消息分组

将相关的消息分组放在同一个消息队列中，消费者可以按照消息分组进行处理。这样可以保证同一分组内的消息按照发送顺序进行处理。例如，在电商系统中，可以将同一个订单的所有消息（如创建订单、支付订单、发货通知等）放入同一个消息分组中。

3、使用有序消息中间件

一些MQ产品提供了有序消息的支持，如RocketMQ、Kafka等。这些中间件提供了一些机制来确保消息按照发送的顺序进行处理。

• RocketMQ：通过为消息设置路由ID（如订单ID）并将消息发送到同一个消息队列中，消费者可以按照消息的顺序进行消费。RocketMQ还提供了MessageListenerOrderly接口来处理有序消息，确保消息的顺序执行。

• Kafka：通过为消息设置相同的key，可以将相关的消息发送到同一个partition中，而Kafka保证同一个partition内的消息是有序的。因此，消费者可以按照消息的顺序从partition中读取消息进行处理。

4、使用锁机制

在消费者端，可以使用锁机制来确保消息的顺序执行。例如，在分布式系统中，可以使用分布式锁来确保在任何时候只有一个消费者可以处理特定消息。这种方法可能会增加系统的复杂性和开销，但可以有效地保证消息的顺序执行。

5、限制并发处理

通过限制消费者的并发级别，可以控制同时处理多少消息。这样可以避免因同时处理大量消息而导致的问题，如死锁和竞态条件。例如，在RabbitMQ中，可以将一个queue对应一个consumer，并关闭autoack，设置prefetchCount=1，这样消费者就会按顺序逐条消费消息。

6、使用单一消费者

在某些情况下，可以使用单一消费者来消费消息队列中的所有消息。这样可以确保消息按照发送的顺序被消费。但这种方法在处理大量消息时可能会成为性能瓶颈。

7、考虑业务逻辑和场景

在设计系统时，还需要根据具体的业务逻辑和场景来选择合适的消息顺序保证方案。例如，在某些情况下，全局顺序可能并不是必需的，而只需要保证某个分区或分组内的消息顺序即可。

九、mq怎么能保证消息不丢失

一、持久化机制

• 消息持久化：将消息保存到稳定的存储介质上，如硬盘或数据库。这样即使在系统故障或断电后，消息也能够恢复。在RabbitMQ中，可以配置队列、交换机和消息本身为持久化。在Kafka中，可以通过设置消息的持久化标志来实现。

• 刷盘机制：RocketMQ通过刷盘机制确保消息持久化到磁盘。同步刷盘意味着只有消息写入磁盘后，才返回成功的ACK响应；异步刷盘则可能先将消息写入PageCache缓存，再择机写入磁盘。

二、消息确认机制

• 生产者确认：MQ提供生产者确认机制，确保消息已成功发送到MQ。例如，RabbitMQ的confirm消息确认机制会在消息成功投递到队列后发送确认消息给生产端。

• 消费者确认：消费者在处理完消息后，向MQ发送确认消息（ACK），告知消息已成功处理。如果MQ在一定时间内未收到确认消息，可能会将消息重新发送给其他消费者。

三、冗余备份机制

• 消息复制和备份：在多个MQ服务器之间进行消息复制和备份，确保即使某个MQ服务器发生故障，消息仍然能够被其他服务器接收和处理。这有助于防止单点故障导致的消息丢失。

四、事务机制

• 事务性消息：在消息发送和消费过程中使用事务机制，确保消息的原子性。即要么消息被完整地发送和消费，要么不进行任何操作。如果消息发送或消费失败，可以回滚事务以保证消息的可靠性。

五、重试机制和死信队列

• 重试机制：当消息发送或消费失败时，自动进行重试。通过设置重试次数和间隔时间，可以提高消息的可靠性。

• 死信队列：将处理失败的消息重新路由到另一个死信队列，以便后续处理或分析。

六、监控和报警

• 监控和报警系统：通过监控和报警系统实时监控消息传递的状态和性能，及时发现并处理异常情况，确保消息的可靠性。

十、redis缓存雪崩问题 怎么解决

1、保证缓存层的高可用性

1. 使用Redis哨兵模式

   • Redis哨兵模式负责监控Redis主从服务器的健康状态。一旦主服务器出现问题，哨兵将自动切换到备份服务器作为新的主服务器，从而保障数据的持续可用。例如，在一个电商系统中，如果主Redis节点因故障宕机，哨兵可以迅速将从节点提升为新的主节点，继续提供缓存服务，避免缓存雪崩。

2. 采用Redis集群部署方式

   • 将数据分散到多个Redis节点，通过分区实现数据的存储和管理。例如，使用Redis Cluster，即使个别节点出现故障，其他节点仍然可以处理缓存请求，提高了Redis服务的可用性和性能。同时，在部署集群时，要注意数据的分布和复制，以及故障转移和节点扩容等问题。

3. 多机房部署Redis

   • 在多个机房部署Redis实例。这样，即便某个机房出现故障（如断电、网络故障等），其他机房的Redis仍然可以正常工作，实现缓存层的高可用。例如，大型互联网公司可能会在不同地区的数据中心部署Redis，以应对可能的机房级故障。

2、限流降级组件

1. 使用限流组件（如Hystrix、Sentinel等）

   • 在高并发场景下，无论是缓存层还是存储层都可能出错。将它们视为资源，当并发量较大时，如果一个资源不可用，可能会造成所有线程在获取这个资源时异常，导致整个系统不可用。例如，Hystrix可以对请求进行动态监控和管理，通过限流机制控制进入系统的请求数量，防止过多请求同时到达缓存层或存储层，避免因缓存雪崩引发的系统崩溃。

2. 降级策略

   • 降级在高并发系统中是一种有效的保底策略。例如在推荐服务中，如果个性化推荐服务（依赖缓存）不可用，可以降级补充热点数据，不至于造成整个推荐服务不可用。当Redis缓存出现问题时，可以暂时提供一些默认数据或者简化的服务，而不是让系统直接崩溃。

3、缓存不过期策略

• 在Redis中保存的key永不失效，这样就不会出现大量缓存同时失效的问题，但这种方法会占用更多的Redis存储空间，并且可能导致数据的更新不及时。例如对于一些基本不变的配置信息，可以采用这种方式缓存。

4、优化缓存过期时间

1. 设置随机过期时间

   • 为每一个key选择合适的过期时间，避免大量的key在同一时刻同时失效。例如，可以在原有失效时间的基础上增加一个随机值（如1 - 5分钟的随机范围），使每个缓存过期时间的重复率降低，从而减少集体失效事件的发生。

2. 分散缓存失效时间

   • 对于相似查询模式对应的缓存数据，设置不同的过期时间，防止这些数据同时失效导致大量请求同时访问数据库。

5、使用互斥锁重建缓存

1. 单机环境

   • 在单机环境下，可以使用Java并发包下的Lock。当根据key去缓存层查询数据，若缓存层未命中时，对key加锁，然后从存储层查询数据，将数据写入缓存层，最后释放锁。若其他线程发现获取锁失败，则让线程休眠一段时间后重试。

2. 分布式环境

   • 在分布式环境下，使用分布式锁（如Redis中的SETNX方法）。例如，当多个服务实例同时发现缓存失效时，只有一个实例能够获取分布式锁去查询数据库并更新缓存，其他实例等待，避免大量的请求同时到达存储层查询数据、重建缓存。不过这种方式可能会造成用户等待，在高并发下，如果缓存重建期间key是锁着的，可能会导致大量用户请求阻塞。

6、异步重建缓存

• 构建缓存采取异步策略，会从线程池中获取线程来异步构建缓存，从而不会让所有的请求直接到达存储层。该方案中每个Redis key维护逻辑超时时间，当逻辑超时时间小于当前时间时，则说明当前缓存已经失效，应当进行缓存更新，否则说明当前缓存未失效，直接返回缓存中的value值。

7、其他策略

1. 缓存预热

   • 在系统低峰期或启动时，预先加载热门数据到缓存中。例如，在电商系统每天凌晨流量较小时，将热门商品信息加载到缓存，确保系统启动后有一部分数据已经缓存，减少缓存失效的影响。

2. 增加缓存层级

   • 引入多级缓存架构，例如本地缓存和分布式缓存结合使用。本地缓存可以作为第一层缓存，用于快速响应请求；分布式缓存（如Redis）作为第二层缓存，用于缓存更大量的数据。这样即使Redis缓存发生雪崩，仍然可以依赖本地缓存继续提供部分服务。

3. 数据预加载

   • 通过定时任务等方式提前加载某些热门数据到缓存中，减少缓存失效后重新加载的压力。可以根据业务特点和访问模式灵活设计数据预加载策略。

4. 监控和告警

   • 实时监控Redis服务器的健康状态和键失效情况。在雪崩发生时及时告警，以便快速采取措施。例如，通过监控工具实时查看Redis的内存使用、命中率、键的过期情况等指标，当发现大量键即将过期或者Redis性能下降时，提前进行处理。

十一、jvm调优

1、明确性能目标

在开始调优前，明确性能目标是非常重要的。吞吐量、延迟、内存使用和稳定性是衡量系统性能的关键指标。

• 吞吐量：表示为单位时间内系统能处理的任务数（如请求、事务或操作）。

• 延迟：指完成一个操作所需的时间，是用户体验的重要组成部分。

• 内存使用：应用运行时占用的内存总量。有效管理内存使用可以防止应用因内存耗尽而崩溃。

• 稳定性：衡量的是系统在长时间运行中的可靠性和一致性。

2、选择合适的垃圾收集器

不同的垃圾收集器有不同的设计目标，适用于不同类型的应用和工作负载。

• Parallel GC：优化了吞吐量，适合在后台运算较多且可以容忍较长GC停顿时间的应用。

• G1 (Garbage First) Collector：适用于多核服务器，优化了响应时间，减少停顿，尤其适合需要处理大堆内存的应用。

• CMS (Concurrent Mark Sweep) Collector：设计目标是尽可能减少应用暂停时间，适合那些对延迟敏感的应用。

• ZGC (Z Garbage Collector)：适合超大堆内存和低延迟需求的场景，可以处理多达数TB的堆内存而只有毫秒级的GC停顿。

3、调整JVM启动参数

调整JVM启动参数是JVM调优过程中非常核心的一步，可以直接影响Java应用的性能。以下是一些常见的调整选项和它们的作用：

• 堆大小：

  • -Xms：设置JVM启动时的初始堆大小。如果你预计应用需要大量内存，设置一个较大的初始值可以减少JVM在运行初期的自动增长堆的次数，从而提高性能。

  • -Xmx：设置JVM可以使用的最大堆大小。这个值限定了应用可以使用的最大内存，防止应用占用过多系统内存。

• 垃圾收集器参数：

  • -XX:+UseParallelGC：启用Parallel GC。

  • -XX:+UseG1GC：启用G1垃圾收集器。

  • -XX:+UseConcMarkSweepGC：启用CMS垃圾收集器。

  • -XX:+UseZGC：启用ZGC垃圾收集器（如果JVM版本支持）。

• 新生代和老年代大小：

  • -Xmn：设置年轻代的初始大小和最大大小。年轻代的大小会影响到垃圾收集的频率和性能。

  • -XX:NewRatio：设置年轻代与老年代的比例。

• Survivor区比例：

  • -XX:SurvivorRatio：设置年轻代中Eden区与两个Survivor区的比例。调整这个比例可以优化对象的晋升和回收。

• 自适应大小调整：

  • -XX:+UseAdaptiveSizePolicy：启用这个选项可以让JVM自动调整堆各区的大小和GC的目标停顿时间，根据应用的行为动态调整以提供最佳性能。

4、监控和分析

使用工具监控JVM的运行情况，如内存使用情况、垃圾回收情况、线程状态等，并进行性能分析，以找出性能瓶颈和优化的潜在点。

• jconsole：JDK自带的可视化监控工具，可以查看应用程序的运行概况、内存、线程、类、VM概括、MBean等信息。

• VisualVM：也是JDK自带的可视化监控工具，可以监控服务的CPU、内存、线程、类等信息，并捕获有关JVM软件实例的数据。

• MAT（Memory Analyzer Tool）：一款功能强大的Java堆内存分析器，用于查找内存泄漏以及查看内存消耗情况。

• GCeasy：一款在线的GC日志分析器，可以实时进行内存泄漏检测、GC暂停原因分析、JVM配置建议优化等功能。

5、代码和架构层面的优化

除了JVM层面的调优，代码和架构层面的优化也是不可忽视的。

• 减少对象创建：频繁创建和销毁对象会增加垃圾回收的负担。优化代码，避免不必要的对象创建，尽量复用对象或使用对象池技术。

• 使用合适的集合类型：选择合适的集合类型可以提高性能。例如，如果需要高效的插入和删除操作，可以使用LinkedList；如果需要快速的查找操作，可以使用HashMap。

• 优化循环操作：减少循环操作中的方法调用和对象创建，尽量减少循环嵌套的层数，使用合适的循环方式（如增强型for循环、迭代器等）。

• 避免过度同步：过多的同步操作可能导致性能下降。在多线程环境下，使用合适的同步机制，避免不必要的锁竞争和阻塞。

• 水平扩展：通过将负载分布到多台服务器上，实现应用程序的水平扩展。合理设计系统架构，采用负载均衡、分布式缓存等技术，提高系统的可伸缩性和吞吐量。

• 异步处理：采用异步处理方式可以提高系统的响应速度和并发能力。例如，使用消息队列、异步任务等技术，将耗时操作异步化，避免阻塞。

• 缓存优化：合理使用缓存可以减少对后端资源的访问，提高系统性能。根据应用程序的特点，选择合适的缓存策略和缓存数据结构。

6、持续监控和迭代

性能调优是一个持续的过程，需要不断地监控和优化。定期的性能测试，如压力测试和耐力测试，可以帮助发现和修正导致系统不稳定的问题。同时，根据应用的变化和负载的变化，定期重新评估和调整JVM参数。

十二、发生fullGC该如何排查

1、收集GC日志

首先，需要开启GC日志记录，这可以通过设置JVM参数来实现。例如，使用-Xloggc:file_name参数指定GC日志文件的路径，并使用-XX:+PrintGCDetails和-XX:+PrintGCDateStamps等参数来生成详细的GC日志。

2、分析GC日志

1. 使用工具分析：

   • 不建议直接用记事本打开GC日志文件进行分析，因为其内容可能非常复杂。可以使用如GCFU、GCViewer或其他开源的分析GC日志的工具来帮助分析。

   • 这些工具可以清晰地展示出Full GC的频率、每次执行时间等异常情况。正常情况下，Full GC几个小时或几天做一次比较正常，如果几分钟就做一次则比较频繁。

2. 关注关键指标：

   • Full GC的频率：如果Full GC的发生频率远高于正常情况，那么就需要深入调查原因。

   • Full GC的持续时间：长时间的Full GC会导致系统停顿，影响用户体验。

   • Full GC前后的内存占用情况：分析Full GC前后老年代的使用情况，如果老年代使用情况仍有80%以上，可能是程序存在内存泄漏问题。

3、监控内存使用情况

使用JVM提供的工具如jstat或可视化工具如VisualVM来监控堆内存使用情况，特别是年轻代（Young Generation）和老年代（Old Generation）的内存使用情况。

4、检查代码和配置

1. 检查代码：

   • 内存泄漏：使用工具如MAT（Memory Analyzer Tool）或JProfiler来检测内存泄漏。内存泄漏会导致老年代的对象持续增加，从而频繁触发Full GC。

   • 大对象分配：检查代码中是否有大对象直接分配在老年代中，或者是否有大量的大对象频繁创建和销毁。大对象可能导致内存分配失败，增加Full GC的风险。

   • 显式调用System.gc() ：避免在代码中显式调用System.gc() ，因为这可能触发Full GC。

2. 检查JVM配置：

   • 堆大小设置：确保堆大小设置合理，避免堆内存过小导致频繁Full GC。

   • 新生代和老年代比例：根据应用程序的特点，调整新生代和老年代的比例，确保新生代足够大以容纳短生命周期对象。

   • 垃圾收集器选择：根据应用程序的需求，选择合适的垃圾收集器。不同的垃圾收集器有不同的性能特点，可能更适合你的应用程序。

5、优化应用程序

1. 优化对象生命周期：减少不必要的对象创建和销毁，尽量复用对象或使用对象池技术。

2. 优化数据结构和算法：使用高效的数据结构和算法来减少内存消耗和垃圾生成。

3. 避免过度同步：减少不必要的同步操作，降低线程争用和锁竞争的可能性。

6、持续监控和调整

性能调优是一个持续的过程。在进行了上述步骤后，需要持续监控应用程序的性能和GC行为。如果发现Full GC问题仍然存在，可能需要根据新的监控数据和分析结果继续调整JVM参数或优化应用程序代码。

十三、导致fullGC的情况有哪些

1. 老年代空间不足：当老年代（Old Generation）空间不足以容纳存活的对象时，JVM会触发Full GC来释放空间。

2. 永久代/元空间溢出：在Java 8之前，永久代（PermGen）用于存储类的元数据、常量池等。如果永久代空间耗尽，会触发Full GC。Java 8及以后，永久代被元空间（Metaspace）取代，元空间不足也会导致Full GC。

3. 晋升失败（Promotion Failure）：当年轻代对象晋升到老年代时，如果老年代空间不足，无法容纳这些对象，会触发Full GC。

4. 内存碎片化：老年代中的内存碎片可能导致即使有足够的空闲空间，也无法容纳新的大对象，从而触发Full GC。

5. 显式调用System.gc() ：Java允许通过System.gc() 方法显式地建议JVM执行垃圾回收，这可能会触发Full GC，但JVM可以选择忽略这个请求。

6. 内存泄漏：当应用程序中存在内存泄漏时，对象无法被垃圾回收，随着时间的推移，这些对象会占用越来越多的内存，最终触发Full GC。

7. 大量对象一次性晋升到老年代：如果应用程序一次性加载大量数据或创建大量对象，这些对象可能会直接晋升到老年代，导致老年代空间迅速不足。

8. 垃圾回收器策略：某些垃圾回收器（如CMS）在特定条件下可能会触发Full GC，例如CMS垃圾回收器在初始标记和最终标记阶段。

9. 堆内存设置不当：如果堆内存设置过小，可能导致频繁的Full GC。

10. 并发线程数过多：在多线程环境中，如果线程数过多，可能会导致GC线程和应用程序线程争用CPU资源，影响GC的效率。

11. 外部资源限制：如文件句柄、网络连接等外部资源限制可能导致对象无法正常回收，从而触发Full GC。

12. JVM内部错误：在某些情况下，JVM自身的内部错误也可能导致Full GC。

十四、对象在什么情况会进入老年代

一、基于对象年龄

1. 达到年龄阈值

   • JVM会给对象增加一个年龄（age）的计数器，对象每“熬过”一次GC（这里指MinorGC），年龄就要 + 1。默认情况下，当对象的年龄达到15岁（可通过 -XX:MaxTenuringThreshold调整这个阈值）时，就会被移动到老年代。例如，在一个长期运行且对象存活周期较长的应用中，对象经过多次MinorGC后，年龄不断累加，当达到设定的年龄阈值时，就会进入老年代。

2. 动态年龄判断

   • 假如在Survivor区中，一批对象（年龄1 + 年龄2 + …+年龄n）的总大小大于这块Survivor内存的50%（这个比例默认是50%，也可通过参数调整），那么大于这批对象年龄的对象，就可以直接进入老年代。例如，Survivor区为100MB，其中年龄为1、2、3的对象总和大小超过50MB，那么年龄为3及以上的对象就会进入老年代。

二、对象大小

1. 大对象直接进入老年代

   • 如果设置了 -XX:PretenureSizeThreshold这个参数，当要创建的对象大于这个参数的值时，就直接把这个大对象放入到老年代，不会经过新生代。例如，在处理大型文件或图像数据时，如果创建一个超大的字节数组，若其大小超过 -XX:PretenureSizeThreshold设置的值，就会直接进入老年代。这样做可以避免大对象在新生代屡次躲过GC，还得把它们复制来复制去的，最后才进入老年代，减少不必要的复制开销。

三、空间分配相关

1. MinorGC后存活对象Survivor区放不下

   • 在进行MinorGC之后，如果存活的对象太多，无法放入Survivor区，那么这些存活对象就会直接进入老年代。例如，在一个对象创建速度较快且对象存活率较高的应用场景中，MinorGC后可能会出现Survivor区无法容纳所有存活对象的情况，此时这些对象就会被移到老年代。

2. 分配担保机制下进入老年代

   • 在MinorGC之前，JVM会检查老年代可用的可用内存空间是否大于新生代所有对象的总大小。如果老年代的内存大小小于新生代所有对象的大小，会看 -XX: -HandlePromotionFailure的参数是否设置。如果有这个参数，会继续判断老年代的内存大小是否大于之前每一次MinorGC后进入老年代的对象的平均大小。如果判断失败或者 -XX: -HandlePromotionFailure参数没设置，此时就会直接触发一次Full GC。如果Full GC过后，老年代还是没有足够的空间存放MinorGC过后的剩余存活对象，就会导致内存溢出（OOM）；如果有足够空间，那么MinorGC过后剩余的存活对象就会进入老年代。例如，在一些内存紧张且对象分配不稳定的应用中，可能会触发这种分配担保机制，导致对象进入老年代。

十五、spring中的循环依赖问题？(三级缓存)

Spring解决循环依赖的具体过程如下：

1. 当Spring创建一个Bean时，它会首先检查一级缓存中是否已经存在这个Bean的实例。如果存在，直接返回这个实例。

2. 如果一级缓存中没有，Spring会检查二级缓存。如果二级缓存中有早期版本的Bean引用，直接返回这个引用。

3. 如果二级缓存中也没有，Spring会检查三级缓存。如果三级缓存中有Bean工厂对象，Spring会使用这个工厂对象来创建早期版本的Bean引用，并将其放入二级缓存中。

4. 然后，Spring会继续创建这个Bean，包括依赖注入和初始化过程。在这个过程中，如果发现需要引用到其他Bean，Spring会再次进行上述的缓存检查流程。

5. 一旦Bean创建完成，它的实例会被放入一级缓存中，并且二级缓存中的早期版本引用会被清除。

通过这种方式，Spring可以在创建Bean的过程中，即使存在循环依赖，也能够提前暴露出早期版本的Bean，以便其他Bean可以引用到它们，从而解决循环依赖问题。

十六、三级缓存中存放的是什么？

1. singletonFactories：三级缓存，存放的是Bean工厂对象，用于生成早期的Bean引用。这些工厂对象可以用来创建早期版本的Bean，以便在循环依赖的情况下，其他Bean可以引用到这些早期版本的Bean。

十七、分布式锁有哪些?

一、基于数据库的分布式锁

1. 乐观锁

   • 乐观锁通常利用数据库中的版本号或时间戳字段来实现。在更新数据前，先检查版本号或时间戳是否一致，一致则更新并更新版本号或时间戳，否则认为数据已被其他事务修改。

2. 悲观锁

   • 悲观锁通过数据库的行级锁（如MySQL的SELECT ... FOR UPDATE）来实现。当一个事务需要访问某行数据时，会锁定该行，其他事务在锁定期间无法访问该行数据。

3. 表锁

   • 通过对数据库表加锁来实现分布式锁。这种方式的粒度较大，会影响表内所有数据的访问。

二、基于Redis的分布式锁

1.SETNX命令

• Redis的SETNX（SET if Not eXists）命令可以用于实现分布式锁。当键不存在时，设置键的值并返回1，表示加锁成功；当键已存在时，返回0，表示加锁失败。

2.Lua脚本

• 通过Lua脚本确保解锁操作的原子性。在解锁时，需要检查当前线程是否持有锁（即检查键的值是否与预期值相等），如果相等则删除键，表示释放锁。

十八、redis实现分布式锁，会有什么问题

一、锁超时问题

• 问题描述：Redis分布式锁一般通过设置键的过期时间来避免死锁。然而，如果锁的持有者由于某些原因（如长时间执行、网络延迟等）未能及时释放锁，或者锁的持有者在释放锁之前崩溃，那么锁可能会提前过期，导致其他客户端获取到锁，从而引发并发问题。

• 解决方案：可以使用续约机制或定时任务来定期刷新锁的过期时间。同时，需要合理设置锁的过期时间，以确保在锁持有者正常释放锁之前不会过期。

二、竞争条件

• 问题描述：多个客户端在竞争同一把锁时，可能会出现因时间差异导致的竞争条件。例如，客户端A获取锁后，由于某些原因未能及时释放锁，而客户端B在等待一段时间后尝试获取锁，可能会因为网络延迟等原因导致客户端B误认为锁已被释放，从而引发并发问题。

• 解决方案：可以通过使用Redis的Lua脚本来确保操作的原子性，从而避免竞争条件的发生。

三、单点故障

• 问题描述：Redis分布式锁依赖于Redis服务器的可用性和稳定性。如果Redis服务器发生故障或不可用，可能会导致分布式锁失效，从而引发并发问题和资源争用。

• 解决方案：可以使用Redis的主从复制或集群部署来提高系统的可用性和容错性。在主节点故障时，从节点可以接管锁服务，确保系统的正常运行。

四、不支持重入

• 问题描述：Redis分布式锁本身并不支持重入。重入锁是指同一个线程或进程可以多次获取同一个锁而不会导致死锁。在某些场景下，如果需要在同一个线程或进程中多次获取锁来执行多个操作，Redis分布式锁可能无法满足需求。

• 解决方案：可以在客户端实现重入锁的逻辑，通过给锁设置唯一的标识符（如客户端ID或线程ID）来跟踪锁的持有者，并在需要时增加锁的重入计数。

五、精确性和一致性

• 问题描述：由于分布式系统中的网络延迟、故障和并发访问等因素的存在，Redis分布式锁无法保证绝对的精确性和一致性。这可能会导致某些线程或进程在未获得锁的情况下继续执行操作，从而破坏了资源的互斥访问。

• 解决方案：可以通过优化网络配置、提高Redis服务器的性能和使用更高版本的Redis来降低这些问题的影响。同时，在设计分布式系统时，也需要考虑到这些因素可能带来的风险，并采取相应的容错和恢复机制。

六、性能开销

• 问题描述：Redis分布式锁涉及到网络通信和操作Redis服务器，会带来一定的性能开销。特别是在高并发环境下，频繁的锁获取和释放操作可能会增加网络延迟和服务器负载。

• 解决方案：可以通过优化Redis的配置、使用更高性能的服务器和网络设备以及合理设计锁的使用场景来降低性能开销。同时，也可以考虑使用其他轻量级的分布式锁实现方式或优化应用程序的代码来减少锁的使用频率。

十九、redis分布式锁是可重入的吗

Redis分布式锁本身不是可重入的。可重入锁，也称为递归锁，是指同一个线程或进程在持有锁的情况下，可以多次获取同一个锁而不会导致死锁。然而，标准的Redis分布式锁实现并不具备这种特性。

在Redis分布式锁的实现中，通常使用SET命令的NX（仅在键不存在时设置）和EX（设置键的过期时间）选项来创建一个锁。当客户端获取锁时，它会设置一个唯一的标识符（通常是客户端ID加上一个随机值）作为键的值，并设置一个过期时间以避免死锁。当客户端释放锁时，它会检查键的值是否与其设置的唯一标识符相匹配，如果匹配则删除键以释放锁。

由于Redis分布式锁的这种实现方式，它不支持同一个线程或进程在持有锁的情况下多次获取锁。如果尝试这样做，将会导致锁无法被正确释放，因为释放锁的操作需要验证键的值与唯一标识符相匹配。如果同一个线程或进程多次获取锁并更改了键的值，那么后续的释放锁操作将无法识别出正确的唯一标识符，从而无法删除键以释放锁。

然而，可以通过在客户端实现一些额外的逻辑来模拟可重入锁的行为。例如，可以在客户端维护一个锁的重入计数器，每当获取锁时增加计数器的值，每当释放锁时减少计数器的值。只有当计数器的值减为零时，才真正执行释放锁的操作。但这种方法需要在客户端进行额外的状态管理，并且需要确保在客户端崩溃或重启时能够正确地恢复状态，以避免死锁或资源泄露的问题。

---

一、项目中用到了哪些Redis数据类型

1. String（字符串）

• 特性：简单、可排序，支持二进制安全。

• 使用场景：

  • 存储文本、JSON 数据。

  • 用作缓存，存储临时数据以减少数据库负载。

  • 作为计数器，用于统计访问次数、库存数量等。

2. Hash（哈希）

• 特性：键值对存储，支持字段级操作。

• 使用场景：

  • 存储用户数据、会话信息、对象属性等。

  • 用于存储结构化数据，便于字段级访问和操作。

3. List（列表）

• 特性：有序集合，支持插入、删除、修剪。

• 使用场景：

  • 存储队列、时间线、排名等。

  • 用作消息队列，实现生产者-消费者模型。

  • 存储购物车数据，便于用户添加、删除商品。

4. Set（集合）

• 特性：无序的唯一元素集合，支持交集、并集、差集操作。

• 使用场景：

  • 存储标签、分类、关注列表、黑名单等。

  • 用于去重操作，确保数据的唯一性。

  • 实现社交功能中的好友关系、共同关注等。

二、项目中怎么解决Redis缓存一致性问题

1. 先更新数据库，再删除缓存

• 实现方式：当数据发生变化时，首先更新数据库中的数据，然后删除 Redis 中的缓存。

• 优点：

  • 简单直观，易于实现。

  • 在大多数情况下能保证数据的一致性。

• 缺点：

  • 在高并发场景下，可能会出现缓存不一致的问题。例如，一个线程更新数据库后还没来得及删除缓存，另一个线程就读取了旧的缓存数据。

• 改进方案：使用延时双删策略。即在删除缓存后，休眠一段时间（这个时间通常根据业务的读请求处理时间来确定），再次删除缓存。这样可以确保在休眠期间读请求写入的旧缓存数据被删除。

2. 先删除缓存，再更新数据库

• 实现方式：当数据发生变化时，首先删除 Redis 中的缓存，然后更新数据库中的数据。

• 优点：

  • 减少了数据库更新后缓存未同步导致的不一致性问题。

• 缺点：

  • 如果删除缓存后更新数据库失败，那么缓存中的数据将一直为旧值。

  • 在高并发场景下，可能会出现缓存不一致的问题。例如，一个线程删除了缓存后还没来得及更新数据库，另一个线程就读取了旧的缓存数据（如果此时旧缓存数据还未过期）。

• 注意：这种策略一般不推荐使用，因为存在较多潜在的一致性问题。

3. 使用消息队列

• 实现方式：当数据发生变化时，发送一个消息到消息队列。消费者从消息队列中取出消息后，先更新数据库，再删除缓存。

• 优点：

  • 实现了数据库和缓存更新的解耦。

  • 通过消息队列的重试机制，可以保证缓存最终得到更新。

• 缺点：

  • 增加了系统的复杂度。

  • 需要维护消息队列的稳定性和可用性。

4. 订阅数据库变更日志

• 实现方式：使用数据库提供的变更日志功能（如 MySQL 的 Binlog），订阅数据库的变更日志。当数据发生变化时，根据变更日志更新缓存。

• 优点：

  • 实时性高，能够立即感知到数据的变更。

  • 无需侵入业务代码，通过中间件实现解耦。

• 缺点：

  • 需要维护变更日志的订阅和处理逻辑。

  • 对于不支持变更日志的数据库，需要额外的实现方式。

5. 使用读写锁

• 实现方式：在更新数据时，先获取写锁，然后更新数据库和缓存。在读取数据时，先获取读锁，然后读取缓存或数据库。

• 优点：

  • 保证了数据的一致性和并发安全性。

• 缺点：

  • 降低了系统的并发性能。

  • 在分布式环境中实现读写锁较为复杂。

6. 设置缓存过期时间

• 实现方式：为缓存数据设置一个合理的过期时间。当缓存数据过期后，自动从数据库中重新加载数据。

• 优点：

  • 简单有效，减少了缓存不一致的可能性。

  • 适用于数据变化不频繁的场景。

• 缺点：

  • 在数据变化频繁的场景下，可能会导致缓存命中率降低。

  • 缓存过期时间需要根据业务场景进行合理设置。

7. 缓存预热

• 实现方式：在系统启动时或数据库发生变化时，预先加载缓存数据。

• 优点：

  • 减少了缓存不一致的可能性。

  • 提高了系统的响应速度。

• 缺点：

  • 需要消耗额外的系统资源来加载缓存数据。

  • 在数据变化频繁的场景下，缓存预热的效果可能不明显。

三、项目中布隆过滤器怎么实现的

四、MySQL删除和更新语句

五、MySQL索引分类以及区别

1. 按功能逻辑分类

   • 普通索引：最基本的索引类型，没有任何限制，主要用于加快系统对数据的访问速度。允许在定义索引的列中插入重复值和空值。

   • 唯一索引：索引列的值必须唯一，但允许有空值。主要用于避免数据出现重复。

   • 主键索引：一种特殊的唯一索引，不允许有空值。一个表只能有一个主键索引，通常是在创建表的时候同时创建。

   • 全文索引：主要用于查找文本中的关键字，适用于CHAR、VARCHAR和TEXT列。在MySQL中，只有MyISAM存储引擎支持全文索引。

   1. 功能上的区别

      • 普通索引主要用于提高查询速度，没有唯一性要求。

      • 唯一索引除了提高查询速度外，还要求索引列的值必须唯一。

      • 主键索引是特殊的唯一索引，不允许有空值，一个表只能有一个主键索引。

      • 全文索引主要用于文本搜索，支持基于关键字的搜索。

六、MySQL查id=100的记录，底层是怎么查的，用到二分查找了吗

一、索引的使用

1. B树索引：

   • MySQL中最常用的存储引擎之一是InnoDB，它使用B+树索引来加速数据检索。

   • 当你的查询条件（如id = 100）涉及到索引列时，InnoDB会利用该索引来快速定位到目标数据。

   • 在B+树索引中，查找过程类似于二分查找，但并非纯粹的二分查找，因为它是在树形结构上进行的查找，而不是在简单的有序数组中。

2. 二分查找的类比：

   • 可以将B+树索引的查找过程类比为二分查找，因为两者都利用了数据的有序性来减少查找范围。

   • 在B+树中，从根节点开始，根据目标值与节点中关键字的比较结果，决定进入左子树还是右子树，直到找到目标值或确定目标值不存在。

二、没有索引的情况

• 如果id列上没有索引，MySQL将执行全表扫描（Full Table Scan），即逐行检查每条记录，直到找到id为100的记录或确认该记录不存在。

• 全表扫描的效率远低于利用索引的查找，特别是在大型表中。

三、二分查找的局限性

• 虽然B+树索引的查找过程在逻辑上与二分查找相似，但它并不是在内存中进行的简单二分查找。

• B+树索引存储在磁盘上，因此实际的查找过程还涉及到磁盘I/O操作，这比内存中的二分查找要复杂得多。

• 此外，B+树索引的设计还考虑了数据的平衡性和磁盘访问的效率，以确保在各种情况下都能提供稳定的查找性能。

四、讲讲mysql优化，集群分布式的区别，你是怎么认为的？

在我看来，MySQL优化是一个持续的过程，它需要根据实际的应用场景和数据特点进行调整和优化。无论是通过表设计、查询优化还是配置调整等方式，目的都是为了提高数据库的性能和稳定性。

而集群和分布式则是两种不同的架构模式，它们各有优缺点并适用于不同的场景。集群模式更适合于需要高可用性、负载均衡和自动故障转移的场景，而分布式模式则更适合于需要处理大量数据、提高性能和可扩展性的场景。在实际应用中，我们需要根据具体的需求和资源情况来选择合适的架构模式。

五、如果有个集群是专门做读操作的，那么在什么情况下会这么用呢。

• 内容管理系统（CMS）：这类系统通常涉及大量的内容读取操作，如网页浏览、文章阅读等，而写入操作相对较少，如内容发布和更新。在这种场景下，使用专门用于读操作的集群可以显著提高系统的并发处理能力。

• 新闻网站：新闻网站需要快速响应大量用户的请求，展示最新的新闻内容。由于新闻内容的读取频率远高于写入频率，因此使用读写分离架构，将读操作分配到专门的集群上，可以提高网站的访问速度和用户体验。

• 电子商务平台：在电子商务平台中，用户浏览商品、查看订单等操作非常频繁，而商品信息的更新和订单的提交则相对较少。通过将读操作分配到专门的集群上，可以提高平台的响应速度和并发处理能力。

六、由于主从服务器直接有延迟，我想读，用什么策略可以做到读时没延迟

使用缓存策略

• 原理：通过引入缓存中间件（如Redis、Memcached等）来缓存热点数据，减少对数据库的直接访问。

• 适用场景：适用于读多写少、数据更新不频繁的场景。

• 实现方式：

  • 在应用层集成缓存中间件客户端。

  • 在执行读操作前，先查询缓存中是否存在所需数据；如果存在，则直接返回缓存中的数据；否则，再访问数据库并更新缓存。