我的Java面试实战

CV全干攻城狮

已于 2024-03-20 22:53:18 修改

阅读量1.5k

点赞数 39

文章标签：面试职场和发展

于 2024-03-10 23:10:47 首次发布

本文链接：https://blog.csdn.net/An_nb/article/details/136611461

版权

面试实战

20240308面试

聚簇索引与非聚集索引的特点是什么？

答：在InnoDB中聚簇索引和非聚簇索引实际上是物理空间存储方式的一个不同。

聚簇索引

聚簇索引将数据存储在索引树的叶子节点上。
聚簇索引可以减少一次查询，因为查询索引树的同时就能获取到数据。
聚簇索引的缺点是，对数据进行修改或删除操作时需要更新索引树，会增加系统的开销。
聚簇索引通常用于数据库系统中，主要用于提高查询效率。

非聚簇索引（又称二级索引 / 辅助索引）

非聚簇索引不将数据存储在索引树的叶子节点上，而是存储在数据页中。
非聚簇索引在查询数据时需要两次查询，一次查询索引树，获取数据页的地址，再通过数据页的地址查询数据（通常情况下来说是的，但如果索引覆盖的话实际上是不用回表的）。
非聚簇索引的优点是，对数据进行修改或删除操作时不需要更新索引树，减少了系统的开销。
非聚簇索引通常用于数据库系统中，主要用于提高数据更新和删除操作的效率。

Mysql有哪些引擎

答：MySQL 常用的引擎有：

InnoDB：InnoDB 是 MySQL 的默认引擎，它是一款功能齐全、高性能、事务安全的存储引擎。InnoDB 支持事务、外键、崩溃恢复等特性，非常适合对数据完整性要求较高的应用场景。

MyISAM：MyISAM 是一款轻量级、高性能的存储引擎，它不具备事务和外键等特性，但它的查询速度非常快。MyISAM 适合对数据完整性要求不高，但对查询速度要求较高的应用场景。

Memory：Memory 是一款将数据存储在内存中的存储引擎，它的读写速度非常快，但它不具备持久性，一旦服务器宕机，数据将丢失。Memory 适合对数据完整性要求不高，但对查询速度要求极高的应用场景。

Archive：Archive 是一款专为存储归档数据设计的存储引擎，它具有很高的压缩比，可以节省存储空间。Archive 适合存储历史数据或不经常访问的数据。

Blackhole：Blackhole 是一款将所有写入的数据都丢弃的存储引擎，它不具备存储数据的功能。Blackhole 适合用于测试或临时存储数据。

在选择 MySQL 存储引擎时，应根据实际情况选择合适的数据引擎。

以下是一些 MySQL 常用引擎的应用场景：

InnoDB：适用于对数据完整性要求较高，需要支持事务和外键的应用场景，如在线商城、银行系统等。

MyISAM：适用于对数据完整性要求不高，但对查询速度要求较高的应用场景，如博客、论坛等。

Memory：适用于对数据完整性要求不高，但对查询速度要求极高的应用场景，如缓存系统、实时分析系统等。

Archive：适用于存储历史数据或不经常访问的数据的应用场景，如日志数据、归档数据等。

Blackhole：适用于测试或临时存储数据的应用场景。

MyISAM和InnoDB是MySQL中两种常见的存储引擎，它们在索引实现上存在以下区别：

存储方式：MyISAM使用非聚簇索引，索引文件和数据文件是分开的；而InnoDB使用聚簇索引，将索引和数据一起存储在同一个文件中。
锁机制：MyISAM采用表级锁定，意味着当对表进行写操作时，整个表都会被锁定，因此可能导致并发写操作的性能较差。而InnoDB采用行级锁定，只锁定需要修改的行，可以提供更好的并发性能和多用户写入的支持。
事务支持：MyISAM不支持事务处理，而InnoDB支持事务和ACID特性（原子性、一致性、隔离性和持久性），可以进行事务管理、回滚和恢复操作。
引用完整性：MyISAM不支持外键约束，而InnoDB支持外键约束，可以设置关联关系来保证数据的完整性。
性能特点：MyISAM在读取频繁、插入和更新较少的场景下性能较好，特别适合于读密集型应用；而InnoDB在并发写入和更新较多的情况下性能较好，适合于写入密集型应用或需要事务支持的场景。

以上就是MyISAM索引与InnoDB索引的五点区别，我们在实际使用时需要根据具体的应用需求和场景来选择适合的存储引擎和索引类型。

B 树和B+树的区别？

答：B树和B+树是常用的数据结构，用于在数据库中进行索引操作。它们之间的区别主要有以下几个方面：

数据存储方式：在B树中，每个节点都包含键和对应的值，叶子节点存储了实际的数据记录；而B+树中，只有叶子节点存储了实际的数据记录，非叶子节点只包含键信息和子节点的指针。
数据检索方式：在B树中，由于非叶子节点也存储了数据，所以查询时可以直接在非叶子节点找到对应的数据，具有更短的查询路径；而B+树的所有数据都存储在叶子节点上，只有通过叶子节点才能获取到完整的数据。
范围查询效率：由于B+树的所有数据都存储在叶子节点上，并且叶子节点之间使用链表连接，所以范围查询的效率较高。而在B树中，范围查询需要通过遍历多个层级的节点，效率相对较低。
适用场景：B树适合进行随机读写操作，因为每个节点都包含了数据；而B+树适合进行范围查询和顺序访问，因为数据都存储在叶子节点上，并且叶子节点之间使用链表连接，有利于顺序遍历。

总结来说： B树和B+树在数据存储方式、数据检索方式、范围查询效率以及适用场景方面存在区别。B树适合随机读写操作，而B+树适合范围查询和顺序访问。在实际应用中，根据不同的场景和需求选择合适的树结构可以带来更高效的数据处理和索引操作。

数据库三大范式是什么

答：数据库三大范式是关系数据库设计中的一组规范，旨在提高数据结构的合理性、减少数据冗余和提高数据操作的效率。它们分别是：

第一范式（1NF）：确保每个数据列都是不可再分的原子值，即每个单元格中只包含一个值。这可以通过将表拆分为更小的表来实现，每个表都包含一个实体的属性。
第二范式（2NF）：建立在第一范式的基础上，要求表中的每个非主键列完全依赖于主键列，而不是依赖于其他非主键列。换句话说，每个表应该只描述一个实体的信息。如果有部分信息依赖于表中的一部分主键，那么需要将这些信息拆分到另一个表中。

例如：不能在一个学生表里既放学生的信息又放课程的信息，应该把课程重新放到一张表里

第三范式（3NF）：在第二范式的基础上，要求表中的每个非主键列之间不应该存在传递依赖关系。也就是说，非主键列之间不应该相互依赖，而是直接依赖于主键列。如果存在传递依赖，需要将其转化为直接依赖关系。

这三个范式是逐步规范化设计数据库的步骤，目的是提高数据的一致性、完整性和减少冗余，从而提高数据库的性能和可维护性。但要注意，范式化设计并不是一成不变的，根据具体的业务需求和应用场景，有时也需要对范式进行适度的调整和冗余处理。

创建索引时需要注意什么？

在创建索引时，需要注意以下几点：

选择适当的列：根据实际查询需求和数据特点，选择合适的列作为索引列。通常情况下，选择经常被用于查询条件、排序或聚合操作的列作为索引列可以获得更好的性能。
避免过多的索引：过多的索引会增加存储空间的开销，并且在数据写入时需要维护多个索引结构，导致性能下降。因此，只创建必要的索引，避免不必要的冗余索引。
考虑联合索引：对于多个列的组合查询条件，可以考虑创建复合索引。复合索引可以覆盖多个列，减少查询时需要访问的索引数量，提高查询效率。
注意索引的顺序：对于多列索引，考虑索引的顺序。将最常用的列放在索引的前面，以提高查询性能。
使用合适的数据类型：选择合适的数据类型可以减小索引的大小，提高索引的效率。尽量避免使用过长或过大的数据类型作为索引列。

综上所述，创建索引需要根据具体的查询需求、数据特点和系统环境来进行权衡和决策。合理创建索引可以提升数据库的性能，但也需要注意索引的维护成本和更新操作的影响。

索引失效的情况有哪些

索引失效是指在使用索引进行查询时，索引无法发挥作用，导致查询性能下降。常见的导致索引失效的情况有以下几种：

不符合最左匹配原则，这不是说联合索引的中的列必须按照相同的顺序出现在where后，而是联合索引的列最左边的列必须出现在where后，具体的顺序无所谓

index1(a,b,c)

select * from table1 where a = 1 and b = 1 and c = 1;

select * from table1 where b = 1 and c = 1 and a = 1;

这俩是一样的，都会用到索引，但是下面这种就不行

select * from table1 where b = 1 and c = 1;

这个就不行，因为联合索引中最左边的那个这段没了

不满足索引列顺序：如果查询条件中的列顺序与索引列的顺序不一致，索引可能无法被使用。例如，一个联合索引（A, B），如果查询条件只包含了B列而没有A列，那么这个索引就无法被利用。
使用函数或表达式：当查询条件中对索引列应用了函数、数学运算、类型转换等操作时，索引可能无法被使用。因为索引的创建是基于原始列值的，无法直接使用函数计算后的结果进行索引匹配。
字符串比较问题：对于字符串类型的索引列，使用了不符合索引规则的比较方式。
数据类型不匹配：当查询条件的数据类型与索引列的数据类型不匹配时，索引可能无法被使用。尤其是在进行隐式数据类型转换、不同字符集的比较或编码问题时，需要特别留意。
1. EXPLAIN select *from student where sname = 2; 这种就不行
  EXPLAIN select *from student where sname = '2';
数据量过小：当表中的数据量较小时，MySQL可能会选择全表扫描而非使用索引，因为全表扫描的成本较低。这种情况下，索引可能无法发挥作用。
使用了NOT、<>、OR等非优化的逻辑操作符：这些逻辑操作符在查询条件中的使用会导致索引失效，因为它们无法充分利用索引的特性。

综上所述，我们要解决索引失效的问题，可以通过合理设计索引、优化查询语句以及避免索引失效的情况发生来提升查询性能。

平时会建表吗？索引是怎么创建的

说一下平时用到的设计模式，在项目中如何应用的

设计模式，看了就忘，该怎么学 - 知乎 (zhihu.com)

1、组合模式

组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。

这个在上交大的仪器共享平台里有用到，当时需要做一个“设备普及化教育”的模块，是用于普及各种设备的操作说明、案例、原理的一个模块

2、模版模式

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。

在审计项目里面的流程类里面有用到，模版固定流程流转的各个步骤

3、策略模式

在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。

4、工厂模式

工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

5、建造模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造的过程和细节我们不需要知道，只需要使用建造者去进行操作

在项目获取复杂对象的时候会用到，比如获取表单对象，表单对象往往比较复杂，由很多部分构成

6、单例模式

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

构造函数必须私有化，防止外部调用构造函数进行实例；
提供静态函数获得该单例。

7、代理模式

为对象提供一种代理，以控制这个对象的访问操作
代理对象和目标对象之间起到了中介作用
保护目标对象和增强目标对象
代理模式能将代理对象与真实被调用的对象分离
一定程度上降低了系统的耦合度，扩展性好

静态代理

为目标对象创建一个代理，将目标对象作为代理的成员变量进行传入，然后在代理里创建方法，在方法里可以执行目标对象的方法，也能做一些额外的增强操作

动态代理

使用JDK提供的InvocationHandler ，实现InvocationHandler 重写invoke

8、装饰器模式

装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。

9、外观模式/门面模式

提供了一个统一的接口，用来访问子系统中的一群接口
定义了一个高层接口，让子系统使用更加容易
感觉类似于相同里的各种业务层实现类，这个实现类里可能调用了很多子系统，然后由控制层来统一进行调用使用

个人感觉项目里的业务实现类就是门面模式，因为一个业务实现类里的业务往往跟好多个模块相关，再把他们实现在一起供外部调用，然后由控制层来统一进行调用使用

10、责任链模式

责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。

在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。

在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，所以责任链将请求的发送者和请求的处理者解耦了

RabbitMQ怎么保证不重复消费

消息中间件是无法保证消息重复消费，所以只能从业务上来保证消费不重复消费，在消费端保证接口的幂等性。

什么是幂等性

幂等性原本是数学上的概念，用在接口上就可以理解为：同一个接口，多次发出同一个请求，必须保证操作只执行一次。 调用接口发生异常并且重复尝试时，总是会造成系统所无法承受的损失，所以必须阻止这种现象的发生。比如下面这些情况，如果没有实现接口幂等性会有很严重的后果：支付接口，重复支付会导致多次扣钱订单接口，同一个订单可能会多次创建。

接口幂等性，一般是用在订单处理或者消费处理的场景的。使用接口幂等性是为了防止同一请求多次处理的状况。

重复消费的原因

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

解决办法：用业务来解决，开始消费插入消费记录表，标记消费中，业务代码执行成功，标记消费表状态为成功，如果业务代码失败，删除消费记录，再次开始消费，继续执行消费流程，开始业务代码，继续上面的消费流程，若再次失败，则消费记录表执行次数字段+1，当执行次数累计达到预订次数，则进行异常记录，为人工干预提供异常记录，来手动处理，并不再执行消费流程

你们公司的Redis是怎么保证高可用的

（1）数据持久化（2）主从同步（主从复制）（3）Redis 哨兵模式（Sentinel）（4）Redis 集群（Cluster）

说一下Redis哨兵模式

Redis 哨兵是一种用于高可用性的解决方案，它可以监控 Redis 主从复制模式下的主节点和从节点，发现节点故障，并自动进行故障转移，保证 Redis 系统的稳定性和可靠性。

Redis 哨兵机制由多个相互独立的进程组成，这些进程使用 TCP/IP 协议相互通信，实现 Redis 节点的监控和故障转移。哨兵机制的关键进程包括：

sentinel：主进程，用于监控 Redis 节点的状态，并执行故障转移操作。
monitor：哨兵进程，用于监控 Redis 的主节点和从节点是否正常工作，并在需要时通知其他哨兵进程和客户端。
judge：哨兵进程，用于对节点的健康状况进行评估，并根据预定义的阈值决定是否要将一个不健康的节点标记为“主观下线”。
failover：哨兵进程，负责执行故障转移操作，将主节点故障时选举出来的从节点晋升为新的主节点，并通知其他 Redis 节点更新配置信息。

通过上述哨兵进程的协同工作，Redis 哨兵机制可以实现自动化的故障转移，使得 Redis 的高可用性得到有效保障。在实际应用中，可以通过配置多个哨兵进程，使其互相监控和备份，从而进一步提高 Redis 系统的可靠性和稳定性。

Redis的主从数据一致是怎么保证的

主从数据复制分为全量复制和增量复制，全量复制发生在slave节点初始化的时候，增量复制发生在master每次数据变更的时候，会增量数据发给从节点

说一下Redis的持久化方式

RDB和AOF

说一下Redis的缓存雪崩、缓存穿透、缓存击穿

1. 缓存击穿（Cache Miss）

a. 什么是缓存击穿？

缓存击穿是指在高并发访问下，一个热点数据失效时，大量请求会直接绕过缓存，直接查询数据库，导致数据库压力剧增。

通常情况下，缓存是为了减轻数据库的负载，提高读取性能而设置的。当某个特定的缓存键（key）失效后，在下一次请求该缓存时，由于缓存中没有对应的数据，因此会去数据库中查询，这就是缓存击穿。

b. 解决方案：

合理的过期时间：设置热点数据永不过期，或者设置较长的过期时间，以免频繁失效。
使用互斥锁：保证同一时间只有一个线程来查询数据库，其他线程等待查询结果。

2. 缓存雪崩（Cache Avalanche）

a. 什么是缓存雪崩？

