Java 热门面试题-07

最近更新：2025-06-20 | 字数总计：12.2k

到底什么是 TCP 连接？

TCP连接是指 Transmission Control Protocol（传输控制协议）连接，是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP连接用于在网络中的两个主机之间建立一个虚拟的连接，以实现数据的有序、可靠传输。

TCP连接的主要特点包括：

面向连接：在数据传输之前，需要建立连接；传输完成后，需要断开连接。
可靠传输：TCP通过序列号、确认应答、数据重传、流量控制、拥塞控制等机制，确保数据传输的可靠性。
有序传输：TCP保证数据按照发送的顺序到达接收方。
基于字节流：TCP将数据看作是无结构的字节流，不保留数据边界。

TCP连接的建立过程（三次握手）：

SYN：客户端发送一个SYN（同步序列编号）报文到服务器，并进入SYN_SENT状态，等待服务器确认。
SYN+ACK：服务器收到SYN报文后，会发送一个SYN+ACK（同步和确认应答）报文作为应答，并将连接状态设置为SYN_RECEIVED。这个报文中既包含SYN也包含ACK（确认字符），表示服务器已经收到了客户端的SYN报文。
ACK：客户端收到服务器的SYN+ACK报文后，会向服务器发送一个ACK报文，确认连接的建立。此报文发送完毕后，客户端和服务器都进入ESTABLISHED状态，完成连接的建立。

TCP连接的终止过程（四次挥手）：

FIN：当客户端完成数据传输后，它需要发送一个FIN（结束）报文到服务器，并进入FIN_WAIT_1状态，等待服务器确认。
ACK：服务器收到这个FIN报文后，会发送一个ACK报文作为应答，并将连接状态设置为CLOSE_WAIT。客户端收到这个ACK后，进入FIN_WAIT_2状态。
FIN：服务器发送自己的FIN报文，并进入LAST_ACK状态，等待客户端的确认。
ACK：客户端收到服务器的FIN报文后，发送一个ACK报文作为应答，然后进入TIME_WAIT状态。经过一段时间（称为2MSL，即最大报文生存时间的两倍）后，确保服务器收到了最后的ACK报文，客户端关闭连接。服务器收到这个ACK报文后，立即关闭连接。

TCP连接的作用：

保证数据传输的可靠性：通过确认机制和重传机制，确保数据不丢失、不重复。
提供流量控制：通过滑动窗口机制，控制数据的发送速率，避免网络拥塞。
实现有序传输：通过序列号和确认应答，保证数据按照发送的顺序到达。

TCP连接是网络通信中的基础，广泛应用于各种网络应用，如Web浏览、电子邮件、文件传输等。

如何处理重复消息？

处理重复消息是分布式系统中常见的问题，尤其是在消息队列和事件驱动架构中。以下是几种常见的处理重复消息的方法：

幂等性设计

定义：确保同一操作多次执行的结果与一次执行的结果相同。
实现方式：
- 数据库操作：使用唯一约束或主键避免重复插入。
- 业务逻辑：设计业务逻辑使其在重复执行时不影响最终状态。

消息去重

定义：在消息处理前检查是否已处理过该消息。
实现方式：
- 唯一标识：为每条消息分配唯一 ID，在处理前检查该 ID 是否已处理。
- 去重表：在数据库中维护已处理消息的记录，处理前查询该表。

消息确认机制

定义：确保消息被成功处理后再确认，避免因未确认导致的重复投递。
实现方式：
- ACK 机制：消息队列提供确认机制，消费者处理成功后发送 ACK。
- 事务性消息：使用支持事务的消息队列，确保消息处理和业务操作在一个事务中。

消息日志

定义：记录所有已处理消息的日志，处理新消息前检查日志。
实现方式：
- 日志存储：使用数据库或分布式存储记录消息日志。
- 日志查询：处理消息前查询日志，确保消息未被处理。

分布式锁

定义：在处理消息前获取分布式锁，确保同一消息不会被多个消费者同时处理。
实现方式：
- Redis 锁：使用 Redis 的 SETNX 命令实现分布式锁。
- ZooKeeper 锁：使用 ZooKeeper 的临时节点实现分布式锁。

消息版本控制

定义：为消息添加版本号，确保只处理最新版本的消息。
实现方式：
- 版本号：在消息中添加版本号字段，处理时检查版本号。
- 版本存储：在数据库中存储消息的最新版本号，处理前进行比较。

示例

幂等性设计示例

public void processOrder(Order order) {
    if (orderRepository.existsById(order.getId())) {
        return; // 订单已处理，直接返回
    }
    orderRepository.save(order);
    // 处理订单逻辑
}

