今日面试题总结

发布时间：2026/10/28 10:09:02

1滑动窗口 + 摘要压缩会话记忆怎么实现？

2 滑动窗口大小怎么确定？一般设多少轮？

3AI Coding 工具遇到的问题 + 完整工作流 + AI Native 做法

4深拷贝 & 浅拷贝

5 finally 一定会执行吗？

6AOP 失效的场景

7 过滤器 Filter 和拦截器 Interceptor 区别？

8哈希冲突解决方法

9完整的RAG流程?

10哪个项目参与最深(介绍一下项目)和个人工作？项目最难或最亮眼的地方是什么？方案为何这样定？之前的性能问题是怎样发现并推进解决的？有哪些主动发现、推动并落地的问题？

11错召回、漏召回你是怎么解决的？

12超发/超卖问题?

13审查 “DB 查工单并缓存” 的代码，有什么问题？

14什么是 AI Agent？

15AI Agent 和普通 Chat 聊天机器人的核心区别是什么？

16何时需要分布式事务，有哪些方案？

17有 AI Coding 工具后，程序员还要会写代码吗？

18从零设计云产品智能客服：知识、资源、排障和转人工。

19AI Coding 的前端开发与交付方式

20前端是否主要使用 AI Coding 开发

21AI Coding 是否涉及端到端交付

22当用户对智能机器人说“帮我向前移动 2 米并打开照明灯”时，如何利用大模型的 Function / Tool Calling 机制输出结构化指令？如果大模型在某些情况下返回了缺漏字段的 JSON（例如只给出了动作类型，遗漏了距离参数），在后端工程上应如何设计校验与兜底逻辑？

23在 RAG 流程中，将文本转为向量（Embedding）并在向量数据库中计算余弦相似度的本质是什么？在切分长文档时，切片过长或切片过短分别会引发什么问题？

24如果需要让机器人精准回答“设备机密维修手册”或“最新排班表”，为什么通常采用 RAG（检索增强生成）方案而不是全量微调（Fine-tuning）模型？请简述 RAG 的三个核心环节。

25AI 编写的代码在本地运行时报出了一长串报错日志（如由于第三方库版本更新导致函数不存在，或混淆了同步与异步调用）。你的排错流程是怎样的？如何甄别 AI 给出的修复代码是否可靠？

26说一下用户数据库配置错误兜底方式

27数据库动态变更不重启服务可以应用 Agent 吗？

28说一下 Agent 接入一个新的 MCP 的完整流程

29消息回调是怎么做的？

30用户输入轮次过多导致模型注意力分散怎么处理？

31上下文超出模型 token 怎么处理？

32文档召回的 benchmark，评估指标设计

33Agent 节点流转过程中运行情况分析

34AI Agent 的核心核心特征有哪些？

35量化评估模型回答效果怎么做的

36单个文档是如何分割的？

37说一下后端项目中涉及到的高并发场景

38说一下 Redis 的压测方式

39说一下 Redis 的数据类型

40Redis 缓存雪崩，击穿，穿透介绍以及应对方式

41Redis 速度快的原因

42介绍 Spring 的 IOC 和 AOP

43说一下 hashmap

44什么是 LLM Agent？核心优势是什么？

45简述 AI Agent 的完整工作闭环

46AI Agent 主要可以落地哪些业务场景？

47AI Agent 的五大核心模块是什么？各自作用？

48简述 Agent Memory 模块的分类及应用场景

49什么是 Agent 规划（Planning）？主流规划方式有哪些？

50什么是 ReAct 架构？在 Agent 中的作用？

51末尾页

1滑动窗口 + 摘要压缩会话记忆怎么实现？

整体是两层记忆：短期原始窗口 + 长期摘要。
1. 滑动窗口：保留最近 N 轮完整对话，原始文本不压缩，模型读取这部分信息保真；
2. 当对话轮数超过窗口阈值，把**窗口外更早的历史**，交给模型做摘要，提炼关键信息（用户需求、结论、约束条件）；
3. 摘要存入长期记忆，后续上下文只带上摘要，不再携带原始长对话；

