快手 Java 面经，根据项目一顿拷打 | 0302

1. 负载均衡是怎么做的，如何实现一直均衡给一个用户

负载均衡实现的一般步骤：

1. 识别负载均衡的需求： 首先需要确定在网络中的哪些资源需要进行负载均衡，如 Web 服务器、应用服务器或数据库服务器等。
2. 选择负载均衡算法： 根据具体的需求选择合适的负载均衡算法，常见的算法包括轮询（Round Robin）、加权轮询（Weighted Round Robin）、最小连接数（Least Connection）等。
3. 配置负载均衡器： 配置负载均衡器，设置负载均衡的规则和算法。这包括指定要均衡的服务器、配置健康检查（Health Check）机制以及设置负载均衡策略等。
4. 请求分发： 当用户发送请求时，负载均衡器会根据选定的算法将请求分发到相应的服务器上。
5. 监控和调整： 监控服务器的负载情况，根据需要动态调整负载均衡策略，以确保各服务器的负载保持均衡。

实现一直均衡给一个用户可能涉及不同的需求和场景，可以通过一些特定的策略来实现：

• 基于 IP 地址的持续连接（IP Stickiness）： 通过将用户的请求路由到同一台服务器，以确保用户的会话状态在同一服务器上保持。这通常通过在负载均衡器上配置 IP 地址和服务器的映射关系来实现。
• 会话保持（Session Affinity）： 类似于 IP Stickiness，但是更加灵活，可以基于用户的会话信息（如 Cookie）来实现，以确保用户的会话状态在同一服务器上保持。
• 动态负载均衡策略： 除了静态配置的负载均衡策略外，还可以根据用户的负载情况和服务器的负载情况动态调整负载均衡策略，以实现持续的均衡。

2. 服务熔断

服务熔断（Circuit Breaker）是一种用于构建分布式系统的设计模式，用于增强系统的稳定性和可靠性。服务熔断的核心思想是在出现服务故障或异常时，及时地中断对该服务的请求，防止故障进一步扩散，并且允许系统在出现问题时快速失败而不是无限期地等待响应。

服务熔断的用途和优势包括：

1. 防止级联故障： 当某个服务或组件出现故障时，服务熔断可以快速地停止对该服务的请求，防止故障扩散到其他部分，从而保护整个系统的稳定性。
2. 快速失败： 服务熔断允许系统在出现问题时快速失败，而不是等待超时，这可以减少用户等待时间，并快速释放资源以减轻系统负担。
3. 降级处理： 当服务熔断触发时，可以采取降级处理策略，例如返回预先定义的默认值、执行备用逻辑或者从缓存中获取数据，以保证系统的基本功能继续可用。
4. 自我修复： 当服务熔断一段时间后，可以尝试重新发起请求，如果服务恢复正常，则关闭熔断器，继续正常提供服务。

常见问题和挑战包括：

1. 熔断器状态管理： 需要有效地管理熔断器的状态，包括打开、关闭和半开状态的切换，以及对状态的监控和调整，确保熔断器的行为符合预期。
2. 故障诊断和处理： 需要及时地检测和诊断服务的故障，并采取相应的措施进行处理，例如记录错误日志、发送警报通知等。
3. 降级策略设计： 需要设计合适的降级处理策略，以保证在服务熔断时系统依然能够提供基本的功能，而不影响用户体验。
4. 性能影响： 在服务熔断时，可能会增加系统的负载和响应时间，因此需要合理评估熔断器的触发条件和恢复机制，以减少性能影响。

总的来说，服务熔断是一种重要的分布式系统设计模式，通过及时地中断对故障服务的请求，可以提高系统的稳定性和可靠性，但同时也需要综合考虑各种因素，合理设计和管理熔断策略，以确保系统的正常运行。

3. 服务降级

服务降级（Service Degradation）是一种在面对系统资源不足或者系统负载过大时，为了保证系统的核心功能或者关键服务的可用性而采取的一种策略。服务降级的核心思想是在系统压力过大时，有选择性地降低非核心或次要功能的服务质量，以确保系统的核心功能仍然能够正常运行。

服务降级的目的在于保证系统在遇到异常或高负载情况下仍能够提供基本的服务能力，从而提高系统的稳定性和可用性。在实际应用中，服务降级通常伴随着一些特定的策略和实践，例如：

