字节面试题（懂车帝）后端开发

最新推荐文章于 2024-11-01 12:20:35 发布

CCF小彤

最新推荐文章于 2024-11-01 12:20:35 发布

阅读量392

点赞数

文章标签：数据库面试数据结构算法

本文链接：https://blog.csdn.net/qq_21555569/article/details/135041714

版权

select

在Linux中，select 函数是一种用于多路复用 I/O 操作的系统调用。它允许一个进程监视多个文件描述符，以确定其中是否有可读、可写或异常事件发生。select 函数的原理涉及到以下几个概念：

文件描述符集合（File Descriptor Sets）： select 函数使用三个文件描述符集合，分别是读（readfds）、写（writefds）、异常（exceptfds）集合。在调用 select 之前，需要将要监视的文件描述符加入到相应的集合中。
超时参数： select 函数可以设置一个超时参数，表示最长等待时间。如果在指定时间内没有任何文件描述符就绪，select 将返回0。如果发生了可读、可写或异常事件，select 将返回就绪文件描述符的数量。
就绪文件描述符集合： 当 select 函数返回时，会修改传入的文件描述符集合，将其中就绪的文件描述符放入相应的集合中。
阻塞与非阻塞： select 函数是一种阻塞调用，即程序在调用 select 时会一直等待，直到有文件描述符就绪或超时。对于非阻塞模式，可以通过设置超时参数为零实现。
轮询： select 函数通过轮询所有监视的文件描述符，检查它们是否就绪。这种轮询方式在文件描述符数量较少时是比较高效的，但在文件描述符数量较大时会导致性能下降。

poll、epoll？

First of all, poll(2) is only level-triggered, but epoll(4) can be used as either edge- or level-triggered interface.

level-triggered vs edge-triggered

level-triggered: get a list of every file descriptor you’re interested in that is readable.
edge-triggered: get notifications every time a file descriptor becomes readable.

Now complexity: poll complexity regarding number of watched descriptors (fds) is O(n) as it scans all the fds every time when a ‘ready’ event occurs, epoll is basically O(1) as it doesn’t do the linear scan over all the watched descriptors.

https://www.hackingnote.com/en/versus/select-vs-poll-vs-epoll/

Dalvik

Dalvik 是 Android 操作系统中已停产的进程虚拟机 (VM)，它执行为 Android 编写的应用程序

在Android versions 4.4 “KitKat” and earlier被使用

已经被新版的Android VM替代，例如：HotSpot

The successor of Dalvik is Android Runtime (ART), which uses the same bytecode and .dex files (but not .odex files), with the succession aiming at performance improvements.

Stack machine

堆栈机是计算机处理器或虚拟机，其中主要交互是将短期临时值移入或移出下推堆栈。在硬件处理器的情况下，使用硬件堆栈。堆栈的使用显着减少了所需的处理器寄存器数量。

堆栈机的操作数和结果都放在栈中，一般指令中不涉及内存地址、寄存器等（即0地址指令）。

Java Native Interface (JNI)

JNI是一个能让JAVA去调用FFI(Foreign Function Interface)外部函数接口的编程框架，这个框架使得运行在 Java 虚拟机 (JVM) 中的 Java 代码能够调用本机（naive）应用程序（特定于硬件和操作系统的程序）以及用其他语言（例如 C、C++ 和汇编）编写的库。

什么是虚拟内存

虚拟内存为每个进程提供了一个一致的、私有的地址空间，它让每个进程产生了一种自己在独享主存的错觉（每个进程拥有一片连续完整的内存空间）。这样会更加有效地管理内存并减少出错。

虚拟内存是计算机系统内存管理的一种技术，我们可以手动设置自己电脑的虚拟内存。不要单纯认为虚拟内存只是“使用硬盘空间来扩展内存“的技术。虚拟内存的重要意义是它定义了一个连续的虚拟地址空间，并且 把内存扩展到硬盘空间。

现代处理器使用的是一种称为 虚拟寻址(Virtual Addressing) 的寻址方式。使用虚拟寻址，CPU需要将虚拟地址翻译成物理地址，这样才能访问到真实的物理内存。 实际上完成虚拟地址转换为物理地址转换的硬件是 CPU 中含有一个被称为 **内存管理单元（Memory Management Unit, MMU）**的硬件。MMU 需要借助存放在内存中的页表来动态翻译虚拟地址，该页表由操作系统管理。