消息去重示例

public void processMessage(Message message) {
    if (processedMessageRepository.existsById(message.getId())) {
        return; // 消息已处理，直接返回
    }
    processedMessageRepository.save(message);
    // 处理消息逻辑
}

消息确认机制示例

public void processMessage(Message message) {
    try {
        // 处理消息逻辑
        messageQueue.ack(message.getId()); // 确认消息
    } catch (Exception e) {
        // 处理失败，不确认消息
    }
}

总结

方法	描述	实现方式
幂等性设计	确保操作多次执行结果一致	唯一约束、业务逻辑设计
消息去重	处理前检查消息是否已处理	唯一标识、去重表
消息确认机制	处理成功后再确认消息	ACK 机制、事务性消息
消息日志	记录已处理消息日志，处理前检查	日志存储、日志查询
分布式锁	处理前获取锁，确保同一消息不被重复处理	Redis 锁、ZooKeeper 锁
消息版本控制	只处理最新版本的消息	版本号、版本存储

根据具体场景选择合适的方法，确保系统能够有效处理重复消息。

Java 中什么情况会导致死锁？如何避免？

在Java中，死锁是指两个或多个线程在执行过程中，因争夺资源而造成的一种相互等待的现象，若无外力作用，这些线程将无法继续执行下去。以下是一些导致死锁的常见情况：

互斥条件：线程对资源的访问是互斥的，即一个资源每次只能被一个线程使用。
请求与保持条件：一个线程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件：线程已获得的资源，在末使用完之前，不能强行剥夺。
循环等待条件：若干线程之间形成一种头尾相接的循环等待资源关系。

具体到代码层面，以下情况可能导致死锁：

锁的顺序不一致：多个线程以不同的顺序获取多个锁。
内部锁和同步：使用synchronized关键字或ReentrantLock等内部锁时，如果没有正确管理锁的获取和释放顺序。
锁嵌套：一个线程已经持有一个锁，然后尝试获取另一个锁，而另一个线程持有第二个锁并尝试获取第一个锁。
等待通知机制不当：使用wait()/notify()机制时，如果通知的时机不正确，可能导致线程永久等待。

为了避免死锁，可以采取以下措施：

避免锁的顺序冲突：确保所有线程以相同的顺序获取锁。
使用定时锁：使用tryLock()方法尝试获取锁，并设置超时时间，以避免无限期等待。
锁粗化：将多个锁合并为一个锁，减少锁的竞争和持有时间。
锁分解：将一个锁分解为多个锁，以减少锁的竞争。
使用锁顺序协议：定义一个全局的锁顺序，所有线程按照这个顺序来获取锁。
避免锁嵌套：尽量减少锁的嵌套使用，如果必须嵌套，确保以一致的顺序获取锁。
使用开源工具：使用如FindBugs、Checkstyle等工具来检测潜在的死锁问题。
合理使用并发工具：使用Java并发包中的工具类，如ConcurrentHashMap、ReadWriteLock等，它们内部已经处理了锁的很多问题。
减少锁的持有时间：尽量减少在锁内部执行的操作，快速释放锁。
使用等待-通知机制的替代方案：如使用CountDownLatch、CyclicBarrier、Semaphore等替代传统的等待-通知机制。
通过以上措施，可以大大降低死锁发生的概率。但是，完全避免死锁是非常困难的，特别是在复杂的系统中。因此，除了预防措施外，还需要有监控和诊断死锁的机制，以便在死锁发生时能够及时发现并处理。

如何保证消息的有序性？

保证消息的有序性是分布式系统中常见的一个需求，尤其是在金融、交易等对数据一致性要求较高的场景中。以下是一些保证消息有序性的策略：

