1230java面经-EW帮帮网

1,有没有一些定位层面上,代码层面上的,比如遇到一些case,定位好几天没定位出来,比如超时、内存泄露、性能优化case?

以下是几个在实际开发中涉及定位问题比较困难的案例，分别包含超时、内存泄露和性能优化方面的情况，以及对应的解决思路：

一、超时问题案例

1. 案例背景

在开发一个基于微服务架构的电商系统时，其中订单服务需要调用库存服务来扣减库存，采用的是 HTTP 协议进行服务间通信。在进行压力测试时，发现部分订单创建操作会出现超时异常，导致订单创建失败，而随着并发量提升，超时情况愈发严重。

2. 初步定位过程

首先，查看订单服务的日志，发现大量请求在调用库存服务的接口时，长时间没有得到响应，超过了设置的 10 秒钟超时时间限制。怀疑是库存服务处理请求过慢或者网络通信出现问题。
接着，在库存服务端查看日志和监控指标，发现 CPU、内存使用率等都在正常范围，数据库查询也没有出现明显的慢查询情况，初步排除了库存服务自身性能问题导致处理缓慢的可能性。同时，网络运维团队反馈网络状况稳定，没有丢包等异常情况，这使得问题定位陷入了困境，连续几天都没能准确找到原因。

3. 深入定位与解决

进一步分析 HTTP 调用链路，通过在订单服务和库存服务的代码中添加详细的链路追踪日志，包括请求发出时间、到达对方服务时间、开始处理时间以及返回时间等信息。最终发现，在库存服务的请求拦截器中，新增了一个用于权限验证的第三方接口调用，但这个接口在高并发情况下响应不稳定，偶尔会出现阻塞等待的情况，从而导致整个库存服务对外部请求的响应被延迟，造成了订单服务调用超时。
解决办法是对这个权限验证的第三方接口调用设置合理的超时时间（比如 3 秒），并添加重试机制（重试 2 次），当超时时及时返回错误信息，避免长时间阻塞请求，经过这样的优化后，订单服务调用库存服务超时的问题得到了解决，订单创建的成功率在高并发场景下也恢复到了正常水平。

二、内存泄露问题案例

1. 案例背景

开发了一个数据处理工具，用于读取大量的文本文件（每个文件大小在几 MB 到几十 MB 不等），解析其中的数据并进行一些复杂的业务逻辑处理，然后将结果存储到数据库中。在长时间运行该工具处理海量文件后，发现服务器内存使用率不断攀升，直至最后因为内存不足导致程序崩溃，明显出现了内存泄露问题，但难以定位具体原因。

2. 初步定位过程

使用 Java 的内存分析工具（如 VisualVM）来监控程序运行时的内存情况，发现随着文件不断被处理，堆内存中的对象数量持续增加，尤其是一些自定义的数据对象（用于存储解析后的数据）占用了大量内存空间，怀疑是这些对象没有被及时回收导致内存泄露。
查看代码中对这些对象的使用逻辑，确认了在业务处理完成后都有对应的释放操作（如将对象引用置为 null 等常规做法），但内存依然不断增长，一时找不到具体是哪里的代码导致对象无法被垃圾回收器回收，连续排查了几天，从数据读取模块到业务处理模块，逐一检查代码都没有明显发现问题所在。

3. 深入定位与解决

通过 VisualVM 生成堆转储文件（heap dump），然后使用 MAT（Memory Analyzer Tool）工具对堆转储文件进行详细分析。发现存在大量的 WeakHashMap 实例，其内部包含了对那些自定义数据对象的强引用，而原本期望 WeakHashMap 的键（是一些临时使用的标识对象）在失去外部强引用后，对应的键值对能够被自动清理，但由于在业务逻辑中，错误地将这些标识对象又进行了额外的强引用保存，导致 WeakHashMap 中的键始终无法被垃圾回收，进而使得其关联的大量数据对象也一直驻留在内存中，造成了内存泄露。
解决办法是修正业务逻辑中对标识对象的引用方式，避免额外的强引用，确保 WeakHashMap 能够按照预期正常清理过期的键值对，经过这样的修改后，长时间运行该数据处理工具，内存使用率保持稳定，不再出现内存泄露导致的程序崩溃情况了。

三、性能优化问题案例

1. 案例背景

公司有一个内部使用的报表系统，基于传统的三层架构（表示层、业务逻辑层、数据访问层）开发，使用的是 Java Web 技术栈，随着业务数据量的不断增长，用户反馈报表生成速度越来越慢，尤其是一些涉及多表关联查询和大量数据聚合的复杂报表，有时需要等待几分钟甚至十几分钟才能生成，严重影响了工作效率，需要对其进行性能优化，但前期定位性能瓶颈比较困难。

2. 初步定位过程

首先，从数据库层面入手，查看数据库的监控指标，发现一些复杂报表对应的 SQL 查询语句执行时间很长，慢查询日志中有大量相关记录。对这些慢查询语句进行分析，起初认为是 SQL 编写不够优化，缺少必要的索引等情况，于是对相关表的查询字段添加了索引，但是性能提升并不明显，报表生成时间依然很长。
接着检查业务逻辑层代码，怀疑是不是在数据处理和传递过程中有过多的冗余操作或者循环嵌套导致效率低下，但经过代码审查和添加一些性能统计代码（记录每个方法的执行时间等）后，发现业务逻辑层的代码执行时间占比并不是很高，问题似乎不在这一层，这样反复排查了好几天，还是没能精准找到关键的性能瓶颈所在。

3. 深入定位与解决

使用性能剖析工具（如 JProfiler）对整个报表系统的运行过程进行详细的性能剖析，从表示层发起报表生成请求开始，到最终结果返回的全链路进行监控。最终发现，在数据访问层每次执行 SQL 查询后，将结果集映射为 Java 对象（通过 ORM 框架 MyBatis 的默认映射机制）时，由于报表的数据结构复杂，涉及大量的嵌套对象和集合，MyBatis 的默认映射方式会产生很多不必要的对象创建和数据复制操作，导致内存占用过高且耗时严重。
解决办法是针对复杂报表的查询结果，自定义 MyBatis 的结果集映射逻辑，采用更高效的映射方式（比如使用 ResultMap 并优化关联查询的映射配置，避免过多的嵌套对象创建），同时在数据库层面，根据新的查询和映射逻辑，重新调整了部分索引结构。经过这样的优化后，复杂报表的生成时间大幅缩短，平均从原来的几分钟缩短到了十几秒，显著提升了报表系统的性能。

2,dubbo和springmvc都是rpc框架是么?区别有什么?

定义与概述
- Spring MVC
  - Spring MVC 不是一个 RPC（Remote Procedure Call，远程过程调用）框架。它是一个基于 Java 的 MVC（Model - View - Controller）框架，主要用于构建 Web 应用程序。它的核心功能是将 Web 请求分发给相应的控制器（Controller）进行处理，控制器调用业务逻辑（Model），并将结果返回给视图（View）进行展示。例如，在一个简单的用户登录系统中，当用户提交登录表单后，Spring MVC 会将请求发送到对应的登录控制器，控制器验证用户信息（可能会调用服务层的业务逻辑），然后根据验证结果返回相应的视图（如登录成功页面或登录失败页面）。
- Dubbo
  - Dubbo 是一个高性能的 RPC 框架。它用于实现分布式系统中不同服务之间的远程通信和调用。Dubbo 可以让服务提供者（Service Provider）将自己的服务暴露出来，服务消费者（Service Consumer）能够像调用本地方法一样调用远程服务。例如，在一个电商系统中，订单服务可能需要调用库存服务来检查商品库存，Dubbo 可以使这两个服务在不同的服务器或者进程中进行通信，实现库存检查的功能。
架构和通信方式
- Spring MVC
  - 架构特点：遵循 MVC 架构模式，由前端控制器（DispatcherServlet）接收所有的 HTTP 请求，然后根据请求的 URL 和配置的映射关系将请求分发给对应的控制器。控制器处理请求后，将结果数据（通常是模型数据）放入 ModelAndView 对象或者直接返回数据（如 JSON 数据），视图解析器（View Resolver）根据配置找到对应的视图模板并将模型数据渲染到视图中。
  - 通信协议：主要基于 HTTP 协议进行通信。在 Web 应用中，浏览器（或者其他 HTTP 客户端）发送 HTTP 请求到服务器，服务器上的 Spring MVC 应用接收并处理这些请求。例如，在处理一个用户查询商品信息的请求时，客户端通过 HTTP GET 请求发送商品 ID，Spring MVC 应用根据这个请求在服务器内部进行处理，最后通过 HTTP 响应返回商品信息（可能是 HTML 页面或者 JSON 数据）。
- Dubbo
  - 架构特点：采用了分层架构，包括服务接口层、配置层、代理层、注册中心、监控中心等。服务提供者和服务消费者通过注册中心（如 Zookeeper）进行服务的注册和发现。当服务消费者需要调用服务时，先从注册中心获取服务提供者的地址等信息，然后通过代理层进行远程调用。Dubbo 还支持多种集群策略，如负载均衡、容错等机制，以保证服务的高可用性和高性能。
  - 通信协议：支持多种通信协议，如 Dubbo 协议、RMI 协议、HTTP 协议等。Dubbo 协议是一种自定义的高性能二进制协议，它在性能上比传统的 HTTP 协议更有优势，适用于内部服务之间的高效通信。例如，在一个微服务架构的系统中，两个微服务之间可以使用 Dubbo 协议进行通信，减少网络传输开销，提高通信效率。
应用场景和功能重点
- Spring MVC
  - 应用场景：适用于构建 Web 应用的后端服务，特别是那些需要生成动态网页或者提供 RESTful API 服务的场景。例如，开发一个企业级的 Web 管理系统，包括用户管理、权限管理、资源管理等功能，Spring MVC 可以很好地处理各种 HTTP 请求，将业务逻辑和视图展示分离开来，方便开发和维护。
  - 功能重点：侧重于请求的处理和分发、视图的渲染以及与 Web 相关的功能，如表单处理、文件上传、数据验证等。它提供了丰富的注解（如@Controller、@RequestMapping等）来简化 Web 开发过程，并且可以与各种视图技术（如 Thymeleaf、FreeMarker 等）相结合，实现多样化的页面展示效果。
- Dubbo
  - 应用场景：主要用于构建分布式的服务架构，在微服务系统或者大型企业级系统中，实现不同服务之间的远程调用和协作。例如，在一个金融系统中，支付服务、账户服务、风控服务等多个服务之间需要进行频繁的通信和协作，Dubbo 可以有效地管理这些服务之间的调用关系，提高系统的可扩展性和灵活性。
  - 功能重点：强调服务的注册与发现、远程调用的高性能和高可靠性、服务治理（如服务的限流、降级、灰度发布等）。Dubbo 提供了一系列的配置选项和扩展接口，可以方便地实现对服务的监控、管理和优化，以满足复杂的分布式系统需求。
性能特点
- Spring MVC
  - 由于基于 HTTP 协议进行通信，并且在处理请求过程中涉及到较多的 Web 相关操作（如请求解析、视图渲染等），在性能上相对 Dubbo 的高性能 RPC 通信方式会稍差一些。特别是在处理大量高并发的内部服务调用场景时，HTTP 协议的开销（如头部信息、文本格式传输等）可能会导致性能瓶颈。不过，对于 Web 应用中面向外部客户端（如浏览器）的请求处理，Spring MVC 的性能是可以满足大多数场景需求的。
- Dubbo
  - Dubbo 使用的高性能二进制协议（如 Dubbo 协议）在数据传输效率上比 HTTP 协议高，并且其内部的通信机制和架构设计（如连接池、异步调用支持等）也有助于提高通信性能。在处理大量内部服务之间的频繁调用场景下，Dubbo 能够展现出更好的性能优势，实现较低的延迟和较高的吞吐量，更适合构建高性能的分布式服务系统。

3，Tcp/lp模型,每一层实现了什么功能,包头信息,最主要的字段是啥,每一层单位是什么?

TCP/IP 模型通常分为四层，以下是每一层的功能、包头信息、主要字段和单位：

网络接口层

功能：负责接收 IP 数据报并通过网络发送之，或者从网络上接收物理帧，抽出 IP 数据报，交给 IP 层。它实际上兼并了物理层和数据链路层，既是传输数据的物理媒介，也可以为网络层提供一条准确无误的线路12。
包头信息及主要字段：常见的以太网帧头中包含目的 MAC 地址（6 字节）、源 MAC 地址（6 字节）和协议类型（2 字节）等。例如，0x0806 表示后面是 ARP 协议，0x0800 表示后面是 IP 协议9。
单位：帧（Frame）10。

网络层

功能：负责相邻计算机之间的通信，主要包括处理来自传输层的分组发送请求，将分组装入 IP 数据报并填充报头，选择去往信宿机的路径后将数据报发往适当的网络接口；处理输入数据报，检查其合法性并进行寻径；处理路径、流控、拥塞问题等1。
包头信息及主要字段

9
- 版本：4 位，如 IPv4 中该字段为 4。
- 首部长度：4 位，标识 IP 协议报头的大小，以 4 字节为单位，最大长度为 60 字节。
- 服务类型：8 位，包含一个 4 位优先权字段以及分别表示最小延时、最大吞吐量、最高可靠性和最小费用的位。
- 总长度：16 位，表示整个 IP 数据报的长度，最大为 65535 字节。
- 标识：16 位，唯一标识主机发送的报文，在分片时每一片的该字段相同。
- 标志：3 位，第一位保留；第二位置为 1 表示禁止分片；第三位表示更多分片，若是分片了，最后一个分片置为 1，其他置为 0。
- 片偏移：13 位，标识分片相对于原始 IP 报文开始处的偏移。
- 生存时间：1 字节，每经过一个路由器，其值自动减 1，当为 0 时，报文将被丢弃。
- 协议：1 字节，指出在上层使用的协议，如 TCP 为 6，UDP 为 17 等。
- 首部校验和：2 字节，用于检验 IP 报文头部在传播过程中是否出错。
- 源 IP 地址和目的 IP 地址：各 32 位，标识发送方和接收方的 IP 地址。
单位：数据包（Packet）2。

传输层