索引是什么？

索引是一种用于快速定位和访问特定数据行的数据结构。它类似于书籍的目录，可以帮助数据库管理系统有效地查找和检索数据，从而提高查询性能。

聚簇索引和非聚簇索引区别和实现

聚簇索引（Clustered Index）：

数据存储方式： 聚簇索引决定了表中数据的物理排序顺序。表的数据行按照聚簇索引的键值顺序存储在磁盘上。因此，一个表只能有一个聚簇索引。
物理排序： 表的数据行按照聚簇索引的键值进行物理排序，这导致相邻的行在磁盘上也是相邻的。
查询性能： 聚簇索引通常可以提高范围查询的性能，因为相关的数据在物理上是相邻的。
表的重新组织： 当表的数据插入或更新时，可能需要重新组织表的物理存储，这可能导致性能开销。

非聚簇索引（Non-clustered Index）：

数据存储方式： 非聚簇索引中，索引和实际数据行是分开存储的。索引文件包含索引键及指向实际数据行的指针。
物理排序： 表的数据行在磁盘上的存储顺序与索引键的顺序无关。
查询性能： 非聚簇索引通常适用于频繁的查询和少量的插入、删除操作，因为插入和删除不会引起数据行的物理重组，但会引起索引得重新构建。
多个索引： 一张表可以有多个非聚簇索引。

聚簇索引和非聚簇索引查找数据方式

聚簇索引和非聚簇索引是数据库中两种不同的索引结构，它们影响着数据的存储和检索方式。

1. 聚簇索引：

存储方式：

数据存储与索引绑定： 在聚簇索引中，数据行的物理存储顺序与索引的顺序一致。聚簇索引实际上改变了表的物理存储顺序，使得数据行按照索引的顺序进行排列。

查找数据方式：

直接定位行： 由于数据行的物理存储顺序与索引一致，通过聚簇索引可以直接定位到存储数据的位置，因此聚簇索引的查找速度较快。
范围查询效率高： 范围查询效率高，因为相关的数据行在物理上也是相邻的。

适用场景：

频繁范围查询和顺序扫描： 适合那些经常需要范围查询或按顺序扫描的列，比如日期范围、序列号等。

2. 非聚簇索引：

存储方式：

数据与索引分开存储： 在非聚簇索引中，索引和实际数据行的存储是分离的。索引仅包含键值和对应数据行的引用，而实际数据行则存储在表的其他地方。

查找数据方式：

通过索引查找键值，再根据引用找到数据行： 非聚簇索引通过索引先定位到键值，然后再根据引用或指针找到实际的数据行。这就需要两次查找，一次在索引中，另一次在数据行中。

适用场景：

经常进行更新的列： 适合那些经常需要进行更新、插入和删除操作的列，因为聚簇索引的更新代价相对较高。

Mysql索引实现

在 MySQL 中，索引是通过不同的数据结构来实现的，其中最常见的是B树（B-tree）和哈希索引。具体选择哪种索引类型取决于数据的特性和查询需求。

B树索引（B-tree Index）：
- 类型： MySQL 中主要使用的索引类型是B树索引，包括B-tree和其变种如B+树。
- 特点： B树是一种自平衡的树状结构，具有良好的平衡性，适用于范围查询和排序等操作。
- 适用场景： B树索引适用于范围查询、排序和模糊查询等场景。
哈希索引（Hash Index）：
- 类型： MySQL 也支持哈希索引，但有一些限制，例如只能用于等值查询，不支持范围查询和排序。
- 特点： 哈希索引使用哈希函数将索引键映射到哈希表中的一个位置，查询时直接通过哈希计算定位。
- 适用场景： 哈希索引适用于等值查询，但不适合范围查询和排序等场景。
全文索引（Full-Text Index）：
- 类型： MySQL 还提供了全文索引，用于全文搜索操作。
- 特点： 全文索引支持对文本数据进行全文搜索，提供更灵活的文本匹配功能。
- 适用场景： 适用于需要对文本进行全文搜索的场景，如文章、博客等。
- 全文索引的实现通常使用的数据结构是倒排索引（Inverted Index）。倒排索引是一种将文档中的词汇与其出现位置之间建立关联的数据结构。它的基本思想是将文档中的每个词都映射到包含该词的文档列表，从而实现对文档的快速搜索。
空间索引（Spatial Index）：
- 类型： 适用于空间数据的索引。
- 特点： 空间索引用于优化对具有空间数据的表的空间查询。
- 适用场景： 适用于包含地理信息或几何对象的表。

