Java面试八股文-2024

面试指南

TMD，一个后端为什么要了解那么多的知识，真是服了。啥啥都得了解

---

MySQL

MySQL索引可能在以下几种情况下失效：

1. 不遵循最左匹配原则：在联合索引中，如果没有使用索引的最左前缀，即查询条件中没有包含联合索引的第一列，那么索引将会失效。
2. 使用了OR操作符：即使在查询条件中使用了联合索引的全部列，如果这些列之间是使用OR操作符连接的，索引也可能会失效。
3. 数据类型转换：如果在查询条件中对字段进行了隐式的类型转换，比如将字符类型的字段与数字进行比较，这可能导致索引失效。
4. 使用了函数或表达式：在查询条件中对字段使用了函数或表达式，如WHERE YEAR(date_column) = 2023，这样会使得索引失效。
5. 选择性低的索引：如果索引的选择性很低，即索引列的值重复率很高，数据库优化器可能会选择全表扫描而不是使用索引。
6. 索引列上有函数或计算：当索引列上有函数或计算时，MySQL无法使用索引来查找行。
7. 全表扫描更快的情况：当MySQL优化器估计出全表扫描比使用索引更快时，系统会选择不使用索引。这通常发生在表中数据量较少，或者查询返回大部分甚至所有行的情况下。

总的来说，索引失效可能会导致查询性能下降，因此在设计查询语句和索引时需要特别注意以上情况，以确保索引能够发挥其应有的作用。

索引不适合哪些场景

1. 数据量少的不适合加索引
2. 更新比较频繁的也不适合加索引
3. 区分度低的字段不适合加索引（如性别）

日常工作中你是怎么优化 SQL 的？

在日常工作中使用SQL时，优化是一个持续的过程，旨在确保数据库查询的效率和性能。以下是一些常见的优化策略：

1. 使用EXPLAIN分析查询：

   • 使用EXPLAIN命令来分析SQL语句的执行计划，从而理解MySQL如何执行查询，哪些地方可能成为瓶颈。

2. 正确地创建和使用索引：

   • 确保为经常用于搜索和排序的列创建索引。
   • 避免创建不必要的索引，以减少插入、更新和删除操作的成本。
   • 使用复合索引来优化多列的查询条件。
   • 定期审查现有索引的有效性，删除不再使用的索引。

3. 编写高效的SQL语句：

   • 避免在WHERE子句中对字段进行函数转换或计算。
   • 减少使用OR操作符，尤其是在索引列上，因为它可能导致全表扫描。
   • 使用连接（JOIN）而不是子查询，以便更有效地利用索引。
   • 仅选择需要的列，而不是使用SELECT *。

4. 优化数据模型：

   • 规范化表结构以避免数据冗余。
   • 在必要时使用反规范化来减少连接操作，提高查询性能。

5. 使用分区和分表：

   • 对于大型表，考虑使用分区来提高查询性能。
   • 在数据量非常大的情况下，可以考虑分表来分散负载。

6. 调整数据库配置：

   • 根据服务器的硬件资源和应用需求调整MySQL的配置参数，如缓冲池大小、连接数等。

7. 监控和诊断：

   • 使用慢查询日志来识别低效的查询。
   • 使用性能监控工具来跟踪数据库的性能指标。

8. 批量操作和事务控制：

   • 使用批量操作来减少数据库的I/O次数。
   • 合理使用事务，确保数据的一致性，同时避免长事务导致的锁竞争。

9. 避免使用锁定的查询：

   • 尽量使用读已提交隔离级别，避免不必要的行级锁。

10. 定期维护：

    • 定期运行OPTIMIZE TABLE来整理表空间，特别是对于经常修改的表。
    • 定期检查并修复表的错误。

11. 学习和使用新的数据库特性：

    • 保持对MySQL新特性的了解，如窗口函数、CTE（公共表表达式）等，这些可以帮助编写更高效的查询。

通过上述方法，可以显著提高SQL查询的性能。然而，每个数据库和应用场景都是独特的，因此可能需要根据具体情况调整优化策略。

MySQL InnoDB页的查询原理

在InnoDB存储引擎中，数据是按页存储的，查询原理涉及以下几个关键点：

1. 页的组织：每个数据页默认大小为16KB，并且这些页在物理磁盘和内存（缓冲池）之间以页为单位进行数据交换。
2. 链表结构：数据页之间通过双向链表连接，这有助于快速扫描数据。而数据记录本身则通过单向链表连接。
3. 索引结构：InnoDB使用B+树作为索引结构，其中主键构成的聚集索引是最为关键的。在B+树的叶子节点上直接存储了数据，这意味着根据主键查找非常高效。
4. 查询过程：当执行一个基于主键范围的查询时，例如SELECT * FROM user WHERE id >= 18 AND id < 40，InnoDB引擎会遍历相应的B+树叶子节点上的记录，这些叶子节点包含了指向实际数据页的指针。通过这些指针，就可以快速定位并读取所需的数据页到内存中。
5. 表空间和存储结构：InnoDB将数据逻辑地存放在一个称为表空间的结构中，表空间由段、区和页组成。表空间是管理数据的文件的逻辑容器，它可以是系统的也可以是用户定义的。
6. 性能优化：由于磁盘I/O相对较慢，InnoDB通过缓冲池机制来减少对磁盘的频繁访问。它会将经常访问的页缓存在内存中，以此提高查询效率。

综上所述，InnoDB的查询原理依赖于其精心设计的数据结构和算法，确保了即使在面对大量数据时也能保持高效的查询性能。了解这些原理对于数据库的性能调优是非常重要的。

在InnoDB中，数据是按页为单位进行存储的，一个页的大小通常是16KB。

InnoDB是MySQL的默认存储引擎，它使用页作为管理存储空间的基本单位。每个数据页的大小固定为16KB，这是InnoDB磁盘和内存交互的基本单位。页的结构可以大致划分为七个部分，其中包括用于存放用户记录（User Records）的空间。当有新的记录插入时，会从页中的空闲空间（Free Space）分配相应的大小到用户记录部分，直到空闲空间被全部占用。

此外，InnoDB中的页不仅仅有一种类型。例如，存放插入缓冲（Insert Buffer）的页、存放撤销日志（Undo Log）的页、存放系统信息的页等。其中，存放表数据的页被称为索引页或数据页。了解页结构对于优化数据库性能和理解InnoDB的工作机制非常重要。

什么是最左前缀原则

最左前缀索引是一种在数据库中用于优化多列索引查询的技术。

在创建联合索引（即包含多个列的索引）时，最左前缀索引要求查询条件必须包含索引的最左侧列，这样才能充分利用索引的优势来提高查询性能。这是因为数据库系统在处理联合索引时，会按照从左到右的顺序来构建索引结构，每个前缀都可以被视为一个独立的索引。例如，如果有一个联合索引包含列A、列B和列C，那么实际上它会包含三个索引：(A)、(A, B)和(A, B, C)。当执行查询时，只有当查询条件包含了最左侧的列（在这个例子中是列A），才能使用到这个联合索引。

最左前缀索引的使用有以下几个要点：

1. 查询条件的顺序：查询条件需要遵循索引中列的顺序，从左到右进行匹配。
2. 索引的利用：只有当查询条件满足最左前缀原则时，才能充分利用联合索引的优势。
3. 索引的创建：在创建联合索引时，应该考虑最常用的查询模式，将最常用于查询条件的列放在联合索引的最左侧。

总的来说，了解最左前缀索引对于数据库的性能优化至关重要，因为它可以确保在多列查询时能够有效地使用索引，从而加快查询速度。在设计数据库表和索引时，应当充分考虑查询模式，合理地设置联合索引的列顺序，以便最大化地利用最左前缀索引带来的性能优势。

什么是前缀索引

前缀索引是一种数据库优化技术，通过为列的部分信息（前缀）添加索引来提高查询效率和减少索引文件的大小。

以下是前缀索引的一些关键信息：

1. 定义：前缀索引是指在数据库中为某个字段的前面几个字符创建索引，而不是为整个字段值创建索引。
2. 优势：前缀索引可以有效减小索引文件的大小，从而提高索引查询的速度，尤其是在处理大型数据表时。
3. 适用条件：当前缀部分具有较高区分度时，即不同的记录在前缀部分有较多不同值时，前缀索引更加有效。
4. 创建方法：在MySQL中，可以通过ALTER TABLE或CREATE INDEX语句指定前缀长度来创建前缀索引。
5. 局限性：使用前缀索引时，不能在某些操作中使用，如ORDER BY、GROUP BY以及覆盖索引，因为只有部分字段被索引。
6. 选择前缀长度：选择合适的前缀长度是一个关键因素，需要通过计算字段值的区分度来确定。区分度越高，所需的前缀长度越短。
7. 示例应用：例如，如果要为user表中的email字段的前10个字符创建索引，可以使用类似以下的SQL语句：

CREATE INDEX idx_email_prefix ON user(email(10));
1

总的来说，前缀索引是一种在数据库性能优化中常用的技术，它可以在保证查询效率的同时减少索引的存储空间。然而，它并不适用于所有场景，需要根据具体的数据特性和查询需求来决定是否使用以及如何使用前缀索引。

OPTIMIZE TABLE 是什么？

OPTIMIZE TABLE是MySQL中用于改善表性能的命令。它的主要作用是整理表的空间使用，减少碎片，提高数据访问效率。在表中进行大量插入、删除或更新操作后，可能会产生空间碎片，导致表的性能下降。使用OPTIMIZE TABLE命令可以重新组织表的数据，释放未使用的空间，让数据更紧凑地存储。

以下是使用OPTIMIZE TABLE的基本语法：

OPTIMIZE TABLE table_name;
1

其中，table_name是要优化的表的名称。

OPTIMIZE TABLE命令执行的操作包括：

1. 整理表空间：通过整理表的磁盘空间，减少碎片，使得数据行紧密排列，从而提高I/O效率。
2. 更新统计信息：更新表的统计信息，帮助优化器选择更有效的执行计划。
3. 重建索引：如果表的索引已经损坏或者因为碎片而效率低下，OPTIMIZE TABLE可以重建索引，提高索引的效率。
4. 减少文件碎片：对于使用InnoDB存储引擎的表，OPTIMIZE TABLE可以减少文件碎片，提高空间利用率。

需要注意的是，OPTIMIZE TABLE命令需要对表具有一定的锁定时间，在此期间表无法进行写入操作。因此，建议在系统负载较低的时段执行此命令，以减少对应用的影响。

此外，对于使用InnoDB存储引擎的表，OPTIMIZE TABLE命令的效果可能不如预期，因为InnoDB会自动进行页的合并和分裂来管理碎片。在这种情况下，可以考虑使用ALTER TABLE命令来更改表的压缩模式，以提高空间利用率和性能。

InnoDB 与 MyISAM 的区别

下面是InnoDB和MyISAM两种存储引擎在关键特性上的对比表格：

注意：这个表格中的信息可能随着MySQL版本的更新而有所变化。例如，InnoDB在MySQL 5.6版本以后开始支持全文索引，但通常认为MyISAM在全文索引方面更为成熟。此外，MyISAM由于其设计简单，在某些读密集的场景下可能有较好的性能表现，但随着现代硬件的发展和多核处理器的普及，InnoDB的性能优势愈发明显。

数据库索引的原理，为什么要用 B+树？

数据库索引的原理是利用数据结构对数据进行排序，以便快速查找。在数据库中，B+树是最常用的索引结构，因为它具有以下优点：

1. 减少磁盘I/O操作：B+树的设计能够有效地减少访问节点的次数，因为每个节点可以存储多个元素，这意味着在查找过程中需要的磁盘I/O操作更少。每次磁盘访问都是昂贵的，因此减少I/O操作次数对于性能至关重要。
2. 增加存储效率：B+树的非叶子节点不存储数据，只存储索引，而所有数据都保存在叶子节点中。这样的设计使得每个节点可以存储更多的索引，从而使整个树的高度降低，进一步减少了I/O操作的次数。
3. 提高查询稳定性：由于所有数据都存在于叶子节点，并且叶子节点之间通过链表连接，这使得范围查询更加高效。在B+树中进行范围查询时，只需遍历叶子节点的链表即可，而在二叉树中可能需要进行二次遍历。
4. 方便数据插入和删除：B+树的结构允许在不影响其他部分的情况下插入和删除数据，这有助于保持树的平衡，从而维持高效的查询性能。

为什么不用一般二叉树？

不使用一般二叉树作为数据库索引的主要原因在于磁盘I/O操作和存储效率。让我们具体来看一下这些方面：

1. 磁盘I/O操作：一般二叉树的节点只包含两个子节点的引用（在二分查找的情况下）以及数据，这意味着每次查找都可能涉及到对磁盘的多次访问。因为数据库系统通常运行在磁盘上，而不是内存中，所以减少对磁盘的访问次数是提高性能的关键。

2. 存储效率：一般二叉树的节点存储了数据以及指向子节点的指针，这导致存储密度较低。相比之下，B+树的非叶子节点仅存储键值，没有实际的数据，这使得每个节点可以拥有更多的键，降低了树的高度，提高了存储效率。

3. 分支因子：由于二叉树的结构限制，每个节点只有两个分支。在B+树中，每个节点可以有更多的分支，这增加了分支因子，并减少了树的高度。

4. 查询性能稳定性：在二叉树中，范围查询可能会导致性能不稳定，因为需要遍历多个不连续的节点。而在B+树中，由于所有叶子节点通过指针连接成一个有序链表，范围查询的性能更为稳定。

5. 维护成本：一般二叉树在插入和删除操作后可能需要重新平衡，这个过程可能相对复杂。B+树通过其设计来简化节点的分裂和合并过程，使得维护成本更低。

因此，虽然一般二叉树在理论的查找效率上可能与B+树相当，但在实际的数据库系统中，B+树提供了更好的性能，特别是在处理大量数据时，能够提供更高的数据访问效率和更低的存储成本。

为什么不是平衡二叉树？

不使用平衡二叉树作为数据库索引的原因主要在于磁盘I/O操作的优化和范围查询的效率。B+树相对于平衡二叉树有以下优势：

1. 减少磁盘I/O操作：B+树的高度较低，通常在2-4层之间，这意味着在查找记录时最多只需要2-4次磁盘I/O操作。而平衡二叉树的高度通常会更高，因为它每个节点只存储一个数据项，这会导致更多的磁盘访问，从而降低了性能。
2. 提高范围查询效率：B+树的叶子节点通过指针连接成一个有序链表，这使得进行范围查询时非常高效。例如，在查找大于等于某个值的所有数据时，一旦找到该值，就可以通过叶子节点的指针连续获取所有相关数据，而不需要像在平衡二叉树中那样回溯到父节点。
3. 增加存储效率：B+树的非叶子节点不存储实际数据，只存储键值，这样可以在每个节点中存储更多的键，从而降低树的整体高度。平衡二叉树的每个节点存储了数据，这限制了每个节点的键数，导致树的高度增加。
4. 方便数据插入和删除：B+树的结构允许在不影响其他部分的情况下插入和删除数据，这有助于保持树的平衡，而平衡二叉树在插入和删除数据时需要更多的旋转操作来维持平衡，这会增加维护成本。

综上所述，虽然平衡二叉树提供了快速的查找性能，但是B+树在数据库索引中更为常用，因为其结构更加适合磁盘I/O的特性，并且在处理范围查询时更加高效。

为什么不是 B 树？

数据库索引选择使用B+树而不是B树，主要是因为B+树在磁盘I/O操作和存储效率方面具有更明显的优势。具体分析如下：

1. 磁盘I/O优化：B+树通过增加分支因子，减少树的高度，从而减少了查找数据时所需的磁盘I/O次数。由于磁盘读取是相对较慢的操作，这种优化对于性能至关重要。
2. 提高查询效率：B+树的所有叶子节点都在同一层，并且通过指针相连，这为范围查询提供了便利。在B树中，范围查询可能需要多次遍历不同层的节点，效率较低。
3. 减少内存开销：B+树的非叶子节点不存储实际数据，只存储键值，这样可以减少内存的使用，提高缓存的效率。
4. 方便维护：B+树的叶子节点包含所有键值，而非叶子节点仅作为索引，这使得节点的分裂和合并操作更加简单，便于维护。

总的来说，虽然B树和B+树都是平衡多路查找树，但是B+树在数据库索引中的应用场景下，因其结构特点，提供了更好的性能优势。这也是为什么关系型数据库普遍采用B+树作为索引结构的原因。

总结

综上所述，B+树通过其特有的结构优势，能够提供更高效的数据访问路径，尤其是在处理大量数据时，这些优势使得B+树成为数据库索引的首选结构。

事务的隔离级别有哪些？

• 读未提交（Read Uncommitted）
• 读已提交（Read Committed）
• 可重复读（Repeatable Read）
• 串行化（Serializable）

MySQL 的默认隔离级别是什么？

Mysql 默认的事务隔离级别是可重复读(Repeatable Read)

MySQL中的Explain命令

MySQL中的Explain命令用于查看查询的执行计划。

Explain命令在MySQL中扮演着重要的角色，它能够帮助开发者理解SQL语句的执行路径和成本，从而对查询进行优化。使用Explain非常简单，只需在SQL查询语句前加上EXPLAIN关键字即可。Explain的结果会以表格形式返回，展示查询执行的细节信息。从MySQL 5.6版本开始，Explain也支持非SELECT语句的解释。

Explain输出结果中包含多个字段，每个字段代表不同的信息：

1. id：标识每个SELECT子句的唯一ID。
2. select_type：表示查询的类型，例如简单查询、主查询、子查询等。
3. table：指出查询将访问哪张表。
4. type：显示了如何查找数据，比如全表扫描、索引扫描或者范围扫描等。
5. possible_keys：可能应用在这张表上的索引。
6. key：实际使用的索引。如果为NULL，则没有使用索引。
7. key_len：使用的索引的长度。
8. ref：哪个字段或常数与key一起被使用。
9. rows：预计需要读取的行数，这个数值越小，表明查询效率越高。
10. filtered：过滤后剩余的行数百分比，这个值越大越好。
11. extra：额外的信息，比如是否使用了临时表、是否进行了排序等。

总之，通过分析这些字段的内容，我们可以了解查询的性能瓶颈所在，并据此采取相应的优化措施，如添加或调整索引、改写查询逻辑等。

如果某个表有近千万数据，CRUD 比较慢，如何优化？

如果某个表有近千万数据，CRUD操作比较慢，可以考虑以下几种优化方法：

1. 索引优化：为经常用于查询条件的字段创建索引，可以加快查询速度。但是要注意不要创建过多的索引，因为索引也会占用存储空间和影响写入性能。

2. 分库分表：将数据分散到多个数据库或表中，可以提高并发处理能力和扩展性。可以根据业务需求选择合适的分库分表策略，如按照时间、地域、用户等进行分片。

3. 读写分离：将读操作和写操作分别分配给不同的数据库服务器，可以提高系统的并发处理能力。可以通过主从复制或者使用专门的读写分离中间件实现。

4. 缓存优化：将热点数据缓存在内存中，可以减少对数据库的访问次数，提高系统性能。可以使用分布式缓存框架如Redis来实现。

5. SQL优化：优化SQL语句，避免使用子查询、临时表等可能导致性能下降的操作。可以使用Explain命令分析SQL执行计划，找出性能瓶颈并进行优化。

6. 硬件升级：增加服务器的内存、CPU等硬件资源，可以提高系统的处理能力。

7. 数据库参数调优：根据服务器的硬件配置和业务需求，调整数据库的参数设置，如缓冲区大小、连接数等，以提高数据库的性能。

8. 数据压缩：对存储的数据进行压缩，可以减少存储空间的占用，提高I/O效率。

9. 分区表：将大表分成多个小表，可以提高查询性能。可以根据业务需求选择合适的分区键，如按照时间、地域等进行分区。

10. 垂直拆分：将一个大表拆分成多个小表，每个小表只包含部分字段，可以减少查询时需要扫描的数据量，提高查询速度。

总之，针对具体的业务场景和系统状况，可以采用多种方法进行优化，以达到提高CRUD性能的目的。

Mysql 主从复制原理

MySQL主从复制是一种数据同步机制，允许数据从一个MySQL数据库服务器（主节点）复制到一个或多个其他服务器（从节点）。这种机制常用于实现数据的热备份、负载均衡和扩展。