2 滑动窗口大小怎么确定？一般设多少轮？

Agent 的对话窗口大小，由单轮平均 token、模型上下文上限、业务成本共同决定。计算方式：窗口总 token 预算 ÷ 单轮对话平均 token，换算成轮数。
工程经验：普通对话助手一般 5~15 轮；代码类单轮 token 高，轮数要更小；简单问答可以放大窗口。还要预留token 给 prompt 模板和工具返回结果，不能把上下文占满。上线后用 A/B 实验，根据召回准确率、token 成本、用户反馈动态调参。

3AI Coding 工具遇到的问题 + 完整工作流 + AI Native 做法

一、遇到的问题
幻觉：生成代码存在逻辑 bug、函数不存在、接口参数错误。
上下文受限：代码库大，无法一次性读全仓库，容易丢失跨文件依赖。
代码正确性差：缺少编译、单元测试校验，生成代码不能直接运行。
输出格式混乱：代码块、注释、文本混在一起，难以解析。
成本与速度：长上下文 token 开销高，推理延迟大。
二、完整工作流
用户输入需求；
仓库检索：RAG 检索相关代码文件、文档；
上下文组装：把检索片段、用户需求、系统 prompt 拼装；
LLM 生成代码；
后置校验：语法检查、编译、单元测试；
结果返回给用户；
收集用户反馈迭代优化。
三、AI Native 做法
不再只是 “大模型外挂检索”，让 AI自主规划编码任务：
Agent 规划：拆解需求，自主决定要读哪些文件、调用哪些工具；
多轮工具调用：读代码、查定义、跑编译、执行测试，发现错误自动修复；
增量修改：只改动必要代码片段，不是全量重写；
闭环自校验：模型自己观察编译 / 测试报错，迭代修复代码。

4深拷贝 & 浅拷贝

浅拷贝：只拷贝对象的引用地址，新对象和原对象指向同一个堆内存。基本数据类型拷贝值；引用类型拷贝引用。修改新对象里的引用属性，原对象也会跟着变。
深拷贝：完整拷贝整个对象，包括所有引用类型的成员，生成全新堆对象。新旧对象完全独立，修改任意一方互不影响。
常见实现：浅拷贝`clone()`；深拷贝可以重写 clone、序列化、JSON 序列化。
`Object.clone()`默认是浅拷贝？是的。

5 finally 一定会执行吗？

正常情况下，try 块 return 前，finally 代码会执行。
但**不是一定执行**。
不执行场景：
① 代码执行`System.exit(0)`，直接终止 JVM，finally 不跑；
② JVM 崩溃、系统断电、OOM 致命错误（系统级错误 Error），进程直接挂掉，finally 不会执行；
③ 线程被 kill。
Exception 是异常，Error 是错误，Error 属于系统级问题，JVM 直接崩溃，无法执行 finally。

6AOP 失效的场景

Spring AOP 基于 JDK/CGLIB 动态代理，只有**外部通过代理对象调用方法**才会生效。失效场景：
1. 同类内部方法调用（this. 方法 ()），走的是原对象，不是代理对象，AOP 不拦截；
2. 目标方法不是 public；
3. 静态方法、final 方法，无法被代理；
4.代理对象没有被 Spring 管理；

解决：用`ApplicationContext`拿到代理对象，或者`AopContext.currentProxy()`。

7 过滤器 Filter 和拦截器 Interceptor 区别？

Filter 是 Servlet 规范，Interceptor 是 Spring 框架提供。
执行顺序：请求进来先过 Filter，再到 Interceptor；返回时反过来。
拦截粒度：Filter 拦截 Servlet 请求，基于 URL；Interceptor 拦截 Controller 方法，可拿到处理器信息。
依赖：Filter 不依赖 Spring 容器；Interceptor 属于 Spring，能注入 Bean。

8哈希冲突解决方法

