1222面经

1，Kafka 如何保障顺序消耗?

Kafka 保障顺序消耗重要通过以下几个关键机制和配置来实现：
分区策略

• Kafka 将主题划分为多个分区，每个分区内的消息是天然有序的，其按照消息发送到分区的先后顺序进行存储和追加。
  
• 生产者在发送消息时，可以指定消息要发送到的分区。如果不指定，Kafka 会根据默认的分区策略进行分配。比方，按照轮询的方式将消息匀称分配到各个分区，以确保每个分区的负载相对均衡。
  

消耗者配置

• 单消耗者实例按分区顺序消耗：在消耗者端，一个消耗者实例可以同时订阅多个分区。当消耗者拉取消息时，会按照分区内的顺序依次获取消息进行消耗，从而保证了在单个分区内的消息顺序性。
  

1. import org.apache.kafka.clients.consumer.ConsumerConfig;
2. import org.apache.kafka.clients.consumer.ConsumerRecords;
3. import org.apache.kafka.clients.consumer.KafkaConsumer;
4. import java.util.Arrays;
5. import java.util.Properties;
7. public class KafkaConsumerExample {
8.     public static void main(String[] args) {
9.         Properties props = new Properties();
10.         props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
11.         props.put(ConsumerConfig.GROUP_ID_CONFIG, "test-group");
12.         props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
13.         props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
15.         KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
16.         consumer.subscribe(Arrays.asList("test-topic"));
18.         while (true) {
19.             ConsumerRecords<String, String> records = consumer.poll(100);
20.             for (var record : records) {
21.                 System.out.printf("Received message: key = %s, value = %s, partition = %d, offset = %d\n",
22.                         record.key(), record.value(), record.partition(), record.offset());
23.             }
24.         }
25.     }
26. }

复制代码

• 多消耗者实例的顺序协调：当一个消耗者组中有多个消耗者实例时，Kafka 会通过协调机制确保每个分区只会被组内的一个消耗者实例消耗，避免多个消耗者同时消耗同一个分区导致的顺序紊乱题目。
  

消息确认机制

• Kafka 采取的是基于偏移量（offset）的消息确认机制。消耗者在成功消耗一条消息后，会向 Kafka 提交该消息的偏移量，表现这条消息已经被正确处理。
  
• 只有当消耗者提交了偏移量，Kafka 才会认为该消息已经被成功消耗，并且后续不会再次将该消息发送给消耗者。这种机制确保了消息不会被重复消耗，同时也保证了消息消耗的顺序性。
  

幂等性和事件支持

• 幂等性：Kafka 生产者支持幂等性写入，即无论消息发送多少次，其在分区中的最终状态都是相同的。这对于保障消息顺序消耗非常告急，由于它避免了因消息重复发送而导致的顺序紊乱题目。
  
• 事件支持：Kafka 还提供了事件机制，允许生产者在一个事件中将多条消息发送到多个分区，并且保证这些消息要么全部成功提交，要么全部回滚。
  

2，秒杀场景，如何设计一个秒杀功能?

秒杀场景通常具有高并发、瞬时流量大等特点，设计一个秒杀功能必要从多个方面综合考虑，以下是一个较为全面的设计方案：
前端设计

• 静态资源优化：将秒杀页面的 HTML、CSS、JavaScript 等静态资源进行优化，如压缩、合并、缓存等，减少页面加载时间，提高用户体验。
  
• 防刷机制：在前端通过验证码、滑块验证等方式，增加机器人刷请求的难度，肯定程度上过滤掉非法请求。
  

后端设计

• 库存管理
  
  
  
  • 预扣库存：当用户发起秒杀请求时，先在缓存中预扣库存，而不是直接操纵数据库。如允许以快速响应请求，减少数据库的压力。
    
  • 库存扣减：采取乐观锁或灰心锁来保证库存扣减的原子性和同等性。比方，使用乐观锁时，在更新库存时判断当前库存是否大于即是预扣的数量，如果是则扣减库存，否则回滚事件并返回库存不敷的提示。
    
  
  

1. public class SeckillServiceImpl implements SeckillService {
3.     @Autowired
4.     private RedisTemplate<String, Object> redisTemplate;
6.     @Autowired
7.     private SeckillMapper seckillMapper;
9.     @Override
10.     @Transactional
11.     public boolean seckill(Long seckillId, Long userId) {
12.         // 从缓存中获取库存
13.         String stockKey = "seckill:stock:" + seckillId;
14.         Integer stock = (Integer) redisTemplate.opsForValue().get(stockKey);
15.         if (stock == null || stock <= 0) {
16.             return false;
17.         }
18.         // 预扣库存，在缓存中减1
19.         redisTemplate.opsForValue().decrement(stockKey);
20.         try {
21.             // 扣减数据库库存
22.             int result = seckillMapper.reduceStockByOptimisticLock(seckillId);
23.             if (result > 0) {
24.                 // 生成订单等后续操作
25.                 createOrder(seckillId, userId);
26.                 return true;
27.             } else {
28.                 // 库存扣减失败，回滚缓存中的预扣库存
29.                 redisTemplate.opsForValue().increment(stockKey);
30.                 return false;
31.             }
32.         } catch (Exception e) {
33.             // 发生异常，回滚缓存中的预扣库存
34.             redisTemplate.opsForValue().increment(stockKey);
35.             throw new RuntimeException("秒杀失败", e);
36.         }
37.     }
38. }

复制代码