以下是MySQL主从复制的基本原理：

1. binlog（二进制日志）: 在主服务器上，每当有数据变更发生时，如INSERT、UPDATE或DELETE操作，这些变更会被记录在binlog中。
2. 读取binlog: 从服务器连接到主服务器，并请求主服务器发送新的binlog事件。这个过程可以通过IO线程来完成。
3. relay log（中继日志）: 从服务器接收到来自主服务器的binlog事件后，会将这些事件写入到自己的relay log中。
4. 应用binlog: 从服务器的另一个线程，称为SQL线程，会读取relay log中的事件，并将它们依次应用到从服务器的数据库中，从而保持与主服务器的数据一致性。

此外，在实际应用中，主从复制可能会存在一定的延时，即从服务器的数据更新可能落后于主服务器。这种延时通常被称为同步延时。为了减少这种延时，可以采用半同步复制的方式，即在主服务器上等待至少一个从服务器确认接收到binlog事件后才认为该事件提交成功。

主从复制分了五个步骤进行：
步骤一：主库的更新事件(update、insert、delete)被写到 binlog
步骤二：从库发起连接，连接到主库。
步骤三：此时主库创建一个 binlog dump thread，把 binlog 的内容发送到从库。
步骤四：从库启动之后，创建一个 I/O 线程，读取主库传过来的 binlog 内容并写入到 relay log
步骤五：还会创建一个 SQL 线程，从 relay log 里面读取内容，从Exec_Master_Log_Pos 位置开始执行读取到的更新事件，将更新内容写入到slave 的 db

Hash索引和B+树索引的区别是什么？

Hash索引和B+树索引是数据库中常用的两种索引类型，它们在查询效率和数据组织等方面存在一些区别。具体分析如下：

1. 查询效率：对于等值查询，Hash索引可以提供更快的查找速度，因为它通过一次散列运算就能直接定位到数据的存储位置。而B+树索引需要从根节点开始，通过逐层遍历找到叶子节点，这个过程涉及到多次磁盘I/O操作。
2. 数据组织：B+树索引的所有数据都存储在叶子节点，并且叶子节点之间通过指针相连，这使得范围查询非常高效。而Hash索引由于其数据组织方式，不适合进行范围查询。
3. 冲突处理：当多个不同的键值散列到同一个索引位置时，会发生冲突。Hash索引通常使用链表来解决冲突，这可能导致在最坏情况下，查询效率降低。B+树索引则没有这种冲突问题。
4. 插入和删除：由于B+树的结构特性，插入和删除操作可以保持较高的效率，尤其是在保持页面填充率的情况下。而Hash索引在处理大量插入和删除导致冲突增多时，性能可能会受到影响。

总的来说，Hash索引在等值查询方面具有明显的优势，尤其是在查询效率上。然而，B+树索引在范围查询和有序性方面表现更好，且更适合处理大量数据的插入和删除。在实际应用中，选择哪种索引取决于具体的应用场景和需求。

count(1)、count(*) 与 count(列名) 的区别？

在SQL中，COUNT(1)、COUNT(*)和COUNT(列名)都是用来统计记录数量的函数，但它们之间存在一些细微的区别：

• COUNT(1)：这个函数会统计表中的所有记录数，包括那些所有列都为NULL的记录。换句话说，只要数据库中有这条记录，无论记录的内容如何，COUNT(1)都会将其计入总数。
• COUNT(*)：这个函数与COUNT(1)的行为相同，也会统计表中的所有记录数，包括那些所有列都为NULL的记录。在大多数数据库系统中，COUNT(*)和COUNT(1)的效率是相同的。
• COUNT(列名)：这个函数会统计指定列中非NULL值的数量。如果某条记录的指定列值为NULL，则这条记录不会被计入总数。这在统计某一特定列的有效数据时非常有用。

总的来说，COUNT(1)和COUNT(*)在功能上是等价的，它们都会计算表中的所有记录，而COUNT(列名)则会忽略掉指定列中值为NULL的记录。在实际使用时，选择哪种方式取决于你想要统计的内容。如果你想统计所有记录，可以使用COUNT(1)或COUNT(*)；如果你想统计特定列的非NULL值的数量，那么应该使用COUNT(列名)。

mysql 中 int(20)和 char(20)以及 varchar(20)的区别？

在MySQL中，INT(20)、CHAR(20)和VARCHAR(20)是三种不同的数据类型，它们用于存储不同类型的数据，并且在存储方式和空间占用上也有所不同。

1. INT(20)：

   • 数据类型：整数（Integer）。
   • 存储范围：通常为-2147483648到2147483647（取决于具体的数据库系统）。
   • 显示长度：括号中的数字表示显示宽度，即在结果集中显示的字符数，但这并不影响实际存储的空间大小或值的范围。
   • 空间占用：通常占用4个字节的存储空间。

2. CHAR(20)：

   • 数据类型：定长字符串（Character）。
   • 存储范围：最多可以存储20个字符。
   • 显示长度：括号中的数字表示字段可以存储的最大字符数。
   • 空间占用：无论实际存储的数据长度如何，都会占用20个字符的存储空间。如果实际数据长度不足20个字符，剩余的空间会用空格填充。

3. VARCHAR(20)：

   • 数据类型：变长字符串（Variable Character）。
   • 存储范围：最多可以存储20个字符。
   • 显示长度：括号中的数字表示字段可以存储的最大字符数。
   • 空间占用：根据实际存储的数据长度动态分配存储空间，最大不超过20个字符。不会像CHAR那样浪费空间。

需要注意的是，这些数据类型的具体实现可能会因不同的数据库管理系统而有所差异。在实际使用时，应根据数据的性质和应用场景选择合适的数据类型。

update 变更前后的值相同的话，执行过程是什么样子的

在MySQL中，当使用UPDATE语句更新数据时，如果变更前后的值相同，实际上数据库不会执行任何数据的更改操作。这是因为数据库系统在执行UPDATE语句时，会首先检查新值与当前值是否相同。

具体来说，以下是执行过程的简化描述：

1. 语法解析：数据库系统首先对UPDATE语句进行语法解析，确认语句的结构正确无误。
2. 权限验证：数据库系统会检查执行该语句的用户是否具有相应的权限，以进行数据更新操作。
3. 锁定行：为了维护数据的一致性，数据库系统可能会锁定要更新的数据行，防止其他事务同时修改同一数据。
4. 生成新的行版本：数据库系统会生成一个新的行版本，包含更新后的值。
5. 比较新旧值：数据库系统会比较新的值和当前值是否相同。
6. 决定是否更新：如果新旧值相同，数据库系统会认为没有实际的数据变更需要执行，因此不会进行任何数据的更改操作。这意味着原数据保持不变，不会产生任何日志记录或触发器执行等副作用。
7. 释放锁：最后，数据库系统会释放之前锁定的数据行。
   需要注意的是，尽管没有实际的数据变更操作被执行，但这个过程仍然涉及到一系列的步骤和资源消耗，包括解析、权限验证、锁定等。因此，在实际开发中，应尽量避免编写可能导致无意义更新的语句，以提高数据库性能和效率。

请解释第一、第二、第三范式，并举例说明。

数据库范式是关系型数据库设计中的一组规则，用于确保数据的逻辑一致性和减少数据冗余。以下是第一、第二、第三范式的解释以及各自的举例说明：

1. 第一范式（1NF）：

• 解释：第一范式要求数据库表中的每一列都是不可分割的基本数据项，即每个字段都是原子性的，不能再分解成更小的部分。这个范式的目的是消除重复的组和确保每个数据项都是最小的、不可分割的单位。
• 举例：如果一个表格中有一个列是“地址”，而地址包含了街道、城市和邮编，那么这个表就不符合第一范式。为了符合第一范式，应该将地址拆分成三个独立的列：街道、城市和邮编。

2. 第二范式（2NF）：

• 解释：在满足第一范式的基础上，第二范式要求数据库表中的所有非主键列都完全依赖于主键，而不是部分依赖。这意味着一个表中只能有一个主键，且其他字段必须依赖于这个完整的主键。
• 举例：如果有一个订单详情表，其中包含订单编号、产品ID、数量和价格，如果订单编号和产品ID共同作为主键，那么数量和价格应该只依赖于这两个字段的组合，而不是其中的任何一个字段。

3. 第三范式（3NF）：

• 解释：在满足第二范式的基础上，第三范式要求数据库表中的所有字段都不依赖于其他非主键字段。这是通过消除传递依赖来实现的，即确保所有非主键列都直接依赖于主键，而不是通过其他列间接依赖。
• 举例：如果在一个员工表中，有员工ID、部门ID、部门名称和员工姓名等字段，其中员工ID是主键，部门ID是一个外键。为了满足第三范式，应该将部门名称从员工表中移除，并在一个单独的部门表中存储部门ID和部门名称的信息。这样，员工表中的部门名称就不再依赖于员工ID，而是直接依赖于部门ID。

总的来说，通过遵循这些范式，可以设计出结构良好、数据冗余低、更新异常少的数据库。在实际应用中，通常会根据具体的业务需求和数据使用情况来决定是否需要严格遵循这些范式，或者进行适当的反范式化以优化性能。

使用TEXT类型来存储JSON数据违反数据库的第一范式吗？

使用TEXT类型来存储JSON数据并不违反数据库的第一范式（1NF）。

数据库的第一范式主要是针对关系型数据库设计的，它要求表中的每一列都是不可分割的基本数据项，即每个字段都是原子性的。而TEXT类型通常用于存储字符串数据，包括JSON格式的字符串。当将JSON数据作为字符串整体存储在TEXT类型的列中时，它被视为一个单一的值，而不是多个独立的数据项。因此，从数据库设计的角度来看，使用TEXT类型存储JSON字符串是符合第一范式的。

需要注意的是，虽然从技术上讲，使用TEXT类型存储JSON数据不违反第一范式，但在实际的数据库设计和应用中，可能会有其他的考虑因素。例如，有的公司数据库规范建议“尽可能不使用TEXT类型”，这可能是因为TEXT类型不适合索引，查询效率低，且不易进行数据完整性校验。而对于需要存储JSON数据的场景，一些数据库系统提供了专门的JSON数据类型，这些类型可以提供更好的数据校验和查询性能。

总的来说，从数据库范式的角度来看，使用TEXT类型存储JSON数据并不违反第一范式，但在实际应用中，应当根据具体需求和数据库系统的功能特性来选择合适的数据类型。

WITH AS 语法详解

【Mysql】WITH AS 语法详解

MySQL 如何统计慢SQL

在MySQL中，可以通过设置慢查询日志来统计慢SQL。以下是具体的步骤：

1. 开启慢查询日志功能：

• 通过命令 SET GLOBAL slow_query_log = 'ON'; 启用慢查询日志功能。
• 确保 long_query_time 参数设置合理，该参数定义了慢查询的阈值，即执行时间超过这个值的SQL将被记录到慢查询日志中。默认情况下，long_query_time 的值是10秒，但可以根据需要进行调整。

2. 查看慢查询相关的状态和变量：

• 使用命令 SHOW STATUS LIKE '%slow%'; 可以查看慢查询的统计信息。
• 使用命令 SHOW VARIABLES LIKE '%slow%'; 可以查看慢查询日志的相关配置项。

3. 分析慢查询日志：

• 分析慢查询日志文件以找出执行时间较长的SQL语句。可以使用 mysqldumpslow 工具帮助分析慢查询日志文件中的内容。
• 对于识别出的慢SQL，使用 EXPLAIN 命令或 SHOW PROFILE 命令进一步分析其执行计划和性能瓶颈。

4. 优化SQL语句：

• 根据慢查询日志的分析结果，对识别出的慢SQL进行优化，可能包括重写SQL语句、添加或修改索引等措施。

5. 监控和定期审计：

• 定期检查慢查询日志，持续监控数据库的性能状况，并根据需要进行优化调整。

此外，需要注意的是，开启慢查询日志可能会对数据库性能产生一定影响，因此在调优完成后，根据实际情况考虑是否需要关闭慢查询日志功能。

总的来说，通过上述步骤，可以有效地统计和分析MySQL中的慢SQL，进而优化数据库的性能。

drop、delete 与 truncate 的区别

在数据库管理中，drop、delete和truncate都是用来删除数据的操作，但它们之间存在一些关键的区别。具体分析如下：

• drop：是一种数据定义语言（DDL）操作，用于删除整个表（包括表结构和数据），并且会释放表所占用的空间。一旦使用drop命令，表及其所有相关的约束、触发器、索引都会被删除，且无法回滚。依赖于该表的存储过程和函数将保留，但其状态会变为invalid。
• delete：属于数据操作语言（DML）操作，主要用于删除表中的部分或全部数据，但不删除表结构。delete命令可以被回滚（rollback），因为它是一个事务性操作。它可以与where子句一起使用来指定删除哪些行。此外，执行delete操作时，会触发与表相关联的触发器，并记录详细的日志信息，便于后续恢复。
• truncate：也是DDL操作，用于快速清空表中的所有数据，但不删除表结构。与delete相比，truncate操作更快，因为它不会记录每一行的删除操作到日志中。由于这个原因，truncate不能被回滚，且不会触发与表相关联的触发器。使用truncate后，表所占用的存储空间会恢复到初始大小，并且自增ID也会重置为初始值。

总的来说，如果需要删除整个表及其结构，并释放空间，应使用drop；如果想要保留表结构而删除所有数据，并且希望操作快速且不触发触发器，应选择truncate；若只需删除部分数据，或者需要在删除操作可回滚的情况下进行，则应使用delete命令。

什么是索引下推

索引下推（Index Condition Pushdown，简称ICP）是MySQL 5.6版本引入的一项新特性，它能有效地减少回表查询次数，从而提高查询效率。具体如下：

1. 减少回表次数：在传统的数据库查询过程中，当我们使用非主键索引进行查询时，首先会根据索引找到对应的数据行，然后回到原始的数据表中获取完整的行数据，这个过程称为“回表”。如果索引覆盖不全，那么对于每一行数据都需要回表一次，这在数据量大时会导致大量的IO操作和查询延迟。索引下推通过在索引遍历的过程中，对索引中包含的字段先做判断，过滤掉不符合条件的记录，从而减少回表的次数。
2. 适用场景：对于InnoDB存储引擎来说，索引下推只适用于二级索引（也叫辅助索引）。这是因为InnoDB的聚簇索引（主键索引）本身就是按照主键顺序存储的，所以在使用主键索引时不需要进行额外的回表操作。
3. 优化原理：索引下推的优化原理是在执行查询时，将查询条件尽可能地“下推”到索引层进行处理。这样，只有在索引层就满足条件的记录才会被取出，而不满足条件的记录则在索引层就被过滤掉，避免了不必要的回表操作。
4. 性能提升：通过这种方式，索引下推能够显著减少对数据行的访问次数，尤其是在处理大量数据时，这种优化可以大幅度提高查询性能。

总的来说，索引下推是一种重要的数据库查询优化技术，它通过减少不必要的回表操作，提高了数据库的查询效率，尤其在大数据量的场景下效果更为明显。

● MySQL 服务层：也就是 SERVER 层，用来解析 SQL 的语法、语义、生成查询计划、接管从 MySQL 存储引擎层上推的数据进行二次过滤等等。
● MySQL 存储引擎层：按照 MySQL 服务层下发的请求，通过索引或者全表扫描等方式把数据上传到 MySQL 服务层。
● MySQL 索引扫描：根据指定索引过滤条件，遍历索引找到索引键对应的主键值后回表过滤剩余过滤条件。
● MySQL 索引过滤：通过索引扫描并且基于索引进行二次条件过滤后再回表。

代码演示

delete from user1;
drop table user1;