哈希冲突：不同 key 算出相同 hash 地址。两种主流方案：
链地址法（拉链法）：数组每个位置挂链表 / 红黑树，冲突元素挂在后面，HashMap 就是这个。
开放寻址法：数组内找下一个空位，分线性探测、二次探测、双重哈希；ThreadLocalMap 用线性探测。

9完整的RAG流程?

知识库构建：加载文档 → 切分文本 → 向量化 → 存入向量库
检索生成：用户提问 → 向量化 → 检索相关文档 → 拼接上下文 → 生成回答

10哪个项目参与最深(介绍一下项目)和个人工作？项目最难或最亮眼的地方是什么？方案为何这样定？之前的性能问题是怎样发现并推进解决的？有哪些主动发现、推动并落地的问题？

根据简历上的项目具体背诵

11错召回、漏召回你是怎么解决的？

错召回就是检索出来不相关的文档，漏召回是本该召回的相关文档没被检索出来，
我是从检索、重排、数据预处理、阈值策略这几块分开优化的。
针对漏召回，首先扩充召回源，混合 BM25 关键词检索和向量检索，同时对 query 做改写、同义词扩展、拆分长 query，调低召回的 topN 阈值，保证相关材料先有机会被捞出来。
针对错召回，主要靠后面的重排模型做精排过滤，同时收紧相似度阈值，过滤掉低分的结果；另外清洗知识库，去除重复、脏数据，给文档加元数据做过滤，比如时间、业务标签，提前筛掉无关内容。
上线之后持续收集 bad case，定期迭代，把高频的错漏 case 补充到提示词、规则或者样本里。

12超发/超卖问题?

答：超发、超卖问题往往是由于多线程的并发访问导致的。所以解决这个问题的手段就是加锁。可以采用悲观锁，也可以采用乐观锁。
如果并发量不是特别高，就使用悲观锁就可以了。不过性能会受到一定的影响。
如果并发相对较高，对性能有要求，那就可以选择使用乐观锁。
当然，乐观锁也有自己的问题，就是多线程竞争时，失败率比较高的问题。并行访问的N个线程只会有一个线程成功，其它都会失败。
所以，针对这个问题，再结合库存问题的特殊性，我们不一定要是有版本号或者CAS机制实现乐观锁。而是改进为在where条件中加上一个对库存的判断即可。
比如，在where条件中除了优惠券id以外，加上库存必须大于购买数量的条件。这样如果库存不足，where条件不成立，自然也会失败。
这样做借鉴了乐观锁的思想，在线程安全的情况下，保证了并发性能，同时也解决了乐观锁失败率较高的问题，一举多得。

13审查 “DB 查工单并缓存” 的代码，有什么问题？

常见问题：（这个到时候拿到具体项目里面去准备具体问题）
1. 缓存穿透：查询不存在工单，每次都会打到 DB；
2. 缓存击穿：热点工单缓存过期，大量请求打数据库；
3. 缓存雪崩：大量 key 同时过期；
4. 缓存和 DB 双写不一致，更新数据库没有正确处理缓存；
5. 没有处理缓存序列化、过期时间；
6. 并发下，缓存更新逻辑出现竞态条件。
【可选扩展（深挖补充）】对应解法：缓存穿透存空值,使用布隆过滤器；击穿用互斥锁、热点永不过期；雪崩设置过期时间随机偏移；更新优先删除缓存，根据业务选择一致性策略。

14什么是 AI Agent？

AI Agent 是基于大语言模型为核心，具备环境感知、目标理解、自主规划、工具调用、执行反馈、自我迭代能力的智能自治系统。区别于传统问答模型，它以目标为导向，可以自主拆解复杂任务、主动执行操作、闭环完成完整业务流程，是具备行动能力的智能体。

15AI Agent 和普通 Chat 聊天机器人的核心区别是什么？