• 请求限流
  
  
  
  • 令牌桶算法：使用令牌桶算法来限定进入秒杀系统的请求流量。系统按照肯定的速率生成令牌放入令牌桶中，每个请求必要获取一个令牌才气继续处理，适时牌桶中没有令牌时，请求将被拒绝。
    
  • 漏桶算法：漏桶算法也可用于请求限流，请求以恣意速率进入漏桶，漏桶以固定的速率将请求流出进行处理，当漏桶满时，新的请求将被抛弃。
    
  
  
• 异步处理
  
  
  
  • 消息队列：将秒杀成功的订单生成等后续操纵放入消息队列中异步处理，如允许以快速响应前端请求，提高系统的并发处理本事。
    
  • 定时任务：对于一些必要定时执行的任务，如库存补充、订单状态更新等，可以使用定时任务来完成，避免对秒杀主流程的影响。
    
  
  
• 分布式事件：在秒杀过程中，如果涉及到多个数据库操纵或跨系统调用，必要使用分布式事件来保证数据的同等性。可以采取 Seata 等分布式事件框架来实现。
  

数据存储设计

• 数据库设计：设计合理的数据库表结构，如秒杀商品表、订单表、用户表等，确保数据的完整性和同等性。
  
• 缓存设计：使用 Redis 等缓存数据库来存储热门商品信息、库存信息等，提高数据的读写速度。
  

高可用设计

• 集群部署：采取集群部署的方式，将秒杀系统部署在多个服务器上，通过负载均衡器将请求分发到差别的服务器上，提高系统的可用性和并发处理本事。
  
• 容灾备份：定期对数据库和缓存进行备份，当出现故障时可以或许快速恢复数据，减少损失。
  

3，Redis 长期化机制是什么?

Redis 提供了两种长期化机制，即 RDB（Redis Database）长期化和 AOF（Append Only File）长期化，它们可以将内存中的数据生存到磁盘上，以防止数据丢失，以下是具体介绍：
RDB 长期化

• 原理：RDB 长期化是通过对 Redis 中的数据进行定期的快照来实现的。在指定的时间间隔内，Redis 会将内存中的数据集快照写入到磁盘上的一个 RDB 文件中。这个过程是通过 fork 一个子进程来完成的，子进程负责将内存中的数据以二进制的形式写入到临时文件，然后更换原有的 RDB 文件，从而实现数据的长期化。
  
• 长处
  
  
  
  • 高效：RDB 文件是一个经过压缩的二进制文件，存储效率高，恢复数据时速度也非常快。
    
  • 适合备份：由于是对整个数据集的快照，因此非常适合用于数据备份和劫难恢复场景。
    
  
  
• 缺点
  
  
  
  • 数据丢失风险：如果在两次快照之间 Redis 发生故障，那么这期间的数据将会丢失。
    
  • 占用内存：在进行快照时，必要 fork 子进程，会占用肯定的内存空间，大概会对性能产生肯定的影响。
    
  
  

AOF 长期化

• 原理：AOF 长期化以日记的形式记录 Redis 服务器所执行的全部写命令，将这些命令追加到一个 AOF 文件的末尾。当 Redis 必要恢复数据时，会重新执行 AOF 文件中的全部写命令，从而将数据恢复到内存中。
  
• 长处
  
  
  
  • 数据安全性高：由于是记录每一条写命令，因此数据的完整性和同等性更好，丢失数据的风险相对较小。
    
  • 实时性好：可以通过配置将 AOF 文件的同步策略设置为每执行一条写命令就同步到磁盘，从而实现数据的实时长期化。
    
  
  
• 缺点
  
  
  
  • 文件体积大：随着时间的推移，AOF 文件会变得越来越大，必要定期进行重写来压缩文件体积。
    
  • 恢复速度慢：在恢复数据时，必要重新执行 AOF 文件中的全部写命令，因此恢复速度相对较慢。
    
  
  

混淆长期化

• 原理：混淆长期化结合了 RDB 和 AOF 两种长期化方式的长处。在开启混淆长期化后，Redis 会以 RDB 的方式进行数据快照，同时将从上次 RDB 快照之后到当前时刻的全部写命令以 AOF 的方式追加到文件中。
  
• 长处
  
  
  
  • 兼顾效率与安全：在数据恢复时，首先加载 RDB 文件，然后再重放 AOF 文件中的增量写命令，如许既可以快速恢复大部门数据，又可以保证数据的完整性。
    
  • 减小 AOF 文件体积：相比单纯的 AOF 长期化，混淆长期化可以有用减小 AOF 文件的体积，提高了文件的读写效率。
    
  
  

4，解决 Redis 热点 Key 题目标方法有哪些?

Redis 热点 Key 是指在 Redis 中，某些特定的 Key 在一段时间内被大量的请求频繁访问，导致该 Key 地点的 Redis 节点负载过高，大概会影响整个系统的性能和稳固性。以下是一些解决 Redis 热点 Key 题目标方法：
优化 Key 的设计

• 分散热点：将热点数据分散到多个差别的 Key 中，避免全部请求都集中在一个 Key 上。比方，对于一个热门商品的库存 Key，可以按照肯定的规则将其拆分为多个子 Key，如 “product:stock:1”“product:stock:2” 等，差别的请求可以访问差别的子 Key。
  
• 添加前缀或后缀：在 Key 的命名上添加一些随机的前缀或后缀，使得请求可以或许匀称地分布在差别的 Key 上。比如，对于用户的订单 Key，可以在订单号的底子上添加一个随机的字符串作为前缀，如 “order_abc123_123456”。
  

本地缓存

• 客户端缓存：在应用程序的客户端本地缓存热点 Key 的数据，当客户端再次必要访问该热点 Key 时，首先从本地缓存中获取数据，如果本地缓存中有，则直接返回，无需再向 Redis 发送请求。
  