1. 优先级划分： 将系统中的功能和服务按照其重要性和优先级进行划分，确保核心功能拥有更高的优先级，并在资源不足时优先保证核心功能的运行。
2. 限流和限速： 通过限制对系统的访问速率或者并发请求数量，以防止系统过载，从而减轻系统负载压力。
3. 降级策略设计： 设计合适的降级策略，当系统资源不足或者系统负载过大时，有选择性地降低非核心功能或次要功能的服务质量，例如降低服务响应时间、减少服务数据的返回量等。
4. 实时监控和调整： 实时监控系统的负载情况和性能指标，根据实际情况动态调整降级策略，以确保系统的稳定性和性能表现。

服务降级的优点包括：

• 提高系统的稳定性： 在面对异常情况或者高负载情况时，通过降级非核心功能或次要功能的服务质量，可以确保系统的核心功能仍能够正常运行，从而提高系统的稳定性。
• 保证核心功能的可用性： 通过有选择性地降级非核心功能或次要功能，可以确保系统的核心功能在异常或高负载情况下仍能够提供基本的服务能力，从而保证核心功能的可用性。
• 减少系统压力： 通过降级非核心功能或次要功能的服务质量，可以减少系统的负载压力，从而提高系统的整体性能和响应速度。

服务降级也存在一些潜在的缺点

• 可能影响用户体验
• 需要精细的策略设计和实时监控
• 可能引起业务方面的不满等。 因此，在实施服务降级策略时，需要综合考虑各种因素，并设计合理的降级策略，以确保系统的整体性能和用户体验。

4. Spring的IOC

Spring框架中的IOC（Inverse of Control，控制反转）是一种设计原则，也是Spring框架的核心之一。IOC的概念是指控制权的转移，即将对象的创建、依赖注入和生命周期管理等控制权交给了容器来管理，而不是由对象自己来控制。这种控制反转的思想使得应用程序的组件之间的关系变得更加灵活、可维护和可测试。

在Spring框架中，IOC的实现主要通过依赖注入（Dependency Injection，DI）来实现。依赖注入是指容器负责在对象创建的同时，自动将对象所依赖的其他对象注入到它们之中，而不是由对象自己来创建或查找依赖的对象。

Spring框架通过XML配置文件、注解或Java代码来描述对象之间的依赖关系，然后由Spring容器在运行时根据这些配置来实现依赖注入。通过IOC容器管理对象之间的依赖关系，使得应用程序的组件解耦，提高了代码的灵活性和可维护性。

Spring的IOC容器通过控制对象之间的依赖关系，实现了对象之间的解耦，提高了代码的灵活性和可测试性，是Spring框架的核心特性之一。

5. 为什么依赖注入不适合使用字段注入

依赖注入有三种主要的方式：构造函数注入、Setter方法注入和字段注入。虽然字段注入是最简洁的一种方式，但它也存在一些问题，这就是为什么在某些情况下不推荐使用字段注入的原因。

1. 可测试性差： 字段注入使得依赖关系被硬编码到了类的字段中，这导致在进行单元测试时很难对这些依赖进行模拟或替换。因为字段注入的依赖是直接赋值给类的字段，而不是通过构造函数或Setter方法来传递，所以在测试时很难通过传入不同的依赖实例来进行测试。
2. 难以追踪依赖关系： 使用字段注入时，依赖关系是通过字段直接注入到类中的，这使得依赖关系不够明确，很难追踪类与其依赖之间的关系。这可能导致代码的可读性和可维护性下降。
3. 耦合性高： 字段注入使得依赖关系与类的实现紧密耦合在一起，从而增加了类与其依赖之间的耦合性。当需要修改依赖关系时，可能需要修改类的字段定义，这违反了开闭原则。

相比之下，构造函数注入和Setter方法注入提供了更好的解耦性和可测试性。构造函数注入将依赖关系通过构造函数传入，而Setter方法注入则通过Setter方法设置依赖。这两种方式都能够清晰地标识出类与其依赖之间的关系，提高了代码的可读性和可维护性，同时也更易于进行单元测试和模拟依赖。因此，在使用依赖注入时，推荐优先考虑使用构造函数注入或Setter方法注入，而尽量避免使用字段注入。

6. Spring的aop

Spring框架中的AOP（Aspect-Oriented Programming，面向切面编程）是一种编程范式，它允许开发者通过将横切关注点（Cross-cutting Concerns）从核心业务逻辑中分离出来，从而提高了代码的模块化程度和可维护性。横切关注点包括日志记录、事务管理、安全检查等与核心业务逻辑无关的功能。