CREATE TABLE `user1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  `age` tinyint(4) NOT NULL,
	`address` varchar(50) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name_age` (`name`,`age`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO `user1` (`name`, `age`, `address`) VALUES
('Alice', 40, 'address1'),
('Amy', 23, 'address2'),
('Tom', 18, 'address3'),
('Mike', 22, 'address4');
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

explain SELECT * FROM user1 WHERE name LIKE 'A%' and age = 23;
1

# 查看索引下推是否开启
select @@optimizer_switch
# 开启索引下推
set optimizer_switch="index_condition_pushdown=on";
# 关闭索引下推
set optimizer_switch="index_condition_pushdown=off";
1
2
3
4
5
6

不使用索引下推实现

Explain SELECT * FROM user1 WHERE name LIKE 'A%' and age = 40;
1

使用索引下推实现

索引下推的使用条件

● ICP目标是减少全行记录读取，从而减少IO 操作，只能用于非聚簇索引。聚簇索引本身包含的表数据，也就不存在下推一说。
● 只能用于range、 ref、 eq_ref、ref_or_null访问方法；
● where 条件中是用 and 而非 or 的时候。
● ICP适用于分区表。
● ICP不支持基于虚拟列上建立的索引，比如说函数索引
● ICP不支持引用子查询作为条件。
● ICP不支持存储函数作为条件，因为存储引擎无法调用存储函数。

MySQL 中in 和exists 的区别

在MySQL中，IN和EXISTS都是用来进行子查询的关键字，但它们在使用上存在一些差异。具体如下：

• IN：当使用IN时，MySQL会先执行子查询并得到一个结果集，然后再根据这个结果集去过滤外部查询的记录。如果子查询返回的结果集较大，这可能会占用较多的内存。在某些情况下，优化器会将IN操作转换为内联（join）操作以提高效率。
• EXISTS：EXISTS通常会比IN更高效，特别是在子查询结果集很大时。这是因为EXISTS只要找到第一个匹配的行就会停止搜索，而IN则需要得到完整的结果集。
  总的来说，对于较大的子查询结果集，EXISTS通常更有效率；而对于较小的子查询结果集，IN可能更合适。然而，最佳选择取决于具体的数据情况和数据库的状态，因此建议在实际应用中进行测试以确定哪种方法更有效。

MySQL中的自增主键可能会遇到什么问题？

MySQL中的自增主键可能会遇到以下问题：

1. 资源浪费：随着时间的推移，自增主键的值会持续增加，即使对应的记录被删除，自增主键也不会复用这些值。这可能导致主键值越来越大，从而浪费了数据库资源。
2. ID耗尽：在极端情况下，如果表中的数据量非常大，自增主键可能会达到其最大值，导致无法再插入新的记录。这时可以通过调整自增属性的起始值和步长来扩大ID的区间，或者设置自增主键字段的最大值，当达到该值时重新开始自增。
3. 性能瓶颈：在高并发的场景下，自增主键可能会成为性能瓶颈。因为InnoDB引擎在生成自增ID时会使用一个表级别的AUTO-INC lock，这可能会影响性能。但在现代MySQL版本中，由于innodb_autoinc_lock_mode的默认值为1，普通的业务插入操作不会受到这个锁的影响，因为自增ID是通过内存中的一个互斥量（mutex counter）来获取的。
4. 分布式环境下的问题：在分布式环境中，由于不同节点可能同时生成自增主键，这可能导致主键冲突或者不一致的情况发生。解决这个问题可能需要采用分布式ID生成方案，如使用全局唯一ID（UUID）或者分布式ID生成器。
5. 依赖于连续主键的业务逻辑问题：有些业务逻辑可能依赖于主键的连续性，例如某些分页逻辑或者基于主键的范围查询。如果主键不连续，这些逻辑可能会出现问题。

总的来说，自增主键是一种方便的数据增长策略，但在设计系统时，需要考虑到上述潜在问题，并根据实际情况选择合适的解决方案。

---

消息队列

什么是消息队列

你可以把消息队列理解为一个使用队列来通信的组件。它的本质，就是个转发
器，包含发消息、存消息、消费消息的过程。最简单的消息队列模型如下：
我们通常说的消息队列，简称 MQ（Message Queue），它其实就指消息
中间件，当前业界比较流行的开源消息中间件包括：
RabbitMQ、RocketMQ、Kafka。

消息队列有哪些使用场景？/为什么使用消息队列？

1. 应用解耦
2. 流量削峰
3. 异步处理
4. 消息通讯
5. 远程调用

消息队列如何解决消息丢失问题？

一个消息从生产者产生，到被消费者消费，主要经过这 3 个过程：

因此如何保证 MQ 不丢失消息，可以从这三个阶段阐述：

• 生产者保证不丢消息
• 存储端不丢消息
• 消费者不丢消息

生产者保证不丢消息

生产端如何保证不丢消息呢？确保生产的消息能到达存储端。
如果是 RocketMQ 消息中间件，Producer 生产者提供了三种发送消息的方式，分别是：

• 同步发送
• 异步发送
• 单向发送

生产者要想发消息时保证消息不丢失，可以：

• 采用同步方式发送，send 消息方法返回成功状态，就表示消息正常到达了存储端Broker。
• 如果 send 消息异常或者返回非成功状态，可以重试。
• 可以使用事务消息，RocketMQ 的事务消息机制就是为了保证零丢失来设计的

存储端不丢消息

如何保证存储端的消息不丢失呢？ 确保消息持久化到磁盘。大家很容易想到就
是刷盘机制。
刷盘机制分同步刷盘和异步刷盘：

• 生产者消息发过来时，只有持久化到磁盘，RocketMQ 的存储端 Broker 才返回一
  个成功的 ACK 响应，这就是同步刷盘。它保证消息不丢失，但是影响了性能。
• 异步刷盘的话，只要消息写入 PageCache 缓存，就返回一个成功的 ACK 响应。
  这样提高了 MQ 的性能，但是如果这时候机器断电了，就会丢失消息。

Broker 一般是集群部署的，有 master 主节点和 slave 从节点。消息到Broker 存储端，只有主节点和从节点都写入成功，才反馈成功的 ack 给生产者。这就是同步复制，它保证了消息不丢失，但是降低了系统的吞吐量。与之对应的就是异步复制，只要消息写入主节点成功，就返回成功的 ack，它速度快，但是会有性能问题。

消费阶段不丢消息

消费者执行完业务逻辑，再反馈会 Broker 说消费成功，这样才可以保证消费
阶段不丢消息。

消息队列有可能发生重复消费，如何避免，如何做到幂等？

消息队列是可能发生重复消费的。

• 生产端为了保证消息的可靠性，它可能往 MQ 服务器重复发送消息，直到拿到成功
  的 ACK。
• 再然后就是消费端，消费端消费消息一般是这个流程：拉取消息、业务逻辑处理、
  提交消费位移。假设业务逻辑处理完，事务提交了，但是需要更新消费位移时，消
  费者挂了，这时候另一个消费者就会拉到重复消息了。

如何幂等处理重复消息呢？

幂等处理重复消息，简单来说，就是搞个本地表，带唯一业务标记的，利用主
键或者唯一性索引，每次处理业务，先校验一下就好啦。又或者用 redis 缓存
下业务标记，每次看下是否处理过了。

如何处理消息队列的消息积压问题？

消息积压是因为生产者的生产速度，大于消费者的消费速度。遇到消息积压问
题时，我们需要先排查，是不是有 bug 产生了。
如果不是 bug，我们可以优化一下消费的逻辑，比如之前是一条一条消息消费
处理的话，我们可以确认是不是可以优为批量处理消息。
如果还是慢，我们可
以考虑水平扩容，增加 Topic 的队列数，和消费组机器的数量，提升整体消费
能力

如果是 bug 导致几百万消息持续积压几小时。有如何处理呢？ 需要解决
bug，临时紧急扩容，大概思路如下：

1. 先修复 consumer 消费者的问题，以确保其恢复消费速度，然后将现有consumer 都停掉。
2. 新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue数量。
3. 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
4. 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
5. 等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的consumer 机器来消费消息。

消息队列技术选型，Kafka 还是 RocketMQ，还是RabbitMQ？

先可以对比下它们优缺点：

• RabbitMQ 是开源的，比较稳定的支持，活跃度也高，但是不是 Java 语言开发的。
• 很多公司用 RocketMQ，是阿里出品的。
• 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的。

如何保证数据一致性，事务消息如何实现？

一条普通的 MQ 消息，从产生到被消费，大概流程如下：

1. 生产者产生消息，发送带 MQ 服务器
2. MQ 收到消息后，将消息持久化到存储系统。
3. MQ 服务器返回 ACK到生产者。
4. MQ 服务器把消息 push 给消费者
5. 消费者消费完消息，响应 ACK
6. MQ 服务器收到 ACK，认为消息消费成功，即在存储中删除消息。

我们举个下订单的例子吧。订单系统创建完订单后，再发送消息给下游系统。如果订单创建成功，然后消息没有成功发送出去，下游系统就无法感知这个事情，出导致数据不一致。
如何保证数据一致性呢？可以使用事务消息。一起来看下事务消息是如何实现的吧。

1. 生产者产生消息，发送一条半事务消息到 MQ 服务器
2. MQ 收到消息后，将消息持久化到存储系统，这条消息的状态是待发送状态。
3. MQ 服务器返回 ACK 确认到生产者，此时 MQ 不会触发消息推送事件
4. 生产者执行本地事务
5. 如果本地事务执行成功，即 commit 执行结果到 MQ 服务器；如果执行失败，发
   送 rollback。
6. 如果是正常的 commit，MQ 服务器更新消息状态为可发送；如果是 rollback，即
   删除消息。
7. 如果消息状态更新为可发送，则 MQ 服务器会 push 消息给消费者。消费者消费完
   就回 ACK。
8. 如果 MQ 服务器长时间没有收到生产者的 commit 或者 rollback，它会反查生产
   者，然后根据查询到的结果执行最终状态。

RabbitMQ

RabbitMQ是什么？有什么特点？

RabbitMQ是一个开源的消息中间件，它实现了高级消息队列协议（AMQP）。

RabbitMQ的主要特点包括：

1. 可靠性：它支持持久化、传输确认以及发布确认等机制，确保了消息传递的稳定性。
2. 灵活的路由策略：在消息进入队列之前，RabbitMQ通过Exchange进行路由，支持多种路由策略如简单模式、工作队列模式、发布订阅模式等。
3. 高并发处理能力：由于使用Erlang语言开发，天生具备高并发处理能力，适合需要处理大量消息传递的场景。
4. 支持集群：多台RabbitMQ服务器可以组成一个集群，形成一个逻辑Broker，增强系统的伸缩性和可用性。
5. 多语言和协议支持：RabbitMQ几乎支持所有的编程语言，并且除了AMQP外，还支持STOMP、MQTT等多种通讯协议。
6. 管理界面：提供了可视化的管理界面，方便用户进行配置和监控。

RabbitMQ的设计目标是为分布式系统提供可靠的、易于使用的和功能强大的消息传递服务。它在金融行业得到广泛应用，因为这个行业对消息系统的可靠性、性能和精确性有着极高的要求。

RabbitMQ 和 AMQP 是什么关系？

RabbitMQ 和 AMQP 有着非常密切的关系，但是他们是属于完全不同的两个概念。

• AMQP： AMQP 不是一个具体的消息中间件产品，而是一个协议规范。他是一个开放的消息产地协议，是一种应用层的标准协议，为面向消息的中间件设计。AMQP 提供了一种统一的消息服务，使得不同程序之间可以通过消息队列进行通信。 SpringBoot 框架默认就提供了对 AMQP 协议的支持。
• RabbitMQ：RabbitMQ则是一个开源的消息中间件，是一个具体的软件产品。RabbitMQ 使用 AMQP 协议来实现消息传递的标准，但其实他也支持其他消息传递协议，如 STOMP 和 MQTT。RabbitMQ 基于 AMQP 协议定义的消息格式和交互流程，实现了消息在生产者、交换机、队列之间的传递和处理。

总之，AMQP 本质上是一个开放的标准，他不光可以被 RabbitMQ 实现，也可以被其他产品实现。通过这种标准的协议，实际上是可以在不同的消息中间件系统之间进行灵活的消息传递。只不过，目前具体实现这种标准的产品目前并不多，RabbitMQ 则是最有影响力的一个产品。因此，RabbitMQ 成了 AMQP 协议事实上的代表。SpringBoot 框架默认提供的 AMQP 协议支持底层也是基于 RabbitMQ 产品实现的。

RabbitMQ 的核心组件有哪些？

RabbitMQ 是一个开源的消息中间件，采用 AMQP（高级消息队列协议）进行消息传递。它允许应用程序之间进行异步通信，提供了一种高效、可扩展、可靠的消息传递机制。

以下是 RabbitMQ 的基本架构设计：

1. 生产者（Producer）： 生产者是消息的发送方，负责产生并发送消息到 RabbitMQ。生产者通常将消息发送到交换机（Exchange）。
2. 交换机（Exchange）： 交换机是消息的分发中心，负责将接收到的消息路由到一个或多个队列。它定义了消息的传递规则，可以根据规则将消息发送到一个或多个队列。
   ○ 直连交换机（Direct Exchange）： 将消息路由到与消息中的路由键（Routing Key）完全匹配的队列。
   ○ 主题交换机（Topic Exchange）： 根据通配符匹配路由键，将消息路由到一个或多个队列。
   ○ 扇出交换机（Fanout Exchange）： 将消息广播到所有与交换机绑定的队列，忽略路由键。
   ○ 头部交换机（Headers Exchange）： 根据消息头中的属性进行匹配，将消息路由到与消息头匹配的队列。
3. 队列（Queue）： 队列是消息的存储区，用于存储生产者发送的消息。消息最终会被消费者从队列中取出并处理。每个队列都有一个名称，并且可以绑定到一个或多个交换机。
4. 消费者（Consumer）： 消费者是消息的接收方，负责从队列中获取消息并进行处理。消费者通过订阅队列来接收消息。
5. 绑定（Binding）： 绑定是交换机和队列之间的关联关系。生产者将消息发送到交换机，而队列通过绑定与交换机关联，从而接收到消息。
6. 虚拟主机（Virtual Host）： 虚拟主机是 RabbitMQ 的基本工作单元，每个虚拟主机拥有自己独立的用户、权限、交换机、队列等资源，完全隔离于其他虚拟主机。
7. 连接（Connection）： 连接是指生产者、消费者与 RabbitMQ 之间的网络连接。每个连接可以包含多个信道（Channel），每个信道是一个独立的会话通道，可以进行独立的消息传递。
8. 消息： 消息是生产者和消费者之间传递的数据单元。消息通常包含消息体和可选的属性，如路由键等。

RabbitMQ 的架构设计允许多个生产者、多个消费者之间通过消息队列进行松耦合的通信，提高了系统的可伸缩性和可维护性。通过灵活配置交换机和队列，可以实现多种消息传递模式，满足不同应用场景的需求

RabbitMQ 如何实现消息的持久化？

RabbitMQ 允许消息的持久化，以确保即使在 RabbitMQ 服务器重新启动后，消息也不会丢失。

RabbitMQ 可以通过以下方式实现消息的持久化：

1. 消息持久化：在 RabbitMQ 中，只需要在发送消息时，将delivery_mode属性设置为 2，就可以将消息标记为持久化。
2. 队列持久化：在 RabbitMQ 中声明队列时，也可以将队列声明为持久化。RabbitMQ 中的队列分为三种不同类型经典队列，仲裁队列和流式队列。其中，经典队列需要将durable属性设置为true。而仲裁队列和流式队列默认必须持久化保存。
3. 交换机持久化：与经典队列类似，RabbitMQ 也可以在声明交换机时，将交换机的 durable 属性设置为true，这样就可以将交换机标记为持久化。

RabbitMQ 的持久化机制会对其性能产生影响。因此，需要根据具体的业务场景和需求来权衡是否需要持久化以及需要哪种类型的持久化。

RabbitMQ如何保证消息不丢失

针对消息丢失场景，RabbitMQ 提供了相应的解决方案，confirm 消息确认机制（生产者），消息持久化机制（RabbitMQ 服务），ACK 事务机制（消费者）；

confirm 消息确认机制（生产者）

Confirm 模式是 RabbitMQ 提供的一种消息可靠性保障机制。当生产者通过 Confirm 模式发送消息时，它会等待 RabbitMQ 的确认，确保消息已经被正确地投递到了指定的 Exchange 中。
消息正确投递到 queue 时，会返回 ack。
消息没有正确投递到 queue 时，会返回 nack。如果 exchange 没有绑定 queue，也会出现消息丢失。
使用方法：
● 生产者通过 confirm.select 方法将 Channel 设置为 Confirm 模式。
● 发送消息后，通过添加 add_confirm_listener 方法，监听消息的确认状态。

消息持久化机制（RabbitMQ 服务）

持久化机制是指将消息存储到磁盘，以保证在 RabbitMQ 服务器宕机或重启时，消息不会丢失。

使用方法：
● 生产者通过将消息的 delivery_mode 属性设置为 2，将消息标记为持久化。
● 队列也需要进行持久化设置，确保队列在 RabbitMQ 服务器重启后仍然存在。经典队列需要将durable属性设置为true。而仲裁队列和流式队列默认必须持久化保存。
注意事项：
● 持久化机制会影响性能，因此在需要确保消息不丢失的场景下使用

ACK 事务机制（消费者）

ACK 事务机制用于确保消息被正确消费。当消息被消费者成功处理后，消费者发送确认（ACK）给 RabbitMQ，告知消息可以被移除。这个过程是自动处理的，也可以关闭进行手工发送 ACK。

使用方法：
● 在 RabbitMQ 中，ACK 机制默认是开启的。当消息被消费者接收后，会立即从队列中删除，除非消费者发生异常。
● 可以手动开启 ACK 机制，通过将 auto_ack 参数设置为 False，手动控制消息的 ACK。

注意事项：
● ACK 机制可以确保消息不会被重复处理，但如果消费者发生异常或者未发送 ACK，消息可能会被重复投递。

RabbitMQ中如何保证消息不被重复消费

什么情况会导致消息被重复消费呢

1. 生产者：生产者可能会重复推送一条数据到 MQ 中，比如 Controller 接口被重复调用了 2 次，没有做接口幂等性导致的；
2. MQ：在消费者消费完准备响应 ack 消息消费成功时，MQ 突然挂了，导致 MQ 以为消费者还未消费该条数据，MQ 恢复后再次推送了该条消息，导致了重复消费。
3. 消费者：消费者已经消费完消息，正准备但是还未响应给ack消息到时，此时消费者挂了，服务重启后 MQ 以为消费者还没有消费该消息，再次推送了该条消息。
   

解决方案

1. 使用数据库唯一键约束
   缺点：局限性很大，仅仅只能用在我们数据新增场景，并且性能也比较低
2. 使用乐观锁
   假设是更新订单状态，在发送的消息的时候带上修改字段的版本号
   缺点：如果说更新字段比较多，并且更新场景比较多，可能会导致数据库字段增加并且还有可能出现多条消息同时在队列中此时他们修改字段版本号一致，排在后续的消息无法被消费
3. 简单的消息去重，插入消费记录，增加数据库判断
   优点：很多场景下的确能起到不错的效果
   缺点：
   1. 这个消费者的代码执行需要1秒，重复消息在执行期间（假设100毫秒）内到达（例如生产者快速重发，Broker重启等），增加校验的地方是不是还是没数据（因为上一条消息还没消费完，没有记录）
   2. 那么就会穿透掉检查的挡板，最后导致重复的消息消费逻辑进入到非幂等安全的业务代码中，从而引发重复消费的问
4. 并发消息去重基于消息幂等表或者redis
   

Redis

一个Redis实例最多能存放多少key

一个Redis实例理论上可以存储最多2^32个keys。

Redis是一个开源的内存数据结构存储系统，它可以用作数据库、缓存和消息中间件。在Redis中，每个key都是唯一的，而每个value则可以是string（字符串）、list（列表）、set（集合）、zset（有序集合）或hash（哈希）等不同类型的数据结构。对于单个key或value的大小限制，Redis允许的最大值为512MB。

在实际应用中，Redis的性能会受到服务器硬件资源（如内存大小）以及配置参数的限制。因此，尽管理论上可以存储极大量的keys，但在具体操作时，需要考虑到实际的物理内存、操作系统的虚拟内存限制以及Redis的配置等因素。

总的来说，虽然理论上的数字非常庞大，但实际使用中还需要根据具体的应用场景和硬件资源来合理规划Redis的使用，确保性能和稳定性。

Redis为什么快？

• 内存存储：Redis将数据存储在内存中，这比磁盘存储的读写速度要快得多。内存的高速访问特性使得Redis能够以极低的延迟快速响应读请求。
• 单线程模型：虽然单线程在处理高并发时看似会成为瓶颈，但Redis通过高效的事件驱动机制来应对这一点。它的事件循环机制能够处理数以千计的并发连接，而不会出现性能下降。
• IO多路复用技术：Redis使用IO多路复用技术，可以在等待某些慢操作（如网络IO）时，处理其他客户端的命令。这种技术可以在不创建新线程的情况下，同时处理多个客户端的请求。
• 高效的数据结构：Redis的数据结构是为高速访问和操作优化的。例如，它使用非阻塞数据结构和自己实现的内存分配器，这些都是为了提高性能。
• 持久化选项：虽然Redis是一个内存数据库，但它提供了RDB和AOF两种持久化机制，确保数据的安全性。这些机制在不牺牲性能的前提下，提供了数据备份和恢复的能力。
• 管道技术：Redis支持管道技术，允许客户端一次发送多个命令而不必等待每个命令的回复，这样可以减少网络往返时间，提高整体效率。

综上所述，Redis之所以能够提供高性能的服务，是因为其架构和设计都针对性能进行了优化，包括内存存储、单线程模型、IO多路复用技术、高效的数据结构和管道技术等。这些特性共同作用，使得Redis成为了许多高性能应用程序的首选缓存解决方案。

有些博主在科普redis为什么快的时候加入了渐进式Rehash 以及 缓存时间戳

• 渐进式rehash介绍：当Redis的哈希表需要改变大小（例如，因为负载因子过大或过小），而不是一次性将所有键值对转移到新的哈希表，Redis会逐步地在每次处理客户端请求时转移一小部分键值对。这样，整个rehash过程分散到了许多客户端请求中，避免了在某一时刻服务器资源的过度消耗，确保了操作的平摊成本较低且系统稳定。
• 缓存时间戳的作用：缓存时间戳是Redis用来跟踪和管理键值对过期的一种机制。每个键值对在内存中都会有一个与之关联的时间戳。这个时间戳记录了键值对的最后访问时间或者过期时间。当读取或操作某个键值对时，Redis会检查这个时间戳来决定是否返回该键值对或将之删除。

综上所述，渐进式rehash和缓存时间戳都是Redis为了保证高性能和高可用性而采用的技术。渐进式rehash使得在调整哈希表大小时不会对服务造成显著影响，而缓存时间戳则允许Redis高效地处理键值对的过期问题。

缓存穿透&缓存雪崩

缓存穿透

缓存穿透：指的是在缓存中没有找到要查询的数据，导致每次查询都需要直接查询数据库，从而导致数据库压力过大。这种情况通常发生在查询的数据不存在或者缓存过期时。

例如，假设有一个商品查询接口，当用户查询一个不存在的商品时，缓存中没有该商品的信息，因此每次查询都会直接查询数据库。如果大量用户同时查询不存在的商品，就会导致数据库压力过大，甚至可能导致数据库崩溃。

为了解决缓存穿透问题，可以采取以下措施：

• 缓存空值：在缓存中存储一个空值或默认值，当查询的数据不存在时，直接返回缓存中的空值或默认值，避免直接查询数据库。
• 使用布隆过滤器：布隆过滤器可以快速判断一个数据是否存在于数据库中，从而避免直接查询数据库。当查询的数据不存在于布隆过滤器中时，直接返回空值或默认值。

缓存雪崩

缓存雪崩：指的是在短时间内大量缓存失效，导致大量请求直接查询数据库，从而导致数据库压力过大。这种情况通常发生在缓存过期时间集中或者缓存服务器故障时。

例如，假设有一个商品详情页面，该页面的缓存过期时间为 10 分钟。当缓存过期后，大量用户同时访问该页面，就会导致大量请求直接查询数据库，从而导致数据库压力过大，甚至可能导致数据库崩溃。

为了解决缓存雪崩问题，可以采取以下措施：

• 分散缓存过期时间：将缓存的过期时间分散开，避免大量缓存同时失效。
• 使用缓存预热：在系统启动时，将一些热点数据预先加载到缓存中，避免在系统启动后大量请求直接查询数据库。
• 使用缓存失效降级：当缓存失效时，暂时关闭缓存，直接查询数据库，并在后台异步更新缓存。

总之，缓存穿透和缓存雪崩都是缓存系统中常见的问题，需要根据具体情况采取相应的措施来解决。

Redis 集群是如何确定某个 K 存在某个节点的？

在 Redis 集群中，确定某个键（K）存在于哪个节点，是通过一种称为哈希槽（Hash Slot）的机制来实现的。

Redis 集群将整个键空间划分为 16384 个哈希槽，每个节点负责一部分哈希槽。当客户端要存储一个键值对时，它会根据键计算出一个哈希值，并将其映射到对应的哈希槽上。然后，客户端会将请求发送到负责该哈希槽的节点上。

具体来说，Redis 采用 CRC16 算法对键进行哈希运算，然后将得到的哈希值对 16384 取模，得到的结果就是对应的哈希槽编号。这样，每个键都会被映射到唯一的哈希槽上，而每个哈希槽又对应着唯一的节点。

通过这种方式，Redis 集群可以实现数据的分布式存储和查询，并且可以很容易地进行扩容和缩容。当集群中的节点数量发生变化时，只需要重新分配哈希槽，就可以实现数据的自动迁移和负载均衡。

说说Redis的持久化机制

Redis有两种持久化机制：RDB和AOF。

• RDB是一种快照持久化的方式，它会将Redis在某个时间点的数据状态以二进制的方式保存到硬盘上的一个文件中。RDB持久化可以通过配置定时或手动触发，也可以设置自动触发的条件。RDB的优点是生成的文件比AOF文件更小，恢复速度也更快，适合用于备份和灾难恢复。
• AOF是一种追加日志持久化方式，它会将Redis执行的写命令追加到一个文件的末尾。当Redis重启时，它会重新执行这些写命令来恢复数据状态。AOF提供了更可靠的持久化方式，因为它可以保证每个写操作都被记录下来，并且不会发生数据丢失的情况。AOF文件可以根据配置进行同步写入硬盘的频率，包括每秒同步、每写入命令同步和禁用同步三种模式。

在使用持久化机制时，可以选择同时使用RDB和AOF，也可以只使用其中一种。同时使用两种方式时，Redis在重启时会先加载AOF文件来恢复数据，如果AOF文件不存在或损坏，则会尝试加载RDB文件。因此，AOF具有更高的优先级。

Redis的过期策略

Redis的过期策略包括定期删除、惰性删除和内存淘汰机制。具体来说：

1. 定期删除：这是由Redis内部定时任务触发的删除策略，每隔一段时间，Redis会扫描数据库中的键，找出那些已经过期的键并删除它们。

2. 惰性删除：这种策略是在访问某个键时，如果发现该键已经过期，Redis会立即删除它。这种策略不会主动去查找过期键，而是在键被访问的时候才进行判断和删除。

3. 内存淘汰机制：当Redis内存不足以容纳新写入数据时，会根据一定的算法选择淘汰部分数据以释放空间。Redis提供了多种内存淘汰算法：

   • noeviction：不进行数据淘汰，新写入操作会报错。默认的内存淘汰策略
   • allkeys-lru：从所有键中选择最近最少使用的键进行淘汰。
   • allkeys-random：从所有键中随机选择键进行淘汰。
   • volatile-lru：从设置了过期时间的键中选择最近最少使用的键进行淘汰。
   • volatile-random：从设置了过期时间的键中随机选择键进行淘汰。
   • volatile-ttl：从设置了过期时间的键中选择剩余生存时间最短的键进行淘汰。

综上所述，了解这些策略有助于优化Redis的使用，确保数据的有效管理和内存的高效利用。

如何查找Redis中的big key

要查找Redis中的big key，可以采用以下几种方法：

1. 使用--bigkeys命令：这是Redis自带的命令，可以扫描整个key空间并统计string、list、set、zset和hash这几种数据类型中每种类型里最大的key。这个命令特别适合于分析string类型，因为string类型统计的是value的字节数。但需要注意的是，如果元素个数少，不一定value就大；反之，如果元素个数多，也不一定代表value就大。
2. 使用memory命令：从Redis 4.0版本开始支持，可以用来查看某个key占用的内存大小。这个命令可以帮助识别出那些占用内存较多的key。

此外，在处理big key时需要注意，big key可能会导致Redis性能问题，特别是在高并发的场景下。因此，定期检查和优化big key对于维护Redis的性能至关重要。

Redis的持久化方式

Redis的持久化方式主要有两种：RDB和AOF。以下是对这两种方式的详细说明：

1. RDB（Redis DataBase）：

• RDB是一种全量持久化方式，它会周期性地将内存中的数据以二进制格式保存到磁盘上的RDB文件。
• RDB文件是一个经过压缩的二进制文件，包含了数据库在某个时间点的数据快照。
• RDB快照有助于实现紧凑的数据存储，适合用于备份和恢复。
• 优点：RDB快照在恢复大数据集时速度较快，因为它是全量的数据快照。由于RDB文件是压缩的二进制文件，它在磁盘上的存储空间相对较小。适用于数据备份和灾难恢复。
• 缺点：可能会丢失最后一次快照之后的所有数据。
• 触发方式：可以通过执行save或bgsave命令手动触发，也可以通过配置文件设置自动触发条件。

2. AOF（Append Only File）：

• AOF持久化记录服务器执行的所有写命令，并在服务重启时通过命令重放来还原数据。
• AOF文件是一个明文文件，记录了所有写操作，因此具有较高的数据完整性。
• 优点：AOF记录了所有的写操作，因此可以提供更高的数据安全性。在系统崩溃后，可以通过重放日志恢复所有操作。
• 缺点：AOF文件的大小可能会比RDB文件大，因为它记录了每个写操作。
• 触发方式：AOF的写入策略可以通过配置文件设置，包括每次写入（同步）、每秒写入或者不主动写入由操作系统决定。

此外，还有一种混合持久化的方式，它兼顾了RDB和AOF的特性，可以在保证数据安全性的同时，也保证了数据的恢复效率。

总的来说，在选择持久化方式时，需要根据具体的应用场景和需求来决定。如果重视数据的安全性，可以选择AOF；如果重视恢复的效率和存储空间的利用，可以选择RDB。

Redis和Memcached的差异

Redis和Memcached都是高性能的内存数据库，用于缓存数据以加快应用程序的访问速度。它们之间的区别如下表所示：

综上所述，Redis提供了更加丰富的数据结构和功能，适用于需要复杂数据操作和持久化的应用场景；而Memcached则更专注于简单的键值缓存，适用于需要快速访问的场景。

网络

---

对称加密与非对称加密有什么区别？

对称加密：指加密和解密使用同一密钥，优点是运算速度较快，缺点是如何安
全将密钥传输给另一方。常见的对称加密算法有：DES、AES 等。

非对称加密：指的是加密和解密使用不同的密钥（即公钥和私钥）。公钥与私
钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常
见的非对称加密算法有 RSA。

DNS 的解析过程？

DNS，英文全称是 domain name system，域名解析系统，是 Internet上作为域名和 IP 相互映射的一个分布式数据库。它的作用很明确，就是可以根据域名查出对应的 IP 地址。在浏览器缓存、本地 DNS 服务器、根域名服务器都是怎么查找的，大家回答的时候都可以说下哈。
DNS 的解析过程如下图：

forward 和 redirect 的区别？

• 直接转发方式（Forward） ，客户端和浏览器只发出一次请求，
  Servlet、HTML、JSP 或其它信息资源，由第二个信息资源响应该请求，在请
  求对象 request 中，保存的对象对于每个信息资源是共享的。
• 间接转发方式（Redirect） 实际是两次 HTTP 请求，服务器端在响应第一次
  请求的时候，让浏览器再向另外一个 URL 发出请求，从而达到转发的目的。

Redirect 的工作原理：
forward 的工作原理

聊聊 SQL 注入？

SQL 注入是一种代码注入技术，一般被应用于攻击 web 应用程序。它通过在web 应用接口传入一些特殊参数字符，来欺骗应用服务器，执行恶意的 SQL命令，以达到非法获取系统信息的目的。它目前是黑客对数据库进行攻击的最常用手段之一

请详细介绍一下 TCP 的三次握手机制？

• 第一次握手(SYN=1, seq=x)，发送完毕后，客户端就进入 SYN_SEND 状态
• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)， 发送完毕后，服务器
  端就进入 SYN_RCV 状态。