like orderby走索引的情况

在 MySQL 中，使用 LIKE 和 ORDER BY 进行查询时，如果满足一定的条件，数据库可能会选择使用索引来提高查询性能。以下是一些可能使得 LIKE 和 ORDER BY 能够走索引的情况：

索引列的前缀匹配： 如果你的 LIKE 查询是在索引列的左边进行前缀匹配，数据库可能会使用索引。例如：
```
SELECT * FROM table_name WHERE indexed_column LIKE 'prefix%';
```
这种情况下，如果 indexed_column 有索引，数据库可能会使用该索引。
使用通配符前缀匹配： 如果 LIKE 查询使用通配符 % 作为后缀，而不是前缀，数据库可能无法充分利用索引。例如：
```
SELECT * FROM table_name WHERE indexed_column LIKE '%suffix';
```
这样的查询可能会导致索引无法优化。
ORDER BY 使用索引列： 如果你在 ORDER BY 子句中使用了索引列，并且查询条件中也使用了 LIKE，那么数据库可能会利用索引来进行排序。例如：
```
SELECT * FROM table_name WHERE indexed_column LIKE 'prefix%' ORDER BY indexed_column;
```
在这个例子中，如果 indexed_column 有索引，数据库可能会使用该索引来加速排序。

需要注意的是，每种情况都取决于具体的查询和数据库的优化器决策。在实际应用中，可以使用 EXPLAIN 语句来分析查询执行计划，以确定是否使用了索引。例如：

EXPLAIN SELECT * FROM table_name WHERE indexed_column LIKE 'prefix%' ORDER BY indexed_column;

这将显示查询的执行计划，你可以检查是否使用了索引。

给你一条sql你会怎么去优化它

当对 SQL 进行优化时，具体的优化方法取决于查询的结构、表的设计、索引的使用等多个因素。然而，以下是一些建议和通用的优化策略，可以根据具体情况调整：

使用合适的索引： 确保查询中的列上有适当的索引，尤其是用于连接和过滤的列。使用 EXPLAIN 语句来分析查询执行计划，查看是否使用了索引。
```
EXPLAIN SELECT * FROM your_table WHERE your_column = 'value';
```
避免全表扫描： 尽量避免在大表上执行没有索引的全表扫描。确保 WHERE 子句中的条件能够充分利用索引。
使用合适的数据类型： 使用更小的数据类型，可以减少磁盘存储和内存消耗。例如，选择合适的整数类型，避免使用过大的 VARCHAR。
谨慎使用 SELECT *： 只选择查询中真正需要的列，而不是使用 SELECT *。这可以减少数据传输和提高查询效率。
分页优化： 对于分页查询，使用 LIMIT 和 OFFSET，避免在应用层进行分页，以减少数据传输。另外，考虑使用游标或基于键的分页。
合理使用连接： 对于连接查询，确保连接条件使用了索引，避免笛卡尔积。选择合适的连接类型，如 INNER JOIN、LEFT JOIN 等。
查询重构： 优化查询语句的结构，使用子查询、联合查询等来优化查询逻辑。有时候将一个复杂的查询拆分为多个简单的查询能够更好地利用索引。
定期分析表和索引： 随着数据的变化，表的结构和索引的使用情况可能需要调整。定期进行表和索引的分析，以确保它们仍然满足查询的需要。
缓存查询结果： 如果一些查询的结果不经常变化，可以考虑使用缓存，以减轻数据库的负担。
数据库参数调整： 根据数据库引擎和具体的需求，调整数据库的配置参数，如缓冲池大小、连接池大小等。

需要注意的是，优化是一个复杂的过程，需要结合具体的数据库、表结构、数据量等因素进行综合考虑。在进行优化时，最好根据实际情况采用一种逐步优化的策略，先分析执行计划，找到性能瓶颈，再有针对性地进行优化。

redis的数据类型有哪些？

Redis 是一种基于内存的键值存储系统，支持多种数据类型。以下是 Redis 支持的主要数据类型：