AOP的核心概念是切面（Aspect），切面是一个模块化单元，它封装了横切关注点，并定义了在何处、何时应用这些关注点。在Spring框架中，切面通常以Java类的形式存在，并且通过特定的注解或XML配置来定义切面。

Spring框架提供了几种实现AOP的方式：

1. 基于代理的AOP： Spring使用动态代理来实现AOP。当一个类被AOP代理后，方法调用会被拦截，从而允许切面在方法调用前、后或者出现异常时执行额外的逻辑。Spring中的基于代理的AOP主要使用JDK动态代理和CGLIB动态代理来实现。
2. 切点和通知： 切点（Pointcut）用于定义在哪些连接点（Join Point）应用切面逻辑，通知（Advice）用于定义切面的行为。Spring框架提供了几种通知类型，包括前置通知（Before Advice）、后置通知（After Advice）、返回通知（After Returning Advice）、异常通知（After Throwing Advice）和环绕通知（Around Advice）。
3. 切面表达式： Spring提供了切面表达式语言（AspectJ Expression Language），通过切面表达式可以更精确地定义切点，并在切面中应用通知。切面表达式支持基于方法签名、参数、注解等方式来定义切点。

通过AOP，开发者可以将横切关注点模块化，避免代码重复和耦合度增加，从而提高代码的可维护性和可重用性。在Spring框架中，AOP常用于日志记录、事务管理、安全检查等方面，使得这些与核心业务逻辑无关的功能可以被统一管理和应用。

7. Spring的事务，使用this调用是否生效

在Spring中，使用this调用方式调用类的方法时，事务是生效的。Spring的事务是基于代理实现的，当一个类被Spring的事务代理包装后，所有对该类的方法的调用，包括通过this调用方式，都会被代理拦截。因此，即使使用this调用方式，Spring的事务管理仍然能够生效。

这是因为Spring的事务是通过AOP实现的，通常使用基于代理的AOP来处理事务。在基于代理的AOP中，Spring会为目标对象创建一个代理对象，而调用该代理对象的方法时，会触发AOP的通知，从而实现事务的管理。因此，无论是直接调用目标对象的方法，还是通过this调用方式调用目标对象的方法，Spring都能够正确地拦截并管理事务。

总之，Spring的事务是基于代理实现的，因此无论通过何种方式调用目标对象的方法，Spring的事务管理都会生效。

8. Spring的循环依赖

在 Spring 中，循环依赖是指两个或多个 Bean 之间互相依赖的情况，导致 Bean 的创建发生循环，从而无法完成依赖注入的过程。这种情况可能会导致应用程序启动失败或者出现不可预测的行为。

Spring 框架提供了一些解决循环依赖的机制：

1. 提前曝光（Early Exposure）： Spring 容器在创建 Bean 的过程中，会提前暴露正在创建的 Bean 实例，以解决循环依赖的问题。当一个 Bean A 依赖另一个 Bean B，而 Bean B 又依赖 Bean A 时，Spring 在创建 Bean A 的过程中，会提前暴露一个代理对象，用于处理 Bean B 对 Bean A 的依赖。这样，Bean A 可以在被完全创建之前，通过代理对象来访问 Bean B。这种方式需要使用 CGLIB 来创建代理对象。
2. 构造函数注入： 使用构造函数注入来解决循环依赖问题。Spring 容器在创建 Bean 的过程中，会首先将依赖项通过构造函数传递进去，从而避免了循环依赖的问题。这种方式需要谨慎使用，因为构造函数注入会将循环依赖暴露在类的构造函数中，可能导致代码不够清晰。
3. Setter 方法注入： 使用 Setter 方法注入来解决循环依赖问题。与构造函数注入类似，通过将依赖项通过 Setter 方法注入，可以避免循环依赖的问题。与构造函数注入相比，Setter 方法注入更加灵活，可以在 Bean 创建完成后再进行依赖注入，但也需要注意循环依赖可能带来的问题。

虽然 Spring 提供了这些解决循环依赖的机制，但是在设计应用程序时，尽量避免出现循环依赖是更好的选择。循环依赖会导致代码的复杂性增加，降低程序的可维护性和可读性。

9. Spring MVC的工作流程；如果是传输文件呢