核心区别体现在四点：
1、能力维度：普通机器人仅支持被动问答，Agent 支持主动规划、自主执行、多轮迭代；
2、工作模式：普通模型单次响应，Agent 形成「感知 - 规划 - 执行 - 反馈」闭环；
3、任务能力：普通模型仅处理简单对话，Agent 可落地复杂长流程任务；
4、拓展性：普通模型无工具联动能力，Agent 可无缝调用各类外部工具、API、知识库。

16何时需要分布式事务，有哪些方案？

当一个业务操作，需要跨多个服务、多个数据库资源，要求所有操作要么全部成功，要么全部回滚，单库本地事务满足不了的时候，就需要分布式事务。常见方案有 2PC、TCC、SAGA、本地消息表、RocketMQ 事务消息，还有 Seata 框架，它封装了 AT、TCC 这些模式，其中 AT 模式业务无侵入，使用最多。
2PC 分为准备阶段和提交阶段，有协调者，缺点是存在阻塞、协调者单点问题，性能差，适合短事务；
TCC 分为 Try、Confirm、Cancel 三个接口，业务层自己实现补偿逻辑，侵入性强，性能较好，适合高并发核心场景；
SAGA 把分布式事务拆成一串本地事务，每个事务配补偿操作，适合长事务；
本地消息表和 RocketMQ 事务消息属于最终一致性方案，异步执行，适合接受短暂数据不一致的业务；
AT 是 Seata 默认模式，基于 undo log 记录快照，自动回滚，业务几乎不用改代码。另外优先考虑业务优化，尽量避免引入分布式事务。

17有 AI Coding 工具后，程序员还要会写代码吗？

需要。
AI Coding 适合做样板代码、DTO、单测、脚本，提升效率。但方案选型、业务理解、并发、事务、资损风险、边界校验需要人来把控；
AI 会产生幻觉，可能写出隐藏 bug。程序员需要看懂、校验、修改 AI 产出，定位根因，承担线上责任。AI 是放大器，不是替代。

18从零设计云产品智能客服：知识、资源、排障和转人工。

1. 知识层：知识库，RAG 检索，存储产品文档、FAQ；做文档分块、向量库；
2. 资源层：对接业务后端接口，工具调用 Function Calling，查询用户工单、账单信息；
3. 排障：Agent 工具调用，执行排障步骤，采集日志；无法解决给出排障指引；
4. 转人工触发条件：多次回答无效、用户主动要求、涉及资损高危场景；把会话上下文、历史问答一并带给人工客服。配套：会话记忆管理、权限控制、SSE 流式输出、知识库管理后台。
【可选扩展（深挖补充）】增加评价反馈，用户反馈好坏，迭代知识库；设置相似度阈值，避免幻觉回答。

19AI Coding 的前端开发与交付方式

AI Coding 是辅助手段。一般是后端先输出接口契约，AI 辅助生成前端页面组件、样式；人去校验交互逻辑、边界异常、联调后端接口。交付物还是标准前端工程，正常打包部署。

20前端是否主要使用 AI Coding 开发

是的，但是不会完全交给 AI。AI 可以快速生成样板页面、组件，提升开发速度；但是业务交互逻辑、异常处理、兼容性，需要人修改、校验，不能直接交付。

21AI Coding 是否涉及端到端交付

可以做端到端原型快速生成，但不能直接线上交付。AI 生成端到端代码经常存在逻辑漏洞、边界缺失；需要人工 review、自测、联调之后，才可以交付上线。

22当用户对智能机器人说“帮我向前移动 2 米并打开照明灯”时，如何利用大模型的 Function / Tool Calling 机制输出结构化指令？如果大模型在某些情况下返回了缺漏字段的 JSON（例如只给出了动作类型，遗漏了距离参数），在后端工程上应如何设计校验与兜底逻辑？

工具调用流程：预先定义move移动、turn_light开灯两个工具描述传给大模型。用户输入后，大模型识别要执行两个工具，输出结构化 JSON 数组，一条控制向前移动 2 米，一条打开照明灯。后端拿到 JSON，分别调用对应硬件接口执行动作。
缺字段兜底： ①后端做 JSON Schema 强制校验，校验必填字段，缺失直接拦截； ②字段缺失，把错误信息回传给大模型，让模型重新补全参数； ③增加业务兜底，关键参数缺失不向下发硬件指令，拒绝执行，返回提示用户补充信息。