单一生产者-单一消费者模型：
- 确保每个主题或队列只有一个生产者发送消息，并且只有一个消费者接收消息。这样可以自然保证消息的顺序性。
分区/队列：
- 在消息队列系统中（如Kafka、RabbitMQ等），可以为每个生产者分配一个独立的分区或队列。消费者从特定的分区或队列中读取消息，以保证来自同一生产者的消息顺序。
消息分组：
- 对消息进行分组，每组消息有一个唯一的标识符（如groupid）。消费者在处理消息时，确保同一组的消息按照顺序处理。
顺序键（Kafka中的Key）：
- 在Kafka中，可以使用消息的Key来保证有序性。具有相同Key的消息会被发送到同一个分区，从而保证它们的顺序。
事务消息：
- 使用事务消息可以保证消息的原子性发送，即要么全部发送成功，要么全部失败。在一些消息队列系统中，事务消息也可以保证消息的顺序性。
同步处理：
- 消费者在处理消息时，可以采用同步处理的方式，即处理完一条消息后再获取下一条消息，这样可以保证消息的顺序性。
状态管理：
- 消费者可以维护一个状态机，跟踪消息的处理状态，确保消息按照预期的顺序进行处理。
重排序机制：
- 如果消息的顺序被破坏，可以实现一个重排序机制，将乱序的消息重新排序后再进行处理。
消息依赖关系：
- 如果消息之间有依赖关系，可以在消息中包含依赖信息，消费者根据这些信息来决定消息的处理顺序。
使用有序集合：
- 在某些存储系统中（如Redis），可以使用有序集合来存储消息，保证消息的顺序性。
避免并行处理：
- 在某些情况下，可以通过避免并行处理来保证消息的顺序性。例如，使用单线程或多线程中的单一工作者模式。
消息确认机制：
- 实现消息确认机制，确保消息被正确处理后才确认，这样可以避免消息的重复处理和乱序。
  实现消息的有序性时，还需要考虑系统的可用性和性能。有时候，为了保证有序性，可能需要牺牲一些性能。因此，在设计系统时，需要根据具体的需求和场景来权衡。

说一下 Netty 的应用场景？

总结性解决方案

实时通信应用
- 聊天应用：处理大量并发的用户连接和消息传输。
- 在线教育互动系统：支持多用户同时在线的实时互动。
游戏服务器
- 多人在线游戏：管理玩家的实时交互和数据同步。
- 游戏后端服务：处理高并发的请求和低延迟的数据传输。
高性能服务器开发
- HTTP 服务器：提供高效的 Web 服务，处理大量的 HTTP 请求。
- WebSocket 服务器：支持实时双向通信，适用于实时数据更新场景。
自定义协议实现
- 物联网设备通信：实现定制化的通信协议，管理大量设备的连接和数据传输。
- 区块链节点通信：处理区块链网络中的数据同步和交易传播。
金融交易系统
- 高频交易系统：应对高并发和低延迟的交易请求。
- 支付系统：确保交易的实时性和安全性。
大数据处理系统的网络通信模块
- 数据交换：在大数据处理框架（如 Apache Spark、Flink）中负责节点间的通信。
- 实时数据处理：支持实时日志分析和流数据处理。
API 网关
- 请求路由：管理微服务架构中的服务间请求转发。
- 负载均衡：分配流量以提高系统可用性和性能。
音视频直播服务器
- 流媒体传输：处理大量的音视频数据流，支持多用户同时观看。
人工智能服务的网络通信模块
- 推理请求处理：支持机器学习模型的实时推理和数据传输。
数据库的集群通信
- NoSQL 数据库：管理集群节点间的通信和数据同步。
网络安全设备的通信模块
- 防火墙和入侵检测系统：处理大量的网络流量和安全事件。
云计算的负载均衡器
- 请求转发：在云环境中分配计算资源，提高服务的可用性和扩展性。

Netty 的应用场景包括但不限于实时通信应用、游戏服务器、高性能 HTTP 和 WebSocket 服务器、自定义协议实现、金融交易系统、大数据处理系统的网络通信模块、API 网关、实时数据处理系统、音视频直播服务器、区块链节点的通信模块、人工智能服务的网络通信模块、数据库的集群通信、网络安全设备的通信模块以及云计算的负载均衡器等。

什么是 Spring IOC？

Spring IOC（控制反转，Inversion of Control）是Spring框架的核心概念之一，它是一种设计原则，用于减少代码之间的耦合度。在传统的编程中，对象负责创建和管理它们依赖的其他对象，这导致了高度的耦合，使得代码难以维护和测试。

在Spring IOC中，对象不需要自己创建依赖对象，而是由Spring容器负责创建和管理这些依赖对象，并将它们注入到需要它们的对象中。这种机制使得对象之间的依赖关系被反转，对象不再控制依赖对象的创建，而是由容器来控制。

Spring IOC通过依赖注入（Dependency Injection, DI）来实现。依赖注入主要有三种方式：

构造器注入：通过类的构造器来注入依赖。
Setter注入：通过类的setter方法来注入依赖。
字段注入：直接通过类的字段注解来注入依赖。

使用Spring IOC的优势包括：

降低耦合度：对象不需要知道如何创建它们的依赖，只需要知道它们的接口。
提高可测试性：更容易进行单元测试，因为可以轻松地替换依赖对象的实现。
简化配置：通过XML配置文件或注解来配置依赖关系，减少了硬编码。
促进松耦合设计：鼓励遵循良好设计原则，如单一职责原则和开闭原则。