缓存雪崩是指在大规模缓存失效或者缓存宕机的情况下，大量请求同时涌入数据库，导致数据库负载过大甚至崩溃的情况。

正常情况下，缓存中的数据会根据过期时间进行更新，当大量数据同时失效时，下一次请求就会直接访问数据库，给数据库带来巨大压力。

b. 解决方案：

合理的过期时间：为缓存的过期时间引入随机值，分散缓存过期时间，避免大规模同时失效。或者是粗暴的设置热点数据永不过期
多级缓存：使用多级缓存架构，如本地缓存 + 分布式缓存，提高系统的容错能力。
使用互斥锁：保证同一时间只有一个线程来查询数据库，其他线程等待查询结果。
高可用架构：使用Redis主从复制或者集群来增加缓存的可用性，避免单点故障导致整个系统无法使用。

3. 缓存穿透（Cache Penetration）

a. 什么是缓存穿透？

缓存穿透是指恶意请求查询一个不存在于缓存和数据库中的数据，导致每次请求都直接访问数据库，从而增加数据库的负载。

攻击者可以通过故意构造不存在的 Key 来进行缓存穿透攻击。

b. 解决方案：

缓存空对象：对于查询结果为空的情况，也将其缓存起来，但使用较短的过期时间，防止攻击者利用同样的 key 进行频繁攻击。
参数校验：在接收到请求之前进行参数校验，判断请求参数是否合法。
布隆过滤器：判断请求的参数是否存在于缓存或数据库中。

你们公司的项目的工作流是怎么做的

有用到多线程并发编程吗？

创建线程池的7大参数

核心线程

最大线程

线程过期时间

线程过期时间单位

阻塞队列

核心线程数是根据什么制定的

cpu密集型核心线程 = cpu核心数 + 1

io密集型核心线程数 = cpu核心数 * 2

20240311面试

System.out.printli(3|9)会输出什么

3|9 = 0011（二进制）| 1001（二进制） = 1011（二进制） = 11（十进制）

为什么重写equlas时必须重写hashCode方法

== 与 equals的区别

如果两个引用类型变量使用==运算符，那么比较的是地址，它们分别指向的是否是同一地址的对象。结果一定是false，因为两个对象不可能存放在同一地址处。要求是两个对象都不是能空值，与空值比较返回false。==不能实现比较对象的值是否相同。所有对象都有equals方法，默认是Object类的equals，其结果与==一样。如果希望比较对象的值相同，必须重写equals方法。

hashCode与equals的区别

Object中的equals:

equals 方法要求满足：

自反性 a.equals(a)

对称性 x.equals(y) y.equals(x)

一致性 x.equals(y)

多次调用结果一致对于任意非空引用x，x.equals(null) 应该返回false

Object中的hashCode:

它是一个本地方法，它的实现与本地机器有关，这里我们暂且认为他返回的是对象存储的物理位置。

当equals方法被重写时，通常有必要重写hashCode方法，以维护hashCode方法的常规约定：值相同的对象必须有相同的hashCode。object1.equals(object2)为true，hashCode也相同；hashCode不同时，object1.equals(object2)为false；hashCode相同时，object1.equals(object2)不一定为true；当我们向一个Hash结构的集合中添加某个元素，集合会首先调用hashCode方法，这样就可以直接定位它所存储的位置，若该处没有其他元素，则直接保存。若该处已经有元素存在，就调用equals方法来匹配这两个元素是否相同，相同则不存，不同则链到后面（如果是链地址法）。

先调用hashCode，唯一则存储，不唯一则再调用equals，结果相同则不再存储，结果不同则散列到其他位置。因为hashCode效率更高（仅为一个int值），比较起来更快。

HashMap#put源码

hash是key的hash值，当该hash对应的位置已有元素时会执行以下代码（hashCode相同）

如果equals返回结果相同，则值一定相同，不再存入。

如果重写equals不重写hashCode会怎样

两个值不同的对象的hashCode一定不一样，那么执行equals，结果为true，HashSet或HashMap的键会放入值相同的对象。

话不多说，直接上例子，~~~

首先我们只重写equals()方法

看我们的测试类

依次输出

是否出现矛盾？？？用equals比较说明对象相同，但是在HashMap中却以不同的对象存储（没有重写hascode值，两个hascode值，在他看来就是两个对象）。到底这两个对象相等不相等？？？？说明必须重写hashCode()的重要性，

接下来重写重写equals方法和hashCode方法,再比较

测试类

依次输出

看到这里，同学你懂了吗？还不懂，可以自己实现一遍代码。

说说你常用的集合以及特点

ArrayList。有序、可重复，底层数据结构是数组，查询快、增删慢、线程不安全、效率高。
Vector。有序、可重复，底层数据结构是数组，查询快、增删慢、线程安全、效率低。
LinkedList。有序、可重复，底层数据结构是链表，查询慢、增删快、线程不安全、效率低^[1][2]^。
HashSet。无序、唯一，底层数据结构是链表和哈希表，通过hashCode()和equals()来确定唯一性。

如何创建一个线程

继承Thread类

实现Runnable接口

实现Callable接口

线程池

线程的生命周期

一、线程的生命周期总结下来分为以下五种：

（1）新建：当一个Thread类或其子类的对象被声明并创建时。新生的线程对象属于新建状态。

（2）就绪：处于新建状态的线程执行start()方法后，进入线程队列等待CPU时间片，该状态具备了运行的状态，只是没有分配到CPU资源。

（3）运行：当就绪的线程分配到CPU资源便进入运行状态，run()方法定义了线程的操作。

（4）阻塞：在某种特殊情况下，被人为挂起或执行输入输出操作时，让出CPU并临时终止自己的的执行，进入阻塞状态。

（5）死亡：当线程执行完自己的操作或提前被强制性的终止或出现异常导致结束，会进入死亡状态。

二、线程的生命周期之间的转换图

sleap()方法和wait()方法的区别和共同点

对于 sleep() 方法，我们首先要知道该方法是属于 Thread 类中的。而 wait() 方法，则是属于 Object 类

中的。

sleep() 方法导致了程序暂停执行指定的时间，让出 cpu 该其他线程，但是他的监控状态依然保持

者，当指定的时间到了又会自动恢复运行状态。在调用 sleep() 方法的过程中，线程不会释放对象

锁。

当调用 wait() 方法的时候，线程会放弃对象锁，进入等待此对象的等待锁定池，只有针对此对象调用

notify() 方法后本线程才进入对象锁定池准备，获取对象锁进入运行状态。

如果我有三个线程，cup只有一核，他们是如何工作的

并发执行，每个时间片只有一个任务在执行

写一下JVM的内存模型

1 、栈

又称方法栈 , 线程私有的 , 线程执行方法是都会创建一个栈阵 , 用来存储局部变量表 , 操作栈 , 动态链接 , 方

法出口等信息 . 调用方法时执行入栈 , 方法返回式执行出栈 .

2 、本地方法栈

与栈类似 , 也是用来保存执行方法的信息 . 执行 Java 方法是使用栈 , 执行 Native 方法时使用本地方法栈 .

3 、程序计数器

保存着当前线程执行的字节码位置 , 每个线程工作时都有独立的计数器 , 只为执行 Java 方法服务 , 执行

Native 方法时 , 程序计数器为空 .

4 、堆

JVM 内存管理最大的一块 , 对被线程共享 , 目的是存放对象的实例 , 几乎所欲的对象实例都会放在这里 ,

当堆没有可用空间时 , 会抛出 OOM 异常 . 根据对象的存活周期不同 ,JVM 把对象进行分代管理 , 由垃圾回

收器进行垃圾的回收管理

5 、方法区

又称非堆区 , 用于存储已被虚拟机加载的类信息 , 常量 , 静态变量 , 即时编译器优化后的代码等数据 .1.7

的永久代和 1.8 的元空间都是方法区的一种实现

写出下列代码输出结果

public class Main {
 public static void main(String[] args) {
 
 Integer i1 = 100;
 Integer i2 = 100;
 Integer i3 = 200;
 Integer i4 = 200;
 
 System.out.println(i1==i2);//true
 System.out.println(i3==i4);//false
 }
}

运行结果：

为什么会出现这样的结果？输出结果表明 i1 和 i2 指向的是同一个对象，而 i3 和 i4 指向的是不同的对

象。此时只需一看源码便知究竟，下面这段代码是 Integer 的 valueOf 方法的具体实现：

public static Integer valueOf(int i) {
 if(i >= -128 && i <= IntegerCache.high)
 return IntegerCache.cache[i + 128];
 else
 return new Integer(i);
 }

其中 IntegerCache 类的实现为：

private static class IntegerCache {
static final int high;
static final Integer cache[];
static {
final int low = -128;
// high value may be configured by property
int h = 127;
if (integerCacheHighPropValue != null) {
// Use Long.decode here to avoid invoking methods that
// require Integer's autoboxing cache to be initialized
int i = Long.decode(integerCacheHighPropValue).intValue();
i = Math.max(i, 127);
// Maximum array size is Integer.MAX_VALUE
h = Math.min(i, Integer.MAX_VALUE - -low);
}
high = h;
cache = new Integer[(high - low) + 1];
int j = low;
for(int k = 0; k < cache.length; k++)
cache[k] = new Integer(j++);
}
private IntegerCache() {}
}

从这 2 段代码可以看出，在通过 valueOf 方法创建 Integer 对象的时候，如果数值在 [-128,127] 之间，

便返回指向 IntegerCache.cache 中已经存在的对象的引用；否则创建一个新的 Integer 对象。

上面的代码中 i1 和 i2 的数值为 100 ，因此会直接从 cache 中取已经存在的对象，所以 i1 和 i2 指向的是

同一个对象，而 i3 和 i4 则是分别指向不同的对象。

数据库题

Student(Sid,Sname,Sage,Ssex)学生表
Sid：学号
Sname：学生姓名
Sage：学生年龄
Ssex：学生性别