功能：提供应用程序间的通信，主要包括格式化信息流和提供可靠传输。对于 TCP 协议，会通过超时重传机制和发送应答机制确保数据可靠传输；UDP 协议则不为 IP 提供可靠性、流控或差错恢复功能，具有较低延迟和较高效率12。
包头信息及主要字段
- TCP 报文头
  - 源端口和目的端口：各 16 位，标识发送方和接收方的应用程序端口号。
  - 序号：32 位，一次 TCP 通信过程中某一个传输方向上的字节流的每一个字节编号。
  - 确认号：32 位，用作对另一方发送来的 TCP 报文段的响应。
  - 首部长度：4 位，指出 TCP 报文头部长度，以 4 字节为单位，若无选项内容，通常为 5，即头部为 20 字节。
  - 标志位：包含 FIN、ACK、SYN 等标志位，代表不同状态下的 TCP 数据段。
  - 窗口大小：16 位，表明当前接收端可接受的最大的数据总数。
  - 校验和：16 位，由发端计算和存储，并由收端进行验证，计算时要包括 TCP 头部和 TCP 数据，同时在 TCP 报文段的前面加上 12 字节的伪头部。
  - 紧急指针：16 位，只有当 URG 标志置 1 时有效，指出在本报文段中紧急数据共有多少个字节。
- UDP 报文头：源端口和目的端口各 16 位，标识发送方和接收方的应用程序端口号；长度 16 位，指定 UDP 报头和数据总共占用的长度；校验和 16 位，覆盖 UDP 头部和 UDP 数据9。
单位：段（Segment）或用户数据报（Datagram）2。

应用层

功能：向用户提供一组常用的应用程序，如电子邮件、文件传输访问、远程登录等，还能进行数据加密、解密、格式化等操作1。
包头信息及主要字段：不同的应用层协议有不同的包头格式和字段。例如，HTTP 协议中包含请求方法、URL、协议版本等字段；DNS 协议中包含标识、标志、问题数目、资源记录数目等字段。
单位：消息或报文（Message）2。

4，三次握手

三次握手的概念
- 三次握手是 TCP（Transmission Control Protocol）协议用于建立连接的过程。在网络通信中，TCP 协议是一种可靠的、面向连接的传输层协议。为了确保通信双方都能正确地发送和接收数据，需要通过三次握手来建立连接，这个过程就像是两个人打电话前互相确认对方是否能听到自己的声音一样。
三次握手的详细过程
- 第一次握手：客户端发起连接请求（SYN）
  - 客户端想要与服务器建立 TCP 连接时，会生成一个随机的初始序列号（Sequence Number，简称 SEQ），这个序列号是用来标识发送的数据字节流的顺序的。然后客户端将这个序列号放在 TCP 报文的序列号字段中，同时将 TCP 报文头部的同步标志位（SYN）设置为 1，表示这是一个连接请求报文。之后，客户端将这个 TCP 报文发送给服务器。例如，客户端发送的 TCP 报文可能是SYN = 1, SEQ = x，其中x是一个随机生成的初始序列号。
- 第二次握手：服务器响应并确认（SYN + ACK）
  - 服务器收到客户端的连接请求报文后，首先会检查这个请求是否合法。如果请求合法，服务器会为这个新的连接分配资源，并且生成自己的初始序列号（设为y）。然后服务器会发送一个 TCP 报文给客户端，在这个报文中，将同步标志位（SYN）设置为 1，表示这也是一个同步报文；同时将确认标志位（ACK）设置为 1，表示这是对客户端请求的确认。在确认号（ACK Number）字段中，服务器会将客户端发送的初始序列号x加 1 后的值放入，也就是ACK = x + 1，这表示服务器已经收到了客户端的序列号为x的报文。而服务器自己的序列号y则放在序列号字段中，即SYN = 1, ACK = x + 1, SEQ = y。
- 第三次握手：客户端确认（ACK）
  - 客户端收到服务器的响应报文后，会检查确认号是否正确，即是否等于自己发送的初始序列号加 1。如果正确，说明服务器已经正确收到了自己的连接请求。然后客户端会再次发送一个 TCP 报文给服务器，在这个报文中，将确认标志位（ACK）设置为 1，确认号字段中放入服务器发送的初始序列号y加 1 的值，即ACK = y + 1，序列号字段则是在第一次握手中自己发送的初始序列号x基础上，根据已经发送的数据字节数进行递增（如果没有发送数据，就还是x），此时的 TCP 报文为ACK = y + 1, SEQ = x + 1（假设没有发送其他数据）。服务器收到这个报文后，就确认客户端也能正确接收自己的信息，至此，TCP 连接成功建立。
三次握手的作用
- 确保双方的接收和发送能力
  - 通过三次握手，客户端和服务器都能够确认对方具有接收和发送数据的能力。在第一次握手时，客户端向服务器表明自己有发送数据的能力；在第二次握手时，服务器向客户端表明自己有接收和发送数据的能力；在第三次握手时，客户端再次确认自己有接收数据的能力。这样就保证了双方都能正常地进行通信。
- 同步序列号
  - 序列号在 TCP 通信中非常重要，它用于保证数据传输的顺序性和可靠性。通过三次握手，双方可以交换并确认初始序列号，使得后续的数据传输能够按照正确的顺序进行组装和处理。例如，如果没有同步序列号，数据在传输过程中可能会出现乱序或者重复接收的情况，而三次握手可以有效地避免这些问题。
- 防止失效的连接请求建立新连接（旧的重复连接请求）
  - 假设在网络环境中，客户端发送的一个连接请求报文因为网络延迟等原因，在很长时间后才到达服务器。如果没有三次握手，服务器可能会直接根据这个延迟到达的请求建立新的连接，而此时客户端可能已经放弃了这个请求或者已经建立了其他连接。通过三次握手，服务器在第二次握手时会返回一个包含客户端初始序列号的确认信息，客户端在第三次握手时会检查这个确认信息是否是自己当前请求的响应，如果不是（因为序列号已经过期或者不符合当前的请求），客户端就不会建立连接，从而避免了失效的连接请求建立新连接的情况。

5，四挥服务端如果没有数据需要传输了,它的两次挥手可不可以合为一个?

TCP 四次挥手过程回顾
- 第一次挥手：客户端发送一个 FIN（Finish）报文给服务器，表示客户端没有数据要发送了，请求关闭连接。
- 第二次挥手：服务器收到 FIN 报文后，会发送一个 ACK（Acknowledge）报文给客户端，确认收到客户端的关闭请求。此时，服务器可能还有数据需要发送给客户端，所以不能立刻关闭连接。
- 第三次挥手：当服务器也没有数据需要发送了，它会发送一个 FIN 报文给客户端，表示服务器也准备关闭连接。
- 第四次挥手：客户端收到服务器的 FIN 报文后，发送一个 ACK 报文给服务器，确认收到服务器的关闭请求，然后等待一段时间（2MSL，Maximum Segment Lifetime）后，客户端关闭连接，服务器收到 ACK 报文后也关闭连接。
为什么不能合并服务器的两次挥手
- 数据传输完整性的考虑
  - 当服务器收到客户端的第一个 FIN 报文时，虽然服务器可能没有数据需要主动发送给客户端了，但它可能处于正在处理数据或者刚刚处理完数据还没来得及发送的状态。如果将第二次和第三次挥手合并，服务器直接发送 FIN 报文，就可能导致一些已经处理但还没来得及发送的数据丢失。例如，服务器正在打包一些响应数据，收到客户端的 FIN 报文后，如果立即发送 FIN 而不发送 ACK，这些响应数据就没有机会发送给客户端了。
- 协议状态转换的要求
  - TCP 协议的状态机是非常严谨的。在收到客户端的 FIN 报文后，服务器会进入 CLOSE - WAIT（关闭等待）状态，此时它可以继续发送剩余的数据。只有当服务器确定没有数据要发送了，才会进入 LAST - ACK（最后确认）状态并发送 FIN 报文。这种状态转换机制保证了连接关闭过程的有序性和可靠性。如果合并两次挥手，就会破坏这种状态转换规则，导致协议的实现出现混乱，无法正确处理连接关闭的情况。
- 可靠性和异常处理机制
  - 分开的两次挥手可以提供更好的可靠性和异常处理能力。例如，如果服务器在发送 ACK 之后，在发送 FIN 之前，发现还有一些重要的数据需要发送或者出现了其他异常情况（如需要重新发送某些数据），它可以在 CLOSE - WAIT 状态下继续处理这些情况。而如果合并为一次挥手，就失去了这种灵活处理的机会，一旦发送了合并后的挥手报文，就相当于直接决定关闭连接，无法再对可能出现的情况进行补救。

6进程、线程、协程有何区别?

进程（Process）
- 定义
  - 进程是计算机中程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位。例如，当你在操作系统中打开一个应用程序（如浏览器），操作系统就会为这个浏览器程序创建一个进程。这个进程拥有自己独立的内存空间、文件描述符等系统资源，并且可以通过进程标识符（PID）来进行区分。
- 资源占用
  - 进程拥有独立的地址空间，这意味着每个进程都有自己的一套虚拟地址，用于访问内存中的数据。它还包括其他资源，如打开的文件、加载的动态链接库、系统分配的 CPU 时间片等。例如，两个不同的文本编辑进程在内存中存储文本内容的空间是相互独立的，不会相互干扰。
- 调度和切换成本
  - 进程的调度和切换相对复杂，成本较高。当操作系统需要从一个进程切换到另一个进程时，需要保存当前进程的上下文（包括程序计数器、寄存器状态、内存管理信息等），然后加载下一个进程的上下文。这个过程涉及到大量的系统资源和内核操作，并且可能会导致缓存的刷新等情况，因此开销较大。例如，在多任务操作系统中，从一个大型游戏进程切换到一个办公软件进程，需要操作系统进行复杂的调度和资源重新分配。
- 通信方式
  - 不同进程之间的通信相对复杂。由于它们的地址空间是独立的，通常需要使用一些特定的通信机制，如管道（Pipe）、消息队列（Message Queue）、共享内存（Shared Memory）、信号量（Semaphore）等。例如，在一个服务器应用中，主进程和子进程可能需要通过共享内存来交换数据，同时使用信号量来控制对共享内存的访问顺序和互斥性。
线程（Thread）
- 定义
  - 线程是进程中的一个执行单元，是操作系统能够进行运算调度的最小单位。一个进程可以包含多个线程，这些线程共享进程的资源，如内存空间、文件描述符等。例如，在一个浏览器进程中，可能有一个线程负责页面的渲染，一个线程负责处理用户的交互事件，一个线程负责网络请求等。
- 资源占用
  - 线程共享进程的地址空间，这是线程与进程的一个重要区别。因此，线程之间可以直接访问进程中的全局变量和堆内存等资源。不过，每个线程也有自己独立的栈空间，用于存储局部变量、函数调用的返回地址等信息。例如，在一个多线程的服务器应用中，不同线程可以共享服务器进程所加载的数据库连接池，但每个线程在处理请求时会有自己的栈空间来存储函数调用相关的信息。
- 调度和切换成本
  - 线程的调度和切换成本相对较低。因为线程共享进程的大部分资源，在切换时只需要保存和恢复线程的少量私有数据（如栈指针、程序计数器等），而不需要像进程切换那样重新加载整个地址空间等大量信息。这使得线程在多任务处理中能够更快速地进行切换，提高系统的并发性能。例如，在一个多线程的计算任务中，从一个线程切换到另一个线程的速度比在不同进程之间切换要快得多。
- 通信方式
  - 线程之间的通信相对简单，因为它们共享进程的资源。可以通过共享内存（如全局变量）来直接进行数据交换。不过，这种简单的通信方式也带来了数据同步的问题，需要使用一些同步机制（如互斥锁、条件变量等）来确保数据的一致性。例如，在一个多线程的计数器应用中，多个线程可能会同时访问和修改一个共享的计数器变量，这时就需要使用互斥锁来保证每次只有一个线程能够修改计数器的值。
协程（Coroutine）
- 定义
  - 协程是一种比线程更加轻量级的用户态的执行单元。它不是由操作系统内核进行调度，而是由程序自己控制。协程可以在一个线程内实现类似于多任务的并发执行效果。例如，在一个网络爬虫程序中，可以使用协程来同时处理多个网页的爬取任务，而不需要像线程那样依赖操作系统的调度。
- 资源占用
  - 协程的资源占用非常少，因为它不需要像线程那样拥有独立的栈空间和系统级别的资源分配。协程通常在用户态的栈上运行，其栈大小可以根据实际需求进行动态调整。例如，在一个高性能的网络服务器中，使用协程来处理大量的连接请求，由于协程占用资源少，可以在一个线程内同时处理成千上万个协程，而不会像线程那样因为资源消耗过大而受限。
- 调度和切换成本
  - 协程的调度和切换成本极低。由于是由程序自身控制协程的切换，不需要像线程那样涉及操作系统内核的上下文切换操作。协程的切换通常只需要保存和恢复少量的寄存器和栈信息，并且可以在用户态快速完成。例如，在一个协程实现的异步 I/O 程序中，协程可以在等待 I/O 操作完成时快速切换到其他协程执行，而不会像线程切换那样产生较大的开销。
- 通信方式
  - 协程之间的通信非常方便，因为它们通常是在同一个线程内运行，共享相同的上下文。可以通过简单的变量赋值或者共享数据结构来进行通信。而且由于协程是顺序执行的（只是可以在适当的时候暂停和恢复），在一定程度上避免了像线程通信那样复杂的同步问题。例如，在一个协程实现的任务处理系统中，不同协程可以通过共享的任务队列来传递任务信息，而不需要像线程那样使用复杂的锁机制来保证数据安全。

7.java有轻量级的微线程吗?就是由java层面,jvm直接去做调度切换的,不是由系统去做的。

虚拟线程（Virtual Threads）介绍
- 在 Java 中，有虚拟线程（也叫纤程，Fiber）的概念，它可以看作是一种轻量级的微线程。从 Java 19 开始，虚拟线程作为预览特性被引入，并且在后续版本中不断完善。
- 虚拟线程是由 JVM 进行调度的，而不是直接依赖操作系统的线程调度。这使得在 Java 层面能够以更轻量级的方式实现并发，减少了上下文切换的开销，并且可以创建大量的虚拟线程来处理高并发任务。
工作原理与调度机制
- 工作原理
  - 虚拟线程运行在用户态，它和传统的操作系统线程（Java 中的平台线程）不同。每个虚拟线程都有自己的栈帧，但这些栈帧是在堆内存中分配的，而不是像平台线程那样在操作系统内核态有独立的栈空间。这样可以更灵活地管理内存，并且使得创建虚拟线程的成本很低。