Spring MVC（Model-View-Controller）是一个基于Java的Web框架，用于开发Web应用程序。它遵循经典的MVC设计模式，将应用程序划分为模型（Model）、视图（View）和控制器（Controller）三个部分，以实现松耦合和模块化开发。

Spring MVC的工作流程：

1. 客户端发起请求： 客户端（通常是浏览器）向服务器发起请求，请求由Servlet容器（如Tomcat）接收。
2. DispatcherServlet拦截请求： 请求被DispatcherServlet拦截，DispatcherServlet是Spring MVC的核心控制器，负责统一管理请求的调度和分发。
3. HandlerMapping确定处理器： DispatcherServlet通过HandlerMapping将请求映射到对应的处理器（Controller）上。
4. 处理器执行请求： 处理器根据请求的映射，执行相应的业务逻辑，并返回一个ModelAndView对象，其中包含了处理结果数据和视图名称。
5. ViewResolver解析视图： ModelAndView中的视图名称被ViewResolver解析为具体的视图对象，视图对象可以是JSP页面、Thymeleaf模板等。
6. 视图渲染： 视图对象将处理结果数据渲染到具体的视图中。
7. 响应返回客户端： 渲染后的视图最终以响应的形式返回给客户端。

传输文件时的工作流程：

如果在Spring MVC中需要传输文件，通常使用multipart/form-data类型的表单来上传文件。工作流程与上述流程类似，但有一些不同之处：

1. 客户端发送包含文件的请求： 客户端通过表单提交包含文件的请求。
2. DispatcherServlet拦截请求： 请求被DispatcherServlet拦截。
3. MultipartResolver解析请求： DispatcherServlet使用MultipartResolver解析包含文件的请求，将请求中的文件内容解析为MultipartFile对象。
4. HandlerMapping确定处理器： 请求被映射到相应的处理器（Controller）上。
5. 处理器处理文件上传： 处理器接收到请求后，处理文件上传操作，通常会将文件保存到服务器本地或进行其他操作。
6. 处理器返回响应： 处理器返回处理结果。
7. 视图渲染或直接返回响应： 如果需要，视图渲染将处理结果渲染到视图中；如果不需要，直接返回响应给客户端。

10. Kafka如何保证消息不丢失

Kafka 是一个分布式流处理平台，它使用一些机制来确保消息不丢失：

1. 持久化到磁盘： Kafka 将消息持久化到磁盘上的文件中，这样即使在消息被处理之前，它们也可以被持久化和存储。因此，即使发生系统故障或者重启，消息也不会丢失。
2. 复制机制： Kafka 通过副本机制来提供高可用性和容错性。在 Kafka 集群中，每个分区的数据都会被复制到多个 Broker 上。这些副本中的一个被选为 Leader，负责处理所有的读写请求，其他副本作为 Followers，用于备份数据。如果 Leader 失效，Kafka 将自动从 Followers 中选举出新的 Leader，从而保证数据的可用性和一致性。
3. 消息确认机制： Kafka 提供了消息确认机制，可以确保消息被成功写入到 Broker 中。生产者可以选择等待 Broker 的确认信息，以确保消息被成功复制到指定数量的副本中后再发送下一条消息。这样可以避免消息丢失，但可能会降低消息的发送速度。
4. 持久化日志： Kafka 使用持久化日志来存储消息，这使得即使在发生异常情况下，消息也不会丢失。Kafka 的存储机制允许在消息被消费之前将其保留在日志中。

Kafka 使用持久化、复制机制、消息确认和持久化日志等多种机制来确保消息不丢失。这些机制使得 Kafka 成为一个可靠的消息系统，适用于处理关键业务数据和高吞吐量的场景。

11. Kafka如何保证消息不重复消费

Kafka 使用消费者组（Consumer Group）来确保消息不重复消费的机制，具体方式如下：