Course(Cid,Cname,T#)课程表
Cid：课程编号
Cname：课程名称
Tid：教师编号

SC(Sid,Cid,score)成绩表
Sid：学号
Cid：课程编号
score：成绩

Teacher(Tid,Tname)教师表
Tid：教师编号：
Tname：教师名字

有上面4张表，进行条件查询

查询平均成绩大于85的所有学生的学号、姓名和平均成绩：
select s.sname,sc.sid,avg(sc.score) as 平均成绩
from sc as sc
left join student as s 
on sc.sid = s.sid
group by sc.sid 
having avg(sc.score)>85;

检索至少选修两门课程的学生学号：
select sid
from sc
group by sid
having count(8)>=2;

说一下索引创建要注意的问题

在创建索引时，需要注意以下几点：

选择适当的列：根据实际查询需求和数据特点，选择合适的列作为索引列。通常情况下，选择经常被用于查询条件、排序或聚合操作的列作为索引列可以获得更好的性能。
避免过多的索引：过多的索引会增加存储空间的开销，并且在数据写入时需要维护多个索引结构，导致性能下降。因此，只创建必要的索引，避免不必要的冗余索引。
考虑联合索引：对于多个列的组合查询条件，可以考虑创建复合索引。复合索引可以覆盖多个列，减少查询时需要访问的索引数量，提高查询效率。
注意索引的顺序：对于多列索引，考虑索引的顺序。将最常用的列放在索引的前面，以提高查询性能。
使用合适的数据类型：选择合适的数据类型可以减小索引的大小，提高索引的效率。尽量避免使用过长或过大的数据类型作为索引列。

什么是回表

不需要回表的情况
覆盖索引查询：如果查询语句中的字段都包含在辅助索引中，且辅助索引覆盖了查询所需的所有字段，就不会触发回表操作。此时，MySQL可以直接从辅助索引中获取查询所需的数据，而无需回到主键索引。
使用聚集索引进行查询：如果查询语句使用聚集索引（即主键索引）进行查询，并且所需的字段都包含在聚集索引中，就不会触发回表操作。因为聚集索引中包含了完整的数据行，可以直接从聚集索引中获取所需的数据。
具体实例
假设，现在我们要查询出id为2的数据，执行查询语句：

select * from one_piece where ID = 2;

这条SQL语句就不需要回表。原因是根据主键的查询方式，只需要搜索id这颗B+树。

主键是唯一的，根据这个唯一的索引，MySQL就能确定搜索的记录。

id为主键索引，主键索引是聚簇索引。

聚簇索引的叶子节点包含整个行记录，一次索引查询就能获取所有的信息。故不需要回表。

需要回表的情况
SELECT语句使用了非聚集索引：如果查询语句使用了非聚集索引（辅助索引）并需要返回非索引字段的值，就会触发回表操作。因为辅助索引中只包含索引列的值，而非索引字段的值存储在主键索引中，所以需要回到主键索引中获取完整的数据行。
查询包含了不在索引中的字段：如果查询语句需要返回不在辅助索引中的字段，就会触发回表操作。因为辅助索引中只包含索引列的值，如果查询需要返回其他字段的值，就需要回到主键索引中获取完整的数据行。
具体实例
比如查询name为索隆的记录，使用查询语句

select * from one_piece where name = “索隆”

这个查询语句就需要回表，原因是通过name这个普通索引查询方式，需要先搜索name索引树，然后得到主键id的值为2，再到id索引树搜索一次。

即先定位主键值，再定位行记录。

这个过程虽然用了索引，但实际上底层进行了两次索引查询，这个过程就称为回表。也就是，基于非主键索引的查询需要多扫描一颗索引树。

我们在应用中应该尽量使用主键查询。当表数据量很大的时候，可以很明显的看出两次查询所用的时间的差距，使用主键查询效率更高。

B树和B+树，为什么选择B+树

经典问题：MySQL为什么采用B+树而不是B树作为索引结构？
范围查询性能：B+树在范围查询方面具有更好的性能。由于B+树的叶子节点形成有序链表，可以非常高效地执行范围查询操作，例如大于、小于、区间查询等。对于数据库系统来说，范围查询是非常常见的操作，因此B+树更适合作为索引结构。

顺序访问性能：B+树在顺序访问方面也表现较好。由于B+树的叶子节点形成有序链表，可以按顺序访问数据，例如排序、分页和顺序遍历等操作。对于一些特定的查询需求，B+树的顺序访问性能更高。

更低的树高度：B+树相对于B树来说，具有更低的树高度。这是因为B+树的关键字全部存储在叶子节点中，非叶子节点只包含关键字范围和指向子节点的指针。较低的树高度意味着在查询过程中需要更少的磁盘访问，提高了查询效率。

内存占用：B+树的节点大小比B树相对较小，可以容纳更多的节点在内存中，从而提高了缓存的效率。这对于数据库系统来说尤为重要，因为它们需要频繁地从磁盘加载节点到内存中进行查询操作。

适应大规模数据集：MySQL作为一种常用的关系型数据库系统，通常需要处理大规模的数据集。B+树对于大规模数据集的索引具有较好的扩展性，能够高效地处理大量的数据和高并发访问

算法二分法

定义：二分查找算法也称折半搜索算法，对数搜索算法，是一种在有序数组中查找某一特定元素的搜索算法。搜索过程从数组的中间元素开始，如果中间元素正好是要查找的元素，则搜索过程结束；如果某一特定元素大于或者小于中间元素，则在数组大于或小于中间元素的那一半中查找，而且跟开始一样从中间元素开始比较。如果在某一步骤数组为空，则代表找不到。这种搜索算法每一次比较都使搜索范围缩小一半，时间复杂度是log(n)

说一下单例模式有哪些写法

饿汉模式。线程安全，调用效率高，不能延时加载。

懒汉模式。线程安全，调用效率不高，能延时加载。

双重检测锁模式。由因JVM底层模型原因，偶尔会出问题，不建议使用。

静态内部类式。线程安全，调用效率高，可以延时加载。

枚举类。线程安全，调用效率高，不能延时加载，可防止反射和反序列化调用。

懒汉式怎么写

主要思想构造器私有化防止被创建，提供一个获取实例的方法，为了线程安全双重检验加锁

懒汉式为了线程安全加锁为什么要双重检查再加锁

我们来解读一下，双重校验锁的意义何在，为什么要这样设计。

首先，第一次校验，也就是第一个判断if(singleton == null)，意义是由于单利模式只需创建一个实列，所以当第一次创建实列成功之后，再次调用Singleton.getInstance()就没有必要进入同步锁代码块，直接返回之前创建的实列即可。

第二次校验，也就是第二次判断if(singleton == null),是为了防止二次创建实列，我们假设一种状况，当singleton还未被创建的时候，线程r1 调用了getInstance 方法，由于此时的singleton 为空，则可以进入第一层判断，线程r1正准备继续执行，此时，线程r2抢占cpu资源，此时r2也调用了getInstance 方法，同理线程r1并没有实例化singleton，线程r2也可以进去判断，然后继续往下执行，进入到同步代码块，进入第二层判断，完成了singleton 的创建，并分配空间，r2线程运行周期结束。执行任务又回到了r1,如果没有第二层判断，线程r1 也会创建一个实列(r2线程已经创建一个实列，第二层判断为false)，这样就完全避免掉多线程环境下会创建多个实列的的问题。

spring的自动装配了解吗

自动装配就是让应用程序上下文为你找出依赖项的过程。说的通俗一点，就是Spring会在上下文中自动查找，并自动给bean装配与其关联的属性！

spring中实现自动装配的方式有两种，一种是通过xml文件、另一种是通过注解

手动装配

讲自动装配之前，我们先来说一下手动装配，手动装配又是什么？手动装配就是手动的将bean中所关联的其他bean装配进去。用代码表示：

<?xml version="1.0" encoding="UTF-8"?>    <beans xmlns="http://www.springframework.org/schema/beans"           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"           xsi:schemaLocation="http://www.springframework.org/schema/beans        https://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="cat" class="com.kuang.pojo.Cat"/>
    <bean id="dog" class="com.kuang.pojo.Dog"/>
    <bean id="people" class="com.kuang.pojo.Peopel">
        <property name="name" value="张三"/>
        <property name="cat" ref="cat"/>
        <property name="dog" ref="dog"/>
    </bean></beans>

在id=people的bean（以后id=xx的bean我们就叫xxBean）中，我们给peopleBean手动装配了与之关联的catBean和dogBean，这就叫做手动装配。

那么有没有什么办法，我们可以不用去手动装配关联的bean，让spring帮我们自动把关联的bean装配进去呢？答案是肯定的。自动装配就可以帮助我们解决这个问题。实现自动装配有两种方式。一种是使用注解的方式、另一种是通过xml文件的方式。下面我们俩讲实现自动装配的两种方式。

自动装配

使用autowire关键字声明bean的自动装配方式。其可选值为byName、byType

1.byName

设置autowire属性为byName，那么Spring会根据class属性找到实体类，然后查询实体类中所有setter方法的名字，根据setter方法后面的名字（例如SetDog，则setter方法后面的名字为dog）再到配置文件中寻找一个与该名字相同id的Bean，注入进来。如图：

2.byType

设置autowire属性为byType，那么Spring会自动寻找一个与该属性类型相同的Bean，注入进来。

*注意：使用byType这种方式，必须保证配置文件中所有bean的class属性的值是唯一的，否则就会报错

例如：下边这种方式是错误的，因为两个bean中的class属性的值重复了，会报错

springboot的@SpringBootApplication注解了解吗

一、@SpringBootApplication注解介绍
@SpringBootApplication这个注解是springboot启动类上的一个注解，是一个组合注解，也就是由其他注解组合起来，它的主要作用就是标记说明这个类是springboot的主配置类，springboot可以运行这个类里面的main()方法来启动程序

这个注解主要由三个子注解组成：

hashmap的源码看过吗

20240313面试

spring事务的传播机制

Spring框架提供了多种事务传播行为：

这里的当前指的是：a()调用b()方法，那a()方法就是当前

REQUIRED：如果当前存在事务，则加入该事务，如果当前没有事务，则创建一个新的事务。这是最常用的传播行为，也是默认的，适用于大多数情况。
REQUIRES_NEW：无论当前是否存在事务，都创建一个新的事务。如果当前存在事务，则将当前事务挂起。适用于需要独立事务执行的场景，不受外部事务的影响。
SUPPORTS：如果当前存在事务，则加入该事务，如果当前没有事务，则以非事务方式执行。适用于不需要强制事务的场景，可以与其他事务方法共享事务。
NOT_SUPPORTED：以非事务方式执行，如果当前存在事务，则将当前事务挂起。适用于不需要事务支持的场景，可以在方法执行期间暂时禁用事务。
MANDATORY：如果当前存在事务，则加入该事务，如果当前没有事务，则抛出异常。适用于必须在事务中执行的场景，如果没有事务则会抛出异常。
NESTED：如果当前存在事务，则在嵌套事务中执行，如果当前没有事务，则创建一个新的事务。嵌套事务是外部事务的一部分，可以独立提交或回滚。适用于需要在嵌套事务中执行的场景。
NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。适用于不允许在事务中执行的场景，如果存在事务则会抛出异常。

通过@Transactional注解的propagation属性来指定事务传播行为。

Redis 的过期策略

Redis的过期策略主要有三种：惰性删除、定期删除和定期淘汰。

惰性删除： 惰性删除是Redis默认的过期键删除策略。当客户端尝试访问一个已过期的键时，Redis会立即将该键删除，并返回空值。这种策略的优点是删除操作是在需要时进行，减少了不必要的删除开销。但是，如果大量过期键在一次性被访问之前没有被访问过，这些键会一直占据内存空间。
定期删除：Redis会每隔一段时间执行一次检查，删除那些已过期的键。默认情况下，Redis每秒执行10次检查。定期删除通过释放过期键所占据的内存空间，使得内存能够及时被回收。但这种方式可能会导致内存占用较高，因为Redis并不保证在每次定期删除操作中都会删除足够数量的过期键。
定期淘汰： 定期淘汰是Redis 4.0版本引入的一种新的过期策略。与定期删除不同的是，定期淘汰不仅删除已过期的键，而且会主动查找并淘汰一些尚未过期但是由于内存不足而需要释放的键。通过定期淘汰，Redis可以更主动地管理内存，避免因为内存持续增长而导致系统性能下降。

总的来说，我们需要根据实际需求和业务场景选择最适合的过期策略，以平衡内存使用和系统性能。

Redis 的淘汰策略

8种内存淘汰策略：

当 Redis 达到最大内存限制时，Redis会确切地使用配置好的最大内存策略指令来执行。相关策略如下：

1.noeviction（默认策略）：不会删除任何数据，拒绝所有写入操作并返回客户端错误消息（error）OOM command not allowed when used memory，此时 Redis 只响应删和读操作；

2.allkeys-lru：从所有 key 中使用 LRU 算法进行淘汰（LRU 算法：最近最少使用算法）；

3.allkeys-lfu：从所有 key 中使用 LFU 算法进行淘汰（LFU 算法：最不常用算法，根据使用频率计算，4.0 版本新增）；

4.volatile-lru：从设置了过期时间的 key 中使用 LRU 算法进行淘汰；

5.volatile-lfu：从设置了过期时间的 key 中使用 LFU 算法进行淘汰；

6.allkeys-random：从所有 key 中随机淘汰数据；

7.volatile-random：从设置了过期时间的 key 中随机淘汰数据；

8.volatile-ttl：在设置了过期时间的key中，淘汰过期时间剩余最短的。

注意：当使用 volatile-lru、volatile-lfu、volatile-random、volatile-ttl 这四种淘汰策略时，如果没有 key 可以淘汰，则和 neoviction 一样返回错误。

怎么保证数据库和Redis的数据一致性

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

先删除缓存，数据库还没有更新成功，此时如果读取缓存，缓存不存在，去数据库中读取到的是旧值，缓存不一致发生。

1.1 解决方案：延时双删

延时双删的方案的思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再 sleep 一段时间，然后再次删除缓存。

sleep 的时间要对业务读写缓存的时间做出评估，sleep 时间大于读写缓存的时间即可。

流程如下：

线程1删除缓存，然后去更新数据库
线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存
线程1，根据估算的时间，sleep，由于sleep的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除
如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值

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

如果反过来操作，先更新数据库，再删除缓存呢？

这个就更明显的问题了，更新数据库成功，如果删除缓存失败或者还没有来得及删除，那么，其他线程从缓存中读取到的就是旧值，还是会发生不一致。

2.1 解决方案一消息队列

这是网上很多文章里都有写过的方案。但是这个方案的缺陷会更明显一点。先更新数据库，成功后往消息队列发消息，消费到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。

这个解决方案其实问题更多。

引入消息中间件之后，问题更复杂了，怎么保证消息不丢失更麻烦
就算更新数据库和删除缓存都没有发生问题，消息的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的

springcloud都有些什么组件，分别的作用是什么

mysql有哪些锁

1. 乐观锁（Optimistic Locking）：假设并发操作时不会发生冲突，只在提交事务时检查数据是否被其他事务修改过。常用于读多写少的场景。
2. 悲观锁（Pessimistic Locking）：假设并发操作时会发生冲突，因此在操作期间持有锁来避免冲突。常用于写多读少的场景。
3. 全局锁（Global Lock）：对整个数据库实例加锁，限制除了超级用户外的所有查询和修改操作。一般用于备份、恢复等操作。
4. 表级锁（Table Lock）：对整个表加锁，其他连接无法修改或读取该表的数据，但可以对其他表进行操作。
5. 页级锁（Page Lock）：对数据页（通常是连续的几个行）加锁，控制并发事务对该页的访问。适用于数据较大且并发量较高的场景。
6. 行级锁（Row Lock）：对单个行加锁，只锁定需要修改的数据行，其他行可以被同时修改或读取。并发性高，但锁管理较复杂。
7. 共享锁（Shared Lock）：也称为读锁，多个事务可以同时持有共享锁并读取数据，但不能修改数据。适用于同时读取同一数据的场景。
8. 排它锁（Exclusive Lock）：也称为写锁，事务持有排它锁时，其他事务无法同时持有共享锁或排它锁，用于保护数据的写操作。
9. 意向共享锁（Intention Shared Lock）：表级锁的辅助锁，表示事务要在某个表或页级锁上获取共享锁。
10. 意向排它锁（Intention Exclusive Lock）：表级锁的辅助锁，表示事务要在某个表或页级锁上获取排它锁。
11. 间隙锁（Gap Lock）：锁定一个范围的键，但不包括这些键的实际值。用于防止其他事务在范围内插入数据。

间隙锁就是两个值之间的空隙加锁，是Innodb在可重复读隔离级别下为了解决幻读问题而引入的一种锁机制。需注意间隙锁只会在可重复读隔离级别（REPEATABLE-READ）下才会生效。
12. 临建锁（Metadata Lock）：锁定数据库对象的元数据，如表结构，用于保证数据定义的一致性。
13. 记录锁（Record Lock）：行级锁的特定类型，锁定单个行，确保其他事务无法同时修改或读取该行。
这些锁类型在不同的场景中可以组合使用，根据具体需求选择适当的锁策略来保证数据的一致性和并发性。同时，需要注意锁的粒度、锁冲突、死锁等问题，合理设计和管理锁可以提高数据库的并发性能。

mysql建立索引应该注意什么

20240314面试

volatile++是否是原子性操作?

不是

因为它实际上是三个操作组成的一个符合操作。

首先获取volatile变量的值
将该变量的值加1
将该volatile变量的值写会到对应的主存地址
一个很简单的例子：

如果两个线程在volatile读阶段都拿到的是a=1，那么后续在线程对应的CPU核心上进行自增当然都得到的是a=2，最后两个写操作不管怎么保证原子性，结果最终都是a=2。每个操作本身都没啥问题，但是合在一起，从整体上看就是一个线程不安全的操作：发生了两次自增操作，然而最终结果却不是3

什么是双亲委派机制?

双亲委派机制（Parent Delegation Mechanism）是Java中的一种类加载机制。在Java中，类加载器负责加载类的字节码并创建对应的Class对象。双亲委派机制是指当一个类加载器收到类加载请求时，它会先将该请求委派给它的父类加载器去尝试加载。只有当父类加载器无法加载该类时，子类加载器才会尝试加载。

这种机制的设计目的是为了保证类的加载是有序的，避免重复加载同一个类。Java中的类加载器形成了一个层次结构，根加载器（Bootstrap ClassLoader）位于最顶层，它负责加载Java核心类库。其他加载器如扩展类加载器（Extension ClassLoader）和应用程序类加载器（Application ClassLoader）都有各自的加载范围和职责。通过双亲委派机制，可以确保类在被加载时，先从上层的加载器开始查找，逐级向下，直到找到所需的类或者无法找到为止。

这种机制的好处是可以避免类的重复加载，提高了类加载的效率和安全性。同时，它也为Java提供了一种扩展机制，允许开发人员自定义类加载器，实现特定的加载策略。

Hashmap的容量为什么是2的n次幂

1.为了保证得到的新的数组索引和老数组索引一致。HashMap的初始容量是2的n次幂，扩容也是2倍的形式进行扩容，是因为容量是2的n次幂，可以使得添加的元素均匀分布在HashMap中的数组上，减少hash碰撞，避免形成链表的结构，使得查询效率降低！

双向链表和双向循环链表?

双向链表是链表的一种，它的每个节点中都有两个指针：前指针和后指针。分别指向节点的前驱和后继。所以，从双向链表中的任意一个结点开始，都可以很方便地访问它的前驱结点和后继结点。
其结构如下示意图所示：
链表中任意两相邻的节点通过前后指针相互相连。
在这里插入图片描述
节点：
、

双向循环链表的结构如下：
它是在双向链表的基础上，将双向链表的首节点指向尾节点，尾节点指向首节点。使得各个节点之间通过指针连接成环。

连接成环后，这里就没有严格上的首节点和尾节点了，也没有严格上的“前”和“后”节点了。为了实现以及描述的方便：我们在双向循环链表中取一个节点作为标记headNode(我们这里headNode中不存放数据相当于表头),其headNode的前指针指向tailNode。这样我们就可以，用双向链表的操作来操作这个结构了。

反射的实现方式都有什么?

反射的三种实现方式
1.通过 new 关键字获取javaBean实例，通过实例获取到Class对象。new 关键字会产生一个Student对象，一个Class对象

Persone stu = new Persone();
Class per1= stu.getClass();

2.通过类获取Class对象
Class per2= Student.class;

3.通过类路径（包名+类名）获取Class对象
Class per3= Class.forName("com.guhui.webserver.Persone")

Spring Boot 的核心注解是哪个?它主要由哪几个注解组成的?

在一个service方法A的内部，通过this调用该service的内部其他方法B时，会不会导致方法B的事务传播机制失效?

在 Spring 中，事务的传播机制默认是基于方法调用的。当一个带有事务注解的方法被调用时，Spring 会检查当前的事务上下文（Transaction Context），如果存在事务，则将该方法的执行加入到当前事务中。但是，当同一个类中的一个带有事务注解的方法通过 this 关键字调用同一个类中的另一个带有事务注解的方法时，事务传播机制不会生效。

这是因为 Spring 的事务传播机制是通过代理对象实现的。当一个类被 Spring 代理后，调用该类内部的方法会绕过代理对象，而直接调用目标对象的方法，从而使得事务注解无法生效。

为了解决这个问题，可以通过将带有事务注解的方法抽取到另一个类中，并通过依赖注入的方式调用，或者使用 @Transactional 注解中的 propagation 属性来显式地指定事务的传播行为，确保事务传播机制生效。例如，你可以将方法 B 抽取到另一个 service 类中，并在方法 A 中通过依赖注入的方式调用它，这样就能保证事务传播机制正常工作。

什么是覆盖索引?其特点是什么?

覆盖索引（Covering Index）是数据库中一种索引的类型，其特点是除了包含索引列之外，还包含了查询所需的其他列的数据。这样，在满足查询条件时，数据库引擎可以直接从索引中获取所有需要的数据，而不必再去查找主表或者聚集索引中的数据，从而提高查询的性能。

覆盖索引的特点包括：

减少IO操作: 因为覆盖索引中包含了所有需要的数据，所以查询可以直接在索引中获取数据，而不必再去查询主表或者聚集索引，从而减少了IO操作。
减少数据传输: 当查询只需要覆盖索引中的列时，数据库引擎只需从索引中获取数据，而不需要将整行数据从磁盘传输到内存中，这可以减少网络传输的数据量，提高查询效率。
减少锁竞争: 使用覆盖索引可以减少查询过程中对数据的锁竞争。因为不需要再去查询主表或者聚集索引中的数据，所以减少了对数据的访问，降低了锁的竞争。
节省存储空间: 覆盖索引只包含了索引列以及查询所需的其他列，不包含主表或者聚集索引中的其他列，因此占用的存储空间相对较小。

总的来说，覆盖索引通过将查询所需的数据直接存储在索引中，可以提高查询性能，减少IO操作，降低锁竞争，节省存储空间，是优化数据库查询性能的一种重要手段。

执行计划的type有哪几种?结果值从好到坏依次是?

在数据库中，执行计划（Execution Plan）的 type 属性描述了数据库查询执行的方式。不同的 type 表示了不同的查询执行策略，其中常见的 type 包括：

ALL: 表示全表扫描，即对表中的所有记录进行扫描，不使用索引。这种执行计划通常效率较低，因为需要读取整个表的数据。
INDEX: 表示使用了索引扫描，但是需要扫描索引中的所有条目，而不是使用索引覆盖扫描（Covering Index Scan），可能会导致额外的IO操作。
UNIQUE: 表示使用唯一索引进行查询，由于唯一索引的特性，可以在查询过程中立即找到匹配的记录，效率较高。
RANGE: 表示使用了范围扫描，通常与索引扫描一起使用，表示查询根据索引的范围进行扫描。
REF: 表示使用了引用（Reference）关系，通常用于连接查询（JOIN），可以通过外键来进行查询。
FULLTEXT: 表示使用了全文索引进行查询，用于全文搜索。
SYSTEM: 表示系统表的扫描。
CONST: 表示使用了常数表进行查询，通常用于查询常数表中的数据。

执行计划的 type 属性通常是根据查询语句、表结构和索引情况等因素自动生成的，不同的数据库系统可能会有不同的执行计划类型。一般来说，执行计划的结果值从好到坏依次是：

CONST：常数表查询，效率最高。
SYSTEM：系统表扫描，一般情况下也较快。
UNIQUE：唯一索引查询，效率较高。
REF：引用关系查询，通常是连接查询，效率一般。
RANGE：范围扫描，通常是索引扫描的一种，效率取决于范围的大小和索引的选择性。
INDEX：索引扫描，效率取决于索引的使用情况。
ALL：全表扫描，效率最低，应尽量避免使用。

MySQL数据表中id自增，为什么会出现id不连续的情况?怎么保证其连续性?

1. 插入失败
在插入数据时，如果出现了插入失败的情况，可能会导致ID自增长不连续。例如，在使用INSERT语句插入数据时，可能遇到了主键冲突或其他约束错误，导致插入失败。这时，MySQL并不会为插入失败的记录分配一个ID，从而导致ID的不连续。

INSERT INTO table_name (id, name) VALUES (1, 'John');
-- 插入成功，ID为1

INSERT INTO table_name (id, name) VALUES (2, 'Mary');
-- 插入失败，ID为2的记录不存在

INSERT INTO table_name (id, name) VALUES (3, 'Tom');
-- 插入成功，ID为3

2. 记录被删除
当记录被删除时，该记录对应的ID就会变成空缺。例如，我们有一个自增长ID的表，并且我们删除了其中的一条记录，这时ID自增长就会出现不连续的情况。

DELETE FROM table_name WHERE id = 2;
-- 删除ID为2的记录

SELECT * FROM table_name;
-- 输出： 1 | John
-- 输出： 3 | Tom

3. 事务回滚
在使用事务时，如果事务被回滚了，已经插入的记录会被撤销，但是ID的自增长值并不会重置。这就导致了ID的不连续。

START TRANSACTION;
INSERT INTO table_name (name) VALUES ('John');
-- 插入成功，ID为1

ROLLBACK;
-- 事务回滚

SELECT * FROM table_name;
-- 输出：空

解决方案
1. 自定义ID生成规则
如果我们对ID的连续性有严格要求，可以考虑自定义ID生成规则。可以使用UUID、雪花算法或其他方式生成唯一的ID，并将其作为主键。这样可以避免依赖于自增长ID的连续性。

CREATE TABLE table_name (
  id VARCHAR(36) PRIMARY KEY,
  name VARCHAR(100)
);

2. 重新排序ID
如果ID的连续性对业务并不重要，只是为了方便查询和管理，可以通过重新排序ID来解决。可以使用以下步骤：创建一个临时表，将原表中的数据按照一定的规则插入到临时表中，同时分配新的连续ID。
删除原表，并将临时表重命名为原表名。
复制

-- 创建临时表
CREATE TABLE temp_table_name (
  new_id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(100)
);

-- 将原表数据插入临时表，并分配新的连续ID
INSERT INTO temp_table_name (name)
SELECT name FROM table_name ORDER BY id ASC;

-- 删除原表
DROP TABLE table_name;

-- 重命名临时表
ALTER TABLE temp_table_name
RENAME TO table_name;

-- 重新设置连续ID的起始值
ALTER TABLE table_name
MODIFY COLUMN id INT PRIMARY KEY AUTO_INCREMENT;

3. 忽略ID的连续性
在一些情况下，ID的连续性并不是必需的。如果应用中对ID的连续性没有特殊要求，可以忽略不连续的ID，并将其作为普通的自增长ID使用。

结论
MySQL中ID自增长不连续的原因可能是插入失败、记录被删除或事务回滚等。为了解决这个问题，可以使用自定义ID生成规则、重新排序ID或者忽略ID的连续性。根据具体的业务需求，选择合适的解决方案。

redis 的数据类型有哪几种?

String（字符串）：最基本的数据类型，可以包含任意的数据，比如一个整数、浮点数、二进制数据等。
List（列表）：一个序列集合，每个元素都包含在一个双向链表中。列表可以在头部或尾部添加、删除元素，也可以根据索引获取元素。
Set（集合）：包含多个唯一元素的无序集合。可以执行集合操作，如并集、交集、差集等。
Sorted Set（有序集合）：类似于集合，但每个元素都关联了一个分数（score），并按照分数进行排序。
Hash（哈希）：包含多个字段和对应的值的无序散列表。可以用于存储对象，每个字段代表对象的一个属性。
Bitmaps（位图）：一种特殊的字符串，可以用于位运算。
HyperLogLog（基数估计）：用于估计一个集合的基数（不重复元素的数量）的算法。
Geospatial（地理位置）：存储地理位置坐标信息，可以进行位置相关的查询。

Redis 中的主键失效是如何实现的，即失效的主键是如何删除的?

在 Redis 中，主键失效是通过设置主键的过期时间来实现的，而失效的主键则会在过期时间到达后由 Redis 内部的过期键删除机制自动删除。

具体地说，当一个键被设置了过期时间后，Redis 会在内部维护一个过期键的字典（expiration dictionary），用来存储所有设置了过期时间的键以及其对应的过期时间。同时，Redis 的服务器会周期性地（每隔一段时间）检查过期键字典，删除过期的键。这个过期键删除的操作是通过在每次访问键时，进行检查是否过期来实现的。

当一个客户端尝试访问一个过期键时，Redis 会检查该键是否已经过期。如果键已经过期，Redis 会删除该键并返回空值给客户端，表示该键已经被删除。这个删除过程是在访问时进行的，称为惰性删除（lazy deletion），即 Redis 不会主动删除过期键，而是在访问时检查并删除过期的键。

总之，Redis 中的主键失效是通过设置过期时间实现的，而失效的主键则是由 Redis 内部的过期键删除机制在访问时进行检查并删除的。

TCP为什么连接的时候是三次握手，关闭的时候却是四次握手?

TCP连接时的三次握手和关闭时的四次握手是为了确保数据的可靠传输和连接的安全关闭。

三次握手建立连接：
- 第一次握手：客户端发送一个带有 SYN（同步）标志的数据包给服务器，并进入 SYN_SENT 状态。
- 第二次握手：服务器接收到客户端的 SYN 数据包，回应一个带有 SYN 和 ACK（确认）标志的数据包给客户端，并进入 SYN_RECEIVED 状态。
- 第三次握手：客户端接收到服务器的 SYN-ACK 数据包后，向服务器发送一个带有 ACK 标志的数据包，表示确认连接已建立，双方进入 ESTABLISHED 状态，TCP连接建立成功。
通过三次握手，双方确认了彼此的接收能力和发送能力，建立了可靠的连接。
四次握手关闭连接：
- 第一次握手（客户端发起）：客户端发送一个带有 FIN（结束）标志的数据包给服务器，请求关闭连接，并进入 FIN_WAIT_1 状态。
- 第二次握手（服务器发起）：服务器接收到客户端的 FIN 数据包后，发送一个带有 ACK 标志的数据包给客户端，表示接收到了关闭请求，并进入 CLOSE_WAIT 状态。
- 第三次握手（服务器发起）：当服务器准备好关闭连接时，发送一个带有 FIN 标志的数据包给客户端，请求关闭连接，并进入 LAST_ACK 状态。
- 第四次握手（客户端发起）：客户端接收到服务器的 FIN 数据包后，发送一个带有 ACK 标志的数据包给服务器，表示确认关闭请求，进入 TIME_WAIT 状态。在这个状态下，客户端等待一段时间（等待 2 * MSL，MSL 为最大报文段生存时间），确保服务器收到了确认，并且对之前的数据包进行重发等操作，之后进入 CLOSED 状态。服务器接收到客户端的确认后，也进入 CLOSED 状态。
通过四次握手，双方确认了彼此的关闭意图，并确保已经传输完所有的数据，以及释放了所有的连接资源，保证了连接的安全关闭。四次握手中的最后一次握手是为了确保服务器收到了客户端的确认，从而避免出现客户端发出 FIN 后，服务器未收到确认而一直处于 CLOSE_WAIT 状态，导致服务器的资源无法释放。

如何保证消息的顺序性?幂等性?

保证消息的顺序性：
- 单一生产者单一消费者：在单一生产者单一消费者的场景下，可以通过队列来保证消息的顺序性。生产者按顺序将消息发送到队列，消费者从队列中按顺序获取消息进行处理。
- 分区顺序：在分布式系统中，可以将消息按照某种规则进行分区，保证同一分区内的消息有序，然后消费者按照分区顺序处理消息。
- 全局序列号：为每条消息分配一个全局唯一的序列号，并保证生产者按照顺序发送消息，消费者按照序列号顺序处理消息。
保证消息的幂等性：
- 唯一标识：给每条消息赋予一个唯一的标识符，消费者在处理消息时，可以根据标识符来判断消息是否已经被处理过，避免重复处理。
- 幂等操作：设计幂等性的操作，即使同一消息被处理多次也不会产生额外的影响。比如，更新操作可以改为判断数据是否存在，如果不存在则插入，如果存在则更新，这样无论操作执行多少次结果都是一样的。
- 消息处理记录：记录每条消息的处理状态，比如使用数据库或者分布式缓存来记录消息的处理状态，防止重复处理。

综上所述，保证消息的顺序性和幂等性是设计分布式系统时需要考虑的重要问题，可以通过合适的设计和技术手段来实现。

微服务之间是如何独立通讯?各有什么优缺点?

在微服务架构中，gateway网关的作用是什么

在微服务架构中，网关（Gateway）是一个用于管理、路由和保护微服务的组件。它作为系统的入口点，承担了多种重要的功能，包括：

路由转发：网关可以根据请求的 URL、路径或者其他条件，将请求路由到相应的微服务实例。通过配置路由规则，可以将不同的请求映射到不同的后端服务，实现请求的转发和负载均衡。
协议转换：网关可以将外部请求转换为内部微服务所需的协议格式，例如将 HTTP 请求转换为 gRPC 请求或者其他协议格式，使得微服务之间的通讯更加灵活。
安全认证：网关可以集中处理认证和授权，对请求进行身份验证、访问控制和权限管理，保护微服务不受未授权访问和恶意攻击。
流量控制：网关可以实现流量控制策略，限制每个微服务的请求速率和并发连接数，防止服务过载和雪崩效应。
监控和日志：网关可以记录请求日志和统计信息，监控服务的健康状态和性能指标，帮助运维人员实时监控和诊断系统问题。
容错和降级：网关可以实现容错和降级策略，对失败的请求进行重试、回退或者转发到备用服务，提高系统的可用性和可靠性。

总的来说，网关在微服务架构中起到了统一入口、路由转发、安全认证、流量控制、监控日志等多种作用，帮助简化系统架构、提高系统的安全性、可靠性和可维护性。

mysql有哪些常用的索引类型

在MySQL中，索引按照索引列的类型可以分为以下几种：

主键索引：用于唯一标识每一条记录，主键索引的值不允许重复且不能为空，并且一个表只能有一个主键索引。
唯一索引：用于保证索引列的值唯一，允许为空值，但是一个表可以有多个唯一索引。
普通索引：没有唯一性限制，允许重复值和空值，是最基本的索引类型。
组合索引：在多个字段上创建的索引，可以包含多个列。组合索引可以提高多列查询的性能，但查询条件必须符合最左前缀原则，即查询从左到右使用组合索引中的列。

以上就是MySQL常见的四种索引，这些不同类型的索引在数据库中起到了加速数据检索操作的作用，可以根据具体的需求和使用场景选择适当的索引类型。同时，需要注意索引的创建对写操作（如插入、更新、删除）可能会产生额外的开销，因此需要权衡索引的使用与数据操作的平衡。

主键索引和普通索引有什么不同

主键索引和普通索引的不同主要在于其作用和约束：

主键索引（Primary Key Index）：
- 主键索引是一种特殊的唯一索引，用于唯一标识表中每一行数据的索引。
- 每个表只能有一个主键索引，主键索引要求值唯一且不能为空，通常是用来确保表中每行数据的唯一性和完整性。
- 主键索引可以是单列索引，也可以是多列组合索引。
普通索引（Normal Index）：
- 普通索引是一种对表中的某个列或多个列创建的索引，用于加速对该列的查询操作。
- 普通索引可以是唯一索引，也可以是非唯一索引。唯一索引要求索引列的值唯一，非唯一索引则允许重复值。
- 普通索引可以用于加速各种查询操作，包括等值查找、范围查找、排序和连接操作。

总的来说，主键索引是一种特殊的唯一索引，用于标识表中每一行数据的唯一性和完整性，而普通索引则是对表中某个列或多个列创建的索引，用于加速对该列的查询操作。

Redis主要用来解决什么问题

Redis（Remote Dictionary Server）是一个开源的内存数据库，主要用来解决以下几类问题：

缓存：作为缓存存储常用的键值对数据，可以加速应用程序的访问速度。由于 Redis 数据存储在内存中，读取速度非常快，适合作为高速缓存层来存储频繁访问的数据，如数据库查询结果、页面片段、会话数据等。
会话存储：用于存储用户会话数据，如用户登录状态、购物车数据等。将用户会话数据存储在 Redis 中，可以实现分布式、高可用的会话管理，提高应用的性能和可靠性。
消息队列：提供了丰富的数据结构和命令，支持消息队列的功能，如发布/订阅模式、列表结构等，可用于实现消息传递和异步任务处理。
计数器和排行榜：通过 Redis 的原子性操作，可以实现高性能的计数器和排行榜功能。比如统计网站的访问量、点赞数、热门文章等。
分布式锁：利用 Redis 的原子性操作和过期特性，可以实现分布式锁，保证多个客户端之间的操作互斥，防止出现竞态条件和数据错乱。
实时数据处理：由于 Redis 的高性能和持久化特性，可以用来存储实时数据，并支持实时数据分析、统计和监控等功能。
地理位置信息：Redis 支持地理位置信息的存储和查询，可以用于实现位置服务、附近的人等功能。

总的来说，Redis 主要用来解决高速缓存、会话存储、消息队列、计数器和排行榜、分布式锁、实时数据处理等问题，为应用程序提供高性能、高可靠性的数据存储和处理服务。

spring怎么使用事务

在 Spring 中，使用事务通常涉及以下几个方面：

配置数据源和事务管理器：首先需要配置数据源和事务管理器，Spring 提供了各种数据源和事务管理器的实现，可以根据具体的数据库和需求进行配置。
声明式事务管理：Spring 支持声明式事务管理，可以通过注解或者 XML 配置来声明事务。常用的注解包括 @Transactional，用于标注在方法或者类上，表示该方法或者类需要进行事务管理。在 XML 配置中，可以使用 <tx:annotation-driven> 开启注解驱动事务管理。
事务切面配置：通过配置事务切面，将事务功能织入到方法调用中。可以使用 @EnableTransactionManagement 注解启用事务管理，然后配置事务切面的织入点和通知类型。
编程式事务管理：除了声明式事务管理外，Spring 还支持编程式事务管理，可以通过编程方式来控制事务的开启、提交、回滚和关闭。使用 TransactionTemplate 类或者 PlatformTransactionManager 接口进行编程式事务管理。

下面是一个简单的示例，演示了如何在 Spring 中使用声明式事务管理：

import org.springframework.transaction.annotation.Transactional;

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional
    public void updateUser(User user) {
        userRepository.save(user);
    }

    @Transactional(readOnly = true)
    public User getUserById(Long id) {
        return userRepository.findById(id).orElse(null);
    }
}