- 调度机制
  - JVM 中的虚拟线程调度器负责管理虚拟线程的执行。它可以根据任务的阻塞情况（如 I/O 操作阻塞）来暂停当前虚拟线程的执行，并切换到其他可执行的虚拟线程。这种调度方式可以充分利用 CPU 资源，避免因为线程阻塞而导致的浪费。例如，当一个虚拟线程执行一个网络 I/O 操作（如读取网络数据）而被阻塞时，调度器可以快速切换到其他准备好执行的虚拟线程，而不需要像传统的操作系统线程那样等待操作系统的调度，并且在 I/O 操作完成后，虚拟线程可以被重新调度执行。
使用场景与优势
- 高并发 I/O 密集型任务
  - 虚拟线程特别适合处理 I/O 密集型的任务，如网络编程、数据库访问等场景。在这些场景中，传统的线程模型可能会因为线程数量过多（为了处理大量的 I/O 请求）而导致性能下降，因为操作系统线程的创建和上下文切换开销较大。而虚拟线程可以创建大量的实例来处理这些 I/O 请求，并且在 I/O 操作等待期间可以高效地切换到其他任务，从而提高系统的吞吐量和响应速度。
- 降低资源消耗
  - 相比传统的操作系统线程，虚拟线程占用的资源更少。由于它不需要操作系统为其分配独立的内核栈空间等资源，在内存使用和上下文切换开销方面都有很大的优势。这使得在资源有限的环境下（如容器化环境），可以更高效地利用系统资源来处理更多的并发任务。
- 简化并发编程模型
  - 从编程角度来看，虚拟线程可以让开发者以更简单的方式编写并发程序。开发者可以像使用传统线程一样使用虚拟线程，但是不需要过多地担心线程数量过多导致的性能问题。例如，在编写一个简单的 Web 服务器应用时，可以使用虚拟线程来处理每个 HTTP 请求，而不需要复杂的线程池管理和优化，因为虚拟线程的调度由 JVM 自动完成，并且可以高效地处理大量请求。

示例代码（Java 19 +）

以下是一个简单的示例，展示如何使用虚拟线程来执行任务：

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.stream.IntStream;

public class VirtualThreadExample {
    public static void main(String[] args) {
        // 创建一个虚拟线程执行器
        ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
        // 提交多个任务（这里简单地打印数字）
        IntStream.range(0, 10).forEach(i -> {
            executor.submit(() -> {
                System.out.println("Task " + i + " executed by " + Thread.currentThread());
            });
        });
        // 关闭执行器
        executor.shutdown();
    }
}

在这个示例中，通过Executors.newVirtualThreadPerTaskExecutor()创建了一个可以为每个任务分配一个虚拟线程的执行器。然后使用forEach循环提交了 10 个任务，每个任务在虚拟线程中打印自己的编号和执行线程的信息。注意，这只是一个简单的示例，在实际应用中，虚拟线程可以用于更复杂的高并发场景，如网络请求处理、异步 I/O 操作等。

8，操作系统的中断处理怎么工作,比如键盘按了下回车?

中断的基本概念
- 中断是指计算机在执行程序的过程中，当出现某些紧急事件（如硬件故障、外部设备请求等）时，CPU 暂停当前正在执行的程序，转而去执行相应的中断处理程序来处理该事件，处理完成后再返回原来被中断的程序继续执行。这就好比你在看书（程序执行），突然电话铃响了（中断事件），你先放下书去接电话（执行中断处理程序），接完电话后再回来继续看书。
键盘中断的触发
- 硬件层面：当按下键盘上的回车键时，键盘内部的电路会检测到这个按键动作。键盘控制器（键盘内部的一个芯片）会将这个按键对应的扫描码发送到计算机的主板上的 I/O 接口（如 USB 接口等）。这个扫描码是一个唯一标识按键的编码，对于回车键有一个特定的扫描码。
- 系统层面：计算机的 I/O 接口会向 CPU 发送一个中断请求信号（IRQ，Interrupt ReQuest）。这个信号会通过计算机的中断控制器（如 8259A 芯片等）传递给 CPU。中断控制器的作用是管理和分发各种外部设备的中断请求，它会根据预先设定的优先级等规则来处理多个同时到来的中断请求。
中断处理过程
- 中断响应
  - CPU 在执行当前程序的每个指令周期结束后，会检查是否有中断请求。当收到键盘的中断请求后，CPU 会暂停当前程序的执行，将当前程序的上下文（包括程序计数器、寄存器状态等）保存到系统栈中。这个过程非常快速，确保能够及时响应中断事件。例如，保存程序计数器的值，这样在中断处理完成后，CPU 可以知道从哪里继续执行原来的程序。
- 中断向量查找
  - CPU 根据中断请求的类型（由中断控制器提供相关信息），查找中断向量表。中断向量表是一个存储中断处理程序入口地址的数据结构，每个中断类型在中断向量表中有一个对应的表项。对于键盘中断，有一个特定的表项，其中存储着键盘中断处理程序的入口地址。CPU 通过查找这个表项，获取到键盘中断处理程序的入口地址。
- 中断处理程序执行
  - CPU 跳转到获取到的键盘中断处理程序入口地址，开始执行中断处理程序。对于键盘中断，处理程序首先会从 I/O 接口读取键盘发送的扫描码，然后根据扫描码确定是回车键被按下。接着，可能会将这个按键事件传递给操作系统的输入子系统。操作系统的输入子系统会根据当前应用程序的焦点状态（即哪个应用程序应该接收这个按键事件），将按键事件放入相应应用程序的输入队列中。例如，如果当前焦点在一个文本编辑器上，那么操作系统会将回车键的按键事件放入这个文本编辑器的输入队列，等待文本编辑器从队列中获取并处理这个事件。
- 中断返回
  - 在键盘中断处理程序执行完相关操作后，CPU 会从系统栈中恢复之前保存的程序上下文，包括程序计数器、寄存器状态等。然后，CPU 继续执行被中断的程序，就好像中断事件没有发生过一样，从原来被中断的位置继续执行指令。这样，整个系统的程序执行流程又恢复正常，直到下一次中断事件发生。

9，java创建线程需要触发软中断吧,软中断流程怎么样的?了解系统调用吗?

Java 创建线程与软中断的关系
- 在 Java 中创建线程通常不需要程序员直接触发软中断。Java 通过java.lang.Thread类或java.util.concurrent包中的线程池等高级抽象来创建和管理线程。当使用new Thread()或线程池的execute()、submit()方法来启动一个线程时，底层是通过调用操作系统的系统调用来创建线程的，这个过程对 Java 程序员来说是透明的。
- 然而，从操作系统层面看，在某些情况下线程的调度和切换可能涉及软中断。例如，当一个线程的时间片用完或者因为等待 I/O 等资源而被阻塞时，操作系统会通过软中断来进行线程的切换。但这是由操作系统内核自动完成的，不是 Java 代码直接触发的。
软中断流程概述
- 软中断的触发
  - 软中断是一种由软件（通常是操作系统内核）触发的中断机制。它不像硬中断那样是由外部硬件设备直接触发的。软中断可以由多种情况触发，如定时器到期、系统调用完成后的返回处理、进程或线程的调度等。例如，当一个定时器设置的时间间隔到期时，内核中的定时器模块会触发一个软中断来处理定时相关的任务，如更新系统时间、检查是否有超时的进程等。
- 中断向量和处理程序
  - 与硬中断类似，软中断也有相应的中断向量表（在一些操作系统中也称为软中断向量表），用于存储软中断处理程序的入口地址。当软中断被触发后，CPU 根据中断向量表找到对应的软中断处理程序入口地址。每个软中断都有一个编号，用于在中断向量表中查找对应的处理程序。例如，在 Linux 操作系统中，TIMER_SOFTIRQ是用于定时器相关软中断的编号，当这个软中断被触发时，CPU 会跳转到对应的定时器软中断处理程序。
- 处理程序执行和现场保护
  - 在执行软中断处理程序之前，CPU 会保存当前正在执行任务（可能是一个进程或者线程）的现场，包括程序计数器、寄存器状态等信息。然后，CPU 开始执行软中断处理程序。软中断处理程序根据具体的任务进行相应的处理。例如，在处理定时器软中断时，可能会更新系统时钟、重新设置定时器的值，以及检查是否有超时等待的进程或线程需要唤醒等操作。
- 恢复现场和返回
  - 在软中断处理程序执行完成后，CPU 会恢复之前保存的现场，包括将程序计数器和寄存器状态恢复到软中断发生前的状态。然后，CPU 继续执行被软中断打断的任务，就好像软中断没有发生过一样。这样，整个系统的运行流程得以继续。
系统调用概述
- 定义和作用
  - 系统调用是操作系统提供给应用程序（如 Java 程序）的接口，用于让应用程序请求操作系统内核提供的服务。这些服务包括文件操作（如打开、读取、写入文件）、进程管理（如创建、终止进程）、内存管理（如分配、释放内存）、网络通信（如发送、接收网络数据）等各种功能。例如，当一个 Java 程序需要读取一个文件时，它不能直接访问磁盘，而是需要通过系统调用请求操作系统内核来完成文件读取的操作。
- 系统调用的执行过程
  - 应用程序请求：在应用程序（如 Java）中，当需要执行一个系统调用时，会通过特定的库函数（在 Java 中可能是通过java.io等包中的文件操作类，这些类最终会调用底层的系统调用）来发起请求。例如，FileInputStream类的read方法在底层可能会调用操作系统的read系统调用来读取文件内容。
  - 陷入内核态：当发起系统调用请求后，应用程序会从用户态陷入内核态。这是因为系统调用涉及到对计算机硬件资源和内核数据的访问，这些操作是受到保护的，只有内核态才能进行。在这个过程中，CPU 会进行模式切换，同时会保存当前用户态的程序上下文，包括寄存器状态、程序计数器等信息。
  - 内核处理：内核收到系统调用请求后，会根据请求的类型（如文件读取、进程创建等）调用相应的内核函数来处理。例如，对于文件读取请求，内核会检查文件权限、查找文件在磁盘上的位置、通过磁盘驱动程序读取文件内容等操作。
  - 返回结果：内核处理完系统调用请求后，会将结果返回给应用程序。同时，CPU 会从内核态切换回用户态，并恢复之前保存的用户态程序上下文。然后，应用程序可以继续使用系统调用返回的结果进行后续的操作。例如，FileInputStream类的read方法在收到系统调用返回的文件内容后，会将内容返回给 Java 程序，Java 程序可以根据需要进行进一步的处理，如将内容显示在屏幕上或者进行数据解析等操作。

10，I0多路复用了解吗?

I/O 多路复用的定义与概念
- I/O 多路复用是一种用于同时处理多个 I/O 事件的技术。在网络编程和文件 I/O 等场景中，程序通常需要处理多个输入输出源（如多个网络连接、多个文件描述符）。I/O 多路复用允许程序在一个线程（或进程）中同时监视多个 I/O 通道（如套接字、文件等），当这些通道中有一个或多个准备好进行 I/O 操作（如可读、可写、出现异常等）时，能够及时得到通知并进行相应的处理，而不需要为每个 I/O 通道单独创建一个线程来处理，从而避免了创建大量线程带来的资源消耗和上下文切换开销。

常见的 I/O 多路复用机制

select 系统调用

原理：select函数允许程序监视一组文件描述符（包括套接字），等待它们中的一个或多个变为可读、可写或出现异常状态。它通过维护三个文件描述符集合（读集合、写集合、异常集合）来实现。程序将需要监视的文件描述符添加到相应的集合中，然后调用select函数。select函数会阻塞，直到有文件描述符满足条件（可读、可写或异常）或者超时。

示例代码（简单示意）

#include <stdio.h>
#include <sys/types.h>
#include <sys/select.h>
#include <unistd.h>

int main() {
    fd_set read_fds;
    struct timeval timeout;
    int max_fd = 0;
    int fd1 = 0, fd2 = 1; // 假设监视标准输入（0）和标准输出（1）
    // 初始化读文件描述符集合
    FD_ZERO(&read_fds);
    FD_SET(fd1, &read_fds);
    FD_SET(fd2, &read_fds);
    max_fd = (fd1 > fd2)? fd1 : fd2;
    // 设置超时时间为5秒
    timeout.tv_sec = 5;
    timeout.tv_usec = 0;
    // 调用select函数进行监视
    int ret = select(max_fd + 1, &read_fds, NULL, NULL, &timeout);
    if (ret == -1) {
        perror("select");
        return 1;
    } else if (ret == 0) {
        printf("Timeout occurred.\n");
    } else {
        if (FD_ISSET(fd1, &read_fds)) {
            char buffer[100];
            int n = read(fd1, buffer, sizeof(buffer));
            if (n > 0) {
                buffer[n] = '\0';
                printf("Read from stdin: %s", buffer);
            }
        }
        if (FD_ISSET(fd2, &read_fds)) {
            printf("stdout is ready for writing.\n");
        }
    }
    return 0;
}

缺点：select有一些限制，例如文件描述符集合大小通常是有固定上限的（在一些系统中是 1024），并且每次调用select时，都需要将文件描述符集合从用户空间复制到内核空间，返回时又要从内核空间复制回用户空间，这会产生一定的开销。

poll 系统调用

原理：poll系统调用和select类似，也是用于监视多个文件描述符的状态。不过，poll使用的是一个pollfd结构的数组来表示文件描述符及其事件，而不是像select那样使用固定大小的集合。poll函数会遍历这个数组来检查每个文件描述符的状态，同样会阻塞直到有文件描述符满足条件或者超时。

示例代码（简单示意

#include <stdio.h>
#include <poll.h>
#include <unistd.h>

int main() {
    struct pollfd fds[2];
    int ret;
    // 监视标准输入
    fds[0].fd = 0;
    fds[0].events = POLLIN;
    // 监视标准输出
    fds[1].fd = 1;
    fds[1].events = POLLOUT;
    // 调用poll函数进行监视
    ret = poll(fds, 2, 5000);
    if (ret == -1) {
        perror("poll");
        return 1;
    } else if (ret == 0) {
        printf("Timeout occurred.\n");
    } else {
        if (fds[0].revents & POLLIN) {
            char buffer[100];
            int n = read(fds[0].fd, buffer, sizeof(buffer));
            if (n > 0) {
                buffer[n] = '\0';
                printf("Read from stdin: %s", buffer);
            }
        }
        if (fds[1].revents & POLLOUT) {
            printf("stdout is ready for writing.\n");
        }
    }
    return 0;
}

优点与缺点：poll没有文件描述符数量的固定限制，相对更灵活。但是，它也需要在每次调用时将pollfd数组复制到内核空间，并且在返回时检查每个文件描述符的状态，可能会有一定的性能开销。