1. 分区和偏移量： Kafka 将每个主题（Topic）划分为多个分区（Partition），每个分区包含一个有序的消息序列。消费者在消费消息时，会按照分区的顺序消费消息。而每个分区中的消息都有一个唯一的偏移量（Offset），用来标识消息在分区中的位置。
2. 消费者组： 消费者可以组成消费者组，一个消费者组中可以包含一个或多个消费者。每个消费者组对于一个主题的每个分区都可以有一个或多个消费者，但是一个分区只能被同一个消费者组中的一个消费者消费。消费者组中的消费者之间协调消费任务，每个消费者负责消费分区中的一部分消息。
3. 偏移量的管理： 每个消费者都会记录自己消费的分区和偏移量，以便在重启或者重分配分区时能够继续消费之前的消息。消费者将消费的最新偏移量保存在 Kafka 中的内部主题（__consumer_offsets）中。
4. 消费者组协调器： Kafka 集群中的一个特殊的 Broker 会负责充当消费者组的协调器（Consumer Group Coordinator），它负责分配分区给消费者组中的消费者，并确保每个分区只被一个消费者消费。

通过以上机制，Kafka 确保了消息不重复消费的原则：

• 消费者组内的每个消费者负责消费不同的分区，确保了分区内消息的顺序性。
• 消费者组中的消费者协调分配分区，避免了多个消费者同时消费同一个分区的情况。
• 消费者记录消费的偏移量，以便在重启或者重分配分区时能够继续消费之前的消息。

Kafka 通过消费者组、分区和偏移量的管理机制来保证消息不重复消费，从而确保了消息处理的准确性和一致性。

12. MySQL的三大日志

1. 二进制日志（Binary Log）： 二进制日志记录了数据库中所有的修改操作，以二进制格式保存。这些操作包括数据的插入、更新、删除以及数据结构的更改（如表结构的修改）。二进制日志对于数据库的备份、复制和恢复非常重要。

2. 重做日志（Redo Log）： 重做日志是InnoDB存储引擎特有的日志类型。它记录了数据库中每个事务所做的修改操作，但与二进制日志不同，重做日志以物理格式记录。重做日志用于数据库的恢复，以保证事务的持久性和一致性。

3. 撤销日志（Undo Log）： 撤销日志也是InnoDB存储引擎特有的日志类型。它记录了事务执行过程中所做的修改操作的逆操作，用于回滚事务、处理并发事务和提供数据库的一致性视图。

13. ElasticSearch如何进行全文检索

Elasticsearch 是一个分布式、RESTful 风格的搜索和分析引擎，它提供了强大的全文检索功能。下面是 Elasticsearch 如何进行全文检索的简要流程：

1. 创建索引（Index）： 在 Elasticsearch 中，数据被组织在索引中。索引类似于关系型数据库中的数据库，用于存储一类相关的数据。在进行全文检索之前，首先需要为数据创建一个索引。
2. 添加文档（Document）： 在索引中添加文档，文档是 Elasticsearch 中存储的基本单位。文档通常是 JSON 格式的数据，可以包含一个或多个字段，每个字段包含一个或多个值。
3. 建立映射（Mapping）： 映射定义了文档中每个字段的数据类型和分析方式。在创建索引时，可以自定义字段的映射，或者让 Elasticsearch 根据文档的结构自动推断映射。
4. 执行搜索请求： 通过发送搜索请求来进行全文检索。搜索请求可以包含一个或多个查询条件，Elasticsearch 将根据这些条件来匹配文档，并返回符合条件的结果。
5. 分析查询条件： Elasticsearch 会对查询条件进行分析，将查询条件解析为一个或多个查询子句。查询子句包括词项查询、短语查询、范围查询等，用于匹配文档中的字段值。
6. 执行查询： Elasticsearch 执行查询操作，并使用倒排索引来快速定位匹配的文档。倒排索引是一种将文档中的每个词项映射到包含该词项的文档列表的数据结构，可以高效地进行全文检索。
7. 评分和排序： Elasticsearch 根据匹配度对搜索结果进行评分，并按照评分对结果进行排序。评分是根据文档与查询条件的匹配程度来计算的，匹配度越高的文档排名越靠前。
8. 返回搜索结果： Elasticsearch 返回符合查询条件的文档结果，通常包括文档的 ID、分数和其他字段值等信息。

Elasticsearch 的全文检索流程包括创建索引、添加文档、建立映射、执行搜索请求、分析查询条件、执行查询、评分和排序以及返回搜索结果等步骤。通过这些步骤，Elasticsearch 可以高效地进行全文检索，并返回符合查询条件的文档结果。

14. 除了IK分词器还用到哪些分词器

除了 IK 分词器外，Elasticsearch 还有其他常用的分词器，例如：