总之，Spring IOC通过将对象的创建和依赖管理委托给Spring容器，实现了控制反转，从而提高了代码的可维护性、可测试性和可扩展性。

你了解 Java 线程池的原理吗？

Java 线程池的原理是通过复用一组预先创建的线程来执行任务，而不是每次执行任务时都创建和销毁线程。这可以显著提高性能，因为线程的创建和销毁是一个相对昂贵的操作。

Java 线程池的核心概念包括：

线程池的创建：使用 ExecutorService 接口的实现类，如 ThreadPoolExecutor，来创建线程池。可以通过设置核心线程数、最大线程数、线程空闲时间、队列类型等参数来配置线程池。
任务的提交：将任务提交给线程池，任务可以是实现 Runnable 或 Callable 接口的实例。线程池会根据当前的线程数和任务队列的情况来决定如何执行任务。
任务的执行：如果线程池中的线程数小于核心线程数，线程池会创建新的线程来执行任务。如果线程数已经达到核心线程数，但任务队列未满，任务会被放入队列中等待执行。如果线程数达到最大线程数且任务队列已满，线程池会根据拒绝策略来处理新任务。
线程的回收：当线程空闲时间超过设定的阈值时，线程池会回收多余的线程，直到线程数回到核心线程数。
线程池的关闭：通过调用 shutdown() 或 shutdownNow() 方法来关闭线程池。shutdown() 方法会等待所有正在执行的任务完成，而 shutdownNow() 方法会尝试立即停止所有正在执行的任务。

Java 线程池的原理使得任务的执行更加高效和可控，适用于需要处理大量异步任务的场景。

Redis 数据过期后的删除策略是什么？

引言
Redis 是一个高性能的键值存储系统，支持数据过期机制。当数据过期后，Redis 采用特定的删除策略来清理过期键，以保证内存的有效利用和系统的高效运行。
过期键删除策略
Redis 的过期键删除策略主要包括两种：
- 惰性删除（Lazy Expiration）
  - 定义：当尝试访问一个键时，Redis 会检查该键是否已过期。如果过期，则立即删除该键。
  - 优点：
    - 实现简单，不主动消耗 CPU 资源。
  - 缺点：
    - 过期键可能在内存中堆积，占用额外的空间。
- 定期删除（Periodic Expiration）
  - 定义：Redis 定期启动后台任务，随机抽样数据库中的键进行过期检查，并删除过期的键。
  - 实现机制：
    - 通过定时器每隔一段时间（默认为 100 毫秒）触发一次检查。
    - 每次检查时，Redis 会抽样一定数量的键进行过期检查。
  - 优点：
    - 主动清理过期键，避免内存占用过多。
  - 缺点：
    - 会消耗一定的 CPU 资源，可能影响性能。
策略结合
Redis 通过结合惰性删除和定期删除两种策略，有效地管理过期键：
- 平衡性能与内存使用：惰性删除在访问时检查过期键，不影响常规操作的性能；定期删除则在后台定期清理，避免过期键堆积。
- 优化资源利用：这种结合确保了过期键能够被及时清理，同时保持系统的高效运行。
结论
Redis 采用惰性删除和定期删除相结合的策略，有效地管理过期键，平衡了性能和内存使用，确保系统的高效性和稳定性。

Redis 数据过期后的删除策略包括惰性删除和定期删除。惰性删除机制在访问键时检查其是否过期，如果过期则立即删除。定期删除机制则通过定时任务周期性地检查并删除过期的键。这两种策略相结合，确保了过期键能够被及时清理，同时保持系统的高效运行。

如何处理消息堆积？

引言
在分布式系统中，消息堆积是一个常见的问题，它可能导致系统性能下降、响应时间增加甚至系统崩溃。有效处理消息堆积对于保证系统的稳定性和可靠性至关重要。
消息堆积的原因
- 生产者速率超过消费者速率：当消息生产者的速度远大于消费者处理消息的速度时，消息队列中会积累大量未处理的消息。
- 消费者故障：消费者节点出现故障或性能瓶颈，导致处理能力下降。
- 系统资源不足：服务器资源（如CPU、内存）不足，限制了消费者处理消息的能力。
- 消息处理逻辑复杂：单条消息的处理逻辑过于复杂，消耗大量时间，降低了整体处理速度。
处理消息堆积的策略
- 增加消费者实例：
  - 水平扩展：通过增加更多的消费者实例来提高整体处理能力。
  - 负载均衡：确保消息均匀分布到各个消费者实例，避免单点过载。