epoll（Linux 特有的高效机制）

原理：epoll是 Linux 特有的 I/O 多路复用机制，它在处理大量文件描述符时比select和poll更高效。epoll通过在内核中维护一个事件表，程序通过epoll_create函数创建一个epoll实例，通过epoll_ctl函数向这个实例中添加、修改或删除需要监视的文件描述符及其事件类型（可读、可写、异常等）。然后使用epoll_wait函数来等待事件的发生。epoll使用事件驱动的方式，当有文件描述符的事件发生时，内核会直接将相关信息通知给应用程序，而不需要像select和poll那样遍历所有文件描述符来检查。

示例代码（简单示意）

#include <stdio.h>
#include <sys/epoll.h>
#include <unistd.h>
#include <string.h>

int main() {
    int epollfd = epoll_create1(0);
    if (epollfd == -1) {
        perror("epoll_create1");
        return 1;
    }
    struct epoll_event event;
    struct epoll_event events[10];
    // 监视标准输入
    event.data.fd = 0;
    event.events = EPOLLIN;
    if (epoll_ctl(epollfd, EPOLL_CTL_ADD, 0, &event) == -1) {
        perror("epoll_ctl");
        return 1;
    }
    int nfds;
    // 等待事件发生
    nfds = epoll_wait(epollfd, events, 10, -1);
    if (nfds == -1) {
        perror("epoll_wait");
        return 1;
    }
    for (int i = 0; i < nfds; ++i) {
        if (events[i].data.fd == 0 && (events[i].events & EPOLLIN)) {
            char buffer[100];
            int n = read(0, buffer, sizeof(buffer));
            if (n > 0) {
                buffer[n] = '\0';
                printf("Read from stdin: %s", buffer);
            }
        }
    }
    close(epollfd);
    return 0;
}

优点：epoll在处理大量并发连接时性能出色，它只需要在文件描述符状态发生变化时返回通知，减少了不必要的遍历操作。同时，epoll支持边缘触发（ET）和水平触发（LT）两种模式，提供了更灵活的事件通知方式。

应用场景与优势
- 网络服务器编程：在高性能的网络服务器（如 Web 服务器、邮件服务器等）中，需要同时处理大量的客户端连接。I/O 多路复用可以让服务器在一个或少量线程（进程）中高效地处理这些连接，实现对多个套接字的可读（接收客户端请求）和可写（发送响应数据）事件的监控。例如，一个 Web 服务器可以使用 I/O 多路复用技术来监听多个 HTTP 客户端的请求，当有请求到达时，及时进行处理并返回响应，提高服务器的并发处理能力。
- 文件 I/O 监控：在处理多个文件的读写操作时，I/O 多路复用也很有用。例如，在一个数据备份程序中，可能需要同时监视多个文件的读取进度或者多个备份目标文件的写入状态，通过 I/O 多路复用可以高效地实现这种监控，及时发现文件 I/O 中的问题（如读取错误、磁盘空间不足等）。
- 资源高效利用：相比于为每个 I/O 通道创建一个单独的线程来处理，I/O 多路复用避免了大量线程的创建和上下文切换开销。在高并发场景下，这可以显著减少系统资源的消耗，提高系统的整体性能和稳定性。同时，它还可以提高程序的响应速度，因为可以及时处理多个 I/O 事件，而不是被阻塞在某个单独的 I/O 操作上。

11，redis这种单线程模型有什么缺点吗?

性能瓶颈方面
- CPU 利用率受限
  - Redis 单线程模型在处理 CPU 密集型任务时存在明显的限制。由于它只有一个处理线程，无法充分利用多核 CPU 的优势。例如，在执行一些复杂的计算任务，如对存储在 Redis 中的大量数据进行聚合计算或者加密解密操作时，单线程的处理速度可能会成为瓶颈。因为即使服务器的 CPU 有多个核心，Redis 也只能使用其中一个核心来处理这些任务，其他核心可能处于空闲状态，这就导致了硬件资源的浪费，并且在数据量较大或者计算复杂度较高的情况下，性能提升会比较困难。
- 高并发场景下的延迟问题
  - 在高并发场景下，虽然 Redis 通过基于内存操作和高效的 I/O 多路复用机制（如epoll在 Linux 系统上）能够处理大量的客户端请求，但当请求复杂度增加或者请求量达到一定程度时，仍然可能会出现延迟。例如，当大量客户端同时发送复杂的命令（如带有多个嵌套操作的事务命令），Redis 需要依次处理这些命令，单个请求的处理时间可能会因为前面排队的请求而变长，从而导致客户端等待时间增加，影响系统的响应速度。
功能扩展方面
- 难以实现复杂的多阶段事务
  - Redis 的单线程模型使得实现复杂的多阶段事务变得困难。在分布式系统或者涉及多个数据存储的复杂场景中，可能需要执行跨多个 Redis 实例或者跨 Redis 与其他数据库的事务。由于 Redis 单线程的特性，很难在不影响性能的情况下，像多线程数据库那样方便地实现复杂的事务协调和回滚机制。例如，当一个事务涉及 Redis 和一个关系型数据库（如 MySQL）时，很难在 Redis 单线程模型中有效地同步两个系统的操作，保证数据的一致性和事务的原子性。
- 模块开发的限制
  - 对于一些需要在 Redis 内部开发复杂模块的场景，单线程模型可能会带来限制。例如，开发一个自定义的数据结构或者一个新的功能模块，需要考虑不能因为这个模块的操作而阻塞整个 Redis 的处理流程。如果模块中涉及到一些可能会耗时的操作（如复杂的网络请求或者长时间的计算），就很难直接集成到 Redis 的单线程架构中，否则会影响 Redis 对其他客户端请求的正常处理。
可靠性和可用性方面
- 单点故障风险
  - 由于 Redis 是单线程模型，在这个线程出现问题（如程序崩溃、陷入死循环或者遇到未处理的异常）时，整个 Redis 服务将会停止工作，这就带来了单点故障的风险。虽然可以通过配置 Redis 的持久化策略（如 RDB 和 AOF）来减少数据丢失的风险，并且可以使用 Redis 的主从复制和 Sentinel（哨兵）机制来实现高可用性，但在主节点出现故障时，故障转移过程仍然可能会导致短暂的服务中断，并且在一些极端情况下，如果数据同步不及时，可能会出现数据不一致的问题。
- 维护和升级的挑战
  - 在对 Redis 进行维护和升级时，单线程模型可能会带来一些挑战。例如，在进行软件版本升级或者配置调整时，需要暂停 Redis 服务，这会导致服务不可用。而且由于其单线程的架构，很难在不停止服务的情况下进行一些热更新或者动态扩展功能等操作，这对于一些对可用性要求较高的应用场景来说是一个比较大的缺点。

12，get和post的区别是什么?

数据传输方式
- GET 请求
  - GET 请求的数据是通过 URL（Uniform Resource Locator）进行传输的。数据以键值对的形式附加在 URL 的后面，多个数据之间用 “&” 符号连接，并且在 URL 中数据是可见的。例如，在访问一个搜索页面时，URL 可能是https://example.com/search?q=keyword&page=1，其中q=keyword和page=1就是通过 GET 方式传递的数据，分别表示搜索关键词和页码。因为数据在 URL 中，所以 GET 请求的数据量受到 URL 长度的限制。不同的浏览器和服务器对 URL 长度的限制有所不同，但一般来说，这个限制相对较小，不适合传输大量数据。
- POST 请求
  - POST 请求的数据是放在请求体（Request Body）中的。请求体是请求消息的一部分，与请求头（Request Header）和请求行（Request Line）共同构成了完整的 HTTP 请求。POST 请求的数据在 URL 中不可见，这使得它适合传输敏感信息，如用户的密码、个人隐私数据等。而且 POST 请求对数据量的限制相对较宽松，理论上可以传输的数据量比 GET 请求大得多，具体的数据量限制主要取决于服务器的配置和性能。
安全性
- GET 请求
  - 由于 GET 请求的数据在 URL 中是明文显示的，所以安全性较低。如果传输的数据包含敏感信息，如用户登录密码、银行账户信息等，这些信息很容易被窃取。例如，在浏览器的历史记录、服务器的访问日志或者网络监控设备中，都可以直接看到 GET 请求中的数据。而且，GET 请求可能会被浏览器缓存，这也增加了数据泄露的风险。不过，对于一些非敏感信息，如公开的文章编号、产品 ID 等，GET 请求是一种简单方便的传输方式。
- POST 请求
  - POST 请求相对来说更安全，因为数据在请求体中，不会直接暴露在 URL 中。但是，这并不意味着 POST 请求就是绝对安全的。如果传输过程中没有使用加密协议（如 HTTPS），请求体中的数据仍然可能在网络传输过程中被窃取。因此，在传输敏感信息时，应该同时使用 POST 请求和加密协议来确保数据的安全性。
幂等性
- GET 请求
  - GET 请求是幂等的，这意味着多次执行相同的 GET 请求应该返回相同的结果（前提是服务器的数据没有发生变化）。例如，多次访问https://example.com/product?id=1来获取产品编号为 1 的产品信息，每次得到的结果应该是一样的。幂等性使得 GET 请求可以被安全地缓存，浏览器和代理服务器可以根据缓存机制来减少对服务器的重复请求，提高网络性能。
- POST 请求
  - POST 请求通常不是幂等的。每次执行 POST 请求可能会对服务器端的数据产生不同的影响。例如，在一个电商系统中，使用 POST 请求提交订单，每次提交都会创建一个新的订单记录，所以多次执行相同的 POST 请求会产生不同的结果。这种非幂等性使得 POST 请求不能像 GET 请求那样简单地被缓存，因为缓存后的 POST 请求再次执行可能会导致不符合预期的数据修改。
用途和语义
- GET 请求
  - 主要用于从服务器获取资源。常见的用途包括查询数据、获取网页内容、获取图片、获取文件等。例如，在浏览器中访问网页、在 RESTful API 中查询数据（如GET /api/users来获取用户列表）等场景，都是使用 GET 请求。GET 请求的语义是获取（Retrieve），它不会对服务器端的数据进行修改。
- POST 请求
  - 用于向服务器提交数据，通常会导致服务器端的数据发生改变。常见的用途包括提交表单数据（如用户注册、登录、发布文章等）、上传文件等。例如，在一个博客系统中，用户通过 POST 请求提交新文章的内容，服务器接收到 POST 请求后，会将新文章的数据保存到数据库中。POST 请求的语义是提交（Submit）或创建（Create），它会对服务器的数据或者状态产生影响。

13，http和rpc的本质区别是什么?

协议定义与用途
- HTTP（Hypertext Transfer Protocol）
  - HTTP 是一种用于分布式、协作式和超媒体信息系统的应用层协议。它主要用于在 Web 浏览器和 Web 服务器之间传输超文本（如 HTML 文档），但也可以用于传输其他类型的数据，如 XML、JSON 等。其设计初衷是为了实现 Web 资源的获取和展示，使得用户能够通过浏览器访问各种网页和 Web 服务。例如，当你在浏览器中输入一个网址，浏览器就会使用 HTTP 协议向对应的 Web 服务器发送请求，服务器返回包含网页内容的响应，从而让你能够浏览网页。
- RPC（Remote Procedure Call）
  - RPC 是一种用于实现远程过程调用的协议。它的目的是让一个程序（客户端）能够像调用本地函数一样调用另一个程序（服务器端）中的函数或方法，而这个被调用的函数或方法实际上是在远程服务器上运行的。RPC 主要用于分布式系统中不同组件之间的通信和协作，使得分布式系统的开发和调用过程更加简单和透明。例如，在一个微服务架构的电商系统中，订单服务可能需要调用库存服务来检查商品库存，RPC 协议可以让订单服务像调用本地方法一样调用库存服务的库存检查方法。
通信模型和语义
- HTTP
  - 请求 - 响应模型：基于请求 - 响应的通信模型。客户端发送一个 HTTP 请求到服务器，请求中包含请求方法（如 GET、POST 等）、请求头（包含诸如用户代理、内容类型等信息）、请求 URL（用于定位资源）和可选的请求体（用于 POST 等请求方法来传递数据）。服务器接收到请求后，根据请求的内容进行处理，然后返回一个包含状态码、响应头（如内容长度、缓存控制等）和响应体（实际的数据内容）的响应。例如，在一个 GET 请求中，客户端请求获取一个网页，服务器返回包含网页 HTML 代码的响应。
  - 资源导向语义：HTTP 具有很强的资源导向语义。它通过 URL 来定位和访问资源，每个 URL 代表一个特定的资源，如一个网页、一张图片或者一个数据接口。请求方法（如 GET 用于获取资源、POST 用于提交资源等）则明确了对这些资源的操作方式。这种语义使得 HTTP 非常适合用于 Web 资源的访问和管理。
- RPC
  - 函数调用语义：RPC 的通信模型更像是本地函数调用。客户端发起一个远程调用请求，这个请求包含要调用的远程函数的名称、参数列表等信息。服务器接收到请求后，根据函数名称找到对应的函数并执行，然后将函数的返回值作为响应返回给客户端。例如，客户端调用一个远程的加法函数add(a, b)，它会将函数名称add和参数a、b发送给服务器，服务器执行加法运算后，将结果返回给客户端。
  - 面向过程或面向对象语义（取决于实现）：RPC 协议可以基于面向过程或者面向对象的方式来实现。在面向过程的 RPC 中，客户端调用远程的过程（函数）；在面向对象的 RPC 中，客户端可以调用远程对象的方法，并且可能涉及对象的序列化和反序列化等操作，以实现对象在不同进程或机器之间的传递和调用。
数据格式和灵活性
- HTTP
  - 多种数据格式支持：HTTP 对数据格式的支持非常灵活，可以传输各种格式的数据。在实际应用中，常见的数据格式包括 HTML（用于网页）、JSON（用于数据接口）、XML（用于数据交换和配置文件）等。客户端和服务器可以通过在请求头和响应头中设置Content - Type和Accept等字段来协商数据格式。例如，一个 RESTful API 可以根据客户端的请求返回 JSON 格式的数据，而客户端可以通过设置Accept: application/json来表明它期望接收 JSON 格式的数据。
  - 通用性和可扩展性：由于 HTTP 是一种广泛应用于 Web 领域的通用协议，它具有很好的可扩展性。新的功能和特性可以通过在请求头和响应头中添加新的字段或者定义新的状态码来实现。例如，HTTP/2.0 通过引入新的帧格式和多路复用等特性，提高了协议的性能和效率，同时保持了与 HTTP/1.1 的兼容性。