1. Standard 分词器： 标准分词器是 Elasticsearch 默认的分词器，它是一个基于 Unicode 标准的分词器，按照单词边界进行分词，支持多种语言。
2. Whitespace 分词器： 空格分词器根据空格字符将文本分割成单词，适合处理英文文本或者不需要分词的场景。
3. Simple 分词器： 简单分词器是一个非常简单的分词器，根据非字母字符将文本分割成单词，适用于处理非结构化文本数据。
4. Lowercase 分词器： 小写分词器将文本转换为小写，然后使用标准分词器进行分词，适用于处理不区分大小写的场景。
5. Keyword 分词器： 关键字分词器将整个文本作为一个单词，适用于不需要分词的场景，通常用于对字段进行精确匹配或者聚合操作。
6. Pattern 分词器： 模式分词器根据指定的正则表达式将文本分割成单词，适用于需要根据特定规则进行分词的场景。
7. Stop 分词器： 停止词分词器将指定的停止词（如常见的连接词、介词等）从文本中移除，适用于需要去除停止词的场景。
8. Snowball 分词器： 雪球分词器支持多种语言的词干提取，可以将单词转换为其词干形式，适用于需要进行词干提取的场景。

15. 分词器的底层实现

分词器（Tokenizer）在 Elasticsearch 中的底层实现通常是基于 Lucene 的分词器实现的。Lucene 是一个开源的全文搜索引擎库，Elasticsearch 是基于 Lucene 构建的分布式搜索和分析引擎，因此它继承了 Lucene 强大的分词器功能。

在 Lucene 中，分词器负责将文本按照一定规则进行分词，生成一个个词项（Term）。词项是搜索的基本单位，是搜索引擎索引中的最小单元。分词器根据具体的语言、词汇、文法等规则将文本分割成不同的词项，然后进行索引和搜索。

分词器的底层实现通常包括以下几个方面：

1. 字符解析： 分词器首先将输入的文本字符流进行解析，识别出文本中的单词、标点符号、数字等字符。
2. 词项生成： 根据一定的规则，分词器将解析后的字符流进行分割，生成一个个词项。词项的生成方式可以根据具体的分词器实现而不同，例如基于词典、规则、统计信息等。
3. 词项过滤： 在生成词项的过程中，分词器可能会对词项进行过滤，去除一些不需要的词项，例如停止词（Stop Words）等。
4. 词干提取： 有些分词器会对词项进行词干提取，将词项转换为其原始形式，以提高搜索的准确性和召回率。
5. 标记位置和偏移量： 分词器还会为每个词项记录其在文本中的位置和偏移量，以便后续索引和搜索操作。
6. 分词器链： 在 Elasticsearch 中，可以通过配置多个分词器来构建一个分词器链（Tokenizer Chain），每个分词器依次对输入的文本进行处理，生成词项序列。

分词器的底层实现是基于 Lucene 的分词器实现的，它通过对文本进行解析、分割、过滤、词干提取等操作，生成词项序列，为搜索引擎的索引和搜索提供了基础支持。在 Elasticsearch 中，分词器的实现可以根据具体的需求和场景进行自定义和配置。

16. 线性的数据结构（链表和数组），有什么区别

链表和数组是两种常见的线性数据结构，它们之间有一些区别，主要包括以下几个方面：

1. 内存分配方式：
   • 数组在内存中是一段连续的内存空间，每个元素都占据固定大小的内存空间，可以通过索引直接访问任意位置的元素。
   • 链表中的元素在内存中不是连续存储的，每个元素包含一个指向下一个元素的指针，通过指针将各个元素连接起来，因此在链表中访问元素需要从头节点开始遍历。
2. 插入和删除操作：
   • 数组的插入和删除操作比较低效，因为需要移动大量元素来维持连续的内存空间。在最坏情况下，时间复杂度为 O(n)。
   • 链表的插入和删除操作相对高效，只需要修改相邻元素的指针，时间复杂度为 O(1)。
3. 查找操作：
   • 数组的查找操作比较高效，可以通过索引直接访问元素，时间复杂度为 O(1)。
   • 链表的查找操作比较低效，需要从头节点开始遍历链表，直到找到目标元素或者到达链表末尾，时间复杂度为 O(n)。
4. 空间复杂度：
   • 数组需要一块连续的内存空间来存储所有元素，因此需要预先分配足够的空间，如果空间不足需要进行扩容操作。
   • 链表不需要预先分配连续的内存空间，可以动态分配内存，因此可以灵活地处理不同大小的数据集。