字符串（String）：
- Redis 中最简单的数据类型，可以包含任何类型的数据，例如文本、二进制数据等。
- 常用命令：SET、GET、INCR、DECR 等。
哈希表（Hash）：
- 存储字段和与其关联的值，适用于存储对象。
- 常用命令：HSET、HGET、HDEL、HGETALL 等。
列表（List）：
- 有序的字符串元素集合，支持从两端进行元素的插入和删除。
- 常用命令：LPUSH、RPUSH、LPOP、RPOP、LRANGE 等。
集合（Set）：
- 无序的唯一元素集合，用于存储不重复的元素。
- 常用命令：SADD、SREM、SMEMBERS、SINTER 等。
有序集合（Sorted Set）：
- 类似于集合，但每个元素都关联了一个分数，用于按分数排序。
- 常用命令：ZADD、ZREM、ZRANGE、ZSCORE 等。
位图（Bitmap）：
- 由二进制位组成的数据结构，支持位运算。
- 常用命令：SETBIT、GETBIT、BITOP 等。
HyperLogLog：
- 用于近似计数的数据结构，可以估算一个集合中元素的数量。
- 常用命令：PFADD、PFCOUNT、PFMERGE 等。
地理位置（Geospatial）：
- 存储地理位置信息的数据结构，支持距离计算等地理信息操作。
- 常用命令：GEOADD、GEODIST、GEORADIUS、GEOHASH 等。

这些数据类型使得 Redis 成为一款非常灵活和强大的数据存储系统，开发者可以根据具体的应用场景选择合适的数据类型。每种数据类型都有对应的一系列命令和操作，通过这些命令可以实现对数据的存储、查询、修改等操作。

redis hashmap底层实现

在 Redis 中，哈希表（Hash Map）是通过字典（Dictionary）来实现的。字典是一种用于存储键值对的数据结构，而哈希表是字典的底层实现之一。

以下是 Redis 哈希表的一些基本特点和实现细节：

开放地址法解决冲突： Redis 使用开放地址法（Open Addressing）来解决哈希冲突。当发生冲突时，会尝试找到下一个可用的槽位，直到找到一个空槽位或者达到最大尝试次数。
哈希冲突处理： Redis 使用了MurmurHash2算法作为哈希函数，它在均匀分布和性能方面都有不错的表现。
rehash操作： 当哈希表的负载因子超过一定阈值时，Redis 会触发 rehash 操作，即将哈希表的大小扩大一倍，并将元素重新分布到新的表中。这个过程是原子的，不会中断对哈希表的操作。
压缩列表： 在哈希表的底层，当元素数量较小时，Redis 可以选择使用压缩列表（ziplist）来存储键值对，这能够更节省内存。
字典结构： 哈希表在 Redis 中实际上是字典结构，不仅用于实现 HASH 类型，还用于实现其他数据类型，例如 SET 类型。

总体而言，Redis 的哈希表实现是为了追求高效的查找、插入和删除操作，并在动态扩容时保持高性能。哈希表是 Redis 数据结构的核心之一，对于支持快速的键值查询和存储的场景提供了很好的性能。

OSI五层模型（TCP/IP五层模型）

物理层（Physical Layer）：
- 主要涉及传输媒介，如电缆、光纤、无线电波等。
- 负责在设备之间传输原始比特流。
数据链路层（Data Link Layer）：
- 通过物理层提供的原始比特流，将数据转换为帧。
- 处理物理地址（MAC地址）以及错误检测和纠正。
- 主要有两个子层：逻辑链路控制（Logical Link Control，LLC）和介质访问控制（Media Access Control，MAC）。
网络层（Network Layer）：
- 主要负责数据包的路由、寻址和分组转发。
- 使用IP地址进行设备的标识。
- 典型的协议包括IP（Internet Protocol）。
传输层（Transport Layer）：
- 提供端到端的通信，确保数据的可靠传输。
- 主要有两个主要的传输协议：TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。
应用层（Application Layer）：
- 提供网络服务和应用程序之间的接口。
- 包括各种协议，如HTTP、FTP、SMTP等，用于实现特定的网络应用。

讲一下进程和线程，进程间通信方式，线程通信方式

进程和线程：

进程（Process）：

一个进程是正在运行中的程序的实例。每个进程都有自己的独立内存空间、代码、数据和系统资源。
进程之间相互独立，一个进程的崩溃不会影响其他进程的稳定性。
进程拥有自己的地址空间，进程间通信需要使用特定的机制。