spring实现事务的原理是什么

Spring 实现事务的原理主要基于 AOP（面向切面编程）和代理模式，核心是通过代理对象对事务进行管理。下面是 Spring 实现事务的基本原理：

代理模式：Spring 使用代理模式为被管理的对象生成代理对象，来控制事务的行为。Spring 默认使用动态代理和 CGLIB（Code Generation Library）两种方式生成代理对象，其中动态代理适用于接口代理，而 CGLIB 适用于类代理。
AOP 切面：Spring 使用 AOP 切面来切入事务管理的代码，在方法执行前开启事务，在方法执行后通知（Advice），可以在方法执行前提交或回滚事务，从而实现事务管理的功能。通过在切面中添加事务后执行事务管理逻辑。
事务管理器：Spring 提供了多种事务管理器（TransactionManager）实现，如 JDBC、Hibernate、JTA 等，用于管理事务的生命周期，包括事务的开启、提交、回滚、隔离级别的设置等。
事务注解：Spring 提供了 @Transactional 注解用于声明事务，通过在方法或类上添加 @Transactional 注解，可以将被注解的方法或类纳入事务管理的范围内。
事务传播机制：Spring 提供了丰富的事务传播机制，用于控制多个事务方法之间的调用关系和事务边界，包括 PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED 等。