数组和链表各有优缺点，选择使用哪种数据结构取决于具体的应用场景和需求。如果需要频繁进行插入和删除操作，且数据量不确定，可以选择链表；如果需要频繁进行查找操作，且数据量相对稳定，可以选择数组。

17. 如何使用两个栈实现队列

使用两个栈实现队列的基本思路是，利用一个栈作为入队栈，用于存储入队的元素；另一个栈作为出队栈，用于存储出队的元素。具体实现如下：

1. 入队操作：
   • 将元素压入入队栈中即可。
2. 出队操作：
   • 如果出队栈为空，将入队栈中的所有元素依次弹出并压入出队栈中，然后从出队栈中弹出栈顶元素；
   • 如果出队栈不为空，直接从出队栈中弹出栈顶元素。

使用两个栈实现队列的关键在于在出队操作时将入队栈的元素倒序压入出队栈中，从而实现队列的先进先出（FIFO）的特性。

下面是使用 Python 语言实现的示例代码：

class MyQueue:
    def __init__(self):
        self.in_stack = []  # 入队栈
        self.out_stack = []  # 出队栈

    def push(self, x: int) -> None:
        self.in_stack.append(x)

    def pop(self) -> int:
        if not self.out_stack:
            while self.in_stack:
                self.out_stack.append(self.in_stack.pop())
        return self.out_stack.pop()

    def peek(self) -> int:
        if not self.out_stack:
            while self.in_stack:
                self.out_stack.append(self.in_stack.pop())
        return self.out_stack[-1]

    def empty(self) -> bool:
        return not self.in_stack and not self.out_stack

这样实现的队列的时间复杂度为：

• 入队操作的时间复杂度为 O(1)；
• 出队操作的平均时间复杂度为 O(1)；
• 空间复杂度为 O(n)。

18. Dns基于什么协议实现，为什么是udp

DNS（Domain Name System，域名系统）是基于 UDP（User Datagram Protocol，用户数据报协议）实现的。

UDP 是一种无连接的、不可靠的传输层协议，它不提供数据包的可靠性、流量控制和拥塞控制等功能，但它具有简单、轻量、低延迟的特点。而 DNS 的设计目标是快速响应用户查询，并且要求尽可能地减小网络通信的延迟，因此选择了 UDP 作为 DNS 协议的传输层协议。

DNS 之所以选择 UDP 而不是 TCP，主要是出于以下考虑：

1. 低延迟： UDP 相对于 TCP 更加轻量，不需要建立连接、维护连接状态和进行错误重传等操作，因此可以减小网络通信的延迟，适合对延迟要求较高的场景。
2. 简单快速： UDP 头部较小，没有 TCP 那样的连接管理和流量控制机制，因此可以更快速地发送和接收数据，减小数据包的大小，降低网络负载。
3. 高并发： UDP 不需要维护连接状态，每个 UDP 数据包都是独立的，因此可以支持更高的并发连接数，适合于 DNS 服务器处理大量并发的查询请求。

尽管 UDP 存在丢包和数据包损坏的风险，但在 DNS 的设计中，这些风险是可以被容忍的。DNS 使用了一些机制来提高可靠性，例如查询超时重传、请求重试、缓存等，以确保数据传输的可靠性和正确性。

总的来说，DNS 选择 UDP 作为传输层协议，是为了追求更低的延迟、更高的性能和更好的并发能力，同时通过其他机制来提高数据传输的可靠性。

19. http的特点

HTTP（Hypertext Transfer Protocol，超文本传输协议）是一种用于传输超文本数据（如 HTML）的应用层协议，它是现代 Web 通信的基础。HTTP 的特点包括以下几个方面：