- RPC
  - 自定义数据格式（可能）：RPC 协议的数据格式通常是由具体的 RPC 框架来定义的。有些 RPC 框架可能使用自定义的数据格式来提高性能或者满足特定的功能需求。例如，一些高性能的 RPC 框架可能使用二进制数据格式来减少数据传输的大小和提高序列化 / 反序列化的速度。不过，也有一些 RPC 框架支持常见的数据格式，如 JSON、XML 等，以方便与其他系统进行集成。
  - 针对性和效率（在特定场景下）：RPC 协议的数据格式和通信方式通常是针对远程函数调用的场景进行优化的。与 HTTP 相比，它可能在处理频繁的函数调用和数据传输方面具有更高的效率，因为它不需要像 HTTP 那样处理复杂的资源定位和请求方法语义。但是，这种针对性也使得 RPC 在通用性方面相对较弱，不太适合用于像 Web 浏览这样的复杂资源访问场景。
性能特点
- HTTP
  - 协议开销和性能优化：HTTP 协议本身具有一定的开销，如请求头和响应头的信息传输。在 HTTP/1.1 及以前，每次请求 - 响应都需要建立一个新的 TCP 连接（对于非持久连接）或者复用一个 TCP 连接（对于持久连接），这在一定程度上会影响性能。不过，HTTP/2.0 通过引入多路复用、头部压缩等技术，大大提高了性能。例如，在一个加载多个资源（如图片、脚本、样式表）的网页请求中，HTTP/2.0 可以在一个 TCP 连接上同时传输多个资源的请求和响应，减少了连接建立的时间和开销。
  - 缓存机制的影响：HTTP 具有丰富的缓存机制，可以通过设置缓存控制头（如Cache - Control、Expires等）来控制客户端和代理服务器对资源的缓存。有效的缓存可以减少服务器的负载和网络传输，提高性能。例如，对于一些不经常变化的静态资源（如网站的 logo 图片），可以设置较长时间的缓存，使得客户端在后续访问时可以直接从缓存中获取资源，而不需要再次向服务器发送请求。
- RPC
  - 高效的函数调用（在合适场景下）：RPC 在处理远程函数调用方面通常具有较高的性能，尤其是在处理内部系统之间的频繁调用时。因为它的通信模型是直接针对函数调用进行优化的，没有像 HTTP 那样复杂的资源定位和请求方法语义。一些 RPC 框架还可以通过优化序列化 / 反序列化过程、采用高效的通信协议（如自定义的二进制协议）和连接池等技术来提高性能。例如，在一个分布式计算系统中，多个节点之间频繁调用计算函数，RPC 可以提供高效的通信方式，减少调用延迟。
  - 性能受具体实现和场景影响较大：RPC 的性能在很大程度上受到具体的 RPC 框架、网络环境和调用场景的影响。不同的 RPC 框架在序列化 / 反序列化效率、网络传输协议、连接管理等方面存在差异，这些差异会导致性能的不同。而且，RPC 在处理复杂的资源访问和跨系统集成场景时，可能会因为缺乏通用性而需要额外的开发和优化工作，从而影响性能。

14，请你说一下从浏览器中输入一个url会发生什么?

从浏览器中输入一个 URL 后，会发生以下一系列的事情：

输入与检查

检查输入合法性：浏览器首先会检查输入的 URL 格式是否正确，如果格式不正确，可能会提示用户重新输入7。
确定请求类型：浏览器会判断输入的内容是搜索关键字还是完整的 URL。如果是搜索关键字，浏览器会使用默认搜索引擎将其转换为搜索 URL；如果是完整的 URL，浏览器会按照既定规则对其进行解析。

缓存检查与 DNS 解析

缓存检查：浏览器会检查本地缓存中是否有该 URL 对应的 IP 地址。如果缓存中有，就直接使用；如果没有，会向操作系统的 DNS 缓存查询。若操作系统缓存中也没有，浏览器会向本地域名服务器发送 DNS 请求2。
DNS 解析：本地域名服务器收到请求后，如果没有该域名的记录，会进行递归查询或迭代查询，向其他域名服务器请求解析域名对应的 IP 地址，最终获取到目标服务器的 IP 地址2。

建立连接

TCP 连接：浏览器获得 IP 地址后，会与服务器进行三次握手建立 TCP 连接。第一次握手，浏览器向服务器发送一个带有 SYN 标志的数据包，请求建立连接；第二次握手，服务器收到请求后，返回一个带有 SYN/ACK 标志的数据包；第三次握手，浏览器收到服务器的响应后，再发送一个带有 ACK 标志的数据包，此时 TCP 连接建立成功2。

发送请求

构建请求报文：建立连接后，浏览器会构建 HTTP 请求报文，包括请求行、请求头和请求体。请求行包含方法、URL 和 HTTP 版本；请求头包含浏览器信息、接受的数据类型等；请求体则在 POST 等有数据提交的请求中使用2。
发送请求：浏览器将构建好的请求报文通过已建立的 TCP 连接发送给服务器2。

服务器处理与响应

处理请求：服务器收到请求报文后，会根据请求的资源和方法进行处理，这可能涉及到查询数据库、处理业务逻辑等操作23。
构建响应报文：服务器处理完请求后，会构建 HTTP 响应报文，包括响应行、响应头和响应体。响应行包含 HTTP 版本、状态码和状态消息；响应头包含服务器信息、内容类型、内容长度等；响应体则是实际的数据内容，如 HTML 文件内容2。
发送响应：服务器将构建好的响应报文通过 TCP 连接发送回浏览器2。

浏览器处理响应与渲染页面

检查状态码：浏览器收到响应报文后，首先会检查状态码。如果是 200 等表示成功的状态码，就会开始解析响应体中的内容；如果是 301/302 等表示重定向的状态码，浏览器会从响应头的 Location 字段中读取重定向的地址，然后再次发起 HTTP 请求。
解析与渲染：如果响应的内容类型是 HTML 页面，浏览器会解析 HTML 代码，构建 DOM 树。在解析 HTML 的过程中，浏览器会发现需要加载的其他资源，如 CSS 文件、JavaScript 文件、图片等，会再次发送 HTTP 请求去获取这些资源，并按照一定的顺序加载和执行。浏览器根据 DOM 树和 CSS 样式表构建渲染树，然后进行布局和绘制操作，最终将页面呈现给用户2。

断开连接

当数据传输完成后，浏览器和服务器会通过四次挥手来断开 TCP 连接2。

15，输入url后会进行dns解析找到ip,那假如直接在浏览器输入ip地址会怎么样?能访问到吗?和输入url有什么不同?

如果直接在浏览器输入 IP 地址，通常情况下是可以访问到对应服务器的，但与输入 URL 有以下不同：

访问可行性与结果

能否访问：如果目标服务器允许通过 IP 地址访问，并且没有设置访问限制，那么直接输入 IP 地址是可以访问到服务器的。但有些网站可能出于安全等方面的考虑，禁止了通过 IP 地址直接访问，只允许通过域名访问14。
访问结果不确定性：直接输入 IP 地址访问到的可能是服务器的默认页面或特定的 IP 绑定页面，而不一定是你想要访问的具体网站内容。因为一个 IP 地址可能对应多个网站或服务，服务器需要根据域名等信息来确定具体提供哪个网站的内容。如果没有域名的指引，可能会出现访问到错误页面或无法找到特定资源的情况。而输入 URL 则可以通过域名和路径等准确地定位到具体的资源3。

用户体验

记忆难度：IP 地址是由数字组成的，如 IPv4 地址是四组数字，每组最大为 255，形式比较枯燥难记，如 192.168.1.1。而 URL 通常包含有意义的域名和路径，更符合人类的记忆和阅读习惯，如https://www.baidu.com，更容易被用户记住和识别38。
访问准确性：输入 URL 可以准确地访问到特定的网站和页面，因为 URL 中的域名和路径等信息明确地指向了目标资源。而直接输入 IP 地址可能会因为不清楚该 IP 地址对应的具体服务或网站，导致访问到不相关的内容或出现错误。

安全与管理

安全性：直接暴露 IP 地址可能会带来一定的安全风险，黑客或不法分子一旦获取到 IP 地址，就可以通过技术手段追踪和监控上网活动，进而获取个人隐私信息，还可能发起各种网络攻击，如 DDoS 攻击、入侵攻击等。而 URL 相对来说更难以直接获取到服务器的真实 IP 地址，一定程度上增加了服务器的安全性1213。
管理便利性：对于网站管理员来说，通过域名可以更方便地进行 DNS 解析和负载均衡等管理。域名可以随时更改，而 IP 地址更改则需要重新配置网络设置。如果只允许通过域名访问，管理员可以更灵活地管理网站的访问策略，如限制特定域名的访问、设置域名的解析规则等14。

16，你说dns解析的时候有的是递归有的是迭代,为什么要这么设计?为什么不能都是迭代或者都是递归?

递归查询的特点与优势
- 用户端简单性
  - 递归查询对于客户端（如浏览器）来说非常简单。客户端只需要向本地域名服务器发送一次 DNS 查询请求，然后等待最终的结果。例如，当浏览器请求解析www.example.com的 IP 地址时，它向本地域名服务器发送请求后，就可以 “坐享其成”，不需要关心后续复杂的查询过程。这使得客户端的 DNS 查询逻辑相对简洁，减轻了客户端的负担。
- 隐藏查询复杂性
  - 递归查询将查询的复杂性隐藏在域名服务器端。本地域名服务器会代替客户端完成整个查询过程，包括向根域名服务器、顶级域名服务器和权威域名服务器的查询。这样可以避免客户端直接面对复杂的域名空间结构和查询流程，使得客户端不需要了解 DNS 服务器的层次结构和如何在不同层次的服务器之间进行查询。
- 效率在某些场景下较高
  - 在大多数情况下，递归查询能够较快地得到结果。因为本地域名服务器通常会缓存大量的 DNS 记录，对于常见的域名查询，可能直接从缓存中就能获取结果。而且，即使需要进行实际的查询，本地域名服务器可以利用其专业的查询机制和优化策略，快速地在 DNS 服务器层次结构中找到答案。
递归查询的局限性与需要迭代查询的原因
- 资源集中与压力问题
  - 如果所有的 DNS 查询都采用递归查询，那么所有的查询压力都会集中在本地域名服务器上。本地域名服务器需要为每个客户端查询请求承担整个查询过程，包括与多个其他域名服务器的交互。在高并发的情况下，这可能会导致本地域名服务器资源耗尽，出现性能问题，甚至无法正常提供服务。
- 更新延迟与缓存一致性问题
  - 递归查询高度依赖本地域名服务器的缓存。如果缓存的记录没有及时更新，可能会导致客户端获取到过期的 IP 地址信息。而且，由于本地域名服务器在递归查询过程中可能会缓存中间结果，当域名信息发生变化时，这些缓存的中间结果可能会影响后续查询的准确性。迭代查询可以在一定程度上缓解这个问题，因为它允许客户端或者中间服务器直接从权威来源获取最新的信息。
- 灵活性与分布式查询需求
  - 在复杂的网络环境和分布式系统中，有时候需要更灵活的查询方式。例如，当一个大型企业内部有多个 DNS 服务器，并且需要对某些特定域名进行内部管理和查询时，迭代查询可以让内部的 DNS 服务器根据自己的策略和需要，逐步查询各个相关的域名服务器，而不是完全依赖于本地域名服务器的递归查询。这对于实现定制化的域名管理和分布式的 DNS 查询非常重要。
迭代查询的特点与优势
- 分散查询压力
  - 迭代查询将查询压力分散到各个参与查询的域名服务器上。在迭代查询过程中，每个域名服务器只需要响应它所负责的那部分信息，而不需要像递归查询那样承担整个查询过程。例如，根域名服务器只需要返回顶级域名服务器的信息，顶级域名服务器只需要返回权威域名服务器的信息，这样可以避免某个服务器因承担过多查询任务而出现性能问题。
- 实时性与准确性
  - 迭代查询可以直接从权威域名服务器获取最新的信息。因为在迭代查询过程中，查询者（可以是客户端或者中间的域名服务器）会直接与权威域名服务器进行交互，这样能够最大程度地减少因缓存等原因导致的信息延迟和不准确问题。对于一些对域名信息准确性和实时性要求较高的应用场景，如动态域名服务、频繁更新的网站等，迭代查询是一种更可靠的方式。
- 支持复杂的域名管理与分布式环境
  - 在分布式的域名管理系统中，迭代查询可以更好地适应复杂的域名空间划分和管理需求。不同的域名服务器可以根据自己的职责和权限，在迭代查询过程中提供相应的信息，并且可以灵活地配置查询路径和策略。例如，在一个跨国企业的网络环境中，不同国家或地区的分支机构可以通过迭代查询来管理和查询自己区域内的域名信息，同时也可以与其他区域的域名服务器进行协作查询。
两种查询方式并存的意义
- 满足不同层次用户和场景需求
  - 递归查询适合普通用户和简单的客户端应用。这些用户和应用通常只关心最终的查询结果，对查询过程的复杂性和效率要求不高，更希望能够简单快捷地获取 IP 地址信息。而迭代查询适合对域名管理有更高要求的用户和场景，如网络管理员、大型企业网络、复杂的分布式系统等，这些用户和场景需要更灵活、准确和实时的域名查询方式。
- 优化 DNS 系统整体性能和可靠性
  - 通过递归查询和迭代查询的结合，可以优化 DNS 系统的整体性能和可靠性。本地域名服务器可以利用递归查询为大多数客户端提供快速的服务，同时，在需要更新缓存或者获取更准确信息时，可以使用迭代查询。这样既可以减轻客户端的负担，又可以保证域名查询系统在不同场景下都能高效、准确地运行。

17tcp为什么要三次握手,两次不行吗?

两次握手可能导致的问题
- 旧连接请求的干扰
  - 假设网络环境存在延迟，客户端发送了一个连接请求（SYN），但由于网络问题，这个请求在网络中滞留了一段时间。之后客户端因为没有收到服务器的响应，重新发送了一个连接请求，并且与服务器成功建立了连接。当这个连接关闭后，之前滞留的旧连接请求可能会延迟到达服务器。如果是两次握手，服务器收到这个旧的连接请求后，会认为是一个新的连接请求而建立新的连接。然而，此时客户端并没有想要建立新连接的意图，这就会导致服务器资源的浪费，建立一个无用的连接。