线程（Thread）：

一个线程是进程中的一个执行单元，共享相同的内存空间和系统资源。
线程是轻量级的，相对于进程来说，线程的创建和切换开销较小。
线程之间可以共享数据，但也需要考虑同步和互斥问题。

进程间通信方式：

管道（Pipe）：
- 一种半双工通信方式，允许一个进程向管道写入数据，另一个进程从管道读取数据。
- 可以是匿名管道，也可以是命名管道。
消息队列（Message Queue）：
- 进程之间通过消息传递进行通信，消息队列是消息的缓冲区。
- 进程可以通过消息队列向其他进程发送消息，接收进程从队列中读取消息。
共享内存（Shared Memory）：
- 多个进程共享同一块内存区域，一个进程对共享内存的写入会立即影响到其他进程。
- 需要使用同步机制（如信号量）来避免竞态条件。
信号量（Semaphore）：
- 用于控制多个进程对共享资源的访问。
- 通过对信号量的操作来实现进程的同步和互斥。
套接字（Socket）：
- 通过网络编程实现进程间通信，可以在同一台机器上或网络上的不同机器上通信。

线程通信方式：

共享内存：
- 多个线程可以访问和修改共享的内存区域。
- 需要使用同步机制（如互斥锁、信号量）来避免竞态条件。
互斥锁（Mutex）：
- 用于保护共享资源，确保同时只有一个线程可以访问。
- 一旦一个线程获得互斥锁，其他线程必须等待释放锁后才能访问。
条件变量（Condition Variable）：
- 用于线程之间的通信，一个线程可以等待条件变量的特定条件成立。
- 当其他线程满足条件时，可以通知等待的线程。
信号量（Semaphore）：
- 与进程通信中的信号量类似，用于控制多个线程对共享资源的访问。
消息队列：
- 线程之间通过消息传递进行通信，类似于进程间通信中的消息队列。

这些通信方式提供了不同的机制，开发者可以根据具体的需求选择适当的方式来实现进程间或线程间的通信。

什么是装饰器模式

装饰器模式（Decorator Pattern）是一种结构型设计模式，它允许你通过将对象放入包含行为的特殊包装类中来为原始对象添加新的行为。装饰器模式提供了一种灵活的替代方式，相比继承，它更加动态且不影响其他对象。

在装饰器模式中，有一个抽象组件（Component），它是一个接口或抽象类，定义了一些基本操作。然后有一个具体组件（ConcreteComponent），它是实现抽象组件接口的具体类。接下来，有一个抽象装饰器（Decorator），它也是抽象组件的子类，但它持有一个对具体组件的引用。最后，有具体装饰器（ConcreteDecorator），它实现了抽象装饰器的方法，并可以在调用这些方法前后执行额外的操作。

通过这种方式，你可以在运行时动态地添加新的行为，而不需要修改已有的代码。这使得装饰器模式成为一种灵活且可扩展的设计模式，特别适用于需要在不同情境下组合对象功能的场景。

在许多编程语言中，装饰器模式被广泛应用，例如在 Python 中的函数装饰器，或在 Java 中的 I/O 流操作中。

数据库事务的四种隔离级别

数据库事务（简称：事务）是数据库管理系统执行过程中的一个逻辑单元，由一个有限的数据库操作序列构成。——维基百科
简而言之：一系列数据库操作语句组成事务。
数据库事务的隔离级别有四种：

读未提交（Read Uncommitted）：事务中的修改可以被其他事务读取，即一个事务可以读取到另一个未提交事务修改的数据。
简而言之：一个事务可以读到其他事务修改了但未提交的数据。

读已提交（Read Committed）：事务只能读取已经提交的数据，不能读取未提交的数据。在该隔离级别下，事务只能读取到已经提交的数据，因此会避免脏读的情况。（脏读的概念可以参考本栏其他博客）
简而言之：数据的读取只能读取已经提交过的数据，和读未提交相比，读未提交可以读取修改了单位提交的数据。而读已提交则不行，因此避免了脏读的情况。

可重复读（Repeatable Read）：在一个事务中多次读取同一个数据时，能够保证读取到的数据一致，即使其他事务修改了该数据。在隔离级别下，事务在读取数据时会锁定该数据，其他事务不能修改该数据，因此可以避免脏读和不可重复读的情况。
本人理解：应该用锁将写操作锁定，可以重复读取且数据保持一致。