• 应用层缓存：在应用层中增加一层缓存，如使用 Guava Cache 等本地缓存框架，将热点 Key 的数据缓存到应用层。当有请求访问热点 Key 时，先从应用层缓存中获取数据，命中则直接返回，未命中再去 Redis 中获取，并将获取到的数据放入应用层缓存中。
  

分布式缓存

• 同等性哈希算法：采取同等性哈希算法来分配热点 Key 到差别的 Redis 节点上，使得热点 Key 可以或许匀称地分布在多个节点上，避免单个节点负载过高。
  
• Redis 集群：使用 Redis 集群来分散热点 Key 的访问压力。Redis 集群将数据分散存储在多个节点上，当有热点 Key 的访问请求时，集群会根据 Key 的哈希值将请求路由到对应的节点上，从而实现负载均衡。
  

限流与降级

• 请求限流：在应用程序的入口处对访问热点 Key 的请求进行限流，限定单元时间内的请求数量，避免过多的请求涌向 Redis。可以使用令牌桶算法或漏桶算法等限流算法来实现。
  
• 服务降级：当 Redis 的热点 Key 出现性能题目时，对一些非焦点的业务功能进行降级处理，减少对热点 Key 的访问。比方，对于一些保举系统中的热点商品保举，可以暂时降低保举的精度或减少保举的数量，以减轻 Redis 的压力。
  

数据预热

• 提前加载热点数据：在系统启动或业务低峰期，提前将热点数据加载到 Redis 中，并进行预热，使得热点数据在被大量请求访问之前就已经在 Redis 中处于热状态，提高访问速度。
  
• 动态更新热点数据：根据业务的实际环境，动态地更新热点数据的缓存时间和内容。比方，对于一些实时性要求较高的热点新闻，可以每隔一段时间就更新一次缓存中的新闻内容，确保用户获取到的是最新的热点数据。
  

5，MySQL 主从复制是如何实现的?

MySQL 主从复制是指将一台 MySQL 服务器（主服务器）的数据复制到一台或多台其他 MySQL 服务器（从服务器）的过程，着实现重要涉及以下三个步调：
主服务器配置

• 开启二进制日记：在主服务器的my.cnf配置文件中，必要确保log-bin参数已开启，该参数用于指定二进制日记文件的路径和名称前缀。比方：log-bin=mysql-bin，这将使得主服务器在执行写操纵时，会将这些操纵以二进制的形式记录到二进制日记文件中。
  
• 设置服务器唯一 ID：为了在复制架构中唯一标识每台服务器，必要为每台服务器设置差别的server-id。在主服务器的my.cnf配置文件中，设置server-id=1，这里的1只是一个示例，通常可以根据实际环境进行设置，但必须保证整个复制集群中server-id的唯一性。
  

从服务器配置

• 配置毗连主服务器信息：在从服务器的my.cnf配置文件中，必要指定要毗连的主服务器的相关信息，包括主服务器的 IP 地点、端标语、用于复制的用户账号和暗码等。比方：
  

1. server-id=2
2. relay-log=mysql-relay-bin
3. read-only=1
4. log-slave-updates=1

复制代码

其中，server-id设置为与主服务器差别的值，relay-log指定了中继日记文件的名称，read-only=1表现从服务器默认只提供读操纵，log-slave-updates=1表现从服务器在执行中继日记中的 SQL 语句时也会将其记录到本身的二进制日记中。

• 启动复制线程：在从服务器上执行CHANGE MASTER TO语句来配置与主服务器的毗连信息，如CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_PORT=3306, MASTER_USER='repl_user', MASTER_PASSWORD='repl_password';，其中master_ip是主服务器的 IP 地点，repl_user和repl_password是在主服务器上创建的用于复制的用户账号和暗码。配置完成后，在从服务器上执行START SLAVE语句启动复制线程，从服务器会毗连到主服务器并开始等待吸收主服务器发送的二进制日记事件。
  

复制过程

• 二进制日记转储线程（Binlog Dump Thread）：在主服务器上，当有数据修改操纵发生时，会将这些操纵记录到二进制日记中。同时，主服务器会启动一个二进制日记转储线程，该线程负责将二进制日记中的事件发送给从服务器。它会根据从服务器的请求，将二进制日记中的事件按照顺序依次发送给从服务器。
  
• I/O 线程（I/O Thread）：在从服务器上，I/O 线程负责毗连主服务器，并吸收主服务器发送的二进制日记事件。它会将吸收到的二进制日记事件写入到从服务器的中继日记（Relay Log）中。中继日记是从服务器上用于临时存储主服务器二进制日记事件的文件，其格式与二进制日记类似。
  
• SQL 线程（SQL Thread）：从服务器上的 SQL 线程会从中继日记中读取事件，并将这些事件在从服务器上执行，从而实现数据的复制。SQL 线程会按照中继日记中事件的顺序依次执行，确保数据的同等性。
  

6，MySQL InnoDB 和 MyISAM 的区别是什么?

MySQL 中的 InnoDB 和 MyISAM 是两种常用的存储引擎，它们在事件支持、锁机制、并发性能等多个方面存在区别，以下是详细介绍：
事件支持

• InnoDB：支持事件处理，具有事件的四大特性 ACID（原子性、同等性、隔离性、长期性）。通过事件日记和回滚段等机制来保证事件的正确执行和数据的同等性，实用于对数据完整性和同等性要求较高的应用场景，如银行转账、电商订单处理等。
  