• 第三次握手(ACK=1，ACKnum=y+1)，发送完毕后，客户端进入
  ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态。

TCP 握手为什么是三次，为什么不能是两次？不能是四次

思路: TCP 握手为什么不能是两次，为什么不能是四次呢？为了方便理解，我
们以男孩子和女孩子谈恋爱为例子：两个人能走到一起，最重要的事情就是相
爱，就是我爱你，并且我知道，你也爱我，接下来我们以此来模拟三次握手的
过程：

为什么握手不能是两次呢？

如果只有两次握手，女孩子可能就不知道，她的那句我也爱你，男孩子是否收
到，恋爱关系就不能愉快展开。

为什么握手不能是四次呢？

因为握手不能是四次呢？因为三次已经够了，三次已经能让双方都知道：你爱
我，我也爱你。而四次就多余了。

TCP 四次挥手过程?

TCP 四次挥手过程

1. 第一次挥手(FIN=1，seq=u)，发送完毕后，客户端进入 FIN_WAIT_1 状态。
2. 第二次挥手(ACK=1，ack=u+1,seq =v)，发送完毕后，服务器端进入CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态。
3. 第三次挥手(FIN=1，ACK1,seq=w,ack=u+1)，发送完毕后，服务器端进入LAST_ACK 状态，等待来自客户端的最后一个 ACK。
4. 第四次挥手(ACK=1，seq=u+1,ack=w+1)，客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT 状态，等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。

TCP 挥手为什么需要四次呢？

思路： TCP 挥手为什么需要四次呢？为了方便大家理解，再举个生活的例子吧。
小明和小红打电话聊天，通话差不多要结束时，小红说，“我没啥要说的了”。小明回答，“我知道了”。但是小明可能还有要说的话，小红不能要求小明跟着她自己的节奏结束通话，于是小明可能又叽叽歪歪说了一通，最后小明说，“我说完了”，小红回答，“我知道了”，这样通话才算结束。

TCP 四次挥手过程中，为什么需要等待 2MSL,才进入CLOSED 关闭状态

2MSL，two Maximum Segment Lifetime，即两个最大段生命周期。

假设主动发起挥手的是客户端，那么需要 2MSL 的原因是：

1. 为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 这个 ACK 报
   文段有可能丢失，因而使处在 LAST-ACK 状态的服务端就收不到对已发送的
   FIN + ACK 报文段的确认。服务端会超时重传这个 FIN+ACK 报文段，而客
   户端就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK
   报文段。接着客户端重传一次确认，重新启动 2MSL 计时器。最后，客户端和
   服务器都正常进入到 CLOSED 状态。
2. 防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个
   ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所
   有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接
   请求报文段。

说说 TCP 是如何确保可靠性的呢？

• 首先，TCP 的连接是基于三次握手，而断开则是基于四次挥手。确保连接和断开的
  可靠性。
• 其次，TCP 的可靠性，还体现在有状态;TCP 会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
• 再次，TCP 的可靠性，还体现在可控制。它有数据包校验、ACK 应答、超时重传(发送方)、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。

请简述 TCP 和 UDP 的区别

1. TCP 面向连接（如打电话需要先拨号），UDP 面向无连接（即发送数据前不需要建立连接）。
2. TCP 提供可靠的服务，UDP 无法保证。
3. TCP 面向字节流，而 UDP 面向报文。
4. TCP 数据传输慢，UDP 数据传输快
5. TCP 是点对点连接的，UDP 可以一对一，一对多，多对多都可以。
6. TCP 适用于邮件、网页等，UDP 适用于语音广播等。

Java

String，Stringbuffer，StringBuilder 的区别

• String：
  • String 类是一个不可变的类，一旦创建就不可以修改。
  • String 是 final 类，不能被继承
  • String 实现了 equals()方法和 hashCode()方法
• StringBuffer：
  • 继承自 AbstractStringBuilder，是可变类。
  • StringBuffer 是线程安全的
  • 可以通过 append 方法动态构造数据。
• StringBuilder：
  • 继承自 AbstractStringBuilder，是可变类。
  • StringBuilder 是非线性安全的。
  • 执行效率比 StringBuffer 高。

Java中的几种基本数据类型是什么，各自占用多少字节呢

• byte：占用1个字节（8位），取值范围从-128到127。
• short：占用2个字节（16位），取值范围从-32768到32767。
• int：占用4个字节（32位），取值范围从-2147483648到2147483647。
• long：占用8个字节（64位），取值范围从-9223372036854775808到9223372036854775807。
• float：占用4个字节（32位），取值范围从-3.4e+38到3.4e+38。
• double：占用8个字节（64位），取值范围从-1.7e+308到1.7e+308。
• char：占用2个字节（16位），用于表示Unicode字符，取值范围从’\u0000’到’\uffff’。
• boolean：虽然理论上占用1位（1/8字节），在实际应用中通常按1个字节处理

HashMap扩容机制原理

HashMap的扩容机制是当元素数量超过阈值时触发。这个阈值是由容量（capacity）和加载因子（loadFactor）共同决定的，计算公式为：阈值 = 容量 * 加载因子。在JDK7中，HashMap的扩容过程相对简单，它会创建一个新的数组，这个新数组的大小是原数组大小的两倍，然后将旧数组中的元素重新计算哈希值并放入新数组中。而在JDK8中，HashMap引入了红黑树的数据结构来处理哈希冲突，当链表长度大于等于8时，链表会转换为红黑树，以提高查询效率。

具体来说，HashMap的扩容主要包括以下几个步骤：

1. 计算新的容量：新的容量大小通常是旧容量的两倍，即newCapacity = oldCapacity * 2。
2. 创建新的数组：根据计算出的新容量创建一个更大的数组。
3. 重新散列：遍历旧数组中的所有元素，计算每个元素的哈希值并将其映射到新数组的相应位置上。
4. 解决哈希冲突：如果新数组对应位置已有元素（即发生哈希冲突），则将其链入同一位置的链表中；如果链表长度大于等于8，则将链表转换为红黑树以提高查找效率。
5. 更新容量：将旧数组替换为新数组，并更新容量等相关属性。

HashMap的扩容是一个成本较高的操作，因为它涉及到重新计算所有元素的哈希值并可能需要解决哈希冲突。因此，合理地预估并设置HashMap的初始容量和加载因子是非常重要的，以减少扩容的次数，提高HashMap的性能。

HashMap存储结构

HashMap的存储结构主要包括哈希表（数组）、链表和红黑树。具体来说：

• 哈希表（数组）：HashMap通过一个数组来存储键值对，这个数组的每个元素都是一个链表或红黑树，用于解决哈希冲突。当插入一个新的键值对时，HashMap会根据键的哈希值计算出在数组中的索引位置。
• 链表：当两个不同的键拥有相同的哈希值时，它们会被放在同一个数组索引处的链表中。这样可以保证即使发生了哈希冲突，键值对也能被正确地存储和访问。
• 红黑树：在Java 8中，当链表的长度超过一定阈值（默认为8），链表会被转换为红黑树。这样做的目的是为了提高搜索效率，因为红黑树是一种自平衡的二叉查找树，可以在O(log n)的时间复杂度内进行搜索操作。

此外，HashMap的初始容量是16，这意味着在创建HashMap时，会先创建一个长度为16的空数组。随着元素的增加，HashMap会在必要时进行扩容，通常是将数组的大小翻倍，并重新散列所有的键值对到新数组中。

总的来说，HashMap的设计旨在提供快速的插入和查询操作，同时通过合理的数据结构和扩容机制来处理潜在的哈希冲突。

HashMap和HashTable的区别

HashMap和Hashtable都实现了Map接口，但它们在线程同步、空值键值、API方法以及继承关系上有显著不同。

首先，HashMap是非线程安全的，而Hashtable是线程安全的。由于Hashtable的方法都是同步的，它可以在多线程环境中直接使用。相比之下，HashMap在多线程环境下需要外部同步措施，例如通过Collections.synchronizedMap()来保证线程安全。

其次，HashMap允许null作为键或值，而Hashtable不允许。这使得HashMap在使用上更为灵活，但也要注意null值的处理可能会引入复杂性。

再者，两者在API方法上也有所不同。HashMap提供了containsKey()和containsValue()方法，而Hashtable没有这些方法。这是因为Hashtable的contains()方法容易让人引起误解，不清楚是指包含某个键还是值。

最后，Hashtable是基于过时的Dictionary类的，而HashMap是在Java 1.2中随着Map接口一起引入的。HashMap不仅功能更丰富，而且不是基于陈旧类实现的，因此在现代Java代码中更常被推荐使用。

综上所述，虽然HashMap和Hashtable在哈希表的实现机制上相似，但它们在线程同步和空值键值等方面存在明显差异。选择使用哪一个取决于具体的场景需求。

JDK 1.7 ConcurrentHashMap 实现原理

JDK 1.7版本的ConcurrentHashMap通过分段锁技术实现了高效的并发访问。具体来看：

• Segment结构：在JDK 1.7中，ConcurrentHashMap由一个Segment数组组成，每个Segment都是一个独立的哈希表结构，内部包含一个Entry数组。Segment继承了ReentrantLock，因此每个Segment都有自己的锁。
• 数据存储：每个Segment内部维护了一个链表数组，用于解决哈希冲突的问题。当多个键的哈希值相同时，它们会被存储在同一个链表中。
• 初始化大小：ConcurrentHashMap在初始化时会确定Segment的大小，这个过程涉及到位运算和左移操作，以确保Segment的数量能够满足并发需求。
• 并发控制：由于每个Segment都有自己的锁，因此不同的线程可以同时访问不同的Segment，从而实现真正的并发访问。这种设计允许多个线程同时对ConcurrentHashMap进行读写操作，而不会互相干扰。

综上所述，JDK 1.7版本的ConcurrentHashMap通过将数据分割成多个Segment，并为每个Segment配备独立的锁，实现了高并发环境下的线程安全。这种分段锁的设计使得ConcurrentHashMap在多线程程序中具有很高的性能和可用性。

jdk 1.7 中 ConcurrentHashMap 是怎么判断key 在哪个Segment的

在 JDK 1.7 中，ConcurrentHashMap 是通过将数据分为多个 Segment 来实现并发控制的。每个 Segment 都是一个独立的小的哈希表，它们共享同一个数组，但是每个 Segment 都有自己的锁。这样，在多线程环境下，不同的线程可以同时访问不同的 Segment，从而提高并发性能。

要判断一个 key 在哪个 Segment 中，可以通过计算 key 的 hashCode，然后对 Segment 的数量取模得到。以下是一个简单的示例：

import java.util.concurrent.ConcurrentHashMap;