spring同一个类里的方法进行调用事务的生效情况

解释1

在这种情况下，testB() 方法内的事务不会生效，因为事务的传播机制在这里并不适用。

Spring 的事务传播行为只在事务方法被外部调用时生效，而在同一个类内部的方法之间的调用不会触发事务的代理。换句话说，虽然 testB() 方法上标注了 @Transactional 注解，但由于事务方法是在同一个类中的 testA() 方法内部调用的，Spring 并不会对其进行事务代理。

要解决这个问题，您需要将 testB() 方法移动到另一个类中，并确保在调用 testB() 方法时通过 Spring 代理,或者把 @Transactional放到testA()上

解释2

spring 在扫描bean的时候会扫描方法上是否包含@Transactional注解，如果包含，spring会为这个bean动态地生成一个子类（即代理类，proxy），代理类是继承原来那个bean的。此时，当这个有注解的方法被调用的时候，实际上是由代理类来调用的，代理类在调用之前就会启动transaction。然而，如果这个有注解的方法是被同一个类中的其他方法调用的，那么该方法的调用并没有通过代理类，而是直接通过原来的那个bean，所以就不会启动transaction，我们看到的现象就是@Transactional注解无效。

@Autowired
    private ProductsService productsService;

    @Test
    void testA() {
//        在这种情况下，testB() 方法内的事务不会生效，因为事务的传播机制在这里并不适用。
//        Spring 的事务传播行为只在事务方法被外部调用时生效，而在同一个类内部的方法之间的调用不会触发事务的代理。换句话说
//        虽然 testB() 方法上标注了 @Transactional 注解，但由于事务方法是在同一个类中的 testA() 方法内部调用的，Spring 并不会对其进行事务代理。
//        要解决这个问题，您需要将 testB() 方法移动到另一个类中，并确保在调用 testB() 方法时通过 Spring 代理
        testB();
    }

    @Transactional
    void testB() {
        boolean update = productsService.update(new LambdaUpdateWrapper<Products>()
                .set(Products::getStock, 300).eq(Products::getId, 1));
        int a = 10 /0;

    }

mysql怎么实现分布式事务

线程池的组成

Java 线程池由以下几个组成部分组成：

工作队列（Work Queue）：工作队列是用于存储待执行任务的队列。当线程池中的线程空闲时，它们会从工作队列中获取任务来执行。Java 中的线程池通常支持不同类型的工作队列，如有界队列（如 ArrayBlockingQueue、LinkedBlockingQueue）和无界队列（如 SynchronousQueue）等。
线程池管理器（Thread Pool Manager）：线程池管理器负责创建、销毁和管理线程池中的线程。它会根据当前线程池的状态和配置，动态地增加或减少线程数量，以满足任务的需求。
线程工厂（Thread Factory）：线程工厂用于创建线程池中的线程实例。通常情况下，线程工厂会定义线程的一些属性，如名称、优先级、守护状态等。
拒绝策略（Rejected Execution Handler）：拒绝策略定义了当工作队列已满且无法接受新任务时，线程池应该如何处理这些新任务。常见的拒绝策略包括丢弃任务、抛出异常、阻塞调用者等。

综上所述，Java 线程池的组成部分包括工作队列、线程池管理器、线程工厂和拒绝策略。这些组件共同协作，实现了线程的重用、管理和任务调度，从而提高了应用程序的性能和可伸缩性。

有哪些阻塞队列

在 Java 中，常见的阻塞队列包括以下几种：

ArrayBlockingQueue：基于数组实现的有界阻塞队列，它按照先进先出（FIFO）的顺序对元素进行排序。ArrayBlockingQueue 在初始化时需要指定容量，一旦队列达到容量上限，添加操作将会阻塞，直到队列中有空间可用。
LinkedBlockingQueue：基于链表实现的有界或无界阻塞队列，它也按照先进先出（FIFO）的顺序对元素进行排序。LinkedBlockingQueue 在初始化时可以选择指定容量，如果未指定容量则默认为无界队列。
PriorityBlockingQueue：基于优先级堆实现的无界阻塞队列，它不按照先进先出的顺序对元素进行排序，而是根据元素的优先级进行排序。PriorityBlockingQueue 中的元素必须实现 Comparable 接口或者提供 Comparator 来定义元素的优先级。
DelayQueue：延迟队列，它是一个无界阻塞队列，其中的元素只有在延迟期满时才能从队列中取出。DelayQueue 中的元素必须实现 Delayed 接口，该接口定义了元素的延迟时间，以及元素之间的排序规则。
SynchronousQueue：同步队列，它是一个没有存储元素的阻塞队列。SynchronousQueue 中的每个插入操作必须等待另一个线程的相应移除操作，反之亦然。它通常用于生产者-消费者模式中的交换数据。

这些阻塞队列都是线程安全的，可以在多线程环境中安全地进行操作。根据不同的需求和场景，选择合适的阻塞队列可以帮助提高系统的性能和可靠性。

20240314面试

有没有遇到系统宕掉的情况，怎么检查怎么解决的

说说synchronized与ReentrantLock的区别

synchronized和ReentrantLock都是用于实现线程同步的机制，但它们之间有一些区别，下面是它们的主要区别：

获取锁的方式：
- synchronized：在Java中是一种内置的同步机制，通过使用synchronized关键字来实现。它是隐式地获取锁，当线程进入synchronized代码块时，会自动获取锁，并在退出代码块时释放锁。
- ReentrantLock：是Java中的显式锁，需要使用Lock接口的实现类ReentrantLock来获取和释放锁。需要手动调用lock()方法来获取锁，而且需要在finally块中手动调用unlock()方法来释放锁。
灵活性：
- ReentrantLock相对于synchronized更加灵活，提供了更多的特性。例如，可以实现公平锁和非公平锁、可中断的锁、可限时的锁等功能，而synchronized只能实现非公平锁，且不支持中断和限时获取锁。
可重入性：
- ReentrantLock的名称中已经说明了它的可重入性。即同一个线程可以多次获得同一把锁，而不会发生死锁。而synchronized也是可重入的，当一个线程持有锁时，可以重复进入同步块而不会被阻塞。

综上所述，ReentrantLock提供了更多的功能和灵活性，但是使用起来相对复杂，需要手动管理锁的获取和释放。而synchronized是Java语言提供的内置同步机制，简单易用，但功能相对较少。在选择使用时，可以根据具体的需求和场景来决定使用哪种方式。

非root启动tomcat

知道反向代理nginx怎么做负载均衡吗

当使用Nginx作为反向代理时，可以通过配置负载均衡来实现将请求分发给多个后端服务器。以下是一种基本的配置方法：

安装Nginx：首先确保您已经在服务器上安装了Nginx。可以通过包管理器（如apt、yum等）来安装。
配置负载均衡：编辑Nginx的配置文件（通常是 /etc/nginx/nginx.conf 或 /etc/nginx/sites-available/default），在http块中添加负载均衡配置。例如：
1. ```
http {
    upstream backend_servers {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
        # 添加更多的后端服务器
    }
    
    server {
        listen 80;
        server_name example.com;
        
        location / {
            proxy_pass http://backend_servers;
        }
    }
}
```
  在上面的配置中：
2. upstream backend_servers 定义了一组后端服务器，可以是IP地址或主机名。
3. proxy_pass http://backend_servers; 将请求代理到定义的后端服务器组。
配置负载均衡算法：Nginx默认使用轮询（round-robin）算法进行负载均衡，即每个请求按照后端服务器列表的顺序依次分配。如果需要使用其他算法，可以在upstream块中添加相应的指令，如least_conn（最小连接数）等。
1. ```
upstream backend_servers {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    # 添加更多的后端服务器
}
```
重启Nginx：完成配置后，重启Nginx服务以使配置生效。
1. ```
sudo systemctl restart nginx
```

现在，Nginx将会在后端服务器之间进行负载均衡，将请求分发给不同的后端服务器，从而提高系统的性能和可用性。请根据您的具体需求和场景进行相应的配置调整。

linux使用什么命令查看某几行日志

要查看文件的某几行日志，可以使用head和tail命令结合使用。以下是几种常用的方法：

使用head命令查看文件的前几行日志：
1. ```
head -n 10 filename.log
```
  这将显示 filename.log 文件的前10行日志。您可以将 -n 参数后面的数字修改为您想要查看的行数。
使用tail命令查看文件的后几行日志：
1. ```
tail -n 10 filename.log
```
  这将显示 filename.log 文件的后10行日志。同样，您可以修改 -n 参数后面的数字以获取不同数量的行。
使用tail命令查看文件的最新几行日志：
1. ```
tail -f filename.log
```
  这将实时显示 filename.log 文件的最新日志。您可以通过按下 Ctrl + C 来停止查看。
使用sed命令查看文件的指定行范围日志：
1. ```
sed -n '5,15p' filename.log
```
  这将显示 filename.log 文件的第5行到第15行的日志。您可以将数字替换为您想要查看的行号范围。
使用awk命令查看文件的指定行范围日志：
1. ```
awk 'NR>=5 && NR<=15' filename.log
```
  这将显示 filename.log 文件的第5行到第15行的日志。同样，您可以将数字替换为您想要查看的行号范围。

根据您的需求和实际情况，选择适合的命令来查看文件的特定行数或行范围的日志。

linux查看日志的时候怎么搜索关键字

在Linux中查看日志并搜索关键字通常使用grep命令，它可以从输入中过滤出包含指定模式的行。以下是几种常用的方法：

这些是常用的搜索技巧，您可以根据具体的需求和情况选择适合的方法来搜索关键字。

基本搜索：
```
grep "keyword" filename.log
```
这将在 filename.log 文件中搜索包含指定关键字的行，并将其显示出来。您可以将 keyword 替换为您想要搜索的关键字，也可以使用正则表达式来进行更复杂的匹配。
忽略大小写搜索：
```
grep -i "keyword" filename.log
```
添加 -i 参数可以忽略搜索时的大小写区分。
显示匹配行的行号：
```
grep -n "keyword" filename.log
```
添加 -n 参数可以显示匹配行的行号。
显示不匹配的行：
```
grep -v "keyword" filename.log
```
添加 -v 参数可以显示不包含指定关键字的行。
递归搜索：
```
grep -r "keyword" /path/to/directory
```
使用 -r 参数可以递归搜索指定目录下的所有文件。
同时搜索多个文件：
```
grep "keyword" file1.log file2.log
```
您可以将多个文件名作为参数传递给grep命令，以在多个文件中搜索关键字。
管道搜索：
```
cat filename.log | grep "keyword"
```
您可以使用管道操作将日志文件的内容传递给grep命令，以进行搜索。

docker file了解吗

Dockerfile是用于构建Docker镜像的文本文件，其中包含了一系列的指令和参数，用于描述如何构建镜像的步骤。通过编写Dockerfile，可以将应用程序及其依赖打包成一个可移植的容器镜像，方便在不同的环境中部署和运行。

以下是一个简单的Dockerfile示例：

# 使用基础镜像
FROM ubuntu:latest

# 设置环境变量
ENV APP_HOME /app

# 在容器中创建工作目录
WORKDIR $APP_HOME

# 将本地文件复制到容器中
COPY . .

# 安装依赖和运行环境
RUN apt-get update && apt-get install -y \
    python3 \
    python3-pip

# 安装应用程序依赖
RUN pip3 install -r requirements.txt

# 暴露端口
EXPOSE 8080

# 容器启动时执行的命令
CMD ["python3", "app.py"]

docker进行挂载目录的时候，重启docker然后出现挂载目录覆盖的情况

工作流是怎么实现的，并行节点、会签等功能

并行节点：并行节点是工作流中的一种节点类型，用于并行执行多个任务或子流程。并行节点可以分为并行分支（Parallel Gateway）和并行合并（Parallel Gateway）两种类型。并行分支将流程分成多个分支，每个分支可以独立执行；并行合并将多个分支的执行结果合并为一个结果。通过并行节点，可以实现并行执行、并行审批等功能。
会签：会签是一种多人参与的审批机制，它要求所有参与者都同意或拒绝某个请求或任务，只有在所有参与者都同意时才能继续流程的执行。会签通常通过特定的节点类型或任务类型来实现，比如并行网关（Parallel Gateway）或多实例任务（Multi-Instance Task）等。