• MyISAM：不支持事件，在执行写操纵时，如果发生错误或非常，大概会导致数据不同等。对于一些简单的、对事件要求不高的应用场景，如数据仓库、日记记录等，可以使用 MyISAM 存储引擎。
  

锁机制

• InnoDB：支持行级锁和表级锁，默认使用行级锁。行级锁可以在并发操纵时，只锁定必要修改的行，提高并发性能。在事件处理过程中，会根据事件的隔离级别和操纵的范例主动选择符合的锁范例。
  
• MyISAM：只支持表级锁，在对表进行写操纵时，会锁定整个表，导致其他并发的读写操纵都必要等待锁的释放。因此，在高并发环境下，MyISAM 的并发性能相对较差。
  

并发性能

• InnoDB：由于支持行级锁，在高并发环境下，多个事件可以同时对差别的行进行操纵，并发性能较好。同时，InnoDB 还支持多版本并发控制（MVCC），可以在不加锁的环境下，实现对数据的并发读取，进一步提高并发性能。
  
• MyISAM：在并发写入时，由于表级锁的限定，只能串行执行，并发性能较差。但在并发读取时，MyISAM 的性能相对较好，由于它不必要像 InnoDB 那样处理复杂的事件和锁机制。
  

存储结构

• InnoDB：数据和索引存储在同一个文件中，即表空间文件（.ibd 文件）。表空间可以由多个文件组成，支持主动扩展。InnoDB 还会将数据存储在内存中的缓冲池（Buffer Pool）中，以提高数据的读写速度。
  
• MyISAM：数据和索引分别存储在差别的文件中，数据文件的扩展名为.MYD，索引文件的扩展名为.MYI。在读取数据时，必要分别从数据文件和索引文件中获取信息，相对来说效率较低。
  

外键支持

• InnoDB：支持外键束缚，通过外键可以建立表与表之间的关联关系，保证数据的完整性和同等性。在进行数据插入、更新和删除操纵时，会主动查抄外键束缚，避免出现数据不同等的环境。
  
• MyISAM：不支持外键束缚，必要在应用程序中通过代码来实现表与表之间的关联关系和数据同等性查抄。
  

缓存机制

• InnoDB：使用缓冲池（Buffer Pool）来缓存数据和索引，提高数据的读写效率。缓冲池中的数据会根据肯定的算法进行镌汰和更新，以保证缓存的命中率。
  
• MyISAM：只缓存索引文件，不缓存数据文件。在读取数据时，如果数据不在缓存中，必要从磁盘中读取，相对来说效率较低。
  

数据恢复

• InnoDB：在发生故障时，可以通过事件日记和备份文件进行数据恢复。事件日记记录了全部的事件操纵，通过重放事件日记，可以将数据库恢复到故障前的状态。
  
• MyISAM：在发生故障时，只能通过备份文件进行恢复。如果没有及时备份，大概会导致数据丢失。
  

7，MySQL 中的 MVCC 是什么?

MVCC 即多版本并发控制（Multi-Version Concurrency Control），是 MySQL 中 InnoDB 存储引擎实现并发控制的一种告急机制，以下是其详细介绍：
根本原理

• MVCC 通过为每行数据维护多个版本来实现并发控制，在事件执行过程中，每个事件看到的都是数据的某个特定版本，而不是最新的版本。如允许以在不加锁的环境下，实现多个事件对同一行数据的并发读取，提高并发性能。
  
• 当一个事件对某行数据进行修改时，InnoDB 会为该行数据创建一个新的版本，并将旧版本保留在系统中。其他事件在读取该行数据时，可以根据本身的事件时间戳或其他条件，选择读取符合的版本，而不会受到当前正在进行的修改操纵的影响。
  

实现机制

• 事件版本号：每个事件在开始时都会被分配一个唯一的事件版本号，这个版本号随着事件的执行而递增。事件版本号用于标识事件的先后顺序和确定事件可以或许看到的数据版本。
  
• 隐蔽列：InnoDB 在每行数据中都添加了一些隐蔽列，用于存储数据的版本信息。这些隐蔽列包括创建版本号（DB_TRX_ID）和删除版本号（DB_ROLLBACK_SEGMENT_ID）。创建版本号记录了该行数据被创建时的事件版本号，删除版本号记录了该行数据被删除时的事件版本号。
  
• 版本链：对于每一行数据，InnoDB 会根据其修改历史形成一个版本链。版本链中的每个节点都对应着该行数据的一个版本，节点之间通过指针相连。当一个事件对该行数据进行修改时，会在版本链的头部插入一个新的版本节点。
  
• ReadView：ReadView 是 MVCC 的焦点概念之一，它是一个事件在某个时刻对数据库的一个视图。ReadView 中包含了一些告急的信息，如创建该 ReadView 的事件版本号、当前系统中活泼的事件列表等。当一个事件进行读取操纵时，会根据本身的 ReadView 来判断应该读取哪个版本的数据。
  

工作过程

• 数据读取：当一个事件进行读取操纵时，InnoDB 会首先根据该事件的 ReadView 来确定可以或许看到的数据版本。如果数据的创建版本号小于或即是该事件的版本号，并且删除版本号大于该事件的版本号或为空，则该事件可以读取该数据版本。
  
• 数据修改：当一个事件对某行数据进行修改时，InnoDB 会为该行数据创建一个新的版本，并将旧版本保留在系统中。新的版本会记录当前事件的版本号作为创建版本号，同时将旧版本的删除版本号设置为当前事件的版本号。
  
• 事件提交与回滚：当事件提交时，其对数据的修改会正式见效，其他事件在后续的读取操纵中大概会看到新的版本。如果事件回滚，InnoDB 会根据版本链将数据恢复到事件开始前的状态。
  