- 优化消费者性能：
  - 提升单个消费者实例的处理能力：通过优化代码、升级硬件等方式提高单个消费者的处理速度。
  - 异步处理：将消息处理逻辑改为异步，减少消费者处理单条消息的时间。
- 调整生产者速率：
  - 限流：限制生产者的消息发送速率，使其与消费者处理能力相匹配。
  - 背压机制：当消费者处理能力不足时，反馈给生产者，使其减缓发送速度。
- 优化消息队列配置：
  - 增加队列容量：适当增加消息队列的容量，以缓冲暂时的消息堆积。
  - 分区和分片：将消息队列进行分区或分片，提高吞吐量和可扩展性。
- 监控和告警：
  - 实时监控：对消息队列的长度、消费者处理速度等指标进行实时监控。
  - 设置告警阈值：当消息堆积达到一定阈值时，及时发出告警，通知运维人员采取措施。
- 消息重试和死信队列：
  - 重试机制：对处理失败的消息进行重试，避免消息丢失。
  - 死信队列：将无法处理的消息转移到死信队列，进行单独处理或人工干预。
结论
消息堆积是分布式系统中常见的问题，通过增加消费者实例、优化消费者性能、调整生产者速率、优化消息队列配置、实施监控和告警以及采用消息重试和死信队列等策略，可以有效处理消息堆积，保证系统的稳定性和可靠性。

处理消息堆积的策略包括增加消费者实例、优化消费者性能、调整生产者速率、优化消息队列配置、实施监控和告警以及采用消息重试和死信队列等。通过这些措施，可以有效管理消息堆积，确保系统的高效运行和稳定性。

什么是服务熔断？

引言
在分布式系统中，服务之间通常通过远程调用进行通信。然而，当某个服务出现故障或响应时间过长时，可能会导致整个系统性能下降甚至崩溃。为了防止这种情况的发生，服务熔断机制应运而生。
服务熔断的定义
服务熔断是一种容错机制，当某个服务的调用次数超过预设的阈值，或者调用失败率超过一定比例时，系统会自动“熔断”对该服务的调用，转而返回一个预定义的错误或默认值。这类似于电路中的熔断器，当电流超过安全范围时，熔断器会熔断，防止电路过载。
服务熔断的作用
- 防止级联故障：当一个服务发生故障时，熔断机制可以防止故障扩散到其他服务，避免整个系统崩溃。
- 提高系统可用性：通过熔断机制，系统可以在部分服务不可用时，仍然保持整体的可用性。
- 快速恢复：熔断机制通常会设置一个冷却时间，在此期间，系统会尝试恢复对熔断服务的调用，如果服务恢复正常，熔断会自动解除。
服务熔断的实现
- 熔断阈值：设定服务调用的失败率或错误次数的阈值，当达到阈值时触发熔断。
- 熔断状态：熔断机制通常有三种状态：
  - 闭合状态（Closed）：正常调用服务。
  - 打开状态（Open）：熔断触发，不再调用服务，返回错误或默认值。
  - 半开状态（Half-Open）：在冷却时间结束后，允许少量请求通过，测试服务是否恢复正常。
- 熔断策略：根据不同的业务需求，可以选择不同的熔断策略，如基于时间窗口的熔断、基于滑动窗口的熔断等。
结论
服务熔断是一种重要的容错机制，通过在服务调用失败率达到一定阈值时自动熔断，防止故障扩散，提高系统的稳定性和可用性。在分布式系统设计中，合理实施服务熔断机制对于保证系统的健壮性至关重要。

服务熔断是一种在分布式系统中防止级联故障的容错机制，当服务调用失败率达到一定阈值时，自动熔断对该服务的调用，转而返回错误或默认值，从而提高系统的可用性和稳定性。

Java 线程池有哪些拒绝策略？

Java 线程池提供了几种不同的拒绝策略，当线程池无法处理新提交的任务时，这些策略决定了任务将如何被处理。以下是 Java 线程池中的四种主要拒绝策略：

AbortPolicy（默认策略）：
- 描述：这是默认的拒绝策略。当线程池无法接受新任务时，它会抛出一个 RejectedExecutionException 异常。
- 使用场景：当你希望在任务被拒绝时立即知道问题，并且希望任务的提交者能够捕获并处理这个异常时，可以使用这个策略。
CallerRunsPolicy：
- 描述：当线程池无法接受新任务时，它会将任务回退给提交任务的线程来执行。
- 使用场景：当你希望任务的提交者自己处理任务，而不是让任务被拒绝时，可以使用这个策略。这在任务量突然增加但可以被提交者处理的情况下特别有用。
DiscardPolicy：
- 描述：当线程池无法接受新任务时，它会默默地丢弃任务，而不做任何处理。
- 使用场景：当你不关心被拒绝的任务，并且希望系统能够继续运行而不被任务拒绝所影响时，可以使用这个策略。
DiscardOldestPolicy：
- 描述：当线程池无法接受新任务时，它会丢弃线程池队列中最老的任务，然后尝试重新提交被拒绝的任务。
- 使用场景：当你希望保留最新提交的任务，并且愿意牺牲最早的任务来确保新任务能够被处理时，可以使用这个策略。