达梦数据库的集群部署知道吗

20240318面试

面向对象oop

new的对象储存在哪

new 一个对象实际上执行了什么

4GB内存，堆设置多大

spring事务什么异常会导致失效

20240319面试

说一下JVM的内存模型

Java虚拟机（JVM）的内存模型定义了Java程序运行时的内存结构和管理规则。它将内存划分为不同的区域，每个区域用于不同的目的，主要包括以下几个部分：

程序计数器（Program Counter Register）：程序计数器是一块较小的内存区域，是线程私有的，用于记录当前线程执行的字节码指令地址或者下一条需要执行的指令地址。对于多线程环境，每个线程都有自己独立的程序计数器。
Java虚拟机栈（JVM Stack）： Java虚拟机栈也是线程私有的，用于存储方法执行的栈帧（Stack Frame）。每个方法在执行的时候都会创建一个栈帧，用于存储局部变量、操作数栈、方法出口等信息。栈帧的大小在编译期间就已经确定，所以栈的深度也是有限制的。当栈空间不足或者发生StackOverflowError时会抛出异常。
本地方法栈（Native Method Stack）：本地方法栈类似于Java虚拟机栈，但它是为Native方法服务的，即使用JNI（Java Native Interface）来调用的方法。它也是线程私有的，同样会抛出StackOverflowError。
堆（Heap）：堆是Java虚拟机管理的最大的一块内存区域，用于存储对象实例以及数组。堆是所有线程共享的区域。Java堆可以动态地分配内存，也可以进行垃圾回收以释放未使用的对象空间。在堆中，主要会涉及到新生代和老年代等概念，以及Eden空间、Survivor空间等区域。
方法区（Method Area）：方法区也是所有线程共享的内存区域，用于存储类的元数据信息、常量、静态变量、即时编译器编译后的代码等。在HotSpot虚拟机中，方法区被称为“永久代”，但在较新的版本中，永久代已经被元空间（Metaspace）所取代。
运行时常量池（Runtime Constant Pool）：运行时常量池是方法区的一部分，用于存储编译期生成的字面量常量和符号引用。它包含类、方法、字段的符号引用以及字面量常量的值。
直接内存（Direct Memory）：直接内存不是Java虚拟机规范中定义的内存区域，但它是Java NIO（New I/O）提供的一种内存管理方式。它不受JVM直接控制，而是由操作系统进行管理的，主要是通过堆外内存来提高I/O性能。

这些区域的组合形成了Java程序运行时的内存结构，Java虚拟机通过对这些内存区域的管理来实现Java程序的运行和内存的分配与释放。

常见的垃圾回收器，以及垃圾回收算法

java常见的垃圾回收器有多种，每种垃圾回收器都有其适用的场景和特点。以下是一些常见的垃圾回收器及其垃圾回收算法：

串行垃圾回收器 (Serial Garbage Collector)：
- 适用场景：主要用于单线程环境或小型应用。
- 垃圾回收算法：使用单线程进行垃圾回收，采用标记-清除算法。
并行垃圾回收器 (Parallel Garbage Collector)：
- 适用场景：多核CPU下的中大型应用。
- 垃圾回收算法：使用多线程并行地进行垃圾回收，采用标记-清除算法或标记-整理算法。
并发标记清除垃圾回收器 (Concurrent Mark-Sweep Garbage Collector)：
- 适用场景：注重降低垃圾回收停顿时间的应用。
- 垃圾回收算法：采用并发标记和清除算法，在垃圾回收过程中允许程序继续执行。
G1垃圾回收器 (Garbage-First Garbage Collector)：
- 适用场景：大堆、低延迟要求的应用。
- 垃圾回收算法：采用分代和区域化的垃圾回收方式，将堆分为多个区域，并采用复制算法和标记-整理算法。
ZGC (Z Garbage Collector)：
- 适用场景：超大堆、低延迟要求的应用。
- 垃圾回收算法：采用分代和压缩算法，采用了读屏障和写屏障来实现在并发情况下的垃圾回收。
Shenandoah垃圾回收器：
- 适用场景：大堆、低延迟要求的应用。
- 垃圾回收算法：采用了分布式垃圾回收算法，通过多个线程并发地进行垃圾回收，采用标记-复制算法。

垃圾回收算法通常包括以下几种：

标记-清除算法 (Mark-Sweep)：首先标记出所有活跃的对象，然后清除掉未标记的对象。
标记-整理算法 (Mark-Compact)：首先标记出所有活跃的对象，然后将它们向一端移动，然后清除掉未移动的对象。
复制算法 (Copying)：将内存分为两块，一块用于分配对象，另一块用于垃圾回收，将存活的对象复制到未使用的内存区域，然后清除已使用的区域。
分代算法 (Generational)：根据对象的存活周期将堆空间划分为不同的代，通常分为新生代和老年代，针对不同代采用不同的垃圾回收策略，如新生代常使用复制算法，老年代常使用标记-清除或标记-整理算法。

知道CMS垃圾回收器吗

CMS（Concurrent Mark-Sweep）垃圾回收器是Java虚拟机的一种垃圾回收器，旨在减少长时间的垃圾回收停顿时间。它采用了并发标记和清除算法。

CMS垃圾回收器的主要特点包括：

并发标记：CMS在垃圾回收过程中尽可能地与应用程序并发执行。它通过初始标记、并发标记和重新标记三个阶段来实现并发标记。初始标记和重新标记阶段会暂停应用程序的执行，但这两个阶段的停顿时间通常都很短。
并发清除：与标记阶段并行进行的是垃圾的清理工作。CMS在标记阶段标记出需要清除的对象后，通过并发线程来清除这些对象，从而尽量减少应用程序的停顿时间。
低停顿时间：CMS垃圾回收器主要目标是减少长时间的垃圾回收停顿时间，因此它通常适用于对垃圾回收停顿时间敏感的应用程序。

然而，CMS垃圾回收器也有一些缺点：

内存碎片问题：由于CMS采用标记-清除算法，可能会产生内存碎片，导致堆空间的有效利用率降低，进而可能导致频繁的Full GC。
并发模式失败：当CMS无法跟上垃圾产生速度，或者堆空间过小时，可能会导致并发模式失败，从而触发Serial Old收集器的Full GC，造成较长的停顿时间。
对CPU资源的竞争：CMS在并发阶段会消耗一定的CPU资源，可能会与应用程序竞争CPU，影响应用程序的性能。

由于上述缺点，随着Java虚拟机的发展，一些新的垃圾回收器如G1和ZGC逐渐成为了更优的选择，而CMS垃圾回收器在一些现代的Java应用中逐渐被淘汰

JVM 堆内存为什么要分新生代，老年代

Java虚拟机（JVM）将堆内存分为新生代和老年代的主要目的是为了提高垃圾回收的效率和减少垃圾回收的停顿时间。这种分代的设计是基于以下几个考虑：

对象的生命周期不同：在大多数Java应用中，对象的生命周期可以划分为短暂的和持久的两种类型。大部分对象在被创建之后很快就不再被引用，它们很快就会成为垃圾。因此，将这些短暂对象放在新生代，可以使得这部分对象的垃圾回收更加高效。
不同的垃圾回收算法：新生代和老年代通常采用不同的垃圾回收算法。新生代一般使用复制算法，因为大多数对象都是短暂的，可以很快地被回收。而老年代一般采用标记-清除或者标记-整理算法，因为老年代的对象生命周期长，采用复制算法会浪费空间。
避免全堆扫描：如果整个堆内存都使用同一种垃圾回收算法，那么在进行垃圾回收时，需要扫描整个堆内存。将堆内存分为新生代和老年代后，只需要在新生代中进行垃圾回收时扫描新生代，这样可以减少垃圾回收的开销。
针对不同的优化策略：由于新生代和老年代的特点不同，可以针对它们分别进行优化。例如，新生代可以采用更大的eden空间来减少对象晋升到老年代的次数，老年代可以采用更复杂的垃圾回收算法来提高垃圾回收的效率。

因此，通过将堆内存分为新生代和老年代，可以根据不同对象的特点采用不同的垃圾回收策略，从而提高垃圾回收的效率和性能。

hashmap的数据结构

HashMap是Java中常用的哈希表实现的一种数据结构，它基于键-值对存储数据，并提供了快速的查找、插入和删除操作。HashMap的内部数据结构主要包括数组和链表（或红黑树），它们的组合实现了高效的键值对存储和检索。

HashMap的主要数据结构可以简要描述如下：

数组（Bucket数组）： HashMap内部维护了一个数组，称为桶数组（或者叫数组表），用于存储键值对。数组的每个元素都是一个桶（Bucket），每个桶可以存储一个或多个键值对。
链表或红黑树：每个桶中存储的键值对通过链表或者红黑树来组织。当桶中的元素数量超过阈值（通常是8个），链表会转换成红黑树，这样可以提高查找、插入和删除操作的性能。
哈希函数： HashMap使用哈希函数来确定键值对在数组中的位置。哈希函数将键映射到数组的索引上，这样可以快速定位到键值对所在的桶。
负载因子： HashMap还维护了一个负载因子（Load Factor），用于衡量桶数组的填充程度。当桶数组中存储的键值对数量超过了负载因子乘以数组的长度时，会触发扩容操作，重新调整数组的大小，以保持其性能。

总的来说，HashMap通过哈希函数和数组结构来实现快速的键值对查找，通过链表或红黑树来处理冲突，同时通过负载因子来动态调整数组的大小，以提高性能和空间利用率。HashMap的时间复杂度为O(1)，在大多数情况下具有非常高的效率。

hashmap链表的优化

在HashMap中，当某个桶（Bucket）中的元素数量达到一定阈值时，就会发生链表转换为红黑树的操作，这是为了提高对该桶中元素的查找、插入和删除操作的效率。

转换过程可以简述如下：

链表转换为红黑树：当某个桶中的元素数量超过了一定阈值（通常为8个），且桶数组的长度超过64时，就会触发链表转换为红黑树的操作。此时，HashMap会将该桶中的元素重新组织为一棵红黑树，以提高查找、插入和删除的性能。
红黑树转换为链表：当红黑树中的元素数量减少到一定程度（通常为6个以下），就会触发红黑树转换为链表的操作。此时，HashMap会将红黑树重新转换为链表，以节省空间并减少冗余的平衡树结构带来的开销。

需要注意的是，从链表到红黑树的转换是为了提高性能，而从红黑树到链表的转换是为了节省空间。这样的转换策略可以根据元素数量动态调整数据结构，以达到性能和空间的平衡。

在Java 8之前，HashMap中使用的是纯粹的链表结构来解决哈希冲突，而在Java 8及之后的版本中，HashMap引入了红黑树来优化链表，提高了在哈希冲突较严重时的性能。这种改进使得HashMap在处理大量数据时能够更快地进行查找、插入和删除操作。

怎么才能让hashmap是线程安全的

要使HashMap线程安全，有几种方法可以考虑：

使用同步控制（Synchronization）：可以通过在对HashMap进行操作的方法前加上synchronized关键字来实现同步控制。例如：
```
Map<String, String> synchronizedMap = Collections.synchronizedMap(new HashMap<>());
```
使用并发容器（ConcurrentHashMap）： Java提供了ConcurrentHashMap，它是线程安全的哈希表实现，能够在多线程环境下提供更好的性能。ConcurrentHashMap采用了分段锁（Segment Locking）的方式来实现高效的并发访问。例如：
```
Map<String, String> concurrentHashMap = new ConcurrentHashMap<>();
```

使用读写锁（ReadWriteLock）：可以使用ReadWriteLock来实现对HashMap的读写分离，即在读操作时可以允许多个线程同时访问，而在写操作时只允许一个线程访问。这样可以提高读操作的并发性能。例如：

ReadWriteLock lock = new ReentrantReadWriteLock(); 
Map<String, String> map = new HashMap<>(); 
... 
lock.readLock().lock(); 
try { 
// Read operations 
} 
finally { 
lock.readLock().unlock(); 
} 
... 
lock.writeLock().lock(); 
try { 
// Write operations 
} 
finally { 
lock.writeLock().unlock(); 
}

使用第三方线程安全库：除了Java标准库提供的工具外，还可以使用一些第三方库，如Guava的MapMaker或Apache Commons Collections中的MultiMap，它们提供了线程安全的Map实现。

总的来说，要使HashMap线程安全，最好的方法是使用ConcurrentHashMap或其他线程安全的数据结构，因为它们已经经过了高度优化，并且在设计上考虑了并发访问的各种情况，能够提供更好的性能和线程安全性。

了解ConcurrentHashMap吗？为什么是线程安全的

ConcurrentHashMap是Java集合框架中的一个类，它是线程安全的哈希表实现。它在多线程环境下提供了高效的并发访问，并且相对于同步的HashMap来说，它能够提供更好的性能。ConcurrentHashMap的线程安全性来自于以下几个方面：

分段锁（Segment Locking）： ConcurrentHashMap内部采用了分段锁的机制，将整个哈希表分成多个Segment（段），每个Segment相当于一个小的HashTable，有自己的锁。在多线程环境下，不同的线程可以同时访问不同的Segment，从而减小了锁的粒度，提高了并发访问的效率。
读操作的无锁访问： ConcurrentHashMap允许多个线程同时进行读操作，读操作不会加锁，因此不会阻塞其他读操作，这样可以提高读操作的并发性能。只有在执行写操作时，才会对相应的Segment进行加锁。
CAS操作：在写操作时，ConcurrentHashMap内部使用了CAS（Compare and Swap）操作，而不是传统的锁机制。CAS操作是一种非阻塞的同步方式，在并发量较大时，相比传统的锁机制可以提高性能。
扩容机制： ConcurrentHashMap的扩容操作相对于普通的HashMap更加高效，它不会对整个表进行重建，而是只需要对部分Segment进行扩容。这样可以减小扩容的开销，降低了发生扩容时的并发冲突。

综上所述，ConcurrentHashMap通过分段锁、无锁读操作、CAS操作和高效的扩容机制等技术手段，实现了线程安全和高效的并发访问。这使得它成为了Java中多线程环境下常用的线程安全哈希表实现。

说一下CAS

CAS（Compare and Swap）是一种原子操作，通常用于并发编程中实现多线程之间的同步。它的原理是在执行更新操作之前，先比较内存中的某个值与预期的值是否相等，如果相等，则更新为新的值，否则不做任何操作。

CAS操作通常包含三个参数：内存地址、旧的预期值和新的值。它的执行过程如下：

读取内存中的值：首先，线程会读取内存中的值，这个值是需要进行比较的。
比较预期值：接着，线程将读取到的值与预期值进行比较。如果两者相等，则说明内存中的值与预期值相等，可以进行下一步操作；如果不相等，则说明内存中的值已经被其他线程修改过了，CAS操作失败，线程需要重新尝试。
更新内存中的值：如果预期值与内存中的值相等，则将内存中的值更新为新的值。更新过程是原子性的，即在更新过程中不会被其他线程干扰。
返回更新结果：CAS操作的返回值通常表示操作是否成功，成功则返回true，否则返回false。

CAS的实现依赖于底层硬件的原子性操作指令，例如x86架构的处理器提供了cmpxchg指令来实现CAS操作。在多线程编程中，CAS操作常用于实现无锁算法和并发数据结构，如ConcurrentHashMap、AtomicInteger等。

尽管CAS操作很强大，但也存在一些限制和问题，例如ABA问题和自旋次数过多等。因此，在使用CAS时需要仔细考虑各种情况，并且通常需要配合其他同步机制一起使用，以保证程序的正确性和性能。

ThreadLocal是什么