优势

• 提高并发性能：MVCC 允许多个事件同时对同一行数据进行并发读取，而不必要加锁，大大提高了数据库的并发性能。
  
• 保证数据同等性：通过为每个事件提供一个同等的数据库视图，MVCC 可以保证事件在执行过程中看到的数据是同等的，即使在并发操纵的环境下也不会出现数据不同等的环境。
  
• 减少锁冲突：由于不必要对数据进行加锁，MVCC 可以减少锁冲突的发生，提高系统的稳固性和可扩展性。
  

8，什么是 Java 中的双亲委派模子?

双亲委派模子是 Java 中类加载器的一种工作机制，以下是关于它的详细介绍：
工作原理

• 当一个类加载器收到类加载请求时，它首先不会本身去尝试加载这个类，而是把这个请求委派给父类加载器去完成。
  
• 只有当父类加载器在其搜刮范围内无法找到所需的类时，子类加载器才会尝试本身去加载。
  

类加载器层次结构

• Bootstrap ClassLoader：它是 Java 类加载层次结构中的顶层类加载器，重要负责加载 Java 焦点库，如java.lang、java.util等包中的类。它是用 C++ 实现的，是 JVM 的一部门，在 Java 中无法直接获取到它的实例。
  
• Extension ClassLoader：它的父类加载器是 Bootstrap ClassLoader，重要负责加载 Java 的扩展库，即位于JRE/lib/ext目录下的类库，或者通过java.ext.dirs系统属性指定的目录下的类库。
  
• Application ClassLoader：它的父类加载器是 Extension ClassLoader，也称为系统类加载器，是 Java 应用程序中默认的类加载器，负责加载应用程序的类路径（classpath）下的全部类。
  

实现代码示例

以下是在 Java 中模拟双亲委派模子的部门代码示例：

1. public class ClassLoaderTest {
2.     public static void main(String[] args) {
3.         // 获取系统类加载器
4.         ClassLoader applicationClassLoader = ClassLoader.getSystemClassLoader();
5.         // 获取扩展类加载器
6.         ClassLoader extensionClassLoader = applicationClassLoader.getParent();
7.         // 获取引导类加载器
8.         ClassLoader bootstrapClassLoader = extensionClassLoader.getParent();
10.         try {
11.             // 使用系统类加载器加载类
12.             Class<?> clazz1 = applicationClassLoader.loadClass("java.lang.String");
13.             System.out.println(clazz1.getClassLoader());
15.             // 使用扩展类加载器加载类
16.             Class<?> clazz2 = extensionClassLoader.loadClass("javax.swing.JButton");
17.             System.out.println(clazz2.getClassLoader());
19.             // 使用自定义类加载器加载类
20.             ClassLoader customClassLoader = new CustomClassLoader();
21.             Class<?> clazz3 = customClassLoader.loadClass("com.example.MyClass");
22.             System.out.println(clazz3.getClassLoader());
23.         } catch (ClassNotFoundException e) {
24.             e.printStackTrace();
25.         }
26.     }
27. }
29. class CustomClassLoader extends ClassLoader {
30.     @Override
31.     public Class<?> loadClass(String name) throws ClassNotFoundException {
32.         if (!name.startsWith("com.example")) {
33.             return super.loadClass(name);
34.         }
35.         try {
36.             // 自定义类加载逻辑
37.             String fileName = name.substring(name.lastIndexOf('.') + 1) + ".class";
38.             InputStream is = getClass().getResourceAsStream(fileName);
39.             if (is == null) {
40.                 return super.loadClass(name);
41.             }
42.             byte[] b = new byte[is.available()];
43.             is.read(b);
44.             return defineClass(name, b, 0, b.length);
45.         } catch (IOException e) {
46.             throw new ClassNotFoundException(name);
47.         }
48.     }
49. }

复制代码

优势

• 避免类的重复加载：确保了 Java 焦点库中的类在整个系统中只有一份，避免了差别类加载器重复加载相同类大概导致的冲突和紊乱。
  
• 保证类的安全性：防止恶意代码自定义一个与 Java 焦点库中同名的类来破坏系统的稳固性，由于焦点库的类总是由 Bootstrap ClassLoader 加载，而自定义类加载器无法覆盖它。
  
• 实现类的隔离性：差别的类加载器可以加载相同名称的类，这些类在差别的类加载器命名空间中是相互隔离的，这在一些复杂的应用场景中，如插件化开发、容器化部署等非常有用。
  

9，synchronized 和 lock 有什么区别?

在 Java 中，synchronized和Lock都可用于实现多线程同步，但在使用方式、功能特性等方面存在一些区别，以下是详细介绍：
用法与语法

• synchronized：它是 Java 中的关键字，可用于修饰方法或代码块。修饰方法时，在方法声明中加上synchronized关键字，如public synchronized void method()，表现该方法是同步方法，同一时刻只有一个线程可以访问该方法。修饰代码块时，使用synchronized(this)或synchronized(obj)的形式，其中this表现当前对象，obj表现指定的对象，在该代码块执行期间，其他线程无法访问被同步的资源。
  
• Lock：它是一个接口，位于java.util.concurrent.locks包中，常用的实现类是ReentrantLock。使用Lock时，必要先通过Lock接口的实现类创建一个锁对象，如Lock lock = new ReentrantLock();，然后在必要同步的代码块前调用lock.lock()方法获取锁，在代码块执行完毕后调用lock.unlock()方法释放锁。
  

功能特性