串行化（Serializable，序列化）：最高的隔离级别，它保证所有事务之间的执行顺序按照某个顺序执行，避免了所有并发问题。在该隔离级别下，事务之间互相等待，直到前一个事务执行完成后才能执行下一个事务，因此可以避免脏读、不可重复读和幻读的情况。
将事务串行化，一次只能按照特定顺序执行一个事务，因为只执行一个事务，会避免很多问题，但是肯定会降低执行效率。

数据库的Buffer Pool

数据库的 Buffer Pool 是一种缓存机制，用于管理数据库系统中的页（Page）。数据库系统通过 Buffer Pool 将磁盘上的页缓存在内存中，以提高对数据的访问速度。当需要访问某个页时，数据库首先检查该页是否已经在 Buffer Pool 中，如果是，则直接从内存中获取，否则需要从磁盘读取到 Buffer Pool 中。

以下是数据库 Buffer Pool 的一般实现方式：

页的管理： Buffer Pool 会维护一个固定大小的内存区域，被划分为若干个页框（Page Frame）。每个页框的大小通常与磁盘页的大小相同。这些页框用于存储从磁盘读取的页。
缓存替换算法： 当需要将一个新的页加载到 Buffer Pool 中而没有足够的空闲页框时，就需要选择一个旧的页进行替换。为了提高缓存的效率，需要使用一些缓存替换算法，例如 LRU（Least Recently Used，最近最少使用）、LFU（Least Frequently Used，最不经常使用）等。
读取和写入管理： 当需要访问某个页时，数据库首先在 Buffer Pool 中查找，如果找到就直接返回；如果没有找到，则从磁盘读取到一个空闲的页框中。在修改了页的内容后，可能需要将修改的页写回到磁盘，这种写回策略可以是同步或异步的，具体取决于数据库系统的设计。
页的固化和刷新： 数据库系统通常会将一些经常使用的页保留在 Buffer Pool 中，而不是立即写回磁盘。这些页被称为脏页（Dirty Page）。当需要释放页框时，系统可能会选择先将脏页写回磁盘，以确保数据的一致性。
页的锁定和并发控制： 在多用户环境中，多个事务可能同时访问相同的数据页。因此，需要实施适当的并发控制机制，例如页级锁定，以确保数据的一致性和隔离性。

具体实现细节可能因数据库管理系统而异，但上述原理是通用的。不同的数据库系统可能有不同的优化和改进，以适应不同的应用场景和性能需求。

8个排序算法时间复杂度

以下是八个常见的排序算法的介绍，以及它们的平均时间复杂度：

冒泡排序（Bubble Sort）:
- 原理： 通过比较相邻元素并交换顺序，将最大（或最小）元素逐步移动到最后。
- 时间复杂度： 平均O(n^2)，最坏O(n^2)。
选择排序（Selection Sort）:
- 原理： 通过每次选择最小（或最大）元素放到已排序部分的末尾。
- 时间复杂度： 平均O(n^2)，最坏O(n^2)。
插入排序（Insertion Sort）:
- 原理： 通过逐步构建有序序列，对于未排序数据，在已排序序列中从后向前扫描，找到相应位置并插入。
- 时间复杂度： 平均O(n^2)，最坏O(n^2)。
快速排序（Quick Sort）:
- 原理： 通过选择一个基准元素，将数组分为两个子数组，小于基准的放左边，大于基准的放右边，然后对子数组递归进行快速排序。
- 时间复杂度： 平均O(n log n)，最坏O(n^2)。
归并排序（Merge Sort）:
- 原理： 将数组分成两半，分别对两半进行排序，然后将已排序的两半合并。
- 时间复杂度： 平均O(n log n)，最坏O(n log n)。
堆排序（Heap Sort）:
- 原理： 构建最大堆或最小堆，然后逐步将堆顶元素与末尾元素交换，再重新调整堆。
- 时间复杂度： 平均O(n log n)，最坏O(n log n)。
希尔排序（Shell Sort）:
- 原理： 将数组分成若干个子序列，分别进行插入排序，然后逐步减小子序列长度，最终进行一次插入排序。
- 时间复杂度： 平均O(n log n) - O(n^2)，最坏O(n^2)。
计数排序（Counting Sort）:
- 原理： 统计数组中每个元素出现的次数，然后根据统计信息将元素放回数组。
- 时间复杂度： 平均O(n + k)，其中k是数据范围。