23在 RAG 流程中，将文本转为向量（Embedding）并在向量数据库中计算余弦相似度的本质是什么？在切分长文档时，切片过长或切片过短分别会引发什么问题？

余弦相似度本质：把文本映射高维向量空间，用向量夹角大小衡量两段文本语义相似程度，夹角越小语义越接近。
切片过长：块里面包含大量无关内容，引入噪声，检索出来无关信息，干扰大模型；
切片过短：语义被截断丢失上下文，语义碎片，检索相关性下降。

24如果需要让机器人精准回答“设备机密维修手册”或“最新排班表”，为什么通常采用 RAG（检索增强生成）方案而不是全量微调（Fine-tuning）模型？请简述 RAG 的三个核心环节。

选 RAG 原因： 1. 文档经常更新，微调要重新训练，成本高；RAG 直接更新知识库即可； 2. 机密数据，微调会把知识固化进模型权重，存在泄露风险；RAG 知识库可以做权限管控； 3. 微调成本高，需要大量高质量样本，RAG 不需要训练模型。
RAG 三大核心环节：文档处理与分块、向量检索召回、将检索片段注入 prompt 交给大模型生成答案。

25AI 编写的代码在本地运行时报出了一长串报错日志（如由于第三方库版本更新导致函数不存在，或混淆了同步与异步调用）。你的排错流程是怎样的？如何甄别 AI 给出的修复代码是否可靠？

排错流程： 1. 先定位报错栈，确认报错位置、报错原因； 2. 区分是依赖版本问题、同步异步问题，还是业务逻辑问题； 3. 复现问题，最小复现案例； 4. 再参考 AI 给出修复方案，而不是直接复制粘贴。
甄别修复代码：1. 看修复逻辑是否匹配报错栈； 2. 检查有没有引入新幻觉 API； 3. 阅读代码逻辑，手动梳理流程； 4. 写完做单元测试，本地复现验证。

26说一下用户数据库配置错误兜底方式

分多层兜底：1.前置校验，配置下发时校验地址、账号、端口格式；2.连接探测，Agent 拿到配置先轻量 ping / 测试连接；3.捕获连接异常、权限异常，区分报错文案，返回给用户，不直接抛堆栈；4.熔断，连续多次配置错误，停止重试；5.配置隔离，坏配置不影响其他 Agent 实例。

27数据库动态变更不重启服务可以应用 Agent 吗？

可以。不用重启，靠配置中心（Nacos/Apollo）监听配置变更，感知数据库连接信息变更；Agent 注册监听器，收到变更后，优雅关闭旧连接池，新建连接池，切换数据源。

28说一下 Agent 接入一个新的 MCP 的完整流程

1. 定义 MCP 工具元信息：名称、描述、入参 schema、出参 schema；
2. 注册到 Agent 工具注册表；
3. 编写调用适配器：封装请求、参数映射、异常捕获；
4. 给模型的 system prompt 注入这个工具描述，让模型知道什么时候调用；
5. 增加权限、限流、超时配置；
6. 测试：触发模型调用、校验返回、异常 case 验证；最后上线，埋点统计调用成功率。

29消息回调是怎么做的？

两种主流方式：
1.HTTP 回调：Agent 执行完工具 / 任务，主动调用业务方提供的回调地址，带上结果；2.MQ 消息回调：执行完成投递消息到指定 topic，消费方监听。同时做幂等，加唯一回调 ID；失败支持重试、死信兜底。

30用户输入轮次过多导致模型注意力分散怎么处理？

1.会话摘要：定期对历史对话做摘要压缩，精简历史；
2. 按重要性做记忆分级：长期重要信息存向量库，不重要的轮次直接丢弃；
3. 控制历史轮数上限，轮数到阈值触发裁剪；
4. 优先保留和当前问题相关的历史，无关对话过滤。