public class ConcurrentHashMapExample {
    public static void main(String[] args) {
        ConcurrentHashMap<String, String> concurrentHashMap = new ConcurrentHashMap<>();
        int segmentSize = concurrentHashMap.segmentSize();
        int segmentMask = concurrentHashMap.segmentMask();

        String key = "example";
        int hashCode = key.hashCode();
        int segmentIndex = (hashCode & segmentMask) / segmentSize;

        System.out.println("Key: " + key + " is in segment index: " + segmentIndex);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

在这个示例中，我们首先创建了一个 ConcurrentHashMap 实例。然后，我们获取了它的 segmentSize 和 segmentMask。接下来，我们计算了 key 的 hashCode，并通过对 segmentMask 进行按位与操作和除以 segmentSize 来得到 key 所在的 Segment 索引。最后，我们输出了这个索引。

JDK 1.8 ConcurrentHashMap 实现原理

JDK 1.8版本的ConcurrentHashMap通过降低锁的粒度和改进数据结构来提高并发性能。具体来看：

• 锁的粒度：与JDK 1.7相比，JDK 1.8的ConcurrentHashMap不再使用Segment，而是直接对节点加锁。这意味着锁的粒度更细，只锁定链表或红黑树的首节点，而不是整个Segment。
• 数据结构：ConcurrentHashMap采用了数组、链表和红黑树的结构。当链表长度超过一定阈值时，链表会转换为红黑树以提高搜索效率。
• 并发原理：ConcurrentHashMap利用CAS操作（Compare-And-Swap）来实现乐观锁，以及synchronized关键字来对头节点加锁，确保并发操作的安全性。
• 方法分析：在put操作中，首先根据key的hash值定位到桶位置，然后使用CAS操作获取该位置的头节点，最后使用synchronized锁锁住头节点，遍历该位置的链表或红黑树进行插入操作。

综上所述，JDK 1.8的ConcurrentHashMap通过优化锁机制和数据结构，提供了更高的并发性能和更好的线程安全性。这些改进使得ConcurrentHashMap成为高并发环境下非常有效的哈希表实现。

ArrayList和LinkedList的区别

ArrayList和LinkedArrayList都是 Java 标准库中的集合类，它们的主要区别在于底层数据结构和操作的不同。

ArrayList是基于动态数组实现的集合类，它的底层数据结构是数组。ArrayList在进行添加、删除、查询等操作时，会根据索引进行数组元素的移动和复制，因此在索引位置上的操作性能较好，但是在插入和删除元素时，需要移动和复制数组中的元素，因此性能较差。

LinkedList是基于双向链表实现的集合类，它的底层数据结构是链表。LinkedList在进行添加、删除、查询等操作时，不需要移动和复制数组中的元素，因此在插入和删除元素时，性能较好，但是在索引位置上的操作性能较差。

总的来说，ArrayList适用于需要高效的随机访问和按索引访问的场景，而LinkedList适用于需要高效的插入和删除操作的场景。

ArrayList和LinkedList的扩容机制

ArrayList和LinkedList在扩容时都使用了相似的机制，但是在细节上有所不同。

ArrayList在扩容时，会创建一个新的数组，长度是原数组长度的 1.5 倍，并将原数组中的元素复制到新数组中。例如，如果原数组长度为 10，扩容后新数组的长度将为 15。ArrayList的扩容机制可以减少数组的复制次数，提高性能。

LinkedList在扩容时，也会创建一个新的数组，长度是原数组长度的 1.5 倍，并将原数组中的元素复制到新数组中。与ArrayList不同的是，LinkedList还会维护一个双向链表，用于记录每个元素的插入顺序。在扩容时，LinkedList会将双向链表中的元素逐个复制到新数组中，并更新双向链表的指针。

需要注意的是，ArrayList和LinkedList的扩容机制都是在添加元素时触发的。如果在插入元素时发现数组已满，就会进行扩容。如果在扩容过程中需要移动大量的元素，可能会导致性能下降。因此，在使用这两个集合类时，需要根据实际情况选择合适的容量，并尽量避免频繁的扩容操作。

JDK 9版本前后，双亲委派模型的变化

在JDK 9版本前后，双亲委派模型的变化主要体现在类加载器的结构调整和模块化系统的引入。具体如下：

1. 类加载器结构调整：在JDK 9之前，Java的类加载器通常分为三种：Bootstrap ClassLoader、Extension ClassLoader和Application ClassLoader。其中，Bootstrap ClassLoader负责加载核心的Java类库，Extension ClassLoader负责加载扩展类库，而Application ClassLoader则负责加载应用程序级别的类。在JDK 9之后，Extension ClassLoader被移除，取而代之的是Platform ClassLoader和Application ClassLoader。
2. 模块化系统的引入：JDK 9引入了Java模块化系统（Java Platform Module System），这是为了实现更好的封装隔离机制。模块化系统的引入也意味着JVM对类加载架构进行了调整，这在一定程度上改变了双亲委派模型的工作方式。
3. 安全性考虑：双亲委派模型的主要目的是为了保证Java官方类库的安全性，防止被开发者覆盖。在JDK 9之前，<JAVA_HOME>lib和<JAVA_HOME>lib\ext中的类库不会被破坏，而在JDK 9之后，由于模块化系统的引入，这种保护机制有所改变，但仍然保持了对核心类库的保护。
4. 破坏双亲委派的方式：虽然双亲委派模型旨在保证安全性，但在某些情况下，如SPI机制和OSGi热替换机制，双亲委派模型会被破坏。JDK 9之后的模块化系统也可以看作是对双亲委派模型的一种破坏，因为它允许更多的灵活性和可配置性。

总结来说，JDK 9的发布对双亲委派模型带来了显著的变化，这些变化旨在提高系统的模块化和可维护性，同时也考虑到了安全性和兼容性的需求。

可以打破双亲委派模型吗

可以打破双亲委派模型。

双亲委派模型是Java类加载器的一个核心概念，它确保了类加载的层次性和安全性。但在某些情况下，开发者可能会出于特定需求打破这一模型。以下是一些打破双亲委派模型的常见做法：

1. 自定义类加载器：通过重写ClassLoader类的findClass()方法，可以实现对无法被父类加载器加载的类进行加载。如果需要直接打破双亲委派模型，可以重写loadClass()方法，但这通常涉及到更复杂的实现和潜在的风险。
2. SPI机制：Service Provider Interface（SPI）机制允许第三方提供的JAR文件中的类可以被加载，即使它们位于CLASSPATH中。这是通过线程上下文类加载器来实现的，它可以在运行时决定使用哪个类加载器来加载类，从而绕过双亲委派模型的限制。
3. 模块化系统：Java 9引入的模块化系统允许更加灵活的类可见性和加载策略，这在一定程度上也改变了双亲委派模型的工作方式。模块系统可以指定模块间的依赖关系和访问权限，从而实现对类加载流程的更精细控制。
4. OSGi平台：OSGi服务平台是一个支持模块化的Java框架，它允许在运行时动态加载、更新和卸载模块。这种动态性要求能够打破双亲委派模型，以便在不同模块间隔离类加载过程。
5. 应用服务器：许多应用服务器（如Tomcat）为了实现热部署和隔离不同的应用程序，也会打破双亲委派模型。它们通常会使用自定义的类加载器来加载应用程序的类，而不是依赖于系统的类加载器。

需要注意的是，打破双亲委派模型可能会导致一些问题，例如安全问题和类版本冲突等。因此，在决定打破双亲委派模型时，应当仔细评估潜在的风险和收益。

Tomcat为什么打破双亲委派模型？/Tomcat为什么自定义加载器？

Tomcat打破双亲委派模型的原因主要是为了实现不同Web应用程序之间的隔离性。具体原因如下：

• 应用隔离性：Tomcat作为一个Web服务器，通常会部署多个Web应用程序。这些应用程序可能会包含相同类名的类或引用不同版本的同一个JAR包。如果遵循双亲委派模型，一个类只能被加载一次，这会导致潜在的冲突和版本控制问题。为了确保每个Web应用程序能够在自己的类加载器环境中独立运行，避免类版本冲突和类名冲突，Tomcat需要打破双亲委派模型。
• 热部署：Tomcat支持热部署，即在不重启服务器的情况下部署或更新Web应用程序。为了实现这一点，每个Web应用程序必须能够在不同的类加载器中独立加载和卸载，这也要求打破双亲委派模型。

此外，Tomcat通过使用自定义的WebAppClassLoader来实现这一机制。WebAppClassLoader会先于父类加载器尝试加载类，这样就能保证Web应用程序的类加载优先级高于系统类加载器，从而实现了应用程序间的隔离。

综上所述，Tomcat打破双亲委派模型是为了提供更好的Web应用程序隔离性和灵活性，这对于运行多版本的JAR包和实现热部署等功能至关重要。

布隆过滤器的实现原理

布隆过滤器的实现原理基于哈希函数和位数组。

布隆过滤器是一种空间效率极高的概率型数据结构，它利用哈希函数的特性来检测一个元素是否属于某个集合。具体来说，布隆过滤器的工作过程包括两个核心步骤：元素的添加和元素的查询。

• 元素添加：当一个元素需要被添加到布隆过滤器中时，会通过K个不同的哈希函数对该元素进行计算，得到K个哈希值。这些哈希值对应到位数组中的特定位置，然后将这些位置的值设置为1。
• 元素查询：在查询一个元素时，同样使用那K个哈希函数计算出对应的位数组位置，然后检查这些位置是否都为1。如果所有位置都是1，那么元素可能属于集合；如果有任何一个位置是0，那么元素肯定不在集合中。

需要注意的是，由于哈希函数的冲突和位数组的空间限制，布隆过滤器存在一定的误判率。这意味着在某些情况下，布隆过滤器可能会错误地判断一个不属于集合的元素为其成员。这个误判率与位数组的大小和使用的哈希函数数量有关：位数组越大，哈希函数越多，误判率就越低，但相应地占用的空间也会更大。

综上所述，布隆过滤器通过哈希函数和位数组的结合，实现了一种空间和时间效率都非常高的数据结构，尤其适用于处理大规模数据集和快速检索的场景。然而，它在提供高效性能的同时，也引入了误判的可能性，这在设计系统时需要权衡考虑。

布谷鸟过滤器（Cuckoo Filter）

布谷鸟过滤器（Cuckoo Filter）是一种基于哈希的数据结构，用于高效地判断一个元素是否属于一个集合。

布谷鸟过滤器的核心思想是使用两个或更多的哈希函数，每个元素在过滤器中有两个位置，这样可以有效地减少误报率。当插入一个新元素时，如果这两个位置都被占用，那么会随机选择其中一个位置替换掉原有的元素。这个过程类似于布谷鸟的巢寄生行为，因此得名“布谷鸟过滤器”。

布谷鸟过滤器的优点包括：

• 动态插入和删除：与布隆过滤器不同，布谷鸟过滤器支持元素的动态插入和删除，这使得它更适合于需要频繁更新数据的应用场景。
• 低误报率：通过使用多个哈希函数和两个位置的策略，布谷鸟过滤器能够有效降低误报率，提供更准确的查询结果。

然而，布谷鸟过滤器也存在一些缺点：

• 存储成本：由于每个元素需要存储两个位置的信息，布谷鸟过滤器的存储成本相对较高。
• 替换冲突：在插入新元素时，如果两个位置都被占用，需要进行替换，这可能导致其他元素的信息被移动，增加了管理的复杂性。

此外，布谷鸟过滤器适用于那些可以接受偶尔误报，但需要频繁更新数据的场景。例如，在网络缓存、数据库查询优化、大数据处理等领域，布谷鸟过滤器都可以发挥其优势。

布谷鸟过滤器和布隆过滤器的区别

布谷鸟过滤器和布隆过滤器都是用于判断一个元素是否属于某个集合的数据结构，但它们在误判率、存储空间以及元素存储上有所不同。具体分析如下：

1. 误判率：布谷鸟过滤器相较于布隆过滤器具有更低的误判率。布隆过滤器可能会误判，如果它说不存在那肯定不存在，如果它说存在，那数据有可能实际不存在。
2. 存储空间：布谷鸟过滤器需要更多的空间来存储数据。布隆过滤器并不存储原始数据，而布谷鸟过滤器中只会存储元素的指纹信息（几个bit，类似于布隆过滤器）。
3. 元素存储：布隆过滤器不能进行删除和更新操作。而布谷鸟过滤器支持动态插入和删除。

总的来说，布谷鸟过滤器适用于对误判率要求较高的场景，而布隆过滤器适用于对查询速度要求较高、可以容忍一定的误判率的场景。

CAP理论

CAP理论指出，分布式系统无法同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance） 这三个要求。

CAP理论是分布式计算领域的一个重要概念，它描述了在分布式系统中三个核心特性之间的关系和权衡：

1. 一致性（Consistency）：一致性是指分布式系统中的所有节点在同一时刻对某个数据的访问和修改结果是一致的。简单来说，就是数据的一致性，保证所有用户访问到的数据都是最新的。
2. 可用性（Availability）：可用性是指分布式系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求，系统都必须在有限的时间内给出回应，即系统提供的服务始终是可响应的。
3. 分区容忍性（Partition tolerance）：分区容忍性指的是分布式系统应该具有良好的分区适应能力，即使在消息传递发生延迟或故障时，系统也能够保持运行并接受新的请求。

综上所述，根据CAP理论，任何分布式系统只能在这三个指标中选择满足其中的两项。例如，一个系统如果要求高度的一致性和可用性，那么在出现网络分区时，系统可能无法保持这两点；反之，如果系统设计强调分区容忍性和可用性，则在网络故障时可能会牺牲一致性。因此，设计分布式系统时需要根据实际需求和场景来决定在这三者之间如何取舍和平衡。

BASE理论

BASE理论是针对分布式系统的高可用性和一致性之间的权衡提出的实践性原则。

BASE理论是在CAP理论的基础上演化而来的，它更加符合大规模互联网服务的实际需求。在分布式系统中，CAP理论指出无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。而在实际的互联网服务中，通常选择牺牲一定程度的一致性来保证系统的可用性和分区容错性。

以下是BASE理论的核心内容：

• 基本可用性（Basically Available）：系统大部分时间都是可用的，但允许在特定情况下（如系统升级、故障恢复等）出现短暂的不可用状态。
• 软状态（Soft State）：系统的状态不需要时刻保持一致，允许存在中间状态，最终会达到一致。
• 最终一致性（Eventual Consistency）：系统的各个副本之间可能暂时不一致，但随着时间的推移，所有副本最终将达到一致的状态。

综上所述，BASE理论提供了一种更为灵活的处理方式，适用于那些对一致性要求不是特别严格，但需要高可用性和良好用户体验的互联网应用。

负载均衡策略

常见的负载均衡策略包括以下几种：

1. 轮询（Round Robin）：这是最简单的负载均衡策略之一，它按照顺序将每个新的请求分发给后端服务器，依次循环。这种策略适用于后端服务器性能相近且每个请求处理时间大致相同的情况。
2. 随机（Random）：服务消费者每次会任意访问一个服务提供者，并且从概率角度看每个提供者被访问的概率一致。这种策略简单且易于实现，但可能导致服务器间的负载不均。
3. 加权轮询（Weighted Round Robin）：与普通轮询类似，但是可以为每台服务器分配一个权重值，权重越高的服务器处理的请求越多。这种策略适用于服务器性能不均等的情况。
4. 最少连接（Least Connections）：将新的请求发送给当前连接数最少的服务器。这种策略适用于处理长连接或不同请求处理时间差异较大的场景。在最小连接数负载均衡策略中，当请求第一次进来时，负载均衡器还不知道每个服务器的当前连接数，因此无法直接选择具有最少连接数的服务器。在这种情况下，负载均衡器通常会使用轮询策略来选择一个服务器来处理请求。 最小连接数负载均衡策略是最符合分布式系统的负载均衡策略
5. 源地址哈希（Source IP Hash）：根据客户端的IP地址进行哈希计算，然后将请求发送到对应的服务器。这种策略可以保证同一客户端的请求总是发送到同一台服务器，适用于需要保持客户端会话的场景。
6. 一致性哈希（Consistent Hash）：通过一致性哈希算法将所有服务器映射到一个环形空间上，根据请求的哈希值来确定处理该请求的服务器。这种策略在服务器增减时能够保持较好的负载均衡效果。
   综上所述，选择合适的负载均衡策略需要考虑多种因素，包括服务器的性能、请求的特点、系统的可扩展性以及成本等。在实际应用中，通常需要根据具体场景和需求来选择最合适的负载均衡策略。

如何理解java并发中的可见性（volatile关键字）

在Java并发编程中，可见性是指一个线程对共享变量所做的修改，对于其他线程来说，能够立即得知这一修改。要理解Java并发中的可见性，需要关注以下几个核心概念：

1. 内存模型：Java内存模型定义了主内存和每个线程的工作内存。线程操作的数据都是从其工作内存中读取的，修改也是在工作内存中进行，然后在某个时间点写回主内存。这就可能导致一个线程在工作内存中的修改，对其他线程不可见。
2. 可见性问题：当一个线程对共享变量做出修改后，其他线程可能会继续使用该变量的旧值，因为它们的工作内存中的副本尚未更新。这就是所谓的可见性问题，它会导致程序的行为不符合预期。
3. volatile关键字：为了解决可见性问题，Java提供了volatile关键字。当一个变量被声明为volatile时，它会保证该变量的修改对所有线程立即可见。这是通过确保对该变量的读写直接在主内存中进行，而不是在工作内存中缓存，来实现的。
4. 原子性、可见性和有序性：这三个特性是保证并发程序正确性的关键。原子性保证了操作的不可中断，可见性保证了变量修改的即时可见，而有序性则保证了操作的顺序执行。

综上所述，理解Java并发中的可见性，需要了解内存模型的概念，以及如何通过volatile关键字来保证变量修改的可见性。同时，还需要认识到可见性问题是并发编程中的一个常见问题，它可能会导致程序运行结果的不确定性。

代码示例（volatile关键字）

以下是使用volatile关键字的示例代码：

public class VolatileExample {
    private static volatile boolean flag = false;

    public static void main(String[] args) throws InterruptedException {
        Thread thread1 = new Thread(() -> {
            while (!flag) {
                // 等待flag变为true
            }
            System.out.println("Thread 1: Flag is true!");
        });

        Thread thread2 = new Thread(() -> {
            try {
                Thread.sleep(1000); // 模拟耗时操作
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            flag = true; // 修改flag的值
            System.out.println("Thread 2: Set flag to true!");
        });

        thread1.start();
        thread2.start();

        thread1.join();
        thread2.join();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

在这个例子中，我们创建了两个线程。第一个线程会一直循环，直到flag变量被设置为true。第二个线程会在1秒后将flag变量设置为true。由于flag变量被声明为volatile，所以当它被修改时，所有线程都会立即看到这个变化，从而避免了可见性问题。

多线程

ThreadLocal

ThreadLocal是Java中的一个类，它用于在每个线程中存储一个独立的变量副本。ThreadLocal提供了一种线程局部变量的机制，使得每个线程都可以独立地访问和修改自己的局部变量，而不会影响其他线程的局部变量。

ThreadLocal的主要作用是解决多线程环境下的数据安全问题。在多线程编程中，多个线程可能会同时访问共享资源，如果没有适当的同步措施，就会导致数据不一致的问题。使用ThreadLocal可以避免这种情况的发生，因为每个线程都有自己的局部变量副本，不会相互干扰。

ThreadLocal的使用方法如下：

1. 创建一个ThreadLocal对象：ThreadLocal<T> threadLocal = new ThreadLocal<>();

2. 设置当前线程的局部变量值：threadLocal.set(value);

3. 获取当前线程的局部变量值：T value = threadLocal.get();

4. 清除当前线程的局部变量值：threadLocal.remove();

需要注意的是，使用完ThreadLocal后，应该及时调用remove方法来清除局部变量值，以避免内存泄漏问题。

ThreadLocal 底层实现原理

ThreadLocal的底层实现原理是通过一个Map来存储每个线程对应的局部变量值。具体来说，ThreadLocal内部维护了一个ThreadLocalMap对象，该对象是一个弱引用的哈希表，用于存储每个线程的局部变量值。

当调用ThreadLocal的set方法时，会将当前线程作为key，将需要存储的值作为value，存入ThreadLocalMap中。如果当前线程已经存在对应的key，则会更新对应的value；否则，会在ThreadLocalMap中新增一条记录。

当调用ThreadLocal的get方法时，会获取当前线程作为key，从ThreadLocalMap中查找对应的value并返回。如果找不到对应的key，则返回null。

需要注意的是，由于ThreadLocalMap中的key是弱引用，因此当线程结束后，如果没有其他强引用指向ThreadLocal对象，那么ThreadLocal对象就会被垃圾回收器回收。此时，ThreadLocalMap中的对应记录也会被自动清除，从而避免了内存泄漏问题。

新建 T1、T2、T3 三个线程，如何保证它们按顺序执行？

按照顺序执行

要保证新建的T1、T2、T3三个线程按顺序执行，可以使用Java的CountDownLatch类。以下是一个示例：

import java.util.concurrent.CountDownLatch;

public class Main {
    public static void main(String[] args) throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(1);

        Thread t1 = new Thread(() -> {
            System.out.println("T1开始执行");
            // 执行任务
            System.out.println("T1执行完毕");
            latch.countDown();
        });

        Thread t2 = new Thread(() -> {
            try {
                latch.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("T2开始执行");
            // 执行任务
            System.out.println("T2执行完毕");
        });

        Thread t3 = new Thread(() -> {
            try {
                latch.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("T3开始执行");
            // 执行任务
            System.out.println("T3执行完毕");
        });

        t1.start();
        t2.start();
        t3.start();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

在这个示例中，我们创建了一个CountDownLatch实例，并将其计数器设置为1。然后，我们创建了三个线程T1、T2和T3。在每个线程的任务执行完毕后，我们调用latch.countDown()方法将计数器减1。在T2和T3线程中，我们使用latch.await()方法等待计数器变为0，然后再继续执行任务。这样，我们就可以确保T1、T2和T3线程按顺序执行。

按照指定顺序执行

要保证新建的T1、T2、T3三个线程按指定顺序执行，可以使用Java的Thread类的join()方法。以下是一个示例：

public class Main {
    public static void main(String[] args) throws InterruptedException {
        // 创建并启动第一个线程
        Thread t1 = new Thread(() -> {
            System.out.println("T1开始执行");
            // 执行任务
            System.out.println("T1执行完毕");
        });
        t1.start();

        // 等待第一个线程执行完毕
        t1.join();

        // 创建并启动第二个线程
        Thread t2 = new Thread(() -> {
            System.out.println("T2开始执行");
            // 执行任务
            System.out.println("T2执行完毕");
        });
        t2.start();

        // 等待第二个线程执行完毕
        t2.join();

        // 创建并启动第三个线程
        Thread t3 = new Thread(() -> {
            System.out.println("T3开始执行");
            // 执行任务
            System.out.println("T3执行完毕");
        });
        t3.start();

        // 等待第三个线程执行完毕
        t3.join();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

在这个示例中，我们首先创建并启动了第一个线程T1，然后使用t1.join()方法等待T1执行完毕。接着，我们创建并启动第二个线程T2，同样使用t2.join()方法等待T2执行完毕。最后，我们创建并启动第三个线程T3，使用t3.join()方法等待T3执行完毕。这样，我们就可以确保T1、T2和T3线程按指定顺序执行。

多线程之间如何进行通信？

在Java中，多线程之间可以通过共享内存、wait()/notify()方法、join()方法等方式进行通信。

以共享内存为例，新建T1、T2、T3三个线程，可以使用一个共享变量来作为线程间通信的媒介。例如：

public class Main {
    private static int count = 0; // 共享变量

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < 1000; i++) {
                    count++;
                }
            }
        });

        Thread t2 = new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < 1000; i++) {
                    count--;
                }
            }
        });

        Thread t3 = new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < 1000; i++) {
                    System.out.println("count=" + count);
                }
            }
        });

        t1.start();
        t2.start();
        t3.start();

        // 等待所有线程执行完毕
        t1.join();
        t2.join();
        t3.join();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