每种排序算法都有其适用的场景和性能特点，选择排序算法应该根据具体的需求和数据特征来进行。

数据库是怎么进行死锁检测

死锁检测是数据库管理系统用来识别并解决事务之间发生死锁的一种机制。死锁是指两个或多个事务因为彼此持有对方需要的资源而无法继续执行的状态。

数据库系统通常使用以下方法进行死锁检测：

等待图（Wait-for Graph）： 数据库系统维护一个等待图，图中的节点表示事务，有向边表示一个事务等待另一个事务持有的资源。当一个事务请求某个资源时，系统会检查是否形成了环路，如果形成了环路，就说明发生了死锁。
超时机制： 数据库系统为每个事务设置一个超时时间。如果一个事务在规定的时间内未能成功获取所需资源，系统会认为该事务可能发生了死锁，将其回滚并释放已经持有的资源。
事务等待超限： 数据库系统会跟踪每个事务等待资源的时间。当一个事务等待的时间超过一定的限制时，系统可以认为它可能处于死锁状态，采取相应的措施，如回滚事务。
周期检测： 数据库系统使用图论算法对等待图进行周期检测。如果等待图中存在环路，且环路中的事务都在等待对方持有的资源，那么就认为发生了死锁。
资源分配图： 死锁检测也可以通过资源分配图来实现。每个节点表示事务，每个资源表示一个资源对象。资源分配图中包含了哪个事务持有了哪个资源以及哪个事务等待哪个资源的信息。死锁发生时，资源分配图中会形成环路。

死锁检测通常是一个开销较大的操作，因此不是所有的数据库系统都启用死锁检测机制。一些数据库系统更倾向于使用死锁预防（如加锁顺序规定）、死锁避免（如银行家算法）等策略来减少死锁的发生。选择何种死锁处理策略通常取决于数据库系统的设计和使用场景的要求。

ThreadLocal是什么

ThreadLocal 是一个 Java 中的类，用于在多线程环境下存储线程局部变量。线程局部变量是指对于同一个变量，每个线程都有其自己独立的副本，彼此之间互不影响。ThreadLocal 提供了一种简单的方式来管理线程的局部变量，使得每个线程都可以独立地操作自己的变量副本，而不会干扰其他线程的副本。

在 Java 中，每个线程都有自己的线程栈，线程栈中的局部变量是线程私有的。ThreadLocal 则提供了一个在多线程环境中访问共享变量的机制，而不需要额外的同步措施。

使用 ThreadLocal 的主要步骤包括：

创建 ThreadLocal 对象。
通过 ThreadLocal 对象的 set 方法设置当前线程的局部变量值。
通过 ThreadLocal 对象的 get 方法获取当前线程的局部变量值。
在不再需要使用时，可以通过 ThreadLocal 对象的 remove 方法清除当前线程的局部变量值。

ThreadLocal原理

ThreadLocal 的实现原理涉及到 Java 中线程的存储结构和 ThreadLocal 类本身。下面是 ThreadLocal 的基本实现原理：

ThreadLocal类结构： ThreadLocal 类包含一个静态内部类 ThreadLocalMap，该类用于存储线程局部变量。每个 ThreadLocal 对象都有一个对应的 ThreadLocalMap 实例。
ThreadLocalMap： ThreadLocalMap 是 ThreadLocal 类的静态内部类，用于存储线程局部变量。这个类实际上是一个自定义的哈希表，其中的键是 ThreadLocal 对象，值是对应线程的局部变量。
ThreadLocal对象作为键： 在 ThreadLocalMap 中，ThreadLocal 对象实际上是作为键存储的。这样，每个 ThreadLocal 对象都可以对应一个线程的局部变量。
线程与ThreadLocalMap的关系： 每个线程都有一个 ThreadLocalMap 的实例，用于存储该线程的所有 ThreadLocal 变量。线程在访问 ThreadLocal 变量时，实际上是通过 ThreadLocalMap 来获取和设置值。
哈希冲突的处理： 由于多个 ThreadLocal 对象可能被多个线程同时使用，因此可能存在哈希冲突的情况。ThreadLocalMap 使用开放地址法来解决哈希冲突，确保每个 ThreadLocal 对象都能正确映射到对应线程的局部变量。
内存泄漏的防范： 由于 ThreadLocal 存储在线程的局部变量中，如果没有及时清理，可能会导致内存泄漏。为了防范这种情况，ThreadLocal 使用了弱引用（WeakReference）来引用 ThreadLocalMap 中的键，这样在发生垃圾回收时，可以正确释放不再被引用的 ThreadLocal 对象。