• 锁的获取与释放
  
  
  
  • synchronized：由 Java 虚拟机主动获取和释放锁，当线程执行完同步方法或代码块时，锁会主动释放，无需手动干预。
    
  • Lock：必要手动调用lock()方法获取锁，unlock()方法释放锁，如果忘记释放锁，大概会导致死锁等题目，以是通常在finally块中释放锁，以确保锁肯定会被释放。
    
  
  
• 锁的可重入性
  
  
  
  • synchronized：具有隐式的可重入性，即同一个线程在已经获取了某个对象的锁的环境下，可以再次进入该对象的同步方法或代码块，不会发存亡锁。
    
  • Lock：通过ReentrantLock等实现类实现可重入性，在构造ReentrantLock对象时，可以传入一个布尔值参数来指定是否为公平锁，默认是非公平锁。
    
  
  
• 锁的公平性
  
  
  
  • synchronized：是非公平锁，即线程获取锁的顺序是不确定的，大概会导致某些线程长时间等待。
    
  • Lock：可以通过构造函数指定是否为公平锁，公平锁按照线程请求锁的顺序来分配锁，避免了线程饥饿题目，但公平锁的性能通常会比非公平锁略低。
    
  
  
• 锁的等待与叫醒机制
  
  
  
  • synchronized：使用Object类的wait()、notify()和notifyAll()方法来实现线程的等待与叫醒，这些方法必须在同步代码块或同步方法中使用，且必须通过获取到锁的对象来调用。
    
  • Lock：通过Condition接口的await()、signal()和signalAll()方法来实现线程的等待与叫醒，Condition对象可以通过Lock对象的newCondition()方法获取。
    
  
  

性能差异

• 在低竞争场景下，synchronized的性能与Lock相称，乃至大概更好，由于synchronized是 Java 内置的同步机制，由虚拟机进行了优化。
  
• 在高竞争场景下，Lock的性能通常优于synchronized，尤其是使用非公平锁时，Lock可以提供更好的并发性能，由于它可以更灵活地控制锁的获取和释放，减少线程的等待时间。
  

使用场景

• synchronized：实用于简单的同步场景，如对共享资源的单次访问进行同步，或者对整个方法进行同步。如果不必要复杂的锁控制和等待叫醒机制，使用synchronized更加简便方便。
  
• Lock：实用于复杂的同步场景，如必要手动控制锁的获取和释放、实现公平锁、多个条件变量的等待与叫醒等。在高并发场景下，如果对性能有较高要求，也可以考虑使用Lock。
  

10，什么是指令重排序，如何解决?

指令重排序是指在程序执行过程中，编译器和处理器为了优化程序性能，对指令执行的顺序进行重新排列的一种现象。以下是关于指令重排序的详细介绍以及解决方法：
产生缘故原由

• 编译器优化：在不改变程序语义的前提下，编译器会对代码进行优化，调整指令的执行顺序，以提高程序的运行速度和效率。
  
• 处理器乱序执行：现代处理器为了充实利用硬件资源，采取了乱序执行技能，允许指令在不影响程序最终结果的环境下，按照肯定的规则进行乱序执行。
  

大概导致的题目

• 多线程并发题目：在多线程环境下，指令重排序大概会导致程序的执行结果与预期不符，出现数据竞争、线程安全等题目。比方，在一个线程中对共享变量进行写操纵，另一个线程中对该共享变量进行读操纵，如果写操纵的指令被重排序到读操纵之后，就大概导致读操纵读取到错误的值。
  

解决方法

• 使用 volatile 关键字：当一个变量被声明为volatile时，编译器和处理器会对该变量的访问进行特殊处理，确保对该变量的读写操纵不会被重排序。在多线程环境下，如果一个共享变量被多个线程访问，并且其中至少有一个线程对该变量进行写操纵，那么可以将该变量声明为volatile，以保证变量的可见性和有序性。
  
• 使用锁机制：通过使用synchronized关键字或Lock接口来实现锁机制，可以保证在同一时刻只有一个线程可以或许访问被锁定的代码块或方法，从而避免指令重排序导致的题目。在使用锁机制时，必要确保在对共享变量进行读写操纵时，始终持有锁，以保证操纵的原子性和有序性。
  
• 使用原子类：Java 提供了一系列的原子类，如AtomicInteger、AtomicLong等，这些原子类在内部使用了CAS（比较并交换）算法来实现原子操纵，并且保证了操纵的可见性和有序性。在多线程环境下，如果必要对共享变量进行原子操纵，可以使用原子类来取代普通的变量，以避免指令重排序导致的题目。
  
• 使用内存屏蔽：内存屏蔽是一种特殊的指令，它可以制止编译器和处理器对指令进行重排序。在 Java 中，可以通过Unsafe类来使用内存屏蔽，但是Unsafe类是一个底层的、不安全的类，不发起直接使用。不外，一些框架和库会在内部使用内存屏蔽来解决指令重排序的题目，比方Disruptor框架。
  

11，Spring loC 和 AOP 是什么?

Spring 是一个开源的 Java 应用程序框架，在企业级 Java 开发中广泛使用。其焦点特性包括控制反转（IoC）和面向切面编程（AOP），以下是对它们的详细介绍：
Spring IoC（Inversion of Control，控制反转）

• 概念：是一种设计模式，通过将对象的创建和依赖关系的管理交给容器来实现，而不是由对象自身去负责。在传统的程序设计中，对象之间的依赖关系通常是在代码中通过new关键字等硬编码的方式创建和管理的。而在 Spring IoC 中，对象的创建和依赖注入由 Spring 容器来完成，对象只必要关心自身的业务逻辑，降低了对象之间的耦合度。
  