1. 无连接性（Connectionless）： HTTP 是一种无连接的协议，每次请求-响应周期都是相互独立的，服务器在收到客户端请求并发送响应后立即断开连接。这种特点使得 HTTP 的连接开销较小，适用于短时交互的通信场景。
2. 无状态性（Stateless）： HTTP 是一种无状态的协议，即服务器不会维护客户端的状态信息。每个请求都是独立的，服务器不能识别两个请求是否来自同一个客户端。这种特点简化了服务器的设计和实现，但也限制了 HTTP 在一些需要保持状态的场景下的应用。
3. 基于文本（Text-based）： HTTP 使用文本格式的请求和响应消息进行通信，消息头部包含了一系列的键值对，用于描述消息的属性和特征，消息体则包含了具体的数据内容。这种基于文本的格式使得 HTTP 的消息易于阅读和理解，并且可以使用简单的文本编辑器进行调试和修改。
4. 支持多媒体类型（Media-independent）： HTTP 不仅可以传输 HTML 文档，还可以传输各种不同类型的多媒体数据，如图片、音频、视频等。HTTP 使用 MIME（Multipurpose Internet Mail Extensions）标准来描述和传输多媒体数据。
5. 灵活性（Flexibility）： HTTP 是一种灵活的协议，支持多种不同的请求方法（如 GET、POST、PUT、DELETE 等）、状态码（如 200 OK、404 Not Found、500 Internal Server Error 等）和头部字段（如 Content-Type、Content-Length、Cache-Control 等），可以根据具体的需求和场景进行定制和扩展。

HTTP 是一种简单、灵活、文本化的应用层协议，具有无连接性、无状态性、基于文本、支持多媒体类型和灵活性等特点，适用于传输超文本数据和多媒体数据的通信场景。

20. http无状态体现在哪

HTTP 的无状态性体现在服务器不会在请求之间保存客户端的状态信息。具体来说，无状态性表现在以下几个方面：

1. 每个请求独立性： HTTP 是一种无连接的协议，每个请求-响应周期都是相互独立的，服务器在收到客户端请求并发送响应后立即断开连接。因此，服务器不能识别两个请求是否来自同一个客户端，也无法知道这两个请求之间是否存在关联性。
2. 不保存客户端状态： 服务器不会保存客户端的状态信息，即服务器在处理每个请求时都是无状态的。客户端发送的每个请求都必须包含足够的信息来描述其自身的状态，服务器在处理请求时不能依赖之前的请求状态。
3. 状态信息在客户端： 为了维护客户端的状态信息，客户端通常会在请求中包含一些标识符或者会话令牌（如 Cookie 或者 Session ID），服务器在接收到请求后会解析这些信息并根据需要进行处理。这种方式使得客户端的状态信息保存在客户端而不是服务器端，从而实现了无状态性。
4. 灵活性： HTTP 的无状态性提供了灵活性，允许服务器在处理请求时不受之前请求的影响，可以根据当前请求的情况来进行处理。这种灵活性使得服务器可以更好地应对不同客户端的请求，并且使得 HTTP 协议更易于扩展和部署。

HTTP 的无状态性意味着服务器在处理每个请求时都是独立的、无状态的，不会保存客户端的状态信息，从而提高了服务器的灵活性和可伸缩性。

21. Cookie和session的区别

Cookie 和 Session 都是用来在客户端和服务器之间保存状态信息的机制，但它们有一些区别：

1. 存储位置：
   • Cookie 是存储在客户端的一小段文本信息，以键值对的形式保存在客户端的浏览器中。
   • Session 是存储在服务器端的一种会话状态，通常存储在服务器内存、数据库或者其他持久化存储介质中。
2. 安全性：
   • Cookie 存储在客户端的浏览器中，因此相对不安全，可能被篡改或者盗用。
   • Session 存储在服务器端，相对安全，客户端无法直接访问或修改。
3. 容量限制：
   • Cookie 的大小通常有限制，一般不超过 4KB。
   • Session 的大小没有明确限制，受服务器资源和配置的影响，可以存储更多的信息。
4. 生命周期：
   • Cookie 可以设置过期时间，在设置的过期时间之前一直保存在客户端，可以长期保存。
   • Session 的生命周期由服务器控制，通常在客户端关闭后自动失效，也可以手动设置过期时间。
5. 存储内容：
   • Cookie 可以存储任意类型的数据，但是由于存储在客户端，不适合存储敏感信息。
   • Session 可以存储任意类型的数据，因为存储在服务器端，可以存储敏感信息。
6. 传输方式：
   • Cookie 在 HTTP 头部中通过 Set-Cookie 和 Cookie 字段进行传输。
   • Session 通常通过在 Cookie 中保存 Session ID 来实现，客户端每次请求时将 Session ID 发送给服务器，服务器根据 Session ID 查找对应的会话状态。

Cookie 和 Session 是两种不同的状态管理机制，它们在存储位置、安全性、容量限制、生命周期、存储内容和传输方式等方面存在一些区别，开发人员需要根据具体的需求和场景选择合适的机制来管理状态信息。