Mysql存储引擎有哪些，区别是什么

InnoDB:
- 事务支持： InnoDB 是 MySQL 的默认存储引擎，提供了对事务的支持（ACID 兼容）。
- 行级锁： InnoDB 使用行级锁定，这有助于提高并发性和减少锁定冲突。
- 外键支持： InnoDB 支持外键约束，确保关联表之间的数据完整性。
MyISAM:
- 表级锁： MyISAM 使用表级锁定，这意味着在写入操作时，整个表被锁定，可能导致并发性较低。
- 不支持事务： MyISAM 不支持事务，因此不适合需要事务支持的应用。
- 全文本搜索： MyISAM 对全文本搜索有较好的支持。
MEMORY (HEAP):
- 基于内存： 将表存储在内存中，适用于临时表或小型缓存表。
- 表级锁： 使用表级锁定，可能导致并发性较低。
- 数据不持久： 数据在数据库重启时丢失。
Archive:
- 高压缩： 使用压缩算法存储数据，适用于大量历史数据的存档。
- 只支持 INSERT 和 SELECT： 不支持 UPDATE、DELETE，不适合频繁更新的表。
CSV:
- 以 CSV 格式存储数据： 适用于将数据以 CSV 格式导入导出。
- 不支持索引： 不支持索引，性能较差。
Blackhole:
- 数据被忽略： 对于插入的数据，Blackhole 引擎会将其忽略，适用于复制或数据传递。
NDB (Cluster):
- 分布式数据库： 提供分布式数据库的支持，用于构建 MySQL 集群。
- 事务和并发： 支持事务和高度并发的处理。

一致性哈希

一致性哈希（Consistent Hashing）是一种分布式哈希算法，用于解决在动态环境下，节点的加入或离开导致的数据重分布问题。这种算法在构建分布式系统中的负载均衡和数据存储方面非常有用。

基本思想是将整个哈希空间划分为一些虚拟的槽位，每个节点或服务器被映射到这个哈希环上的一个或多个槽位。当有新节点加入或离开系统时，只需要对受影响的槽位进行重新映射，而不是对整个数据集进行重新分配。

具体步骤如下：

哈希环： 将哈希空间表示为一个环状结构，通常使用哈希函数将节点映射到环上的一个位置。
节点映射： 每个服务器节点通过哈希函数映射到环上的一个位置，可以映射到多个虚拟槽位。
数据映射： 数据通过哈希函数映射到环上的一个位置。在找到数据所在位置后，可以顺时针或逆时针找到最近的节点，将数据存储或访问。
节点变化： 当节点加入或离开系统时，只需重新映射受影响的槽位，而不需要重新映射所有数据。

优点：

平滑扩展： 当节点数量变化时，只有一小部分数据需要重新分配，而不是整个数据集。
负载均衡： 数据在哈希环上均匀分布，提高了负载均衡性。
简单性： 实现相对简单，容易理解和部署。

一致性哈希在构建分布式缓存系统、分布式数据库和负载均衡器等方面得到了广泛应用。

goroutine 里面 panic 了会怎么样

在Go语言中，当一个goroutine发生panic时，会导致整个程序崩溃，但是Go提供了一种机制来捕获并处理panic，以便程序在遇到错误时能够执行一些清理工作。

默认行为： 如果一个goroutine发生了panic，它会导致整个程序崩溃，并输出panic信息，包括panic发生的位置、调用堆栈等。这有助于开发人员及时发现问题并进行调试。
Recover： Go语言提供了recover函数，它用于在defer语句中捕获panic。recover可以阻止panic继续传播，使程序可以继续执行。通常，recover被用于在defer语句中捕获panic，并在发生panic时执行一些清理工作。

func example() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r)
            // 可以在这里执行一些清理工作
        }
    }()
    
    // 一些可能导致panic的代码
    // ...
}