你可以通过 ThreadPoolExecutor 类的构造函数来设置这些拒绝策略，例如：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    corePoolSize,
    maximumPoolSize,
    keepAliveTime,
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(queueSize),
    new ThreadPoolExecutor.AbortPolicy()
);

在这个例子中，AbortPolicy 被设置为拒绝策略。你可以根据你的应用需求选择合适的拒绝策略。

HTTP 1.0 和 2.0 有什么区别？

HTTP 1.0 和 HTTP 2.0 是两种不同的超文本传输协议版本，它们在性能、效率和功能上有一些关键的区别。以下是 HTTP 1.0 和 HTTP 2.0 之间的一些主要区别：

HTTP 1.0

请求/响应模型：HTTP 1.0 是基于请求/响应模型的，每个请求都需要一个单独的 TCP 连接。
管道化：HTTP 1.0 不支持管道化（pipelining），这意味着客户端必须等待前一个请求的响应才能发送下一个请求。
头部压缩：HTTP 1.0 不支持头部压缩，每个请求和响应的头部都是明文传输的，这增加了网络流量。
多路复用：HTTP 1.0 不支持多路复用，每个连接只能处理一个请求/响应对。
性能：由于上述限制，HTTP 1.0 在处理多个并发请求时性能较低。

HTTP 2.0

请求/响应模型：HTTP 2.0 仍然基于请求/响应模型，但引入了多路复用，允许多个请求和响应在同一个 TCP 连接上同时进行。
管道化：HTTP 2.0 支持双向管道化，允许客户端在等待响应的同时发送新的请求。
头部压缩：HTTP 2.0 使用 HPACK 算法对头部进行压缩，减少了网络流量，提高了效率。
多路复用：HTTP 2.0 支持多路复用，允许多个请求和响应在同一个连接上并发传输，减少了延迟。
服务器推送：HTTP 2.0 引入了服务器推送功能，服务器可以在客户端请求之前主动推送资源。
性能：由于多路复用、头部压缩和服务器推送等功能，HTTP 2.0 在处理多个并发请求时性能显著提高。

总结

HTTP 2.0 是对 HTTP 1.0 的重大升级，它通过引入多路复用、头部压缩和服务器推送等功能，显著提高了 web 应用的性能和效率。大多数现代浏览器和服务器都支持 HTTP 2.0，因此在开发 web 应用时，使用 HTTP 2.0 是一个不错的选择。

如何保证消息不丢失？

为了保证消息不丢失，可以采取以下策略和技术：

确认机制（Acknowledgment）
- 发送方确认：接收方收到消息后，向发送方发送确认消息（ACK）。
- 接收方确认：发送方发送消息后，等待接收方的确认，未收到确认时重新发送。
重传机制（Retransmission）
- 定时重传：设置定时器，定时器到期未收到确认时重新发送消息。
- 指数退避：重传时采用指数退避算法，增加重传间隔，避免网络拥塞。
消息队列（Message Queue）
- 使用支持持久化和确认机制的消息队列系统，如RabbitMQ、Kafka等。
持久化存储（Persistence）
- 将消息持久化存储在磁盘或其他持久化介质上，防止系统故障导致消息丢失。
冗余系统（Redundancy）
- 采用冗余的网络路径、服务器或存储设备，确保单点故障不影响消息传输。
事务处理（Transactions）
- 在数据库或消息系统中使用事务，确保消息发送和确认的原子性。
监控和告警（Monitoring and Alerting）
- 实施监控系统，实时跟踪消息发送和接收情况，及时发现并处理消息丢失或延迟。
容错机制（Fault Tolerance）
- 设计系统时考虑容错性，确保部分组件故障时系统仍能正常运行。
备份和恢复（Backup and Recovery）
- 定期备份消息数据，制定恢复计划，以便在灾难发生时快速恢复消息。
协议选择（Protocol Selection）
- 选择适合的通信协议，如TCP协议，提供可靠的、面向连接的服务，确保数据的完整性和顺序性。

通过结合上述多种方法，可以构建一个高可靠性的消息传输系统，有效保证消息不丢失。