- 无法确认双方的接收和发送能力
  - 在两次握手中，第一次握手客户端向服务器发送连接请求（SYN），服务器收到后进行第二次握手，返回确认（ACK）和自己的连接请求（SYN）。此时，客户端可以确认自己的发送能力和服务器的接收与发送能力，但服务器只能确认自己的接收能力和客户端的发送能力，无法确认客户端是否能够接收自己发送的连接请求。因为没有第三次握手，客户端没有机会向服务器表明它已经收到服务器的连接请求并且能够正常接收。
三次握手的作用和必要性
- 确保双方的接收和发送能力
  - 第一次握手，客户端向服务器发送 SYN 报文，服务器收到后知道客户端有发送能力；第二次握手，服务器向客户端发送 SYN + ACK 报文，客户端收到后知道服务器有接收和发送能力，并且自己的发送能力也再次得到验证；第三次握手，客户端向服务器发送 ACK 报文，服务器收到后知道客户端也有接收能力。通过这三次握手，双方都能确认对方具有接收和发送数据的能力，为后续可靠的数据传输奠定了基础。
- 同步序列号
  - 在 TCP 通信中，序列号用于标识发送的数据字节流的顺序，保证数据传输的顺序性和可靠性。三次握手过程中，双方交换初始序列号。客户端在第一次握手中发送自己的初始序列号，服务器在第二次握手中确认客户端的序列号并发送自己的序列号，客户端在第三次握手中确认服务器的序列号。这样双方就同步了初始序列号，使得后续的数据传输能够按照正确的顺序进行组装和处理。例如，客户端发送的数据序列号从某个初始值开始递增，服务器能够根据这个初始值和递增规则正确地接收和排序数据。
- 防止失效的连接请求建立新连接
  - 如前面所述，由于网络延迟可能导致旧的连接请求延迟到达服务器。在三次握手的情况下，当服务器收到旧的连接请求并返回 SYN + ACK 报文后，由于客户端不会对这个旧请求对应的 SYN + ACK 报文进行第三次握手确认（因为客户端已经放弃了这个旧请求或者已经建立了其他连接），服务器就会知道这个连接请求是无效的，不会建立新的连接，从而避免了资源的浪费和错误连接的建立。

18第三次握手除了防止已失效的连接重写连接到服务端,还有别的原因吗?

确认双方初始化序列号（ISN）同步完成
- 在 TCP 通信中，序列号（Sequence Number）是非常关键的。客户端和服务器都有自己的初始序列号（Initial Sequence Number，ISN）。通过三次握手，双方可以交换并确认彼此的 ISN。
- 第一次握手，客户端发送带有自己初始序列号（设为 ISN_C）的 SYN 包给服务器。第二次握手，服务器收到客户端的 SYN 包后，会记录下客户端的 ISN_C，同时发送带有自己初始序列号（设为 ISN_S）的 SYN + ACK 包给客户端。此时客户端收到服务器的包，能知道服务器的 ISN_S。第三次握手，客户端发送 ACK 包给服务器，这个 ACK 包的确认号（Acknowledgment Number）是服务器的 ISN_S + 1，服务器收到这个 ACK 包后，就完成了双方 ISN 的同步确认。
- 只有完成了这个同步过程，双方才能在后续的数据传输中，根据序列号和确认号来确保数据的顺序性和完整性。例如，在数据传输阶段，客户端发送的数据段序列号是基于 ISN_C 递增的，服务器通过检查序列号与之前同步的 ISN_C 来判断数据的顺序是否正确；同理，服务器发送的数据段序列号基于 ISN_S 递增，客户端通过检查来接收正确顺序的数据。
保证客户端和服务器的全双工通信建立
- 全双工通信的含义：全双工通信是指通信双方可以同时进行发送和接收数据的操作。在 TCP 连接中，这是非常重要的通信模式。
- 三次握手的作用：第一次握手表明客户端有发送数据的意向；第二次握手表明服务器既能接收客户端的数据（通过对客户端 SYN 的 ACK），又有发送数据的意向（发送自己的 SYN）；第三次握手表明客户端能够接收服务器发送的数据。这样就完成了全双工通信通道的建立。
- 例如，在一个文件传输场景中，客户端向服务器发送文件传输请求（第一次握手），服务器同意接收请求并告知客户端自己也可能会发送文件相关信息（如文件状态、进度等）（第二次握手），客户端确认可以接收服务器发送的这些信息（第三次握手）。之后，客户端可以向服务器发送文件数据，同时接收服务器返回的状态信息，实现高效的全双工通信。
为可靠的数据传输提供基础保障
- TCP 是一种可靠的传输协议，它需要确保数据能够准确无误地从一端传输到另一端。三次握手建立的连接状态包含了双方的通信能力、序列号同步等重要信息。
- 这些信息使得 TCP 在后续的数据传输过程中，可以采用诸如超时重传、累积确认等机制。例如，如果在数据传输过程中，客户端发送的数据段没有收到服务器的确认（通过 ACK 包），客户端可以根据之前在三次握手中建立的连接参数（如序列号范围、往返时间估计等），判断数据是否丢失，并在适当的时候进行重传。同样，服务器也可以根据这些连接参数来处理客户端发送的数据，以及发送自己的数据，并确保数据传输的可靠性。

19并发方面了解吗?hashmap是不是线程安全的?如果让你来实现一个线程安全的hashmap你要怎么设计?如果不用加锁你要怎么设计?

并发的基本概念
- 并发是指多个任务（线程或进程）在同一时间段内同时执行。在多核心处理器的系统中，这些任务可能是真正的同时执行；在单核心处理器的系统中，通过操作系统的调度，这些任务在时间片上交替执行，给人一种同时执行的错觉。并发编程的主要目的是提高系统的资源利用率和性能，例如在处理大量 I/O 操作或者计算密集型任务时，通过并发可以让程序更高效地运行。
HashMap 不是线程安全的原因
- 数据结构的不一致性
  - HashMap 内部是基于数组和链表（在 Java 8 中还有红黑树）的数据结构。在多线程环境下，当多个线程同时对 HashMap 进行插入操作时，可能会出现同时计算哈希值并尝试将元素插入到相同位置的情况。如果不进行同步，可能会导致数据丢失或者链表形成环形结构，进而导致后续的操作（如遍历、查找）出现死循环或者错误的结果。
- 扩容问题
  - HashMap 在元素数量达到一定阈值时会进行扩容操作。这个过程涉及到重新计算哈希值并将元素迁移到新的数组位置。如果多个线程同时触发扩容，可能会导致数据混乱。例如，一个线程正在迁移元素，另一个线程却在旧的数组上进行插入或删除操作，就很难保证数据的一致性。

使用锁实现线程安全的 HashMap 设计思路

简单的同步方法（Synchronized）

一种直接的方法是在对 HashMap 操作的方法（如 put、get、remove 等）上添加synchronized关键字。例如：

public class SynchronizedHashMap<K, V> {
    private final HashMap<K, V> map = new HashMap<>();
    public synchronized V put(K key, V value) {
        return map.put(key, value);
    }
    public synchronized V get(K key) {
        return map.get(key);
    }
    public synchronized V remove(K key) {
        return map.remove(key);
    }
}

这种方法的优点是简单易懂，能够保证同一时间只有一个线程访问 HashMap。但是，这种粗粒度的锁会导致性能问题，因为在高并发情况下，多个线程可能会因为等待锁而被阻塞，不能充分利用系统资源。

使用更细粒度的锁（如分段锁）

可以参考ConcurrentHashMap的设计思路，采用分段锁（Segment）的方式。将 HashMap 划分为多个段（Segment），每个段可以独立地进行加锁和解锁操作。例如，在插入元素时，只需要锁定该元素所在的段，而不是整个 HashMap。这样可以提高并发性能，允许多个线程同时访问不同段的元素。

public class SegmentedHashMap<K, V> {
    // 假设分为16个段
    private final Segment<K, V>[] segments = new Segment[16];
    static final class Segment<K, V> {
        private final HashMap<K, V> map;
        // 每个段的锁
        private final ReentrantLock lock;
        Segment() {
            this.map = new HashMap<>();
            this.lock = new ReentrantLock();
        }
    }
    public V put(K key, V value) {
        int segmentIndex = hash(key) % segments.length;
        Segment<K, V> segment = segments[segmentIndex];
        segment.lock.lock();
        try {
            return segment.map.put(key, value);
        } finally {
            segment.lock.unlock();
        }
    }
    // 类似地实现get和remove方法
}

不使用锁实现线程安全的 HashMap 设计思路（基于 CAS）

使用原子操作类（如 AtomicReferenceArray）

可以使用 Java 中的原子操作类来实现无锁的线程安全的 HashMap。例如，用AtomicReferenceArray来代替普通的数组作为存储桶。在插入元素时，通过compare - and - swap（CAS）操作来保证原子性。

public class LockFreeHashMap<K, V> {
    private static final int DEFAULT_CAPACITY = 16;
    private final AtomicReferenceArray<Node<K, V>> table;
    static final class Node<K, V> {
        final K key;
        V value;
        Node<K, V> next;
        Node(K key, V value) {
            this.key = key;
            this.value = value;
        }
    }
    public LockFreeHashMap() {
        table = new AtomicReferenceArray<>(DEFAULT_CAPACITY);
    }
    public boolean put(K key, V value) {
        int hash = hash(key);
        int index = indexFor(hash, table.length());
        Node<K, V> newNode = new Node<>(key, value);
        while (true) {
            Node<K, V> oldNode = table.get(index);
            if (oldNode == null) {
                if (table.compareAndSet(index, oldNode, newNode)) {
                    return true;
                }
            } else {
                // 处理冲突等情况，这里可以通过遍历链表或者红黑树来处理
                // 并尝试使用CAS更新节点
                // 具体实现会比较复杂，需要考虑多种情况
            }
        }
    }
    // 类似地实现get和remove方法
}

这种方式的优点是在高并发环境下可能有更好的性能，因为避免了锁的开销。但是，它的实现比较复杂，并且在高冲突率的情况下，CAS 操作可能会频繁失败，导致性能下降。同时，使用原子操作类需要对底层的 CPU 指令和内存模型有更深入的理解，以确保正确地实现无锁的数据结构。

20juc知道吗?juc下最重要的类是哪一个?

JUC 简介
- JUC 是 Java.util.concurrent 包的简称，它提供了一系列用于支持并发编程的工具类和框架。这些工具类帮助开发者更方便、高效地编写多线程程序，解决了在并发环境下可能出现的数据共享、同步、线程协作等诸多问题。JUC 主要包含以下几类组件：
- 原子类（Atomic Classes）：如AtomicInteger、AtomicLong、AtomicReference等。这些类提供了原子操作，保证在多线程环境下对基本数据类型或对象引用的操作是原子性的，避免了使用synchronized关键字带来的性能开销，用于实现无锁编程。
- 锁（Locks）：包括ReentrantLock、ReadWriteLock等。ReentrantLock是一种可重入锁，它提供了比传统的synchronized关键字更灵活的锁机制，例如可以实现公平锁和非公平锁，并且可以通过lock和unlock方法更精细地控制锁的获取和释放。ReadWriteLock则用于实现读写分离的锁机制，在多个线程读取共享数据和单个线程写入数据的场景下，可以提高并发性能。
- 并发容器（Concurrent Containers）：像ConcurrentHashMap、CopyOnWriteArrayList、BlockingQueue等。ConcurrentHashMap是一个线程安全的哈希表实现，在高并发环境下能够高效地进行数据插入、查询和删除操作，避免了传统HashMap在多线程环境下可能出现的数据不一致问题。CopyOnWriteArrayList是一个线程安全的动态数组，它采用写时复制（Copy - On - Write）的策略，在写入数据时会复制一个新的数组，从而实现高效的读取操作和线程安全的写入操作。BlockingQueue是一个阻塞队列，常用于生产者 - 消费者模式，提供了put（阻塞式插入）和take（阻塞式获取）等方法，方便在多线程之间进行数据传递。
- 线程池（Executor Framework）：包含Executor、ExecutorService、ThreadPoolExecutor等。线程池用于管理和复用线程，避免了频繁创建和销毁线程带来的性能开销。Executor是一个简单的执行接口，ExecutorService提供了更丰富的功能，如提交任务、关闭线程池等，ThreadPoolExecutor则是线程池的核心实现类，通过配置不同的参数（如核心线程数、最大线程数、队列容量等）可以满足各种并发场景的需求。
- 工具类（Tools）：例如CountDownLatch、CyclicBarrier、Semaphore等。CountDownLatch用于实现一个或多个线程等待其他线程完成操作后再继续执行的场景，例如主线程等待多个子线程完成任务后再进行汇总操作。CyclicBarrier用于让一组线程在到达某个屏障点时互相等待，直到所有线程都到达后再一起继续执行，适用于多个线程需要同步协作的场景。Semaphore可以用于控制同时访问某个资源的线程数量，实现资源的限流等功能。
很难确定最重要的类
- 从并发安全数据结构角度看 - ConcurrentHashMap 可能是最重要的
  - 在处理大量并发的键值对存储和访问场景中，ConcurrentHashMap发挥着关键作用。它是很多分布式系统、缓存系统、高并发数据存储系统的基础组件。例如，在一个分布式缓存系统中，多个节点可能会同时对缓存中的数据进行读写操作，ConcurrentHashMap可以保证数据的安全性和一致性，同时提供了高效的读写性能，相比传统的同步HashMap，它能够更好地利用系统资源，支持更高的并发度。
- 从线程协作和同步角度看 - CountDownLatch 或 CyclicBarrier 很重要
  - 在复杂的多线程任务编排场景中，CountDownLatch和CyclicBarrier非常实用。比如在一个大数据处理系统中，可能需要多个子任务（每个子任务由一个线程处理）完成数据读取、清洗、转换等操作后，再进行数据合并和分析。CountDownLatch可以用于主线程等待所有子任务线程完成读取操作后再开始清洗操作，CyclicBarrier可以用于多个线程在完成不同阶段的清洗任务后同步进入下一个转换阶段。它们使得线程之间的协作更加有序和高效。
- 从资源控制和并发编程模型角度看 - Executor 框架（特别是 ThreadPoolExecutor）是关键
  - 在构建高性能的并发应用时，合理利用线程池是非常重要的。ThreadPoolExecutor可以根据系统的资源状况（如 CPU 核心数、内存大小）和任务的特性（如任务是 CPU 密集型还是 I/O 密集型）来配置线程池的参数，如核心线程数、最大线程数、任务队列容量等。这样可以避免无限制地创建线程导致系统资源耗尽，同时能够有效地复用线程，提高任务的执行效率。例如，在一个 Web 服务器中，使用线程池来处理 HTTP 请求，可以根据服务器的负载情况动态调整线程池的大小，提高服务器的并发处理能力和资源利用率。