ThreadLocal是Java中一个线程局部变量工具类，它允许将变量绑定到当前线程，使得每个线程都拥有自己的变量副本。ThreadLocal提供了一种在多线程环境下保持变量的线程封闭性（Thread Confinement）的机制，即每个线程都可以独立地操作自己的变量，不会受到其他线程的影响。

ThreadLocal的主要作用是为每个线程提供一个独立的变量副本，使得线程之间的数据不共享，从而避免了线程安全问题。通常情况下，ThreadLocal对象会作为静态成员变量使用，以保证在整个应用程序生命周期内都能够访问到相同的ThreadLocal实例。

ThreadLocal的基本用法如下：

创建ThreadLocal对象：首先创建一个ThreadLocal对象，用于保存线程局部变量。
设置变量值：通过ThreadLocal对象的set方法，将变量的值与当前线程关联起来。
获取变量值：在需要访问变量的地方，通过ThreadLocal对象的get方法获取当前线程关联的变量值。
清除变量值：在线程结束或者不再需要使用变量时，需要调用ThreadLocal对象的remove方法清除当前线程关联的变量值，以避免内存泄漏。

ThreadLocal通常用于实现线程封闭性的需求，例如：

在Web应用中，可以使用ThreadLocal来存储用户身份信息，以确保每个请求的身份信息在整个请求处理过程中都是可用的，而且不会受到其他请求的影响。
在数据库连接池等资源管理场景中，可以使用ThreadLocal来维护每个线程的数据库连接，确保每个线程都使用自己的连接而不会产生资源竞争。

需要注意的是，虽然ThreadLocal可以解决线程安全问题，但过度地使用ThreadLocal也可能导致内存泄漏和上下文切换等问题，因此在使用ThreadLocal时需要谨慎考虑。

spring事务失效的原因

Spring事务失效可能由多种原因引起，以下是一些常见的情况：

未正确配置事务管理器：在Spring中，事务需要由事务管理器来进行管理。如果没有正确配置事务管理器或者使用了不支持事务的事务管理器，则事务将无法生效。
事务边界不正确：在Spring中，事务的边界通常是由@Transactional注解来指定的。如果该注解被放置在了错误的位置，或者没有被正确地应用到方法或类上，则事务可能无法生效。
未处理异常：默认情况下，Spring事务只有在遇到未捕获的RuntimeException时才会回滚。如果在事务方法中发生了受检异常，而该异常没有被正确处理或者没有被显式地标记为回滚异常（使用rollbackFor属性），则事务可能不会回滚。
1. 当在Spring事务管理中发生异常时，Spring默认情况下只有未捕获的RuntimeException（以及其子类）会触发事务回滚。这意味着如果一个受检异常（Checked Exception）在事务方法中抛出，且没有被捕获处理，那么事务将不会回滚，即使发生了异常，也会提交事务。
  
  这种默认行为的原因在于，受检异常通常被认为是可以被处理的异常，而不一定需要回滚事务。而RuntimeException通常被视为程序错误或者不可恢复的异常，需要回滚事务来保持数据一致性。
  
  因此，如果在事务方法中抛出了受检异常，并且没有被显式地处理或标记为回滚异常，那么Spring事务将会以默认的提交事务的方式进行处理，导致事务失效。
  
  解决这种情况的方法包括：
2. 将受检异常转换为RuntimeException抛出，以触发事务回滚。可以通过Spring的异常转换机制（如org.springframework.dao.DataAccessException）来实现。
3. 使用rollbackFor属性明确指定需要回滚的异常类型。例如：
```
@Transactional(rollbackFor = { IOException.class, SQLException.class })
```
非公开方法内部调用：如果在同一个类内部的一个公开方法内调用了另一个未标记为事务的非公开方法，则事务可能会失效。因为Spring事务默认只在公开的方法调用中生效。
跨越多个线程： Spring的声明式事务管理通常与线程绑定，如果在事务中跨越了多个线程（如使用异步方法或多线程调用），则事务可能会失效。
Spring AOP配置问题：如果AOP配置不正确，如切点表达式错误、通知拦截的目标方法不正确等，都有可能导致事务失效。
方法内部调用自身：在同一个类内部的方法调用自身（即递归调用），可能会绕过Spring的代理，导致事务失效。
嵌套事务配置问题：如果嵌套事务的配置不正确，如事务传播行为配置错误，可能会导致事务失效或者不符合预期的事务行为。

解决事务失效问题通常需要仔细检查和排查上述情况，并进行适当的调整和配置。同时，对于较为复杂的场景，可以通过日志调试或者开启Spring的调试模式来进一步排查问题。

synchronized的锁升级

在Java中，synchronized关键字的锁升级涉及到锁的优化过程，主要包括偏向锁、轻量级锁和重量级锁三种形式。

偏向锁（Biased Locking）：
- 当某个线程第一次访问同步代码块时，会尝试获取偏向锁。
- 如果没有其他线程竞争锁，获取偏向锁成功，标记为偏向锁，此后该线程再次进入同步代码块时无需再次获取锁，直接执行。
- 如果有其他线程竞争锁，偏向锁会升级为轻量级锁。
轻量级锁（Lightweight Locking）：
- 当偏向锁升级失败时，表示有其他线程竞争锁，此时偏向锁会升级为轻量级锁。
- 轻量级锁采用CAS操作来尝试获取锁，如果获取成功，则将锁标记为轻量级锁，并将当前线程ID记录到锁中。
- 如果CAS操作失败，表示有其他线程竞争锁，则会进一步升级为重量级锁。
重量级锁（Heavyweight Locking）：
- 当轻量级锁竞争失败时，表示有多个线程同时竞争锁，此时锁会升级为重量级锁。
- 重量级锁会导致线程阻塞，竞争失败的线程会进入阻塞状态，直到锁被释放。

锁升级的过程是为了在锁竞争情况下提高并发性能，尽可能减少锁的持有时间和线程阻塞时间。通过使用偏向锁、轻量级锁和重量级锁等不同形式的锁，Java虚拟机可以根据锁的竞争情况和使用情况来动态调整锁的状态，以提高锁的效率和性能。

mysql的乐观锁和悲观锁

MySQL中的乐观锁和悲观锁是两种不同的并发控制机制，用于处理多个线程同时访问共享数据的情况。它们的区别在于对数据的锁定方式和处理方式。

悲观锁（Pessimistic Locking）：
- 悲观锁认为在并发环境下，数据很可能会被其他事务修改，因此在访问数据之前会对数据进行加锁，以防止其他事务对数据的修改。
- 在MySQL中，常见的悲观锁实现方式包括使用SELECT ... FOR UPDATE语句或者使用LOCK TABLES语句来对数据进行锁定。
- 当一个事务获取了对某个数据的悲观锁之后，其他事务将无法对该数据进行修改，直到悲观锁被释放。
乐观锁（Optimistic Locking）：
- 乐观锁认为在大多数情况下，数据不会被其他事务修改，因此在访问数据时不会加锁，而是在更新数据时检查数据的版本信息（例如使用版本号或者时间戳）来判断数据是否被修改。
- 在MySQL中，常见的乐观锁实现方式包括使用版本号字段或者时间戳字段来进行乐观锁控制。
- 当一个事务更新数据时，会先读取数据的版本信息，并在更新时检查版本信息是否匹配，如果匹配则更新数据，否则认为数据已经被其他事务修改，需要进行相应的处理（如回滚或者重试）。

乐观锁和悲观锁各有其适用场景和特点：

悲观锁适用于并发更新频繁、数据竞争激烈的场景，但会增加系统的开销和数据库的锁定时间，可能导致性能下降。
乐观锁适用于并发更新较少、数据竞争不激烈的场景，可以减少数据库的锁定时间，提高系统的并发性能。但在高并发环境下，乐观锁可能会导致更新冲突，需要采取额外的措施来处理冲突。

mysql用的是什么数据结构

mysql的事务隔离级别

MySQL支持四种事务隔离级别，分别是读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。不同的隔离级别决定了事务在并发环境下对数据的可见性和一致性要求。

读未提交（Read Uncommitted）：
- 事务中的修改即使未提交，也可以被其他事务读取。
- 这是最低的隔离级别，可能会导致脏读（Dirty Read），即读取到其他事务未提交的数据。
读已提交（Read Committed）：
- 事务只能读取到已经提交的数据，可以防止脏读。
- 但是在同一个事务内，多次读取同一数据可能会读到不同的结果，因为其他事务可能已经提交了修改。
可重复读（Repeatable Read）：
- 在同一个事务中，多次读取同一数据将会得到相同的结果，即使其他事务对数据进行了修改。
- 可重复读隔离级别下，可以防止不可重复读（Non-Repeatable Read），但是可能会出现幻读（Phantom Read），即在同一事务内的两次查询中，第二次查询发现了新增或者删除的行。
串行化（Serializable）：
- 最高的隔离级别，确保事务的完全隔离，即串行执行所有事务。
- 串行化隔离级别下，可以防止幻读，但是会影响系统的并发性能。

MySQL默认的事务隔离级别是可重复读（Repeatable Read）。在实际应用中，可以根据业务需求和性能要求选择合适的隔离级别，以平衡数据一致性和并发性能。

spring的ioc

Spring的IOC（Inversion of Control，控制反转）是Spring框架的核心概念之一，它是一种设计原则，用于降低程序之间的耦合度，提高代码的灵活性和可维护性。IOC的实现主要依赖于依赖注入（Dependency Injection，DI）。

IOC的原理可以简单概括如下：

对象的创建和管理：在传统的编程模式中，对象的创建和管理通常由程序本身负责，即通过new关键字来创建对象，然后手动管理对象之间的依赖关系。而在IOC容器中，对象的创建和管理完全交由IOC容器来负责。
依赖注入： IOC容器通过依赖注入的方式来管理对象之间的依赖关系。依赖注入是指IOC容器在创建对象时，自动将对象所依赖的其他对象注入到它内部，从而实现对象之间的解耦。
配置元数据：在IOC容器中，对象的依赖关系通常通过配置元数据来描述，例如XML配置文件、Java注解或者Java配置类等。这些配置元数据告诉IOC容器如何创建对象以及对象之间的依赖关系。
控制反转： IOC容器通过控制反转的方式来管理对象，即将对象的创建和依赖注入的控制权从程序本身转移到IOC容器中。程序不再负责创建和管理对象，而是通过IOC容器来获取所需要的对象。

Spring框架中的IOC容器实现了以上原理，并提供了多种实现方式，包括XML配置、注解驱动和Java配置等。Spring的IOC容器负责管理应用中的所有Bean对象，以及它们之间的依赖关系。通过IOC容器，开发人员可以将应用程序中的各个组件解耦，使得代码更加灵活、可维护和可测试。

spring的依赖注入

依赖注入（Dependency Injection，DI）是一种设计模式，用于实现对象之间的解耦和松耦合，它的核心思想是将对象的依赖关系从代码中移除，由外部容器负责管理和注入依赖。

依赖注入的主要目的是降低代码的耦合度，提高代码的可维护性、可测试性和可扩展性。它使得对象之间的依赖关系更加清晰和灵活，同时也方便了代码的重用和组件的替换。

依赖注入可以通过以下几种方式来实现：

构造函数注入（Constructor Injection）：通过对象的构造函数来注入依赖。在创建对象时，将所需的依赖作为构造函数的参数传入，从而完成依赖注入。
Setter方法注入（Setter Injection）：通过对象的Setter方法来注入依赖。在对象创建之后，通过调用对象的Setter方法来设置所需的依赖，从而完成依赖注入。
接口注入（Interface Injection）：通过对象的接口方法来注入依赖。在对象创建之后，调用对象实现的接口方法来设置所需的依赖，从而完成依赖注入。

Spring框架是依赖注入的典型实现，它提供了强大的IOC容器来管理对象之间的依赖关系。在Spring中，可以使用XML配置、注解或者Java配置来描述对象之间的依赖关系，并通过IOC容器来实现依赖注入。Spring框架支持构造函数注入、Setter方法注入和接口注入等多种注入方式，开发人员可以根据需要选择合适的注入方式来实现依赖注入。

spring的aop

Spring的AOP（Aspect-Oriented Programming，面向切面编程）是一种编程范式，用于在不同模块间实现横切关注点的重用。AOP允许将应用程序的业务逻辑与横切关注点（如日志记录、性能监控、事务管理等）分离开来，从而提高代码的模块化、可维护性和复用性。

Spring的AOP主要由以下几个核心概念组成：

切面（Aspect）：切面是横切关注点的模块化实现，它包含了需要在目标对象的方法执行前、执行后或者执行过程中执行的逻辑。例如，日志切面可以在目标方法执行前记录日志，事务切面可以在目标方法执行前开启事务，在方法执行后提交事务。
连接点（Join Point）：连接点是在程序执行过程中能够插入切面的点。在Spring中，连接点通常代表目标对象的方法执行时机，例如方法执行前、执行后或者执行异常时。
通知（Advice）：通知是切面在连接点处执行的具体动作。在Spring中，通知包括前置通知（Before Advice）、后置通知（After Advice）、返回通知（After Returning Advice）、异常通知（After Throwing Advice）和环绕通知（Around Advice）等。
切点（Pointcut）：切点是用于定义连接点的表达式，用于指定切面在哪些连接点处执行。在Spring中，切点通常使用AspectJ切点表达式进行定义。
引入（Introduction）：引入是一种向现有类添加新方法或属性的功能。通过引入，切面可以向目标对象添加新的接口、方法或属性，从而扩展目标对象的功能。

Spring的AOP实现是基于动态代理和字节码增强技术的。在运行时，Spring通过动态代理或者字节码增强的方式将切面织入到目标对象的方法中，从而实现横切关注点的插入和执行。

通过Spring的AOP功能，开发人员可以在不修改原有代码的情况下，实现诸如日志记录、事务管理、安全检查等横切关注点的功能，并且可以通过切点表达式和通知类型等灵活配置和组合切面，以满足不同的业务需求。

spring的容器初始化过程

Spring容器的初始化过程主要包括以下几个关键步骤：

加载配置文件： Spring容器在启动时会加载配置文件，例如XML配置文件（如applicationContext.xml）、注解配置类或者Java配置类等。这些配置文件包含了Spring应用程序的相关配置信息，如Bean的定义、依赖关系、AOP配置等。
解析配置信息： Spring容器会解析加载的配置文件，将配置信息转换为内部的数据结构，如BeanDefinition对象。BeanDefinition对象描述了每个Bean的相关信息，包括类名、作用域、依赖关系、初始化方法、销毁方法等。
创建和注册BeanDefinition：在解析配置信息的过程中，Spring容器会根据配置信息创建对应的BeanDefinition对象，并将其注册到容器中。BeanDefinition对象注册到容器后，容器就知道了所有需要管理的Bean的信息。
实例化Bean： Spring容器根据注册的BeanDefinition对象信息，实例化Bean对象。根据Bean的作用域不同，容器可能会在启动时实例化所有的单例Bean，或者在需要时才动态地实例化原型Bean。
依赖注入：在实例化Bean之后，Spring容器会根据Bean之间的依赖关系，自动进行依赖注入。依赖注入通过构造函数注入、Setter方法注入或者接口注入等方式实现。
初始化Bean：容器在完成依赖注入之后，会调用Bean的初始化方法（如init-method指定的方法、@PostConstruct注解标注的方法等）对Bean进行初始化。初始化方法可以用于执行一些必要的操作，如资源加载、属性初始化、连接数据库等。
应用BeanPostProcessor：在Bean初始化之后，Spring容器会应用注册的BeanPostProcessor后置处理器，对Bean进行进一步处理。BeanPostProcessor可以在Bean初始化前后进行自定义的操作，如修改Bean的属性值、替换Bean对象等。
完成容器初始化：当所有Bean都实例化、依赖注入、初始化完成后，Spring容器的初始化过程就完成了。此时容器已经准备好接收请求，可以响应应用程序的调用。