Spring AOP默认用的是什么动态代理，两者的区别？

在Spring框架中，AOP（面向切面编程）默认使用JDK动态代理来创建代理对象。以下是JDK动态代理和CGLIB动态代理的主要区别：

代理方式：
- JDK动态代理：通过java.lang.reflect.Proxy类实现，只能对实现了接口的类进行代理。
- CGLIB动态代理：通过生成一个子类来实现代理，不需要目标类实现任何接口。
性能：
- JDK动态代理：通常比CGLIB代理更快，因为它是基于接口的调用。
- CGLIB动态代理：由于需要生成子类，性能上稍逊于JDK代理。
适用场景：
- JDK动态代理：适用于目标类实现了接口的情况。
- CGLIB动态代理：适用于目标类没有实现任何接口的情况。
配置：
- JDK动态代理：Spring默认使用，无需额外配置。
- CGLIB动态代理：需要在Spring配置中显式指定使用CGLIB，或者在类路径中包含CGLIB库。

在实际应用中，Spring会根据目标类的情况自动选择合适的代理方式。如果目标类实现了接口，Spring会使用JDK动态代理；如果目标类没有实现任何接口，Spring会使用CGLIB动态代理。当然，也可以通过配置强制Spring使用某种代理方式。

如何合理地设置 Java 线程池的线程数？

合理设置Java线程池的线程数是一个需要综合考虑多个因素的过程。以下是一些指导原则和步骤，帮助你设置合适的线程池大小：

确定任务类型：
- CPU密集型任务：这些任务主要消耗CPU资源，较少涉及I/O操作。对于这类任务，线程数通常设置为CPU核心数加上1或2，以避免过多的线程竞争CPU资源。
- I/O密集型任务：这些任务涉及大量的I/O操作，如数据库查询、网络请求等。对于这类任务，线程数可以设置得高于CPU核心数，因为线程在等待I/O时不会占用CPU资源。
考虑系统资源：
- 内存：每个线程都会消耗一定的内存资源。过多的线程可能会导致内存不足，尤其是在线程数设置过高时。
- CPU：过多的线程会增加上下文切换的开销，降低CPU的效率。
监控和调整：
- 监控工具：使用监控工具（如JMX、VisualVM等）来监控线程池的使用情况，包括活跃线程数、队列长度、任务完成时间等。
- 动态调整：根据监控数据，动态调整线程池的大小。如果发现线程池经常处于饱和状态，可能需要增加线程数；如果线程池中的线程经常处于空闲状态，可能需要减少线程数。
经验法则：
- 一个常见的经验法则是：线程数 = CPU核心数 + 1。这适用于大多数情况，但具体设置还需要根据实际任务类型和系统资源进行调整。
- 对于I/O密集型任务，线程数可以设置为CPU核心数的2到3倍。
测试和验证：
- 在生产环境部署之前，进行压力测试，模拟不同的负载情况，观察线程池的性能和资源使用情况。
- 根据测试结果，进一步调整线程池的大小，直到找到最佳的设置。
考虑线程池的队列策略：
- 有界队列：限制队列的大小，可以防止过多的任务堆积，但可能会导致任务被拒绝。
- 无界队列：允许任务无限堆积，但可能会导致内存不足。
- 拒绝策略：配置合适的拒绝策略，如抛出异常、丢弃任务、丢弃最老任务等。
线程池的类型：
- FixedThreadPool：固定大小的线程池，适用于任务数量稳定的情况。
- CachedThreadPool：可动态调整大小的线程池，适用于任务数量波动较大的情况。
- ScheduledThreadPool：支持定时和周期性任务的线程池。

最终，合理的线程池设置需要结合具体的业务场景、系统资源和测试结果来进行。没有一成不变的设置，只有最适合当前情况的配置。

Redis 中有哪些内存淘汰策略？

在 Redis 中，内存淘汰策略（也称为驱逐策略）用于在内存达到最大限制时决定哪些键值对应该被删除以释放空间。Redis 提供了多种内存淘汰策略，可以根据不同的需求选择合适的策略。以下是 Redis 中常见的内存淘汰策略：