21Java中有哪些加锁的方式?除了synchronized和reentlock还有别的吗?

synchronized 关键字
- 方法级别锁：可以直接在方法声明上添加synchronized关键字，这样当一个线程访问该方法时，其他线程就无法访问同一个对象的这个方法。例如：
```
public class SynchronizedExample {
    public synchronized void method() {
        // 方法体内容
    }
}
```
- 代码块级别锁：通过使用synchronized关键字包裹代码块，并指定一个对象作为锁对象。当一个线程进入这个代码块时，会获取该对象的锁，其他线程如果也想进入这个代码块，需要等待锁的释放。例如：
```
public class SynchronizedBlockExample {
    private Object lock = new Object();
    public void method() {
        synchronized (lock) {
            // 代码块内容
        }
    }
}
```

ReentrantLock 类

这是java.util.concurrent.locks包中的一个可重入锁。与synchronized相比，它提供了更灵活的锁机制。例如，可以通过构造函数指定是公平锁还是非公平锁。公平锁会按照线程请求锁的顺序来分配锁，非公平锁则允许插队获取锁。

import java.util.concurrent.locks.ReentrantLock;
public class ReentrantLockExample {
    private ReentrantLock lock = new ReentrantLock();
    public void method() {
        lock.lock();
        try {
            // 需要保护的代码
        } finally {
            lock.unlock();
        }
    }
}

ReadWriteLock 接口（主要是 ReentrantReadWriteLock 实现类）

读写分离锁机制：用于在多线程环境下，对共享数据的读写操作进行分离控制。它包含一个读锁和一个写锁。多个线程可以同时获取读锁，用于读取共享数据，但在有线程获取写锁时，其他线程不能获取读锁或写锁，直到写锁释放。这种机制在数据读取操作远多于写入操作的场景下，可以提高并发性能。例如：

import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
public class ReadWriteLockExample {
    private ReadWriteLock lock = new ReentrantReadWriteLock();
    public void readMethod() {
        lock.readLock().lock();
        try {
            // 读取共享数据的代码
        } finally {
            lock.readLock().unlock();
        }
    }
    public void writeMethod() {
        lock.writeLock().lock();
        try {
            // 写入共享数据的代码
        } finally {
            lock.writeLock().unlock();
        }
    }
}

StampedLock 类

这是 Java 8 引入的一种乐观读锁。它提供了三种模式的锁：写锁、悲观读锁和乐观读锁。乐观读锁假设在读取数据期间数据不会被修改，所以在读取过程中不会加锁，只有在验证读取的数据是否被修改时才会加锁。这种方式在高并发的读多写少的场景下，可以进一步提高性能。例如：

import java.util.concurrent.locks.StampedLock;
public class StampedLockExample {
    private StampedLock lock = new StampedLock();
    public double readMethod() {
        long stamp = lock.tryOptimisticRead();
        double value = // 读取共享数据
        if (!lock.validate(stamp)) {
            stamp = lock.readLock();
            try {
                value = // 重新读取共享数据
            } finally {
                lock.readLockUnlock(stamp);
            }
        }
        return value;
    }
    public void writeMethod() {
        long stamp = lock.writeLock();
        try {
            // 写入共享数据的代码
        } finally {
            lock.writeLockUnlock(stamp);
        }
    }
}

Semaphore 类（信号量）

虽然不是传统意义上的锁，但可以用于控制同时访问某个资源的线程数量，起到一种限流和同步的作用。例如，可以将信号量初始值设置为 1，当作一个互斥锁来使用；也可以设置为其他值，用于控制同时进入某个代码区域的线程数量。

import java.util.concurrent.Semaphore;
public class SemaphoreExample {
    private Semaphore semaphore = new Semaphore(1);
    public void method() {
        try {
            semaphore.acquire();
            // 需要控制访问的代码
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            semaphore.release();
        }
    }
}

22jvm了解吗?jvm垃圾回收讲一下。

JVM（Java Virtual Machine）概述
- JVM 是 Java 程序的运行环境，它负责执行 Java 字节码。JVM 有自己的内存区域划分，包括程序计数器、Java 虚拟机栈、本地方法栈、堆和方法区。其中，堆和方法区是垃圾回收（Garbage Collection，GC）的主要关注区域。
垃圾的定义
- 在 JVM 中，垃圾是指那些已经不再被程序使用的对象。当一个对象没有任何引用指向它时，就可以被认为是垃圾。例如，一个方法中创建了一个局部对象，当方法执行结束后，如果没有其他地方引用这个对象，那么这个对象就成为了垃圾。
垃圾回收算法
- 标记 - 清除算法（Mark - Sweep）
  - 标记阶段：从根对象（如线程栈中的局部变量、静态变量等可以直接访问的对象）开始，通过遍历对象图，标记所有可达的对象。这个过程就像是在一张地图上标记出所有还在使用的 “城市”（对象）。
  - 清除阶段：在标记完成后，清理那些没有被标记的对象，释放它们占用的内存空间。就好比拆除那些没有被标记的 “城市”，将土地（内存）回收。
  - 缺点：这种算法会产生内存碎片。因为清除后的空闲内存是不连续的，当需要分配较大的对象时，可能会找不到足够大的连续内存空间，即使总的空闲内存足够。
- 复制算法（Copying）
  - 它将内存空间划分为两个大小相等的区域，比如 A 区和 B 区。
  - 存活对象复制阶段：只使用其中一个区域（如 A 区）来分配对象，当进行垃圾回收时，将 A 区中存活的对象复制到 B 区，然后清空 A 区。就好像把 A 区中有用的 “东西” 搬到 B 区，然后把 A 区清空。
  - 优点和缺点：优点是实现简单，并且不会产生内存碎片，因为每次复制后都是连续的内存空间。缺点是内存利用率不高，因为需要有一半的内存空间处于空闲状态来进行复制操作。不过，在新生代（Young Generation）中，由于大部分对象都是朝生暮死的，这种算法效率很高。
- 标记 - 整理算法（Mark - Compact）
  - 标记阶段：和标记 - 清除算法类似，从根对象开始标记所有可达的对象。
  - 整理阶段：将所有存活的对象向一端移动，然后清理掉边界以外的内存空间。就像是把有用的 “城市” 都往一边搬迁，然后把另一边的空地回收。
  - 优点和缺点：它解决了标记 - 清除算法的内存碎片问题，但是在整理过程中，对象的移动可能会比较耗时，尤其是在存活对象较多的情况下。
JVM 中的垃圾回收器
- Serial GC（串行垃圾回收器）
  - 这是最基本的垃圾回收器。它在进行垃圾回收时，会暂停所有用户线程（Stop - The - World），采用单线程的方式进行标记 - 清除或者标记 - 整理操作。因为只有一个线程进行回收，所以它的优点是简单高效，适合单 CPU 环境或者内存较小的场景。
- Parallel GC（并行垃圾回收器）
  - 它也是会暂停用户线程进行垃圾回收，但和 Serial GC 不同的是，它采用多个垃圾回收线程并行地进行回收工作。例如，在标记阶段可以有多个线程同时标记对象，这样可以加快垃圾回收的速度，适用于多核 CPU 环境，能够有效利用系统资源。
- CMS（Concurrent Mark Sweep）垃圾回收器
  - 主要阶段：包括初始标记（Initial Mark）、并发标记（Concurrent Mark）、重新标记（Remarking）和并发清除（Concurrent Sweep）。初始标记和重新标记阶段会暂停用户线程，但是时间很短。并发标记和并发清除阶段可以和用户线程同时运行，减少了垃圾回收时的停顿时间，提高了应用程序的响应性能。不过，它也有缺点，比如在并发标记和并发清除阶段会占用 CPU 资源，并且可能会产生浮动垃圾，还会存在内存碎片问题。
- G1（Garbage - First）垃圾回收器
  - G1 将堆内存划分为多个大小相等的 Region，它在回收时会优先回收垃圾最多的 Region。它结合了标记 - 整理和复制算法的优点，在进行垃圾回收时，可以尽量减少停顿时间。而且它能够预测垃圾回收的停顿时间，通过设置合适的参数，可以让垃圾回收的停顿时间控制在用户可接受的范围内，适合大内存、多核 CPU 的应用场景。
垃圾回收的触发时机
- 新生代（Young Generation）：新生代主要存放新创建的对象，它的空间一般比较小。当新生代中的对象占用空间达到一定阈值（如 Eden 区满了）时，就会触发垃圾回收，这个过程称为 Minor GC。因为新生代中大部分对象的生命周期很短，所以 Minor GC 会比较频繁。
- 老年代（Old Generation）：老年代主要存放经过多次 Minor GC 后仍然存活的对象。当老年代空间不足，或者新生代的对象在经过多次 Minor GC 后仍然存活（年龄达到一定阈值），会将这些对象晋升到老年代，当老年代空间占用达到一定比例或者无法容纳晋升的对象时，就会触发 Full GC。Full GC 会对整个堆空间（包括新生代和老年代）进行垃圾回收，它的停顿时间一般比 Minor GC 长。

23jvm垃圾回收的时候,有那么多gcroots,怎么快速定位到gcroots的?

什么是 GC Roots
- GC Roots 是一组必须活跃的引用，从这些引用开始进行可达性分析，来判断对象是否存活。在 Java 中，GC Roots 包括以下几种主要类型：
  - 虚拟机栈（栈帧中的本地变量表）中的引用对象：每个线程在执行方法时，栈帧中的本地变量表保存了方法中的局部变量，这些变量所引用的对象就是 GC Roots 的一部分。例如，在一个方法中定义了一个对象引用变量，只要这个方法还在执行，这个引用所指向的对象就不能被回收。
  - 方法区中类静态属性引用的对象：类的静态变量所引用的对象也是 GC Roots。比如一个类中有一个静态的对象引用，只要这个类被加载，这个静态引用所指向的对象就会被视为活跃对象，不能被垃圾回收。
  - 方法区中常量引用的对象：常量池中的引用对象同样是 GC Roots。例如，一个字符串常量所引用的字符串对象，在常量池存在期间，这个对象不会被当作垃圾回收。
  - 本地方法栈中 JNI（Java Native Interface）引用的对象：当 Java 程序调用本地方法（用其他语言如 C、C++ 编写的方法）时，本地方法栈中的引用对象也是 GC Roots 的一部分。
快速定位 GC Roots 的机制
- OopMap（Ordinary Object Pointer Map）数据结构
  - JVM 在执行代码的过程中，会在特定的位置（如安全点，Safe Point）生成一个 OopMap 数据结构。这个数据结构记录了栈上和寄存器中哪些位置是引用类型。通过 OopMap，JVM 可以快速地找到 GC Roots。在进行垃圾回收的可达性分析阶段，JVM 不需要遍历整个栈和寄存器来查找引用，而是直接根据 OopMap 来定位可能存在引用的位置，从而大大提高了定位 GC Roots 的速度。
  - 例如，在一个方法的字节码指令执行过程中，JVM 会在方法的入口、循环回跳的位置、方法调用返回的位置等安全点生成 OopMap。当触发垃圾回收时，JVM 就可以利用这些预先构建好的 OopMap 来确定哪些对象引用可能是 GC Roots。
- 记忆集（Remembered Set）与卡表（Card Table）辅助
  - 在分代垃圾回收的场景下，为了快速判断老年代对象是否引用了新生代对象（这对于准确的垃圾回收很重要，因为涉及到跨代引用的情况），JVM 使用了记忆集和卡表。记忆集用于记录从非收集区域指向收集区域的引用关系。卡表是记忆集的一种具体实现方式，它将堆内存划分为一个个大小相等的 “卡”（一般为 512 字节）。
  - 当老年代中的某个对象引用了新生代中的对象时，对应的卡表中的 “卡” 就会被标记。在进行垃圾回收（如新生代的回收）时，JVM 只需要检查卡表中被标记的 “卡” 所对应的内存区域，就可以快速定位到老年代中可能引用了新生代对象的 GC Roots，而不需要遍历整个老年代，从而提高了跨代引用处理的效率。

24，堆外内存有什么作用?

突破 JVM 内存限制
- JVM 堆内存的局限：JVM 的堆内存大小是有限制的，这个限制通常由启动参数（如-Xmx）来设定。在处理大量数据或者需要占用大量内存的场景下，堆内存可能会不够用。例如，在处理大规模的文件读取、高性能网络编程（如处理海量网络连接）等场景中，数据量可能会超出堆内存的容量。
- 堆外内存的补充作用：堆外内存不受 JVM 堆大小的限制，可以在 Java 程序需要更多内存资源时提供额外的存储空间。它可以作为一种扩展内存的方式，使得 Java 应用能够处理更大量的数据或者应对更复杂的内存需求场景。比如，在一些大数据处理框架中，为了避免 JVM 堆内存溢出，会将部分数据存储在堆外内存中。
减少垃圾回收的影响
- 垃圾回收对性能的干扰：JVM 的堆内存是垃圾回收（GC）的主要工作区域。频繁的垃圾回收操作会导致程序的暂停（Stop - The - World），影响程序的性能和响应时间。特别是在对性能要求极高的应用场景中，如高频交易系统、实时游戏服务器等，长时间的 GC 停顿是不可接受的。
- 堆外内存的优势：堆外内存不受 JVM 垃圾回收机制的直接控制，数据存储在堆外不会引发 JVM 的垃圾回收。这使得在堆外内存中处理数据可以避免因垃圾回收带来的性能波动。例如，在一些对延迟非常敏感的网络应用中，将网络缓冲区设置在堆外内存，可以保证数据的读写不会因为垃圾回收而产生延迟。
方便与外部系统交互
- 与本地代码交互：在 Java 应用需要与本地（Native）代码（如用 C、C++ 编写的库）进行交互时，堆外内存提供了一个很好的桥梁。本地代码通常不能直接访问 JVM 堆内存，但可以方便地操作堆外内存。例如，在调用一些高性能的图形处理库或者加密算法库时，这些库可能需要直接操作内存块，堆外内存就可以满足这种需求。
- 跨进程共享数据：堆外内存可以被多个进程共享，这在分布式系统或者多进程协作的场景中非常有用。不同的进程可以通过共享堆外内存来交换数据，而不需要复杂的进程间通信（IPC）机制。比如，在一个主 - 从架构的分布式系统中，主进程可以将数据存储在堆外内存中，供多个从进程读取，从而提高数据共享的效率。
提高内存分配和访问效率（在某些场景下）
- 内存分配效率：在一些情况下，堆外内存的分配速度可能比堆内存更快。这是因为堆内存的分配需要考虑 JVM 的内存管理策略，如内存对齐、对象头信息等，而堆外内存的分配相对更直接。例如，在频繁创建和销毁大量小对象的场景中，使用堆外内存可能会提高内存分配的效率。
- 直接内存访问（DMA）优势：对于一些硬件设备（如网络卡、磁盘控制器等），它们支持直接内存访问（DMA）。在这种情况下，数据可以直接从堆外内存传输到硬件设备或者从硬件设备传输到堆外内存，而不需要经过 JVM 堆内存的中间环节，从而提高了数据传输的速度和效率。