在这个示例中，我们创建了三个线程t1、t2和t3，它们分别对共享变量count进行加一、减一和输出操作。由于count是共享变量，因此这三个线程可以对其进行读写操作，从而实现线程间的通信。

怎么控制同一时间只有 2 个线程运行？

在Java中，可以使用Semaphore类来实现同一时间只有2个线程运行的控制。

Semaphore类是一个计数信号量，用来控制同时访问特定资源的线程数量。它常用于实现资源池，防止过度占用资源。

以下是一个示例：

import java.util.concurrent.Semaphore;

public class Main {
    private static Semaphore semaphore = new Semaphore(2); // 创建一个Semaphore对象，并设置最大并发数为2

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    semaphore.acquire(); // 获取许可
                    System.out.println("T1 is running");
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    semaphore.release(); // 释放许可
                }
            }
        });

        Thread t2 = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    semaphore.acquire(); // 获取许可
                    System.out.println("T2 is running");
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    semaphore.release(); // 释放许可
                }
            }
        });

        Thread t3 = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    semaphore.acquire(); // 获取许可
                    System.out.println("T3 is running");
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    semaphore.release(); // 释放许可
                }
            }
        });

        t1.start();
        t2.start();
        t3.start();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

在这个示例中，我们创建了一个Semaphore对象，并设置了最大并发数为2。然后，我们在每个线程的run方法中调用了semaphore.acquire()来获取一个许可，如果没有可用的许可，那么这个线程将会被阻塞，直到有其他线程释放了一个许可。最后，在每个线程的finally块中，我们调用了semaphore.release()来释放一个许可，这样其他等待的线程就可以获取到许可并开始执行了。

Java中的并发编程：深入理解CountDownLatch

Java中的并发编程：深入理解CountDownLatch

单核CPU的多线程

单核CPU上的“多线程”被称为伪多线程，因为在同一时间内，处理器只能处理一个逻辑段。然而，线程之间的切换速度很快，使得看起来像是多个线程“同时”运行。真正的多线程是在多核CPU上实现的，它可以同时处理多个逻辑段，从而充分发挥多核CPU的优势。

对于单核CPU，使用多线程的主要目的是为了防止阻塞。例如，如果单核CPU使用单线程，当某个线程阻塞（如远程读取数据）时，整个程序可能会停止运行，直到数据返回。但值得注意的是，多任务的处理方式在单核CPU上有多种策略：

当一个任务进入阻塞状态（如I/O操作或等待消息队列中的消息）时，CPU可以执行另一个任务，从而避免CPU时间的浪费。
一个任务在某些情况下可以主动放弃CPU的控制权，让其他任务得以运行。
让没有时间顺序依赖的不同任务交替进行，使用户在每个任务上都感受不到明显的延迟。

多核CPU的多线程

多核CPU的多线程是指在一个多核的处理器中，每个物理核心可以同时运行多个线程，以并行处理任务。在任意时刻，可能有多个线程在不同的核心上同时执行，从而实现了真正的并行处理。

例如，假设有一个四核CPU，如果计算机中的总的线程数量小于等于核数（即4），那线程就可以并行运行在不同的核中。在这种情况下，采用多进程、多线程、多协程，能更好地利用CPU, 它们不仅能并发执行，而且能并行执行。

需要明确的是，虽然多线程能充分利用CPU资源，但是一个线程只能挂在一个核上，并且每个核上的所有线程按照时间片轮转。此外，硬件上的多核多线程和C++的多线程大致相当于逻辑概念和实体概念的区别。例如，超线程技术（Hyper-threading，简称HT）就是一个实例，一内核例如双核CPU，运用了超线程技术就能在一颗芯片内部同时处理两个逻辑线程。

总的来说，多核CPU的多线程是一种能有效利用多核CPU的处理能力，提升程序运行效率的技术。

单核CPU的多线程和多核CPU的多线程的主别

单核CPU的多线程和多核CPU的多线程的主要区别在于他们的执行方式。在单核CPU上，多线程是通过轮流执行多个线程来实现的，每个线程被分配一个时间片来占用CPU。然而，由于在任何时刻只有一个线程能够获得CPU的执行权，所以这不能算真正的并行处理。

相比之下，多核CPU的多线程则是指多个线程被分配到多个核心上进行处理，这意味着在任意时刻，都有可能有多个线程在不同的核心上同时执行，从而实现了真正的并行处理。

从资源利用的角度来看，无论是单核还是多核，多线程的主要目的都是为了充分利用CPU的资源。但是，由于硬件上的限制，单核CPU的多线程的性能提升效果可能不如多核CPU明显。

java创建线程的几种方式

Java中创建线程的方式主要有四种：通过继承Thread类、实现Runnable接口、实现Callable接口和使用线程池。这些方式各有优缺点，适用于不同的场景。具体如下：

1. 继承Thread类：定义Thread类的子类，并重写该类的run方法，该run方法的方法体就代表了线程要完成的任务。创建Thread子类的实例，即创建了线程对象。调用线程对象的start()方法来启动该线程。这种方法的缺点是Java不支持多重继承，如果已经有了父类，就不能再继承Thread类。

2. 实现Runnable接口：实现Runnable接口，并重写run()方法，然后创建一个Runnable的实例，将其作为参数传递给Thread类的构造函数。这种方法的优点是不需要考虑多重继承的问题，因为可以实现了多个接口。

3. 实现Callable接口：实现Callable接口，并重写call()方法，然后创建一个Callable的实例，将其作为参数传递给FutureTask类的构造函数，再将FutureTask的实例作为参数传递给Thread类的构造函数。这种方法可以有返回值，并且能够处理异常。

4. 使用线程池：线程池可以有效地管理线程，提高系统性能。通过Executors类提供的一系列工厂方法可以创建不同类型的线程池，如固定大小的线程池、单线程的线程池等。线程池可以重复使用已创建的线程，减少线程创建和销毁的开销。

综上所述，Java提供了多种创建线程的方式，每种方式都有其适用的场景和优缺点。在实际应用中，应根据具体需求选择合适的方式来创建和管理线程。

为什么不建议使用Executors来创建线程池？

不建议使用Executors创建线程池的原因主要有以下几点：

1. 固定线程数量：Executors类中的方法（如newFixedThreadPool）会创建一个固定线程数量的线程池。这可能会导致资源浪费，因为即使部分线程处于空闲状态，它们也会一直占用内存和系统资源。

2. 无法调整线程数量：一旦线程池被创建，无法调整线程数量以适应不同的工作负载。这可能导致在高负载下性能不佳，或者在低负载下资源浪费。

3. 缺乏灵活性：Executors提供的方法虽然方便，但缺乏灵活性。例如，无法设置任务队列的长度、无法设置拒绝策略等。

4. 可能的内存泄漏：如果使用了Executors的newCachedThreadPool方法，它会创建一个可缓存的线程池。这个线程池在空闲时会保留所有线程，导致潜在的内存泄漏问题。

5. 无法定制：Executors提供的方法无法满足特定需求，如定制线程工厂、任务队列等。

因此，建议使用ThreadPoolExecutor类来创建线程池，这样可以更灵活地控制线程池的行为，避免上述问题。

线程池参数详解

Java线程池的参数对于其性能和行为有着至关重要的影响。以下是对这些参数的详细解释：

• 核心线程数（corePoolSize）：这是线程池中的基本线程数量，当提交一个任务时，线程池会首先创建这些核心线程来处理任务，直到达到核心线程数。如果线程池中的数量小于核心线程数，即使有线程空闲，也会创建新的线程来处理新任务。
• 最大线程数（maximumPoolSize）：这是线程池允许创建的最大线程数量。当任务数量超过核心线程数时，线程池会继续创建新的线程，直到达到这个上限。
• 空闲线程存活时间（keepAliveTime）：当线程池中的线程数量超过核心线程数时，空闲线程的存活时间就是由这个参数控制的。如果超过这个时间，多余的线程将会被终止，直到线程池中的线程数量等于核心线程数。
• 时间单位（unit）：这个参数与空闲线程存活时间（keepAliveTime）配合使用，指定存活时间的单位，如TimeUnit.SECONDS表示秒。
• 工作队列（workQueue）：当线程池中的线程都处于繁忙状态时，新提交的任务会被放入工作队列中等待执行。Java线程池提供了多种工作队列，如ArrayBlockingQueue、LinkedBlockingQueue等，不同的队列有不同的特性和适用场景。
• 线程工厂（threadFactory）：这个参数用于自定义线程的创建。通过提供ThreadFactory接口的实现，可以定制线程的创建过程，例如设置线程的名称、优先级等。
• 拒绝策略（handler）：当工作队列已满且无法创建新线程时，线程池会采取的策略。常见的策略包括AbortPolicy（抛出异常）、CallerRunsPolicy（在调用者线程中运行任务）、DiscardOldestPolicy（丢弃最老的任务）等。

综上所述，合理配置这些参数对于确保线程池高效稳定运行至关重要。

线程池工作流程

Java线程池处理流程涉及多个关键步骤，具体如下：

1. 任务提交：当一个任务被提交到线程池时，线程池会调用execute方法来接收这个任务。
2. 核心线程处理：如果当前运行的线程数量小于核心线程数（corePoolSize），线程池会立即创建一个新的线程来处理这个任务。
3. 任务队列处理：如果核心线程都在忙碌，线程池会将任务添加到阻塞队列中。如果队列已满，则进行下一步判断。
4. 非核心线程处理：如果队列已满且当前运行的线程数量小于最大线程数（maximumPoolSize），线程池会创建非核心线程来处理这个任务。
5. 饱和策略处理：如果队列满了并且当前运行的线程数量达到或超过了最大线程数，线程池会根据设定的饱和策略来处理这个任务，例如抛出异常或者丢弃任务等。
6. 线程执行任务：无论是核心线程还是非核心线程，线程在执行完当前任务后，会继续从队列中取下一个任务来执行，直到队列为空。
7. 线程终止：当所有任务都执行完毕，如果线程池允许，超出核心线程数的非核心线程会被终止。

综上所述，Java线程池的处理流程设计得既高效又灵活，能够根据任务量动态调整线程数量，同时通过队列和饱和策略来管理任务流，确保了系统资源的合理利用和任务的有效执行。

线程池工作队列详解

Java线程池的工作队列是用于存放待执行任务的队列。当线程池中的所有线程都在忙碌时，新提交的任务会进入这个队列等待执行。以下是对工作队列的详细解释：

1. 工作队列的类型：

• ArrayBlockingQueue：这是一个基于数组实现的有界阻塞队列，按照FIFO（先进先出）原则进行排序。它适用于需要确保任务顺序的场景。
• LinkedBlockingDeque：这是一个基于链表实现的双向阻塞队列，既可以按照FIFO排序，也可以按照LIFO（后进先出）排序。它的优点是在多线程环境下性能较好。
• SynchronousQueue：这是一个不存储元素的阻塞队列。每个插入操作必须等待另一个线程进行相应的取出操作，反之亦然。它通常用于传递性设计。

2. 工作队列与线程池的配合：

• 工作队列与线程池的maximumPoolSize参数结合使用，可以影响线程池的行为。例如，当使用ArrayBlockingQueue时，如果队列已满，线程池会尝试创建新的线程直到达到maximumPoolSize。如果使用SynchronousQueue，线程池会在队列为空时尝试创建新线程。

3. 工作队列的选择：

• 选择哪种类型的工作队列取决于具体的应用场景。例如，如果任务量很大且需要限制内存消耗，可以选择ArrayBlockingQueue并设置其容量。如果希望在线程之间直接传递任务，而不是排队等待，可以选择SynchronousQueue。

4. 工作队列的作用：

• 工作队列的主要作用是在线程池中的线程都处于繁忙状态时，提供一个缓冲机制，使得新提交的任务能够被暂存起来，等待线程池中的线程有空余时再进行处理。

综上所述，工作队列在Java线程池中扮演着至关重要的角色，它们不仅提供了任务的存储机制，还影响着线程池的整体行为和性能。选择合适的工作队列类型对于优化线程池的性能至关重要。

线程池拒绝策略详解

Java线程池的拒绝策略是当任务无法被线程池接受时采取的行动，这通常发生在工作队列已满且无法创建新的线程时。以下是对四种预设拒绝策略的详细解释：

• AbortPolicy（默认策略）：
  • 行为：直接抛出RejectedExecutionException异常，阻止系统正常运作。
  • 适用场景：适用于需要快速失败并提醒开发者或系统管理员采取行动的情况。
• DiscardPolicy：
  • 行为：静默丢弃任务，不给出任何通知或警告。
  • 适用场景：在任务丢失不会造成严重影响的情况下使用。
• DiscardOldestPolicy：
  • 行为：丢弃队列中最旧的任务，以便为新任务腾出空间。
  • 适用场景：适用于每个任务都有截止时间，且希望尽可能处理最新任务的场景。
• CallerRunsPolicy：
  • 行为：由提交任务的线程自己执行该任务，而不是将其放入线程池中。
  • 适用场景：适用于调用者有额外的处理能力，且不希望因为队列满而导致任务被拒绝的情况。

除了JDK提供的这些策略，还可以根据具体需求自定义拒绝策略。例如，可以记录被拒绝的任务，或者在任务被拒绝时触发某些清理操作。

综上所述，合理选择和配置拒绝策略对于确保线程池的稳定性和可靠性至关重要。

Java线程池如何选择核心线程数和最大线程数

选择线程池的核心线程数和最大线程数是确保其高效运行的关键。以下是具体的选择方法：

核心线程数的选择：

• CPU核心数：核心线程数（corePoolSize）通常设置为CPU核心数的数量，这样可以充分利用CPU资源，避免过多的线程上下文切换。
• 任务特性：对于计算密集型任务，核心线程数应接近CPU核心数；而对于IO密集型任务，由于线程在等待IO操作完成时会阻塞，可以适当增加核心线程数，以提高CPU利用率。
• 系统负载：如果系统同时运行多个应用或服务，还需要考虑其他应用对CPU的使用情况，以避免过度竞争CPU资源。

最大线程数的选择：

• 队列容量：最大线程数（maximumPoolSize）应该根据任务队列的容量来设置。如果队列容量有限，那么当队列满时，线程池需要创建新的线程来处理任务，直到达到最大线程数。
• 资源限制：最大线程数还应考虑系统资源的限制，如内存大小。过多的线程会消耗大量内存，可能导致系统性能下降。
• 性能测试：为了更准确地设置最大线程数，可以进行压力测试，监控JVM的线程情况和CPU的负载情况，根据实际情况调整线程数以合理利用资源。

综上所述，选择核心线程数和最大线程数需要综合考虑CPU核心数、任务特性、系统负载、队列容量、资源限制等因素。

线程池有哪几种状态，分别代表什么意思

线程池的状态包括以下几种：

1. 运行状态(RUNNING)：这是线程池的初始状态，在这个状态下，线程池会接收新任务并处理等待队列中的任务。如果线程池已达到其最大容量，新任务会根据拒绝策略被处理。
2. 关闭状态(SHUTDOWN)：当调用shutdown()方法时，线程池进入此状态。此时，线程池不再接受新的任务，但会继续执行已提交的任务直到全部完成。
3. 停止状态(STOP)：当调用shutdownNow()方法时，线程池会进入此状态。线程池会尝试停止正在执行的所有任务，并返回尚未开始执行的任务列表。
4. 整理状态(TIDYING)：在SHUTDOWN或STOP状态之后，当线程池中所有的任务都已完成并且所有线程都已被终止后，线程池会进入此状态。在此状态下，线程池会进行必要的清理工作，为最终的销毁做准备；该方法是空方法，留给程序员进行扩展。
5. 销毁状态(TERMINATED)：在TIDYING状态之后，当线程池完成了所有清理工作后，线程池会进入此状态。此时，线程池彻底停止，不能再接受任务，也无法被重新启动。

总的来说，了解线程池的状态对于合理使用和管理线程资源是非常重要的，可以帮助开发者更好地控制并发任务的执行和线程池的生命周期。

什么是公平锁和非公平锁？

公平锁和非公平锁是两种不同类型的锁机制，它们主要区别在于线程获取锁的顺序和方式。

公平锁：

• 公平锁是一种锁机制，在这种机制下，多个线程按照申请锁的顺序去获得锁。线程会直接进入队列排队，永远都是队列的第一位才能得到锁。这种方式确保了所有线程最终都有机会获得资源，避免了所谓的“饥饿”现象，即某些线程长时间等待而无法访问资源的情况。
• 公平锁的优点在于它提供了一种预测性较强的访问控制，因为线程获取锁的顺序是可以预知的。这有助于避免线程饿死，即某些线程长时间得不到执行的情况。
• 然而，公平锁的缺点在于它的吞吐量相对较低，因为每次只有一个线程能够获得锁，并且在释放锁后需要重新按照顺序来分配锁，这增加了额外的管理开销。

非公平锁：

• 非公平锁则不保证线程获取锁的顺序与请求顺序一致。当一个线程尝试获取锁时，如果锁是可用的，那么它可以直接获得锁，而不必进入队列等待。这种机制可能会导致某些线程长时间等待，因为它们可能会被不断到来的新线程“插队”。
• 非公平锁的优点在于它的吞吐量较高，因为它减少了线程排队等待的时间，允许线程在锁空闲时立即获得锁。
• 缺点是可能导致某些线程长时间等待，特别是在某些线程频繁请求锁的情况下，其他线程可能会“饥饿”。

公平锁和非公平锁之间的区别：

在选择使用公平锁还是非公平锁时，需要根据具体的应用场景和需求进行权衡。如果需要确保所有线程都能公平地获得资源，避免饥饿现象，那么公平锁是一个更好的选择；而如果对性能的要求更高，可以接受一定程度的不公平性，那么非公平锁可能更为合适。

什么是乐观锁和悲观锁？

乐观锁和悲观锁是处理并发场景下数据竞争的两种不同策略。

乐观锁：

• 乐观锁在操作数据时持乐观态度，假设在大部分时间内不会有其他线程对数据进行修改。因此，在读取数据时不会上锁，但在更新数据时会检查是否有冲突发生。
• 如果在更新时发现有冲突，通常需要重新读取数据并重试更新操作。乐观锁适用于读多写少的场景，可以减少锁的竞争，提高系统的吞吐量。