noeviction（默认策略）：
- 当内存达到最大限制时，Redis 不会删除任何键值对，而是会返回错误，阻止进一步的写操作。这适用于需要保证数据完整性的场景。
allkeys-lru：
- 根据最近最少使用（LRU）算法，删除最近最少被访问的键值对。适用于所有键值对都可以被缓存的场景。
volatile-lru：
- 只针对设置了过期时间（expire time）的键值对，根据 LRU 算法删除最近最少被访问的键值对。适用于部分键值对有固定生命周期的场景。
allkeys-random：
- 随机删除键值对，不考虑访问频率。适用于对数据访问模式没有特定要求的场景。
volatile-random：
- 只针对设置了过期时间的键值对，随机删除。适用于部分键值对有固定生命周期且不需要考虑访问频率的场景。
volatile-ttl：
- 只针对设置了过期时间的键值对，优先删除那些即将过期的键值对。适用于希望延长键值对生命周期的场景。
allkeys-lfu（Redis 4.0 及以上版本）：
- 根据最不经常使用（LFU）算法，删除最不经常被访问的键值对。适用于需要更精确地控制缓存内容的场景。
volatile-lfu（Redis 4.0 及以上版本）：
- 只针对设置了过期时间的键值对，根据 LFU 算法删除最不经常被访问的键值对。适用于部分键值对有固定生命周期且需要控制缓存内容的场景。

选择合适的内存淘汰策略取决于你的应用需求和数据访问模式。例如，如果你的应用需要缓存所有数据，并且访问模式是随机的，那么 allkeys-lru 或 allkeys-lfu 可能是合适的选择。如果你的应用只希望缓存部分有固定生命周期的数据，那么 volatile-lru 或 volatile-lfu 可能更合适。

MySQL 中如果我 select * from 一个有 1000 万行的表，内存会飙升么？

在 MySQL 中执行 SELECT * FROM 语句查询一个包含 1000 万行的表，是否会飙升内存取决于多个因素，包括查询的具体配置、MySQL 的配置参数、表的结构以及服务器的硬件资源。

以下是一些影响内存使用的因素：

查询缓冲区（Query Cache）：
- 如果启用了查询缓冲区，并且查询结果适合缓存，MySQL 可能会将结果缓存起来，这会占用内存。但是，对于大数据量的查询，通常不建议使用查询缓冲区，因为它可能会导致内存占用过大，并且在数据频繁更新时效率不高。
排序和分组：
- 如果查询中包含 ORDER BY 或 GROUP BY 子句，MySQL 可能需要在内存中进行排序或分组操作。这会消耗内存，尤其是当数据量很大时。
连接（JOIN）操作：
- 如果查询中包含连接操作，MySQL 可能需要在内存中处理连接缓冲区，这也会消耗内存。
临时表：
- 对于复杂的查询，MySQL 可能会创建临时表来存储中间结果。如果临时表很大，可能会占用大量内存。
MySQL 配置参数：
- MySQL 的一些配置参数，如 innodb_buffer_pool_size、sort_buffer_size、join_buffer_size、tmp_table_size 和 max_heap_table_size，都会影响内存的使用。这些参数定义了 MySQL 使用的内存缓冲区的大小。
服务器硬件资源：
- 服务器的总内存大小、可用内存以及 CPU 性能也会影响查询的执行和内存的使用。

为了防止内存飙升，可以采取以下措施：

限制查询结果：使用 LIMIT 子句限制返回的行数，避免一次性返回大量数据。
优化查询：确保查询是优化的，使用索引，避免不必要的排序和连接操作。
调整 MySQL 配置：根据服务器的硬件资源和工作负载，调整 MySQL 的配置参数，确保不会因为缓冲区过大而导致内存不足。
分页查询：如果需要处理大量数据，可以考虑分页查询，逐步处理数据。
使用存储过程或应用程序逻辑：在应用程序层面处理数据，而不是一次性从数据库中获取所有数据。

总之，执行 SELECT * FROM 语句查询一个包含 1000 万行的表可能会导致内存使用增加，但是否飙升取决于多种因素。通过优化查询和调整 MySQL 配置，可以控制内存的使用，避免内存不足的问题。

消息队列设计成推消息还是拉消息？推拉模式的优缺点？

在消息队列设计中，消息的传递方式主要有两种模式：推模式（Push）和拉模式（Pull）。这两种模式各有优缺点，适用于不同的场景。

推模式（Push）

优点：

实时性高：消息生产者一旦有新消息，消息队列会立即推送给消费者，确保消费者能够实时接收到消息。
简化消费者逻辑：消费者不需要主动请求消息，减少了消费者的复杂性。
适合消费者处理能力有限的情况：如果消费者处理能力有限，推模式可以控制消息的发送速度，避免消费者被大量消息压垮。

缺点：

可能造成资源浪费：如果消费者暂时无法处理消息，推模式可能会导致消息堆积，占用大量内存和存储资源。
灵活性差：消费者无法根据自己的处理能力灵活地控制消息的接收速度。
可靠性问题：如果消费者在消息推送过程中出现故障，可能会导致消息丢失或重复。

拉模式（Pull）