• 实现原理：Spring 容器在启动时，会读取配置文件（如 XML 配置文件或 Java 配置类），根据配置信息创建对象，并将对象之间的依赖关系进行注入。当一个对象必要依赖其他对象时，它不必要本身去创建，而是由 Spring 容器将所依赖的对象注入进来。
  
• 依赖注入方式
  
  
  
  • 构造函数注入：通过类的构造函数将依赖对象注入进来。比方：
    
  
  

1. public class UserService {
2.     private UserDao userDao;
3.     public UserService(UserDao userDao) {
4.         this.userDao = userDao;
5.     }
6. }

复制代码

• Setter 方法注入：通过类的 Setter 方法将依赖对象注入进来。比方：
  

1. public class UserService {
2.     private UserDao userDao;
3.     public void setUserDao(UserDao userDao) {
4.         this.userDao = userdao;
5.     }
6. }

复制代码

• 字段注入：直接在类的字段上使用@Autowired等注解进行注入。比方：
  

1. public class UserService {
2.     @Autowired
3.     private UserDao userDao;
4. }

复制代码

Spring AOP（Aspect Oriented Programming，面向切面编程）

• 概念：是一种编程范式，它允许将与业务逻辑无关的横切关注点（如日记记录、事件管理、安全查抄等）从业务逻辑中分离出来，形成独立的切面（Aspect），然后在程序运行时将这些切面动态地织入到目标对象的业务逻辑中，从而实现对业务逻辑的增强，而无需修改业务逻辑代码本身。
  
• 相关术语
  
  
  
  • 切面（Aspect）：是一个包含了横切关注点的模块，通常由切点和通知组成。
    
  • 切点（Pointcut）：用于定义在哪些毗连点上应用切面，通常使用表达式来指定。
    
  • 通知（Advice）：是在切点所定义的毗连点上执行的代码，包括前置通知（在目标方法执行前执行）、后置通知（在目标方法执行后执行）、围绕通知（在目标方法执行前后都执行）、非常通知（在目标方法抛出非常时执行）和返回通知（在目标方法正常返回时执行）等。
    
  • 毗连点（Join Point）：是程序执行过程中的一个点，如方法调用、方法执行、非常抛出等，在这些点上可以插入切面的通知。
    
  
  
• 实现原理：Spring AOP 基于代理模式实现，当一个目标对象必要被增强时，Spring 会为其创建一个代理对象，代理对象在调用目标对象的方法时，会根据切点的定义判断是否必要执行切面的通知，如果必要，则在目标方法执行前后或抛出非常时等执行相应的通知。
  
• 使用示例
  

1. // 定义切面
2. @Aspect
3. public class LoggingAspect {
4.     // 定义切点
5.     @Pointcut("execution(* com.example.service.UserService.*(..))")
6.     public void userServicePointcut() {}
7.     // 定义前置通知
8.     @Before("userServicePointcut()")
9.     public void beforeMethod(JoinPoint joinPoint) {
10.         System.out.println("Before method: " + joinPoint.getSignature().getName());
11.     }
12. }

复制代码

12，解决 Hash 碰撞的方法有哪些?

哈希碰撞（Hash Collision）是指差别的输入经过哈希函数计算后得到了相同的哈希值。解决哈希碰撞的方法有多种，以下是一些常见的方法：
开放定址法

• 线性探测法：当发生哈希碰撞时，从当前哈希地点开始，依次向后探测空闲的存储单元，直到找到一个空闲位置为止。比方，哈希表巨细为 10，哈希函数为hash(key)=key % 10，插入键值对(15, "value1")和(25, "value2")时，hash(15)=5，hash(25)=5，发生碰撞，此时使用线性探测法，会将(25, "value2")存储在hash(25)+1=6的位置。
  
• 二次探测法：当发生哈希碰撞时，按照二次函数的规律来探测下一个空闲位置，即探测位置为hash(key)+i^2（i为探测次数）。比方，哈希表巨细为 10，哈希函数为hash(key)=key % 10，插入键值对(15, "value1")和(25, "value2")时，发生碰撞后，第一次探测位置为hash(25)+1^2=6，如果6位置也被占用，则第二次探测位置为hash(25)+2^2=9，以此类推。
  
• 随机探测法：在发生哈希碰撞时，通过一个随机数生成器生成一个随机的步长，然后按照这个步长来探测下一个空闲位置。
  

链地点法

• 根本原理：将全部哈希地点相同的元素构成一个单链表，即把发生碰撞的元素用链表毗连起来，存储在同一个哈希桶中。比方，对于哈希函数hash(key)=key % 10，键值对(15, "value1")、(25, "value2")和(35, "value3")都哈希到5这个位置，那么在哈希表的5号桶中，会形成一个链表，依次存储这三个键值对。
  
• 优化：可以将链表更换为其他更高效的数据结构，如红黑树、跳表等，以提高在哈希桶中查找元素的效率。
  

再哈希法

• 根本原理：当发生哈希碰撞时，使用另一个哈希函数对该键再次进行哈希计算，直到找到一个空闲的位置为止。比方，有哈希函数hash1(key)=key % 10和hash2(key)=(key / 10) % 10，插入键值对(15, "value1")和(25, "value2")时，hash1(15)=5，hash1(25)=5发生碰撞，此时使用hash2(25)=2，将(25, "value2")存储在2号位置。
  
• 多哈希函数选择：可以准备多个差别的哈希函数，在发生碰撞时依次尝试，或者根据肯定的规则动态选择哈希函数。
  

建立公共溢出区

• 根本原理：将哈希表分为根本表和溢出表两部门，当发生哈希碰撞时，将冲突的元素都存储到溢出表中。在查找元素时，先在根本表中查找，如果找不到，则再到溢出表中查找。
  