悲观锁：

• 悲观锁则假设数据经常会产生冲突，因此在数据处理前就会上锁，确保同一时间只有一个线程能访问数据。这样可以保证数据的完整性和一致性，但可能会降低系统的并发性能。
• 悲观锁适用于写多读少的场景，可以防止多个线程同时修改同一份数据，避免数据不一致的问题。

总的来说，选择使用乐观锁还是悲观锁取决于具体的应用场景和对数据一致性的要求。

JVM

垃圾回收器

垃圾回收器（Garbage Collector，简称GC）是Java虚拟机（JVM）用来自动管理内存的机制，主要负责回收堆内存中不再使用的对象，以释放内存资源。

垃圾回收器使用不同的算法来处理新生代和老年代的内存回收。具体来说：

• 新生代回收：新生代通常使用复制算法，该算法将新生代分为Eden区和两个Survivor区（S0和S1）。新创建的对象首先在Eden区分配，当Eden区满时，触发Minor GC。存活的对象被复制到Survivor区，如此往复，每经历一次GC，对象年龄增加。达到一定年龄阈值（如15岁）的对象会晋升到老年代。
• 老年代回收：老年代通常容纳生命周期较长、大对象或已经从新生代晋升的对象。当老年代空间不足时，会发生Full GC，这个过程比Minor GC慢很多，因为它涉及的内存区域更大、对象更多。

JVM提供多种垃圾回收器，它们适用于不同场景和需求：

• Serial收集器：它是最简单的收集器，使用单线程进行垃圾回收，会暂停所有应用线程。适合客户端应用。
• ParNew收集器：它是Serial的多线程版本，用于提高回收效率。
• Parallel Scavenge收集器：它关注于降低垃圾收集的停顿时间，通过多线程并行处理提高效率。
• Serial Old收集器：它是Serial收集器用于老年代的版本，同样是单线程工作。
• Parallel Old收集器：它是Parallel Scavenge用于老年代的版本，多线程并行收集。
• CMS收集器：它是一种并发标记清除的收集器，试图减少应用程序暂停时间。
• G1收集器：它将堆划分为多个区域，可以预测停顿时间，避免Full GC，适合大内存服务器应用。

总的来说，选择合适的垃圾回收器需要根据应用程序的特点和性能要求来决定。例如，对于响应时间敏感的应用，可以选择CMS或G1以避免长时间的停顿。而对于吞吐量优先的应用，可以选择Parallel Scavenge或Parallel Old。在实际使用中，还可以根据监控数据和分析结果调整垃圾回收策略，以获得最佳的性能表现。

垃圾回收算法

垃圾回收算法是自动内存管理机制的核心，它们负责识别和回收那些不再被程序使用的对象所占用的内存。以下是一些常见的垃圾回收算法：

1. 引用计数法：这是一种简单的垃圾回收算法，它通过为每个对象维护一个引用计数来工作。每当有一个新的引用指向该对象时，计数增加；当一个引用不再指向该对象时，计数减少。当对象的引用计数降至零时，意味着该对象不再被使用，可以被回收。这种方法的优点是实现简单，但缺点是无法处理循环引用的情况，即当两个或更多的对象彼此引用形成一个闭环时，即使这些对象不再被外部引用，它们的引用计数也不会为零，因此不会被回收。
2. 复制算法：这种算法将内存分为两个相等的部分，每次只使用其中一半。当这一半的内存用完后，就将还在使用的对象复制到另一半中，然后清除掉已经使用过的那一半内存。这种方法通常用于新生代的垃圾回收，因为它的效率较高，但是内存利用率较低。
3. 标记-清除法：这种算法首先标记出所有活动的对象（即仍在使用中的对象），然后清除掉未被标记的对象。这种方法适用于老年代的垃圾回收，它可以提高内存利用率，但是可能会产生内存碎片。
4. 标记-压缩法：这种方法在标记-清除法的基础上进行了改进，它在标记活动对象的同时，会将这些对象向一端移动，从而避免了内存碎片的问题。
5. 分代算法：这种算法基于这样一个观察：不同生命周期的对象往往具有不同的特性。因此，它将内存分为几个代（通常是新生代和老年代），并根据每个代的特点采用不同的回收策略。
6. Serial收集器：这是一种单线程收集器，它在进行垃圾回收时会暂停应用程序的运行。它的优点是简单高效，但是由于它会暂停应用程序，所以不适合对响应时间要求较高的场景。

综上所述，垃圾回收算法的目标是在不影响程序运行效率的前提下，尽可能地释放不再使用的内存。每种算法都有其适用的场景和优缺点，现代垃圾回收器通常会结合使用多种算法，以达到最佳的性能和效率。

什么是三色标记算法（阿里真题）

三色标记算法是一种高效的垃圾回收方法，它通过将对象分为白色、灰色和黑色三种状态来识别哪些对象是垃圾。具体来说：

• 白色对象：是指那些尚未被垃圾回收器访问过的对象。
• 灰色对象：是当前已经被垃圾回收器访问过，但还没有对其引用的所有对象进行处理的。
• 黑色对象：是完全被处理过的对象，即已经访问了该对象以及它引用的所有对象。

这个算法的核心在于将垃圾回收的过程分为多个阶段，以确保在不影响应用程序运行的情况下进行垃圾回收。这些阶段包括：

• 初始标记阶段：在这一阶段，所有从GC Roots直接可达的对象都会被标记为灰色。这个过程需要暂停应用程序的执行，即所谓的"Stop the World"。
• 并发标记阶段：在这一阶段，垃圾回收器会并发地遍历灰色对象，并将它们引用的对象标记为灰色，同时将这些对象转变为黑色。这个过程不需要暂停应用程序。
• 重新标记阶段：这一阶段是为了处理在并发标记阶段由于应用程序的运行而产生的新对象。这个阶段通常也需要"Stop the World"。
• 并发清除阶段：最后，系统会清除所有仍然标记为白色的对象，因为这些对象被认为是垃圾。

总的来说，三色标记算法通过这种分阶段的方法，能够在不显著影响应用程序性能的同时，有效地进行垃圾回收。这种方法特别适用于现代的多核处理器和大规模堆内存的应用场景。

CMS垃圾回收器的垃圾收集过程

CMS垃圾回收器的垃圾收集过程包括初始标记、并发标记、重新标记和并发清除四个阶段。具体如下：

1. 初始标记：这是垃圾回收过程的第一步，CMS垃圾回收器会暂停所有的应用线程（Stop the World），然后从根对象开始标记所有直接可达的对象。这个过程通常是非常快速的。
2. 并发标记：在初始标记之后，CMS垃圾回收器会与应用程序并发运行，继续标记从根对象可达的所有存活对象。这个步骤是为了减少整个垃圾回收过程中应用程序的停顿时间。
3. 重新标记：由于在并发标记阶段应用程序仍在运行，可能会有新的对象产生或原有的对象状态改变，因此需要重新标记那些可能发生变化的对象。这个阶段同样需要暂停应用程序，但停顿时间也相对较短。
4. 并发清除：最后，CMS垃圾回收器会清除掉所有未被标记的对象，即这些对象被认为是垃圾，可以回收它们占用的内存。这个阶段也是与应用程序并发执行的，以减少对应用程序的影响。

总的来说，CMS垃圾回收器的设计目标是尽量减少垃圾回收过程中应用程序的停顿时间，它主要适用于对响应时间要求较高的应用场景。然而，由于CMS在进行垃圾回收时不会压缩堆内存，可能会导致内存碎片问题。此外，如果堆内存不足，CMS可能会触发Full GC，这时的停顿时间会比较长。因此，在使用CMS垃圾回收器时，需要根据应用程序的特点和性能要求来合理配置JVM参数，以确保系统的稳定性和效率。

G1垃圾回收器的垃圾收集过程

G1 垃圾回收器是 Java 9 中引入的一种垃圾收集器，它是一种服务器端的垃圾收集器，适用于大内存和多处理器的环境。G1 垃圾回收器的垃圾收集过程分为以下几个阶段：

1. 初始标记：暂停所有用户线程，标记所有根对象（如线程栈中的对象、静态变量、全局变量等），这个阶段会触发一次年轻代垃圾回收。
2. 并发标记：与用户线程并发执行，标记所有可达对象。
3. 最终标记：暂停所有用户线程，标记所有在并发标记阶段被遗漏的可达对象。
4. 筛选回收：与用户线程并发执行，根据标记结果，选择需要回收的区域，并将存活对象复制到新的区域。

在 G1 垃圾回收器中，垃圾收集过程是并发进行的，因此可以减少垃圾收集对应用程序性能的影响。同时，G1 垃圾回收器还支持预测垃圾收集，可以根据应用程序的行为和内存使用情况，动态调整垃圾收集的时间和区域，以提高垃圾收集的效率。

G1垃圾回收器

G1垃圾回收器（Garbage-First）是Java HotSpot虚拟机中的一种垃圾回收器，它旨在满足低延迟和高吞吐量的需求，特别适合多核CPU和大内存的应用环境。以下是G1垃圾回收器的一些关键特点：

• 分区式堆结构：G1将Java堆分为多个大小相等的独立区域，这些区域被称为Region。这种设计使得G1能够并行地在多个Region中进行垃圾回收，从而提高了效率。
• 分代收集：虽然G1采用了分区式的堆结构，但它仍然遵循分代收集的原则，将对象分为年轻代和老年代。年轻代中有Eden区和Survivor区，但与传统的分代收集器不同，G1不要求这些区域在堆中是连续的。
• 预测性暂停时间：G1垃圾回收器的一个显著特点是它可以预测垃圾回收的暂停时间，这对于需要实时响应的应用程序来说非常重要。
• 增量式收集：G1在进行垃圾回收时，不会一次性处理整个堆空间，而是选择一部分Region进行处理，这样可以减少单次垃圾回收的暂停时间。
• 并发标记：在G1的垃圾回收过程中，标记阶段可以与应用程序线程并发执行，这有助于减少应用程序的停顿时间。
• 优化点：G1垃圾回收器针对大内存堆的场景进行了优化，能够有效地管理大量的内存区域，提高垃圾回收的效率。

总的来说，G1垃圾回收器通过其独特的设计和优化，为大内存、多核处理器的服务器端应用提供了高效的垃圾回收解决方案。它是官方推荐用于代替CMS收集器的选项，尤其是在对延迟敏感的应用中。

G1垃圾回收器和CMS 垃圾回收器的区别

G1垃圾回收器与CMS垃圾回收器在内存结构、收集范围和使用场景等方面存在显著差异。具体如下：

1. 内存结构：G1将堆内存划分为多个Region，这些区域是逻辑上连续的，但物理上可以不连续。每个Region可以是Eden、Survivor或Old区的一部分，而CMS则遵循传统的分代模型，有连续的内存空间分配给新生代和老年代。
2. 收集范围：G1可以在任何Region中进行垃圾回收，而CMS只针对老年代进行垃圾回收。这意味着G1可以更灵活地管理内存，而CMS则专注于老年代的垃圾收集。
3. STW（Stop-The-World）：G1在进行垃圾回收时会尝试限制STW的时间，使得停顿可预测，这对于响应时间敏感的应用非常重要。相比之下，CMS的STW通常发生在并发标记阶段结束后，且持续时间较长。
4. 使用场景：由于G1提供了预测性的停顿时间，它适用于对延迟敏感的应用程序，特别是在大内存和多核服务器环境中。而CMS适用于对响应时间要求较高的应用场景，尤其是当应用程序的内存使用相对稳定时。

总的来说，G1和CMS都是为了满足不同应用场景下的垃圾回收需求而设计的。G1通过区域划分和预测性停顿时间优化了垃圾回收过程，而CMS则专注于减少应用程序的停顿时间。在选择垃圾回收器时，应根据应用程序的具体需求和特点来决定使用哪种回收器。

有了CMS，为什么还要引入G1

CMS 垃圾收集器和 G1 垃圾收集器都是 Java 垃圾收集器，它们都可以用于垃圾收集和内存管理。但是，它们有一些不同的特点和适用场景。

CMS 垃圾收集器是一种老年代垃圾收集器，它使用标记-清除算法进行垃圾收集。CMS 垃圾收集器的优点是可以与用户线程并发执行，因此可以减少垃圾收集对应用程序性能的影响。但是，CMS 垃圾收集器也有一些缺点，例如在垃圾收集过程中会产生大量的内存碎片，需要进行内存整理，这会导致应用程序暂停。

G1 垃圾收集器是一种新的垃圾收集器，它使用标记-整理算法进行垃圾收集。G1 垃圾收集器的优点是可以更好地处理大内存和多处理器的环境，同时可以减少垃圾收集对应用程序性能的影响。G1 垃圾收集器还可以根据应用程序的行为和内存使用情况，动态调整垃圾收集的时间和区域，以提高垃圾收集的效率。

因此，引入 G1 垃圾收集器是为了更好地处理大内存和多处理器的环境，同时可以减少垃圾收集对应用程序性能的影响。

Java 应用程序发生 OOM（Out Of Memory）异常时，如果抓取转储Heap Dump

当 Java 应用程序发生 OOM（Out Of Memory）异常时，可以通过设置 JVM 参数来抓取堆转储文件（Heap Dump），以便进行内存分析和诊断。以下是抓取堆转储文件的常见步骤：

1. 在启动 Java 应用程序时，添加以下 JVM 参数：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/path/to/heapdump.hprof
1
2

上述参数中的-XX:+HeapDumpOnOutOfMemoryError表示当发生 OOM 异常时，JVM 会自动生成堆转储文件。-XX:HeapDumpPath=/path/to/heapdump.hprof指定了堆转储文件的保存路径和文件名。你可以根据实际情况修改路径和文件名。

2. 运行 Java 应用程序，触发 OOM 异常。

3. OOM 异常发生后，JVM 会将堆转储文件生成到指定的路径。

4. 使用 Java 内存分析工具（如 Eclipse MAT、Java Mission Control、HeapHero 等）打开堆转储文件进行分析。

请注意，抓取堆转储文件可能会导致一定的性能开销，因此只应在开发和测试环境中使用，或者在生产环境中出现问题时临时启用。同时，堆转储文件的大小可能很大，需要确保有足够的磁盘空间来保存。

一些常见的jvm参数配置

JVM提供了众多的参数用于调优和监控Java应用程序的运行，以下是一些补充的常用JVM参数及其含义：

除了上述参数，还有更多专门的参数用于特定的调优场景，例如与编译器优化、内存屏障、JIT编译相关的参数等。在实际工作中，根据应用的需求和系统环境，可能需要调整这些参数以获得最佳的运行效果。了解这些参数的作用可以帮助开发者更好地控制Java应用程序的性能和行为。

实战问题

cpu过高如何快速定位是哪一句代码导致的问题

1. 使用top命令查看系统的 CPU 使用情况。在终端中输入top命令，然后按下1键，可以查看每个 CPU 核心的使用情况。如果某个进程的 CPU 使用率过高，可以通过top命令的PID列找到该进程的进程 ID（PID）
2. top -H -p PID，这是一个 Linux 命令，用于显示特定进程（PID）的线程信息。其中：
   top：是一个常用的系统监控工具，用于实时显示系统的进程信息。
   -H：表示以线程模式显示。
   -p PID：指定要显示的进程的 PID。
   通过执行top -H -p PID命令，你可以查看指定进程的线程信息，包括每个线程的 ID、CPU 使用率、内存使用情况等。这对于调试和性能分析非常有用，特别是在处理多线程应用程序时。
3. linux 将线程id转换为16进制 printf '0x%x\n' XXX ，会输出16进制的线程PID
4. jstack 进程PID｜grep 16进制线程PID -A 20
   此时就可以看到具体是哪句代码的产生的问题了；

内存飙高问题怎么排查

好的，要排查内存飙高问题，可以从以下几个方面入手：

1. 使用top命令：top命令可以实时显示系统中最活跃的进程，并提供了一些有用的信息，如进程的 CPU 使用率、内存使用情况等。通过观察top命令的输出，可以找到内存使用过高的进程。
2. 使用ps命令：ps命令可以列出系统中正在运行的进程。通过添加-aux参数，可以显示每个进程的详细信息，包括进程的 ID、CPU 使用率、内存使用情况等。通过观察ps命令的输出，可以找到内存使用过高的进程。
3. 使用free命令：free命令可以显示系统的内存使用情况，包括物理内存、交换内存、空闲内存等。通过观察free命令的输出，可以了解系统的内存使用情况。
4. 使用jmap命令：jmap命令可以生成 Java 进程的内存转储文件，并将其保存到指定的文件中。通过分析内存转储文件，可以找到内存泄漏的对象。
5. 使用内存分析工具：有许多内存分析工具可以帮助你查找内存泄漏的原因。例如，Java 中的Heapdump工具可以生成 Java 堆转储文件，然后使用MAT（Memory Analyzer Tool）工具分析堆转储文件，找出内存泄漏的对象。

请注意，以上方法仅适用于 Linux 系统。如果你使用的是其他操作系统，可能需要使用不同的工具和命令。

如何查看某个特定端口是否被占用

要查看某个特定端口是否被占用，您可以通过以下步骤进行操作：

1. 打开命令提示符：您需要以管理员身份运行命令提示符。在Windows系统中，可以通过按下Win+R组合键，输入cmd并回车来打开命令提示符窗口。如果您的系统是Mac或Linux，可以打开终端应用程序。
2. 查看所有端口占用情况：在命令提示符或终端中输入netstat -ano命令并回车。这个命令会列出所有端口的使用情况。在Mac或Linux系统中，可能需要使用sudo netstat -ano来获取更详细的信息。
3. 查看指定端口占用情况：如果您想要查看特定端口的情况，可以使用netstat -anp | grep 端口号命令。例如，如果您想查看端口号为8080的端口是否被占用，可以输入netstat -anp | grep 8080。
4. 分析结果：在命令的输出结果中，找到与您要查询的端口号相对应的行。如果该端口处于LISTEN状态，说明它已经被占用。您还可以看到占用该端口的进程ID（PID）。
5. 根据PID查看进程或程序：如果您想知道哪个程序或进程占用了该端口，可以根据PID查找。在Windows系统中，可以使用tasklist | findstr PID命令；在Mac或Linux系统中，可以使用ps -p PID命令。
6. 结束相应进程：如果需要释放该端口，您可以根据PID结束相应的进程。在Windows系统中，可以使用taskkill /F /PID 进程号命令；在Mac或Linux系统中，可以使用kill -9 PID命令。

总的来说，通过以上步骤，您可以有效地检查特定端口是否被占用，并采取相应的措施。在执行这些操作时，请确保您有足够的权限，并且小心操作，以免影响系统的正常运行。

IP地址怎么存储

IP地址可以通过多种方式存储，具体取决于使用的数据库和应用场景。以下是一些常见的存储方法：

字符串类型（VARCHAR）

IPv4地址可以作为字符串存储在数据库中，通常使用VARCHAR(15)来容纳最长的IP地址形式（例如255.255.255.255），加上一个额外的字节用来存储字符串的长度。这种方法的优点是易于阅读和理解，缺点是占用空间相对较大，且查询效率可能不如整数类型。

四个字段

可以将IPv4地址的四个部分分别存储在四个字段中，但这种方法在存储空间和查询效率上通常不是最优的选择。

二进制数据类型

在某些数据库中，可以使用特定的二进制数据类型来存储IP地址，这样可以更直接地处理地址的二进制表示。

无符号整数（UNSIGNED INT）/专用数据类型（推荐）

IPv4地址可以转换为32位的无符号整数进行存储。这样做的优点是存储空间小，只占用4个字节，且查询效率高。缺点是不易阅读，需要进行转换才能查看或使用IP地址的原始格式。

一些数据库提供了专门用于存储IP地址的数据类型，如MySQL的INET_ATON()和INET_NTOA()函数，可以在整数和点分十进制格式之间进行转换。
在MySQL中，INET_ATON()和INET_NTOA()函数用于处理IPv4地址，而INET6_ATON()和INET6_NTOA()函数则用于处理IPv6地址。这些函数的具体作用如下：

INET_ATON(expr)

将一个点分十进制的IPv4地址字符串转换为一个无符号整数。这个转换便于进行数值比较，特别是在需要筛选特定范围内的IP地址时非常有用。