以上是Spring容器初始化的主要步骤，容器初始化过程中会涉及到Bean的加载、解析、实例化、依赖注入、初始化和后置处理等操作，最终完成容器的初始化工作，使得Spring应用程序可以正常运行。

JDK动态代理和CGLIB动态代理的区别

JDK动态代理和CGLIB动态代理是两种常见的动态代理技术，它们在实现方式和应用场景上有一些区别。

基于实现接口 vs 继承父类：
- JDK动态代理要求目标对象必须实现至少一个接口，代理对象通过实现与目标对象相同的接口来对目标对象的方法进行代理。
- CGLIB动态代理则不要求目标对象实现接口，它通过继承目标对象的子类并重写其中的方法来实现代理。
性能差异：
- 通常情况下，JDK动态代理相对于CGLIB动态代理来说性能更好，因为它不需要生成额外的子类来实现代理，而是直接通过接口代理。
- CGLIB动态代理需要创建目标对象的子类，并在运行时通过方法拦截技术来进行代理，相比之下会有一定的性能开销。
代理方式：
- JDK动态代理通过反射机制来实现对接口方法的代理，代理对象实现了目标接口，并通过InvocationHandler来处理方法调用。
- CGLIB动态代理通过继承目标对象的子类，并重写其中的方法来实现代理，代理对象是目标对象的子类。
适用场景：
- JDK动态代理适用于那些已经有接口定义的情况，例如Spring AOP中对接口方法的代理。
- CGLIB动态代理适用于没有接口定义或者无法修改目标对象的情况，例如对于没有实现接口的类或者对于私有方法的代理。

综上所述，JDK动态代理和CGLIB动态代理各有其优劣，开发人员可以根据具体的应用场景和需求选择合适的动态代理技术。

怎么排查OOM

有没有做过JVM调优

有没有做过mysql的调优

线程的创建方式

线程池的7大参数

线程池的执行过程

线程池的拒绝策略有哪些

redis有哪些数据类型

redis缓存的淘汰策略

redis key的过期策略

redis的缓存雪崩缓存击穿缓存穿透

redis的跳表

跳表（Skip List）是一种有序数据结构，常用于实现有序集合或者有序映射等功能。Redis中的有序集合（Sorted Set）就是使用跳表来实现的。

跳表的主要特点是在普通链表的基础上增加了多级索引，通过这些索引可以加速查找元素的过程，从而提高了查找的效率。跳表的时间复杂度为O(log n)，与二分查找类似。

跳表的基本结构如下所示：

每个节点包含一个值和多个指向下一个节点的指针。
每一层都是一个有序的链表，最底层包含所有的元素，每一层的元素数量越来越少。
在每一层中，节点的指针跨越多个节点，这些跨度称为跳跃（skip）。

跳表的实现主要包括以下几个关键部分：

插入操作：在插入新元素时，需要按照一定的策略更新跳表的索引层，以确保索引的正确性和有序性。
删除操作：删除元素时，需要在跳表中定位并删除目标元素的节点，并更新索引层。
查找操作：查找元素时，通过跳表的索引层可以快速定位到目标元素的位置，然后在底层链表中进行顺序查找。

Redis中的有序集合（Sorted Set）就是使用跳表来实现的，它允许用户在集合中存储一组有序的元素，并且支持按照分数（score）来对元素进行排序。通过跳表的高效查找特性，Redis的有序集合能够快速地插入、删除和查找元素，同时保持元素的有序性。

redis的高可用怎么保证

主从复制、哨兵、集群

redis 哨兵的推举算法是什么

Redis哨兵（Redis Sentinel）是用于监控和管理Redis实例的进程，它可以自动进行故障检测、主从切换和配置管理等操作。在Redis Sentinel中，推举（Election）是指选择一个新的领导者（leader）来负责执行故障转移等操作的过程。

Redis Sentinel使用了一种基于投票的推举算法来选择新的领导者。其推举算法主要包括以下几个步骤：

选举触发：当主服务器（master）出现故障或者网络分区时，哨兵进程会触发一次选举过程，以选择一个新的领导者来负责执行故障转移操作。
候选者选择：在选举触发后，哨兵进程会从所有哨兵中选择一部分作为候选者（Candidate），候选者的数量通常是基于配置的。候选者可以是处于正常运行状态的哨兵进程。
投票阶段：每个候选者开始向其他哨兵发送投票请求，请求其他哨兵支持自己成为领导者。如果一个哨兵收到了超过半数的投票，则认为选举成功，并成为新的领导者。
投票结果处理：如果一个候选者收到了超过半数的投票，则成为新的领导者，并负责执行故障转移操作。其他哨兵在收到新领导者的通知后，更新自己的状态并开始监控新的主服务器。

通过这种基于投票的推举算法，Redis Sentinel能够保证在主服务器发生故障时快速地选择一个新的领导者来执行故障转移操作，从而确保系统的高可用性和稳定性。

mysql分库分表有哪些方式

MySQL的分库分表是指将一个大型的数据库按照一定规则划分成多个小型数据库或者表，以减轻单个数据库或表的负载，提高数据库的性能和扩展性。常见的分库分表方式包括：

垂直切分（Vertical Partitioning）：
- 垂直切分是指根据业务功能将不同的表拆分到不同的数据库中，每个数据库只包含一部分表。
- 垂直切分的优点是易于维护和扩展，但缺点是可能导致跨库查询和事务处理的复杂性增加。
水平切分（Horizontal Partitioning）：
- 水平切分是指将同一个表按照某种规则划分成多个子表，每个子表存储部分数据。
- 水平切分的方式包括范围分片、哈希分片和按照业务规则分片等。其中，哈希分片是常用的分片方式之一，通过对数据的哈希值取模来决定数据存放到哪个分片中。
- 水平切分的优点是可以有效减轻单个表的负载，并且可以实现水平扩展，但缺点是可能导致跨分片查询的性能下降。
分区表（Partitioned Table）：
- 分区表是MySQL提供的一种分表技术，可以将一个大表按照某种规则划分成多个子表，每个子表称为一个分区。
- MySQL支持的分区方式包括按照范围、列表、哈希和按照键值等方式进行分区。
- 分区表的优点是可以提高查询性能和管理灵活性，但缺点是可能会增加系统的复杂性和维护成本。
分布式数据库（Distributed Database）：
- 分布式数据库是指将数据分散存储在多个独立的数据库节点中，每个节点负责存储和处理部分数据。
- 分布式数据库通常通过数据库中间件或者分布式存储系统来实现，例如MySQL Cluster、Vitess、TiDB等。
- 分布式数据库的优点是可以实现高可用性和可扩展性，但缺点是需要考虑分布式事务和数据一致性等复杂问题。

以上是常见的MySQL分库分表方式，开发人员可以根据实际业务需求和性能要求选择合适的分库分表策略。

mysql执行计划主要看什么

如何保证rabbitmq的消息不丢失

RabbitMQ提供了多种方式来确保消息不丢失，其中包括持久化、发布确认、消费者确认、备份队列和高可用性集群等机制。下面是几种常见的保证消息不丢失的方式：

消息持久化： RabbitMQ允许将消息和队列设置为持久化，使得消息在服务器重启后仍然可以被恢复。要确保消息持久化，需要同时设置消息和队列的持久化属性。
发布确认：发布确认机制允许生产者确认消息已经成功发送到RabbitMQ服务器。通过确认机制，生产者可以在消息发布后立即得知消息是否已经安全地存储在RabbitMQ中，从而避免消息丢失的情况。
消费者确认：消费者确认机制允许消费者确认消息已经成功地被消费并处理。通过消费者确认，消费者可以在消息被成功处理后通知RabbitMQ服务器，从而确保消息不会被丢失。
备份队列： RabbitMQ提供了备份队列（Alternate Exchange）机制，可以将无法被路由到正常队列的消息发送到备份队列中。通过设置备份队列，可以避免消息因为找不到合适的路由而丢失。
高可用性集群： RabbitMQ支持构建高可用性集群，通过复制队列和消息到多个节点，确保即使某个节点发生故障，消息仍然可以被持久化和恢复。高可用性集群可以提供更高的可靠性和容错性，确保消息不丢失。

通过以上机制的组合使用，可以在一定程度上确保消息在传输、存储和处理过程中不会丢失。然而，即使采取了以上措施，仍然无法完全保证消息不会丢失，因此在设计消息系统时，仍然需要考虑消息丢失的可能性，并采取适当的措施来最小化风险。

如何保证rabbitmq 消息的幂等性

spring事务的传播机制

spring申明式事务注解的@Transactional的rollbackFor参数

知道springcloud的注册中心的用处和原理吗

Spring Cloud中的注册中心是微服务架构中的一个重要组件，用于管理和维护微服务的注册和发现。注册中心的主要作用和原理如下：

用途：
- 服务注册：微服务启动时，会将自己的网络地址和其他元数据注册到注册中心。
- 服务发现：微服务在运行时，可以通过注册中心查询其他服务的地址和元数据，以实现服务之间的通信和调用。
- 服务健康检查：注册中心可以定期检查各个微服务的健康状态，及时发现异常服务并进行处理。
原理：
- 注册：微服务启动时，会向注册中心发送注册请求，注册中心将微服务的信息保存在注册表中，包括服务名、网络地址、端口号、健康状态等。
- 发现：微服务在运行时，可以通过注册中心的查询接口查询其他服务的信息，根据服务名获取对应的网络地址和端口号，从而实现服务之间的通信和调用。
- 保持心跳：注册中心会定期向微服务发送心跳请求，微服务在收到心跳请求后会返回心跳响应，注册中心通过心跳响应判断微服务的健康状态，如果连续多次未收到心跳响应，则标记微服务为异常状态并进行处理。
- 服务实例管理：注册中心还负责管理各个服务的实例，包括增加、删除、更新等操作。当微服务启动或停止时，注册中心会及时更新注册表中的信息。

Spring Cloud提供了多种注册中心的实现，包括Netflix Eureka、Consul、Zookeeper等。其中，Netflix Eureka是Spring Cloud中最常用的注册中心，它基于CAP原则实现了高可用和分布式特性，能够很好地支持微服务架构的注册和发现功能。

知道ACP吗

分布式锁redisson怎么实现的

Redisson底层通过Redis的SETNX命令（在某些实现中可能是SET命令）来实现分布式锁的加锁操作，并使用DEL命令来实现解锁操作。同时，Redisson还支持更多的锁特性，如可重入锁、公平锁、红锁等，以满足不同场景下的需求。

分布式ID的解决策略

在分布式系统中生成唯一ID是一个常见的需求，通常需要考虑到以下几个方面的问题：全局唯一性、性能、可用性和可扩展性。下面是几种常见的分布式ID生成策略：

UUID：使用UUID（Universally Unique Identifier）作为唯一标识符。UUID是128位的全局唯一标识符，通常以字符串的形式表示。它的优点是简单易用，并且在本地生成不会产生冲突，但缺点是占用空间较大，且无序性可能对某些场景不适用。
Snowflake算法： Snowflake算法是Twitter开源的一种分布式ID生成算法，它生成的ID由64位组成，包含了时间戳、机器ID、数据中心ID和序列号等信息。Snowflake算法的优点是生成ID有序递增，并且性能较高，缺点是需要依赖时钟和机器ID等信息，可能存在单点故障和ID重复的风险。
数据库自增主键：可以使用数据库自增主键作为唯一ID。这种方式简单易用，并且保证了唯一性，但缺点是可能会成为系统的瓶颈，且需要维护数据库连接和事务管理。
Redis原子操作：可以利用Redis的原子操作来生成唯一ID。例如，使用Redis的INCR命令来生成自增ID，保证了唯一性和性能，但需要依赖于Redis的可用性和性能。
分布式ID生成服务：可以设计和部署一个专门的分布式ID生成服务，通过集群中的多个节点协作生成唯一ID。这种方式可以根据需求灵活调整ID的生成策略，但需要考虑分布式一致性和高可用性的问题。
雪花算法2.0：除了传统的Snowflake算法外，还有一些改进版的雪花算法，如Snowflake算法的2.0版本，针对时钟回拨等问题进行了改进，提高了ID的生成效率和稳定性。

选择合适的分布式ID生成策略需要根据具体的业务需求和系统架构来确定，通常需要综合考虑唯一性、性能、可用性和可扩展性等方面的因素。

怎么保证多线程情况下自增的订单编号不重复

在多线程情况下保证自增的订单编号不重复是一个常见的问题。有几种常见的解决方案：

数据库自增主键：数据库的自增主键（Auto Increment Primary Key）是最常用的生成唯一订单编号的方式之一。数据库自身会保证在多线程并发情况下，自增主键的值是唯一的。因此，将订单表的主键设计为自增主键，数据库会自动管理订单编号的唯一性，避免了并发问题。
分布式ID生成器：可以使用分布式ID生成器来生成唯一订单编号。这种方案通常会将ID生成器设计成分布式系统，通过多个节点协作生成全局唯一的订单编号，保证在多线程情况下的唯一性。常见的分布式ID生成器包括Snowflake算法、Twitter的分布式ID算法等。
分段锁定：可以将订单编号的生成划分为多个段，每个段的编号范围不重叠。然后在多线程情况下，对每个段进行加锁，确保每个段的订单编号是唯一递增的。这种方式可以减少锁的竞争，提高生成效率。
数据库乐观锁：在数据库中创建一个序列表，用来存储当前订单编号的值。每次生成订单编号时，先通过乐观锁的方式获取当前订单编号，并在获取的基础上递增，然后更新序列表的值。如果更新失败，说明订单编号已经被其他线程修改，需要重新尝试获取和递增。

以上几种方案各有优缺点，可以根据具体的业务需求和系统架构来选择合适的方案。最常用的方式是使用数据库自增主键或分布式ID生成器来生成订单编号，这两种方式都可以保证在多线程情况下的唯一性和高效性。

mysql两个update语句怎么保证顺序执行

在MySQL中，可以通过事务来保证多个UPDATE语句的顺序执行。在事务中执行多个UPDATE语句时，MySQL会根据事务的隔离级别（Isolation Level）来确定执行顺序。

在默认情况下，MySQL的隔离级别是REPEATABLE READ，这意味着在同一个事务中执行的多个UPDATE语句会按照它们在事务中出现的顺序执行，并且事务中的操作对其他事务不可见，直到事务提交。

例如，以下是一个使用事务执行两个UPDATE语句的示例：

START TRANSACTION;

UPDATE table_name SET column1 = value1 WHERE condition1;
UPDATE table_name SET column2 = value2 WHERE condition2;

COMMIT;

在这个示例中，两个UPDATE语句会依次执行，并且在事务提交之前，它们对数据库中的数据都不会产生影响。

需要注意的是，在某些情况下，MySQL的隔离级别可能会导致一些并发问题，如脏读、不可重复读和幻读等。因此，需要根据具体的业务需求和并发情况来选择合适的隔离级别，并且合理地设计事务的边界和范围，以确保数据的一致性和可靠性。

CV全干攻城狮

关注

39
点赞
踩
46

收藏

觉得还不错? 一键收藏
1
评论
我的Java面试实战

同一个接口，多次发出同一个请求，必须保证操作只执行一次。调用接口发生异常并且重复尝试时，总是会造成系统所无法承受的损失，所以必须阻止这种现象的发生。比如下面这些情况，如果没有实现接口幂等性会有很严重的后果：支付接口，重复支付会导致多次扣钱订单接口，同一个订单可能会多次创建。接口幂等性，一般是用在订单处理或者消费处理的场景的。使用接口幂等性是为了防止同一请求多次处理的状况。缓存击穿是指在高并发访问下，一个热点数据失效时，大量请求会直接绕过缓存，直接查询数据库，导致数据库压力剧增。
复制链接

扫一扫