31上下文超出模型 token 怎么处理？

分层策略：
优先统计 token 数量，超过阈值先裁剪低相关性历史；
再做对话摘要压缩；
RAG 场景减少召回文档片段；
最后兜底截断，同时给模型提示，避免丢失关键指令。

32文档召回的 benchmark，评估指标设计

召回基础指标：召回率、精确率、F1；
业务指标：问答准确率、幻觉率、用户满意度；还有时延、召回数量上限。构造 query - 标准文档标注数据集跑 benchmark。

33Agent 节点流转过程中运行情况分析

Agent 是状态节点流转：思考→工具调用→拿到结果→继续思考。埋点记录每个节点耗时、状态、输入输出；看是否卡在工具调用、是否频繁重试、是否循环调用工具；统计成功率、失败原因、链路耗时。

34AI Agent 的核心核心特征有哪些？

主要包含五大特征：自主性、目标导向性、环境感知性、工具交互性、自我反思性。
无需人工逐轮指令，可自主推进任务，适配动态环境变化，实时修正执行策略。

35量化评估模型回答效果怎么做的

两条路线：自动评估+人工评估。
自动：用评估模型打分，检查是否引用检索文档、是否幻觉、是否符合问题；
人工标注做golden 标准，计算准确率、幻觉率；同时收集用户反馈标签。

36单个文档是如何分割的？

用滑动窗口切分，固定 chunk 大小 + 重叠；
优先按语义、标题、段落边界切，尽量不切断语义；
长文本切成多个片段，每个片段单独向量化入库。

37说一下后端项目中涉及到的高并发场景

有的，我们项目中有几个典型的高并发优化场景。
场景一：学习记录上报优化
问题：用户看视频时每隔几秒上报一次播放进度，如果每次都写数据库，高峰期数据库扛不住。
优化：
播放进度先写 Redis 缓存（毫秒级响应）
通过 DelayQueue 延迟队列检测用户是否离开
只有用户离开后才做一次数据库持久化
从"每几秒写一次DB"优化为"每个视频只写一次DB"，数据库写入量下降了90%以上
场景二：优惠券领取的异步化
问题：领券接口同步执行"校验 → 写记录 → 扣库存"，响应慢、吞吐低。
优化：
前置校验全部在 Redis 中通过 Lua 脚本完成（毫秒级）
后续持久化通过 MQ 异步完成
接口响应时间从几百毫秒降到几十毫秒，吞吐量提升数倍
场景三：积分排行榜的读写分离
问题：积分排行榜需要实时展示，如果每次都从数据库查，性能差。
优化：
当前赛季排行榜用Redis ZSet存储，查询排名 O(log N)，实时更新 O(log N)
历史赛季数据按月分表，通过定时任务从 Redis 迁移到 MySQL
前端展示只取 Top 100，数据量可控
场景四：优惠券方案的多线程并行计算
问题：预下单时需要枚举优惠券的所有排列组合，逐个计算优惠金额，方案多时串行计算慢。
优化：用 CompletableFuture + 自定义线程池并行计算所有方案，配合 CountDownLatch 设置2秒超时，把计算时间从几百毫秒压缩到几十毫秒

38说一下 Redis 的压测方式

用 redis-benchmark 工具，指定并发数、请求量、命令；
也可以用 JMeter；压测关注 QPS、延迟、CPU、内存；测热点 key、大 key 场景，看是否有瓶颈。

39说一下 Redis 的数据类型