INET_NTOA(num)

与INET_ATON()相反，这个函数接受一个无符号整数，并将其转换回点分十进制的IPv4地址字符串。

INET6_ATON(ip)

将一个冒号分十六进制的IPv6地址字符串转换为一个二进制的BLOB类型的值，用于存储在数据库中。

INET6_NTOA(blob_value)

与INET6_ATON()相反，这个函数接受一个二进制的BLOB类型的值，并将其转换回冒号分十六进制的IPv6地址字符串。

sql示例

SELECT 
	INET_NTOA(ipv4_address), 
	INET6_NTOA(ipv6_address) 
FROM 
	ip_addresses 
WHERE 
	INET_ATON('192.168.1.100') = ipv4_address;
1
2
3
4
5
6
7

总的来说，在选择存储方式时，需要考虑到存储空间、查询效率、易用性等因素。如果对查询效率有较高要求，可以考虑使用无符号整数；如果需要频繁阅读或修改IP地址，使用字符串类型可能更方便。

什么是DNS

DNS，即域名系统（Domain Name System），是互联网上作为将域名转换为IP地址的系统。

首先，来理解一下什么是域名和IP地址：

• IP地址：是一串数字，用于在互联网上唯一标识一台计算机或其他设备。例如，192.0.2.1就是一个IP地址。
• 域名：通常由一串用点分隔的名字组成，如www.example.com，它更容易被人记住，并用作网站等网络服务的可识别名称。

当你在浏览器中输入一个网址时，比如www.baidu.com，实际上你正在使用一个域名。以下是其背后的工作原理：

1. 本地缓存检查：你的电脑会首先检查浏览器缓存，看是否已经存在该域名对应的IP地址记录。如果有，解析过程即刻结束。
2. 检查系统缓存：如果浏览器缓存中没有找到，系统会检查本地Hosts文件，看是否有匹配的记录。
3. 查询本地DNS服务器：如果前两步都没有找到结果，系统会向配置的本地DNS服务器（通常由你的互联网服务提供商提供）发送查询请求。
4. 递归查询：本地DNS服务器如果也没有该记录，它将进行递归查询，这可能涉及多个上级DNS服务器。
5. 返回结果：一旦找到对应的IP地址，这个信息将被返回给本地DNS服务器，再由本地DNS服务器返回给你的电脑。
6. 结果缓存：本地DNS服务器通常会将这个结果缓存起来，以便快速响应后续相同的查询。
7. 获取网页：得到IP地址后，你的电脑就可以与目标服务器建立连接，从而获取你想要访问的网页内容。

什么是CDN

CDN，全称为Content Delivery Network，即内容分发网络。它的主要目的是通过在现有的Internet结构中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近获取所需的内容，从而提高用户访问网站的响应速度。

CDN的工作原理涉及多个步骤：

1. 域名解析：当终端用户向一个使用CDN服务的域名下的指定资源发起请求时，首先会向本地DNS（LDNS）发起域名解析请求。
2. 缓存检查：LDNS会检查缓存中是否有该域名的IP地址记录。如果有，就直接返回给终端用户；如果没有，LDNS会向上层DNS服务器查询。
3. 内容分发：一旦域名解析完成，用户的请求会被导向距离他们最近的CDN边缘节点。这些节点通常包含有缓存的副本，可以快速响应用户的请求。
4. 优化传输：CDN网络会选择最佳的路径来传输数据，确保快速且稳定的传输到用户端。
5. 提升性能：由于内容是从离用户最近的边缘节点提供的，这大大减少了延迟，提高了加载速度和用户体验。

总的来说，CDN的作用不仅仅是加快网站访问速度，它还可以帮助减轻源服务器的负载，提高网站的稳定性和安全性。通过分散流量到多个节点，CDN还可以帮助抵御一些网络攻击，如分布式拒绝服务（DDoS）攻击。此外，CDN还支持多种行业和场景的内容加速，包括图片小文件、大文件下载、视音频点播、直播流媒体、全站加速和安全加速等。

什么是DDoS

DDoS，即分布式拒绝服务攻击，是一种网络攻击手段。

DDoS攻击的目的是通过大量的网络请求淹没目标服务器，使得正常的服务请求无法得到处理。这种攻击通常涉及多个计算机或设备，这些设备被称为“僵尸网络”，它们在攻击者的操控下同时向目标发送请求。

DDoS攻击的影响可以非常严重，它可能导致：

• 网站或服务暂时不可用，影响用户体验。
• 大量消耗目标服务器的资源，如带宽和处理能力。
• 可能导致正常用户无法访问服务，从而影响业务运营。

为了防御DDoS攻击，可以采取以下措施：

• 增加带宽和服务器资源来吸收或分散攻击流量。
• 使用专门的硬件和软件解决方案来识别和阻止恶意流量。
• 建立多层防御策略，包括云防御和本地防御。
• 对于大型企业或有高安全需求的组织，可以考虑使用专业的DDoS防护服务。

总的来说，DDoS攻击对任何在线服务都是一个严重的威胁，因此需要采取适当的预防措施和应急响应计划来保护网络和服务的正常运行。

什么是WAF

WAF，即Web Application Firewall，是一种专门用于保护Web应用程序的防火墙。它的主要功能如下：

• 过滤和监控HTTP/HTTPS通信：WAF通过检查和监视Web应用程序与Internet之间的HTTP通信来提供保护，确保数据的安全传输。
• 防御常见网络攻击：它可以防止多种网络攻击，包括但不限于跨站点脚本（XSS）、SQL注入、文件包含漏洞等。
• 拦截恶意流量：WAF能够识别并阻止来自HTTP流量的恶意攻击，从而保护网站不受损害。

总的来说，WAF是网络安全中不可或缺的一部分，它帮助企业和个人保护其Web应用程序免受各种网络攻击，确保数据的安全和隐私。

什么是XSS

XSS，全称为Cross Site Scripting，即跨站脚本攻击，是一种常见的网络安全漏洞。

XSS攻击的基本原理是攻击者将恶意代码注入到目标网站的HTML页面中。当其他用户访问这个页面时，这些恶意代码会在他们的浏览器上执行，从而可能导致敏感信息如cookies等被窃取或篡改。

XSS攻击的类型主要分为以下几种：

• 反射型XSS：这种类型的XSS攻击是通过URL参数传递恶意脚本，当用户点击一个包含恶意脚本的链接时，恶意脚本会在用户浏览器中执行。反射型XSS攻击是非持久性的，因为它不会存储在服务器上，而是通过URL直接传递给用户。
• 存储型XSS：与反射型XSS不同，存储型XSS攻击是将恶意脚本存储在目标服务器上，例如在数据库、消息论坛或留言板中。当其他用户浏览受影响的页面时，恶意脚本会被执行。这种攻击是持久性的，因为恶意脚本会被存储并影响所有访问该页面的用户。
• DOM型XSS：这种类型的XSS攻击是指通过修改页面的DOM结构来插入恶意脚本。它不需要服务器的参与，攻击者利用客户端脚本的漏洞来实现攻击。

为了防止XSS攻击，网站开发者需要采取一系列的安全措施，包括但不限于：

• 对用户输入进行验证和过滤，避免不安全的字符注入。
• 使用HTTP头部的Content-Security-Policy（CSP）来限制浏览器加载外部资源。
• 对输出内容进行适当的编码或转义，以防止恶意脚本的执行。
• 使用安全框架和库，它们通常包含了防御XSS攻击的机制。

总的来说，了解XSS攻击的原理和类型对于开发安全的Web应用程序至关重要。

什么是SLB

SLB，即Server Load Balancer，是一种网络负载均衡技术，旨在优化资源的使用效率和提高服务的可靠性。它的核心功能是对多台服务器进行流量分发，确保没有单个服务器承受过多的请求负担。

SLB的主要作用包括：

• 提高性能：通过分散请求到多台服务器，SLB可以有效地提高应用系统的处理能力。
• 增强可用性：在服务器出现故障时，SLB能够将流量重新分配到其他健康的服务器上，从而保证服务的连续性。
• 提升安全性：SLB还可以帮助减轻DDoS攻击的影响，保护后端服务器不受恶意流量的侵害。

总的来说，SLB是现代云计算环境中不可或缺的一部分，它通过智能地管理流量分配，确保了服务的高可用性和灵活性。

什么是ACL

ACL，即访问控制列表（Access Control List），是一种网络安全技术，用于控制数据包在网络中的流动。

ACL由一系列规则组成，这些规则定义了哪些数据包可以通过网络设备，如路由器或防火墙，以及哪些数据包应该被阻止或丢弃。ACL可以根据数据包的特征，如源IP地址、目的IP地址、协议类型、端口号等进行过滤。这种技术是网络安全策略的一个重要组成部分，有助于保护网络不受未授权访问和潜在的安全威胁。

ACL的类型主要包括：

• 标准ACL：基于源IP地址进行过滤。
• 扩展ACL：可以基于源和目的IP地址，以及端口号和其他参数进行更精细的过滤。
• 命名ACL：允许用户为ACL指定一个名称，以便于管理和修改。
• 扩展命名ACL：结合了扩展ACL的功能和命名ACL的便利性。

总的来说，ACL的配置和管理对于维护网络的安全性至关重要。正确配置的ACL可以有效地防止未授权的网络访问，保护敏感数据，并确保网络资源的合理分配。

Docker

常见命令

Docker 常见命令包括容器操作、镜像操作、网络和数据卷操作，以及日志和事件操作等。具体如下：

1. 容器操作命令:

• docker start <容器名或ID>: 启动一个或多个已经被停止的容器。
• docker stop <容器名或ID>: 停止一个运行中的容器。
• docker restart <容器名或ID>: 重启容器。
• docker ps: 列出所有正在运行的容器。
• docker ps -a: 列出所有的容器，包括没有运行的。
• docker inspect <容器名或ID>: 查看容器的详细信息。
• docker exec -it <容器名或ID> /bin/bash: 进入容器的交互式终端。

2. 镜像操作命令:

• docker pull <镜像名>:<标签>: 从 Docker 仓库拉取镜像。
• docker push <镜像名>:<标签>: 将镜像推送到 Docker 仓库。
• docker build -t <镜像名>:<标签> <Dockerfile路径>: 根据 Dockerfile 构建镜像。
• docker images: 列出本地所有的镜像。

3. 网络操作命令:

• docker network ls: 列出所有网络。
• docker network create <网络名>: 创建一个新的网络。

4. 数据卷操作命令:

• docker volume create <卷名>: 创建一个新的数据卷。
• docker volume rm <卷名>: 删除一个数据卷。

5. 日志和事件操作命令:

• docker logs -f <容器名或ID>: 查看容器的日志。
• docker events: 查看 Docker 的事件。

以上是一些常用的 Docker 命令，对于使用 Docker 进行开发、部署和管理容器化应用程序非常实用。

Linux

常见命令

Linux系统中有许多常用命令，具体如下：

1. 文件和目录操作：

   • ls：列出当前目录中的文件和子目录。
   • pwd：显示当前工作目录的路径。
   • cd：切换工作目录。
   • mkdir：创建新目录。
   • rmdir：删除空目录。
   • rm：删除文件或目录，使用rm -r可以递归删除目录及其内容。
   • cp：复制文件或目录。

2. 文件查看和编辑：

   • cat：查看文件内容。
   • nano或vi：编辑文件。
   • chmod：更改文件或目录的权限。
   • chown：更改文件或目录的所有者。

3. 系统管理：

   • top：显示系统中运行的进程及其状态。
   • ps：显示当前用户的进程。
   • kill：终止进程。
   • df：显示磁盘空间使用情况。
   • du：显示目录或文件的磁盘使用情况。

4. 网络管理：

   • ping：检查网络连接。
   • ifconfig：配置网络接口。
   • wget：从网络上下载文件。
   • curl：传输数据到或从服务器。

5. 压缩和解压：

   • gzip：压缩或解压文件。
   • tar：打包或解包文件。

6. 其他有用的命令：

   • man：显示命令的手册页，即帮助文档。
   • history：显示命令历史记录。
   • clear：清屏。
   • exit：退出终端。

查询一个java进程

在Linux系统中，可以使用ps命令结合grep命令来查询一个Java进程。具体操作如下：

1. 打开终端。
2. 输入以下命令：

ps -ef | grep java
1

这个命令会列出所有包含“java”关键字的进程。如果你知道进程的名称或关键字，可以将“java”替换为相应的关键字。例如，要查询名为“myapp”的Java进程，可以使用以下命令：

ps -ef | grep myapp
1

3. 查找你关心的Java进程，并记下它的PID（进程ID）。

查询8080端口是否存在

要查询8080端口是否存在，可以使用以下几种方法：

1. 使用netstat命令：

  netstat -tunlp | grep 8080
1

这个命令会显示所有监听在8080端口的进程。如果输出中包含8080端口，那么该端口被占用；如果没有输出，则端口未被占用。

2. 使用lsof命令：

sudo lsof -i :8080
1

这个命令会列出所有监听在8080端口的进程及其相关信息。如果没有输出任何信息，说明8080端口没有被任何程序占用。如果端口已被占用，则会显示相关的进程信息。

jps

jps 命令是 Java Virtual Machine Process Status Tool 的缩写，它是 JDK（Java Development Kit）提供的一个命令行工具，用于列出正在运行的 Java 虚拟机（JVM）进程的信息。

以下是 jps 命令的一些主要用途和功能：

1. 显示主类名称：它可以显示每个 Java 进程的执行主类（Main Class，即包含 main() 函数的类）名称。

2. 显示本地虚拟机唯一ID：它还可以显示本地虚拟机的唯一标识符（LVMID，Local Virtual Machine Identifier）。

3. 查看进程ID：jps 可以查看 Java 进程的 ID（pid），这有助于在系统中找到特定的 Java 进程。

4. 常用参数：

   • -q：只显示进程 ID，不显示类名称、jar 文件名和传递给 main 方法的参数。
   • -m：输出传递给 main 方法的参数，这在某些嵌入式 JVM 上可能为 null。
   • -l：输出应用程序 main class 的完整 package 名或者应用程序的 jar 文件完整路径名。

jps -l -v 
1

jps -l -v  |grep XXX
1

jps 命令对于管理和监控 Java 应用程序非常有用，尤其是在需要快速获取 Java 进程信息的情况下。例如，当需要查找特定 Java 应用程序的进程 ID 以便进行进一步的性能分析或调试时，jps 命令就是一个很好的工具。此外，jps 命令还支持其他一些高级功能，如使用 jstatd 服务查看远程服务器的 jps 信息。

ps -ef|grep java

ps -ef | grep java 是一个在 Unix/Linux 系统中用于查找正在运行的 Java 进程的命令。

解析：

• ps 命令用于报告当前系统的进程状态。
• -ef 选项表示显示所有进程的详细信息。
• | 是管道符号，用于将前一个命令的输出作为后一个命令的输入。
• grep 命令用于搜索包含特定字符串的文本行。
• java 是要搜索的字符串，表示我们要查找包含 “java” 的进程。

这个命令会列出所有包含 “java” 的进程信息，包括进程 ID、用户、CPU 使用率等。

SpringBoot

SpringBoot可以同时处理多少请求

SpringBoot应用的并发处理请求数主要受到使用的Servlet容器（如Tomcat、Jetty、Undertow等）和配置项的影响。在默认配置下，SpringBoot应用可以并发处理的请求数量是有限的，但具体数量取决于多个因素：

1. 服务器硬件配置：服务器的CPU核心数、内存大小、网络带宽等硬件资源都会影响处理请求的能力。

2. 应用程序的性能优化：应用程序的代码效率、数据库访问优化、缓存策略等也会影响并发处理能力。

3. Servlet容器的配置：例如，Tomcat作为SpringBoot默认的内嵌Web服务器

   1. 最大连接数 (maxConnections)：这是Tomcat可以处理的最大TCP连接数，超过这个数量的连接会被等待或拒绝。在Spring Boot中，这个值默认设置为8192。
   2. 核心线程数 (minSpareThreads)：这是Tomcat启动时创建的线程数，也是保持空闲的最小线程数，以确保能够快速响应新到达的请求。默认情况下，这个值设置为10。
   3. 最大线程数 (maxThreads)：这是Tomcat可以拥有的最大工作线程数。当请求量增加时，Tomcat会创建更多的线程来处理请求，但不会超过这个设置的最大值。默认情况下，这个值设置为200。
   4. 最大等待数 (acceptCount)：当所有可能的请求处理线程都在使用中时，新的传入连接请求会被放入等待队列，这个参数定义了该队列的最大长度。默认情况下，这个值设置为100。

   这些默认值适用于大多数情况，但在有特殊需求的情况下，可以根据实际负载和性能要求进行调整。例如，如果应用程序主要进行CPU密集型操作，可能需要减少最大线程数以匹配CPU的核心数。相反，如果是I/O密集型操作，可能需要增加最大线程数以提高并发处理能力。调整这些参数时，应该综合考虑服务器的硬件配置、应用程序的性能特点以及预期的用户负载，以达到最佳的性能和资源利用率。

以Tomcat为例，默认的核心线程数是10，最大线程数是200，这意味着在没有其他限制的情况下，理论上可以同时处理最多200个请求。然而，这个数值是可以调整的，如果需要处理更多的并发请求，可以通过增加核心线程数和最大线程数来提高处理能力。但需要注意的是，盲目增加线程数可能会导致系统资源耗尽，反而降低性能。

此外，还需要注意的是，如果一个IP地址发送大量请求，并不是每个请求都会对应一个线程。Servlet容器会使用线程池来复用线程，以高效地处理并发请求。

综上所述，SpringBoot可以同时处理的请求数量取决于多种因素，包括服务器硬件配置、应用程序的性能优化以及Servlet容器的配置。在实际部署时，应根据具体的业务需求和服务器能力来合理配置这些参数，以达到最佳的并发处理效果。

@Autowired、@Resource、@Inject的区别

总结：

1. @Autowired和@Inject都是用于实现依赖注入的注解，但@Autowired是Spring提供的，而@Inject是JSR-330规范中定义的。
2. @Resource是J2EE本身提供的注解，用于实现依赖注入。
3. @Autowired和@Inject默认按照byType进行装配，而@Resource默认按照byName进行装配。
4. @Autowired可以应用于字段、setter方法、构造函数和方法，而@Resource可以应用于字段和setter方法，@Inject可以应用于字段、构造函数和方法。

SpringBoot为什么要禁止循环依赖

SpringBoot2.6.0的版本默认禁止了循环依赖，如果程序中出现循环依赖就会报错。
当然并没有一锤子打死，也提供了开启允许循环依赖的配置，只需要在配置文件中开启即可：

spring:
  main:
    allow-circular-references: true
1
2
3

那SpringBoot为什么要要禁止呢？我们都知道Spring解决循环依赖的方式是通过三级缓存，光学这个三级缓存我们就煞费苦心，其实说白了他是一种给程序员擦屁股的行为.
其实对象之间的关系如果是互相依赖是一种不合理的设计，避免你做出这种不合理的依赖，SpringBoot进而禁止循环依赖。

为什么SpringBoot的jar可以直接运行？

SpringBoot的jar文件可以直接运行是因为它内部集成了嵌入式服务器，并且通过spring-boot-maven-plugin插件进行了特殊的打包过程。具体分析如下：

• 嵌入式服务器：Spring Boot 项目在打包为 jar 文件时，会自动包含一个嵌入式服务器，如 Tomcat 或 Jetty。这些服务器是轻量级的，可以提供 HTTP 服务的功能，使得 Spring Boot 应用无需部署在传统的外部服务器上即可运行。
• 特殊打包过程：Spring Boot 提供了一个名为 spring-boot-maven-plugin 的插件，用于将应用程序及其依赖项打包成一个可执行的 JAR 文件。这个 JAR 文件内部包含了所有必要的类和资源，以及一个特定的目录结构，其中包括 META-INF/MANIFEST.MF 文件，该文件包含了主类信息和类路径信息，使得 JAR 文件可以直接运行。

总的来说，Spring Boot 的设计哲学是将应用简化为“一个JAR包”，这样开发者可以方便地将应用打包、分发和部署。这种设计不仅提高了开发效率，也简化了部署流程，使得 Spring Boot 成为许多微服务架构和快速原型开发的首选框架。