13，什么是 ABA 题目?

ABA 题目是在多线程并发编程中，由于对共享资源的访问和修改顺序不同等而导致的一种特殊题目，以下是具体介绍：
题目描述

• 在多线程环境下，一个线程对共享变量进行了多次操纵，使得该变量的值从 A 变成 B，又变回 A，而在这个过程中，其他线程大概在该变量值为 A 时进行了一些操纵，这些操纵大概会由于变量值看似未变而产生错误的结果，即线程看到的变量状态是 A，但是实际上这个 A 已经不是之前的谁人 A 了，中心发生了变化又变回了 A，这就是 ABA 题目。
  

产生缘故原由

• 并发操纵：多个线程同时对同一个共享变量进行读写操纵，且没有进行得当的同步控制。
  
• 指令重排：在没有正确同步的环境下，编译器和处理器大概会对指令进行重排序，导致操纵的执行顺序与代码的书写顺序不同等，从而增加了 ABA 题目出现的大概性。
  

示例

1. import java.util.concurrent.atomic.AtomicReference;
3. public class ABAProblemExample {
4.     private static AtomicReference<String> atomicReference = new AtomicReference<>("A");
6.     public static void main(String[] args) throws InterruptedException {
7.         Thread thread1 = new Thread(() -> {
8.             String prev = atomicReference.get();
9.             System.out.println("Thread 1 read value: " + prev);
10.             // 模拟一些耗时操作
11.             try {
12.                 Thread.sleep(1000);
13.             } catch (InterruptedException e) {
14.                 e.printStackTrace();
15.             }
16.             boolean result = atomicReference.compareAndSet("A", "B");
17.             System.out.println("Thread 1 CAS result: " + result);
18.             result = atomicReference.compareAndSet("B", "A");
19.             System.out.println("Thread 1 CAS result: " + result);
20.         });
22.         Thread thread2 = new Thread(() -> {
23.             try {
24.                 Thread.sleep(2000);
25.             } catch (InterruptedException e) {
26.                 e.printStackTrace();
27.             }
28.             boolean result = atomicReference.compareAndSet("A", "C");
29.             System.out.println("Thread 2 CAS result: " + result);
30.         });
32.         thread1.start();
33.         thread2.start();
35.         thread1.join();
36.         thread2.join();
37.     }
38. }

复制代码

在上述示例中，thread1首先读取atomicReference的值为"A"，然后经过一些操纵将其值从"A"修改为"B"，再修改回"A"。而thread2在thread1操纵完成后，也尝试将atomicReference的值从"A"修改为"C"，此时thread2的compareAndSet操纵会成功，由于它看到的值也是"A"，但实际上这个"A"已经不是最初的谁人"A"了，这就大概导致程序出现意外的结果。
解决方法

• 使用版本号或时间戳：在共享变量中增加一个版本号或时间戳字段，每次对变量进行修改时，同时更新版本号或时间戳。在进行比较和交换操纵时，不但要比较变量的值，还要比较版本号或时间戳，只有两者都相等时，才进行交换操纵。
  
• 使用AtomicStampedReference或AtomicMarkableReference：Java中的AtomicStampedReference和AtomicMarkableReference类可以在原子操纵中同时携带一个版本号或标记位，通过这种方式来解决 ABA 题目。
  

14，算法:反转链表

以下是使用 Java 语言实现反转链表的几种常见算法，这里以单链表为例进行介绍：
迭代法

• 思路：通过遍历链表，依次改变当前节点的指针方向，使其指向前一个节点，从而实现链表的反转。必要使用两个指针，一个指针prev指向当前节点的前一个节点，初始时为null；另一个指针curr指向当前正在处理的节点，初始时指向链表的头节点。在遍历过程中，老师存当前节点的下一个节点，然后将当前节点的指针指向前一个节点，接着更新prev和curr指针，继续下一个节点的处理，直到遍历完整个链表。
  
• 代码示例：
  

1. class ListNode {
2.     int val;
3.     ListNode next;
4.     ListNode(int val) {
5.         this.val = val;
6.     }
7. }
9. public class ReverseLinkedList {
10.     public ListNode reverseList(ListNode head) {
11.         ListNode prev = null;
12.         ListNode curr = head;
13.         while (curr!= null) {
14.             ListNode nextTemp = curr.next;
15.             curr.next = prev;
16.             prev = curr;
17.             curr = nextTemp;
18.         }
19.         return prev;
20.     }
21. }

复制代码

递归法

• 思路：递归地反转链表，将题目逐步分解为更小的子题目。对于一个链表，先反转除了头节点之外的别的部门链表，然后将头节点的指针指向已反转的子链表的末尾，末了返回反转后的头节点。递归的停止条件是当链表为空或者只有一个节点时，直接返回该链表。
  
• 代码示例：
  

1. class ListNode {
2.     int val;
3.     ListNode next;
4.     ListNode(int val) {
5.         this.val = val;
6.     }
7. }
9. public class ReverseLinkedList {
10.     public ListNode reverseList(ListNode head) {
11.         if (head == null || head.next == null) {
12.             return head;
13.         }
14.         ListNode reversedSubList = reverseList(head.next);
15.         head.next.next = head;
16.         head.next = null;
17.         return reversedSubList;
18.     }
19. }

复制代码

在实际应用中，可以根据具体的场景选择符合的方法来反转链表，迭代法相对来说更容易理解和实现，递归法则代码更加简便，但在处理较长链表时大概会有栈溢出的风险（取决于递归深度）。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。