25Redis 如何实现分布式锁?

SETNX 命令实现简单分布式锁
- SETNX 命令原理：SETNX（SET if Not eXists）命令是 Redis 实现分布式锁的基础。当使用 SETNX 命令设置一个键值对时，如果键不存在，则设置成功并返回 1；如果键已经存在，则设置失败并返回 0。在分布式锁的场景中，可以将一个特定的键视为锁，通过 SETNX 来尝试获取锁。
- 获取锁的操作：例如，使用SETNX lock_key unique_value来尝试获取锁，其中lock_key是用于表示锁的键，unique_value是一个唯一的值（通常可以是一个随机生成的字符串或者带有时间戳等能唯一标识的内容）。如果返回 1，则表示获取锁成功；如果返回 0，则表示锁已经被其他客户端获取。
- 释放锁的操作：在释放锁时，不能简单地使用DEL命令来删除lock_key，因为可能会误删其他客户端获取的锁。正确的做法是在删除之前，先判断当前持有的锁的值（unique_value）是否与设置时的值相同。可以使用GET和DEL命令组合来实现，不过这种方式不是原子操作，在高并发场景下可能会出现问题。
使用 SET 命令的扩展参数实现更健壮的分布式锁
- SET 命令的扩展参数：Redis 的 SET 命令在较新的版本中提供了一些扩展参数，使得实现分布式锁更加方便和安全。例如，可以使用SET key value [EX seconds] [PX milliseconds] [NX|XX]格式的命令。其中，EX用于设置键的过期时间为秒，PX用于设置键的过期时间为毫秒，NX表示只有当键不存在时才设置（类似 SETNX 的功能），XX表示只有当键存在时才设置。
- 获取锁的优化操作：使用SET lock_key unique_value NX PX lock_timeout来获取锁，这里同时设置了锁的过期时间lock_timeout（以毫秒为单位）。这样即使持有锁的客户端出现异常（如崩溃或者网络问题），锁也会在过期时间后自动释放，避免了死锁的情况。
- 释放锁的安全操作：为了实现原子性的锁释放，可以使用 Lua 脚本。例如，将以下 Lua 脚本发送给 Redis 服务器来释放锁：
```
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end
```
这个脚本首先检查锁的值是否与传入的值相同，如果相同则删除锁并返回 1，表示锁释放成功；如果不同则返回 0，表示无法释放锁。
RedLock 算法实现高可用分布式锁
- RedLock 算法背景：在分布式系统中，单个 Redis 节点可能会出现故障或者网络分区等问题，为了提高分布式锁的可靠性，RedLock 算法应运而生。RedLock 算法使用多个独立的 Redis 节点来实现分布式锁，通过多数原则（在多个节点中成功获取锁的节点数超过一半）来确定锁是否真正被获取。
- 获取锁的步骤
  - 客户端需要尝试在多个（通常是 N = 5）独立的 Redis 节点上获取锁，使用前面提到的 SET 命令（带有过期时间和 NX 参数）在每个节点上设置锁，记录每个节点获取锁的开始时间和响应结果。
  - 计算获取锁的总时间，如果总时间超过一个预设的时间（比如时钟漂移等因素考虑在内的时间限制），则认为获取锁失败，需要释放已经在部分节点上获取的锁。
  - 如果在多数（N/2 + 1）个节点上成功获取锁，则认为获取分布式锁成功。
- 释放锁的步骤：释放锁时，需要在所有已经成功获取锁的节点上使用前面提到的安全的释放锁操作（如 Lua 脚本）来删除锁。这样可以确保即使部分节点出现故障或者网络问题，也不会导致锁无法正常释放或者错误释放。

26分布式锁服务器挂了怎么办?

基于 Redis 实现分布式锁时服务器挂掉的情况
- 设置合理的过期时间（TTL）
  - 在使用 Redis 实现分布式锁时，通常会给锁设置一个过期时间（Time - To - Live，TTL）。例如，使用SET key value NX PX timeout命令来获取锁，其中timeout就是锁的过期时间。如果服务器挂掉，只要这个过期时间设置合理，锁会在过期后自动释放。但是，确定合适的过期时间是一个挑战。如果过期时间过短，可能会导致业务逻辑还没执行完，锁就提前释放了；如果过期时间过长，又可能会在锁失效后，业务逻辑还在占用资源，影响其他客户端获取锁。
- RedLock 算法的高可用性保障
  - RedLock 算法通过在多个独立的 Redis 节点上获取锁来提高可靠性。当一个 Redis 服务器挂掉时，只要在多数节点（如 5 个节点中的 3 个）上成功获取锁，就可以认为锁是有效的。在释放锁时，需要在所有成功获取锁的节点上释放锁。这样，即使一个节点出现故障，只要其他节点正常工作，分布式锁系统仍然可以正常运行。不过，RedLock 算法也有其局限性，例如需要保证多个 Redis 节点的时间基本同步，而且网络延迟等因素可能会影响其准确性。
- 监控和自动故障转移
  - 可以设置监控系统来实时监测 Redis 服务器的状态。当发现一个服务器挂掉后，通过配置 Redis 的主从复制或者 Redis Sentinel（哨兵）来实现自动故障转移。例如，Redis Sentinel 可以监控主节点的状态，当主节点不可用时，自动将从节点提升为新的主节点，并且在这个过程中尽量保证分布式锁的状态稳定。不过，在故障转移过程中，仍然可能会出现短暂的锁丢失或者多个客户端同时获取锁的情况，需要在业务逻辑层面进行适当的处理，如重试机制或者幂等性设计。
基于 ZooKeeper 实现分布式锁时服务器挂掉的情况
- ZooKeeper 的可靠性机制
  - ZooKeeper 本身是一个高可用的分布式协调服务。它的数据存储在一个集群的多个节点上，通过 ZAB（ZooKeeper Atomic Broadcast）协议来保证数据的一致性和可靠性。当一个服务器挂掉时，只要集群中的多数节点（超过半数）正常工作，ZooKeeper 就可以继续提供服务。在 ZooKeeper 中实现分布式锁通常是使用临时顺序节点（Ephemeral - Sequential Nodes）。
- 临时顺序节点和会话机制
  - 当客户端在 ZooKeeper 中创建一个临时顺序节点用于获取锁时，只要客户端的会话（Session）保持有效，这个节点就存在。如果客户端所在的机器或者网络出现问题导致与 ZooKeeper 的会话断开（比如服务器挂掉），ZooKeeper 会自动删除这个客户端创建的临时节点，从而释放锁。这就避免了因客户端异常而导致锁无法释放的情况。同时，其他客户端可以通过监听节点的变化来及时获取锁的状态，当一个锁节点被删除时，其他客户端可以竞争获取新的锁。
- 集群容错和恢复：
  AGER: ZooKeeper 集群在服务器挂掉后，会根据选举算法（如 Fast Leader Election）从剩余的正常节点中选举出新的领导者（Leader）。在选举过程中，ZooKeeper 会暂停对外服务一小段时间（这个时间通常在几百毫秒到几秒之间，具体取决于集群规模和网络情况）。在恢复服务后，分布式锁系统可以继续正常工作，之前因为服务器挂掉而丢失的锁会根据临时节点的创建和删除规则重新分配。

27你简历用了消息队列,那么如何保证消息顺序性?你项目里面说你实现了用户点赞功能,如果用户频繁点赞取消,那你如何保证点赞和取消赞的顺序是一致的,保证最终结果的正确性?

保证消息队列中消息顺序性的方法
- 选择合适的消息队列及配置
  - 基于分区的消息队列：一些消息队列（如 Kafka）是基于分区（Partition）的架构。如果消息的顺序性很重要，可以将相关的消息发送到同一个分区中。因为在一个分区内，消息是按照发送的先后顺序存储和消费的。例如，对于用户的操作序列（如点赞、取消赞），可以根据用户 ID 进行分区，这样同一个用户的操作消息就会在同一个分区中，保证了顺序性。
  - 队列的先进先出特性利用：对于像 RabbitMQ 这种传统的消息队列，它本身是基于队列的先进先出（FIFO）原则。只要确保消息按照正确的顺序进入队列，并且消费者按照顺序从队列中获取消息，就能保证消息顺序。在生产者端，可以通过业务逻辑来对消息进行排序后再发送，例如根据操作的时间戳或者事件的先后顺序进行排列。
- 消费者端的处理策略
  - 单消费者处理：如果对消息顺序要求极高，可以为每个消息分区或者队列配置单个消费者。这样可以避免多个消费者并发处理消息时可能导致的顺序混乱。不过，单消费者可能会成为性能瓶颈，需要根据实际业务场景权衡。例如，在处理点赞和取消赞消息时，如果并发量不大，单消费者可以很好地保证顺序性。
  - 同步消费和消息确认机制：消费者在处理消息时，可以采用同步方式，即一次只处理一条消息，处理完成并确保没有问题后，再向消息队列发送确认消息（Ack）。这样可以保证消息按照顺序被正确处理。如果消费者在处理过程中出现故障，没有发送确认消息，消息队列会将消息重新发送给其他消费者或者在故障恢复后重新发送给同一消费者，从而保证消息不会丢失且顺序得到维护。
保证点赞和取消赞顺序及最终结果正确性的方法
- 数据库事务处理
  - 使用关系型数据库事务：在数据库层面，可以将点赞和取消赞操作放在一个事务中。例如，在用户点赞时，向点赞表插入一条记录；取消赞时，删除对应的点赞记录。将这些操作放在一个事务中，通过数据库的事务机制（如 ACID 特性）来保证操作的原子性、一致性、隔离性和持久性。这样可以确保无论点赞和取消赞操作如何频繁，在数据库层面的最终结果是正确的。例如，在 MySQL 中，可以使用BEGIN、COMMIT和ROLLBACK语句来控制事务。
  - 数据库锁机制：利用数据库的锁来防止并发操作导致的顺序混乱。例如，对于同一个用户的点赞和取消赞操作，可以使用行级锁。当一个操作（点赞或取消赞）对用户的点赞记录进行操作时，获取该行的锁，其他操作需要等待锁释放后才能进行。这样可以保证同一时间只有一个操作在处理该用户的点赞记录，从而维护了顺序性和结果的正确性。
- 应用层逻辑控制
  - 状态机设计：在应用层，可以设计一个简单的状态机来管理点赞和取消赞操作。例如，定义用户点赞状态为 “已赞”，取消赞状态为 “未赞”。每次操作时，根据当前状态来判断操作是否合法。如果当前状态是 “已赞”，那么只有取消赞操作是合法的；如果是 “未赞”，则只有点赞操作是合法的。通过这种方式，可以确保操作顺序符合预期，并且最终结果正确。
  - 操作序列记录和验证：在应用服务器端，可以记录每个用户的点赞和取消赞操作序列。当收到新的操作请求时，先验证该操作是否符合记录的操作序列。例如，如果记录的操作序列是点赞 - 取消赞，那么下一个合法操作应该是点赞或者无操作，而不是连续的取消赞操作。通过这种方式，可以在应用层过滤掉不符合顺序的操作，保证最终结果的正确性。

1230java面经

1,有没有一些定位层面上,代码层面上的,比如遇到一些case,定位好几天没定位出来,比如超时、内存泄露、性能优化case?

一、超时问题案例

1. 案例背景

2. 初步定位过程

3. 深入定位与解决

二、内存泄露问题案例

1. 案例背景

2. 初步定位过程

3. 深入定位与解决

三、性能优化问题案例

1. 案例背景

2. 初步定位过程

3. 深入定位与解决

2,dubbo和springmvc都是rpc框架是么?区别有什么?

3，Tcp/lp模型,每一层实现了什么功能,包头信息,最主要的字段是啥,每一层单位是什么?

网络接口层

网络层

传输层

应用层

4，三次握手

5，四挥服务端如果没有数据需要传输了,它的两次挥手可不可以合为一个?

6进程、线程、协程有何区别?

7.java有轻量级的微线程吗?就是由java层面,jvm直接去做调度切换的,不是由系统去做的。

8，操作系统的中断处理怎么工作,比如键盘按了下回车?

9，java创建线程需要触发软中断吧,软中断流程怎么样的?了解系统调用吗?

10，I0多路复用了解吗?

11，redis这种单线程模型有什么缺点吗?

12，get和post的区别是什么?

13，http和rpc的本质区别是什么?

14，请你说一下从浏览器中输入一个url会发生什么?

输入与检查

缓存检查与 DNS 解析

建立连接

发送请求

服务器处理与响应

浏览器处理响应与渲染页面

断开连接

15，输入url后会进行dns解析找到ip,那假如直接在浏览器输入ip地址会怎么样?能访问到吗?和输入url有什么不同?

访问可行性与结果

用户体验

安全与管理

16，你说dns解析的时候有的是递归有的是迭代,为什么要这么设计?为什么不能都是迭代或者都是递归?

17tcp为什么要三次握手,两次不行吗?

18第三次握手除了防止已失效的连接重写连接到服务端,还有别的原因吗?

19并发方面了解吗?hashmap是不是线程安全的?如果让你来实现一个线程安全的hashmap你要怎么设计?如果不用加锁你要怎么设计?

20juc知道吗?juc下最重要的类是哪一个?

21Java中有哪些加锁的方式?除了synchronized和reentlock还有别的吗?

22jvm了解吗?jvm垃圾回收讲一下。

23jvm垃圾回收的时候,有那么多gcroots,怎么快速定位到gcroots的?

24，堆外内存有什么作用?

25Redis 如何实现分布式锁?

26分布式锁服务器挂了怎么办?

27你简历用了消息队列,那么如何保证消息顺序性?你项目里面说你实现了用户点赞功能,如果用户频繁点赞取消,那你如何保证点赞和取消赞的顺序是一致的,保证最终结果的正确性?

网站公告

今日签到

热门文章

最新发布