答：很多，比如String、Hash、Set、SortedSet、BitMap等
面试官追问：能不能具体说说使用的场景？
答：比如很多的缓存，我们就使用了String结构来存储。还有点赞功能，我们用了Set结构和SortedSet结构。签到功能，我们用了BitMap结构。
就拿签到来说吧。因为签到数据量非常大嘛，而BitMap则是用bit位来表示签到数据，31bit位就能表示1个月的签到记录，非常节省空间，而且查询效率也比较高。
点赞业务功能
答：我们使用了两种数据结构，set和zset
首先保存点赞记录，使用了set结构，key是业务类型+业务id，值是点赞过的用户id。当用户点赞时就SADD用户id进去，当用户取消点赞时就SREM删除用户id。当判断是否点赞时使用SISMEMBER即可。当要统计点赞数量时，只需要SCARD就行，而Redis的SET结构会在头信息中保存元素数量，因此SCARD直接读取该值，时间复杂度为O(1)，性能非常好。
为什么不用用户id为key，业务id为值呢？如果用户量很大，可能出现BigKey？
您说的这个方案也是可以的，不过呢，考虑到我们的项目数据量并不会很大，我们不会有大V，因为点赞数量通常不会超过1000，因此不会出现BigKey。并且，由于我们采用了业务id为KEY，当我们要统计点赞数量时，可以直接使用SCARD来获取元素数量，无需额外保存，这是一个很大的优势。但如果是考虑到有大V的场景，有两种选择，一种还是应该选择您说的这种方案，另一种则是对用户id做hash分片，将大V的key拆分到多个KEY中，
//结构为 [bizType:bizId:userId高8位]
不过这里存在一个问题，就是页面需要判断当前用户有没有对某些业务点赞。这个时候会传来多个业务id的集合，而SISMEMBER只能一次判断一个业务的点赞状态，要判断多个业务的点赞状态，就必须多次调用SISMEMBER命令，与Redis多次交互，这显然是不合适的。（此处略停顿，等待面试官追问，面试官可能会问“那你们怎么解决的”。如果没追问，自己接着说），所以呢我们就采用了Pipeline管道方式，这样就可以一次请求实现多个业务点赞状态的判断了。

40Redis 缓存雪崩，击穿，穿透介绍以及应对方式

穿透：查不存在 key，大量请求打 DB → 存空值、布隆过滤器。
击穿：热点 key 过期，大量请求打 DB → 永不过期、互斥锁。
雪崩：大量 key 同时过期，DB 压力暴增 → 过期时间加随机偏移、集群隔离、熔断降级。

41Redis 速度快的原因

第一，Redis 是纯内存数据库，数据都存在内存，内存读写远快于磁盘；
第二，采用单线程模型，没有多线程锁竞争、上下文切换开销；
第三，IO 多路复用，一个线程可以管理大量客户端连接；
第四，数据结构都是高度优化的底层结构，比如SDS、跳表、压缩列表；
第五，协议简单，文本化 RESP 协议，解析开销小；
第六，RDB/AOF 持久化是后台子进程做，不阻塞主线程。

42介绍 Spring 的 IOC 和 AOP

IOC 控制反转：把对象创建、依赖交给 Spring 容器管理，解耦；
DI 依赖注入是 IOC 的实现方式。
AOP，即面向切面编程，在Spring中用于将那些与业务无关但对多个对象产生影响的公共行为和逻辑抽取出来，实现公共模块复用，降低耦合。常见的应用场景包括公共日志保存和事务处理。
SSM框架 - 飞书云文档
这个里面有其所有的面试题

43说一下 hashmap

常见集合篇 - 飞书云文档
这个链接拉到最下面就是全部的hashMap面试题

44什么是 LLM Agent？核心优势是什么？

LLM Agent 是以大语言模型为核心大脑的智能体，依靠 LLM 的自然语言理解、逻辑推理、文本生成能力，完成任务拆解、决策判断、内容输出。核心优势：无需大量标注数据、自然语言交互零门槛、泛化能力强、适配各类非结构化场景、快速落地业务。

45简述 AI Agent 的完整工作闭环

1、感知输入：接收用户指令、环境信息、历史上下文；
2、目标解析：精准识别核心需求与任务边界；
3、任务规划：拆解复杂目标为可执行子任务；
4、行动执行：调用工具、检索知识、生成内容；
5、结果反馈：校验执行结果、判断是否完成目标；
6、迭代优化：自我反思问题，修正策略，完成闭环。