先从完整进阶之路浏览知识体系，按问题阅读工程指南，或进入AI 应用开发。作者故事与辅导服务在下文分别说明。

内容适合谁

• 有 Java 基础，希望深入集合、并发、JVM、Spring、数据库与分布式系统的人。
• 正在做后端开发，需要结合原理分析事务、缓存、线程池等工程问题的人。
• 想从 Java 后端扩展到 RAG、Agent 等 AI 应用开发的人。
• 已有项目经历，需要整理真实职责、技术决策和验证材料的人。

零基础读者可以先阅读Java 基础，再按路线安排任务。路线中的周数用于分配任务，不构成学习或求职结果保证。

作者与经历

文章署名统一为 IT枫斗者。作者的个人回顾与其中讲述的团队故事见从借来的工位开始。技术文章中的事实和观点通过参考资料、版本范围和修订记录尽量区分。

故事中的任职、答疑、团队发展与活动经历以作者个人自述为主，配图保留原有公开材料。博客页面截图能支持截图当时显示的文章、访问和粉丝数据及平台称号，不代表当前实时数据，也不能独立证明全部任职经历。

“累计三千多名学员上岸”等数字是作者对历年陪跑经历的历史自述，目前尚缺可复核的完整统计范围、结果定义和去重依据；不能当作已核验人数、成功率或对个人求职结果的承诺。活动照片、分享中的图表和脱敏聊天各有支持范围，不能据此补出未公开的身份、资历或整体效果。本站整理 AI 应用内容，也不意味着这些历史活动已证明作者具有特定 AI 研发任职或项目交付经历。

免费内容与服务

技术文章、学习路线和检查表资料可以免费阅读或下载。读者可以先按技术主题学习，再根据需要选择辅导。

付费服务包括面向已有 Java 基础读者的 Java 面试训练营、补齐 AI 应用与项目表达的 Java + AI 训练营，以及从基础讲解、练习反馈到项目指导的 Java + AI 私教带徒。适用对象、费用与沟通流程见报名说明；具体范围、答疑安排和交付内容以双方确认的服务清单与协议为准。

站内已有案例记录不等于所有参与者都能获得相同结果。评估辅导前，应结合自己的基础、时间和目标岗位确认服务是否匹配。

发现错误怎么办

请在项目 Issues提交文章地址、具体段落、适用版本和建议来源，也可以通过公众号 IT枫斗者 或微信 itfdz666 反馈。修订方式见内容维护与引用规则。

修改前：技术名词很多，责任无法核对

负责企业级 AI 知识库架构，使用 Java、RAG、多租户和权限控制，提升检索准确率。

这句空泛描述取自既有项目经历样例的反例。问题在于：“负责”没有说明具体交付，“企业级”没有部署与运营证据，“提升准确率”没有题集、基线与判定规则。既有样例讲的是 Java 单文件实验；这里改用当前具有 HTTP、数据库与认证的知识库服务，重新核对事实，不挪用单文件实验的七个回放场景。

修改后：作者对当前教学实现的表达

在使用合成文档的 Java 21 / Spring Boot 知识库教学服务中，我负责服务端身份约束、文档版本管理与带引用检索的实现。

通过数据库会话取得租户和角色，检索仅使用当前未删除且当前身份可见的文档；更新、删除检查 expectedVersion，更新通过事务写入新版本并切换当前版本指针，响应返回文档 ID、版本和原文引用。

验证以本地 H2、演示身份和合成输入为条件；公开报告记录了默认 17 项测试通过，以及独立进程 23 次 HTTP 检查和重启验证，可据此核对跨租户、权限收紧、旧版本与删除场景。

默认回答来自本地词项匹配和原文摘录；可选 pgvector 的三维 fixture 验证不代表真实模型或线上语义质量，当前没有生产性能与业务收益结论。

这四句话是一条项目描述的完整展开稿，便于教学核对。实际简历可以压缩篇幅，但保留“个人做了什么、如何实现、在什么条件下验证、结论到哪里为止”。这里的测试数字引用已有公开报告，不表示读者执行过，也不表示本页另做了一轮测试。

逐句为什么这样改

| 句子 | 改写理由 | 对应的实现或证据 |
|

首批目录

| 页面 | 已经填好的内容 | 你需要带走的产物 |
|

三分钟讲解全文

下面的时间仅用于练习分配，实际时长取决于语速，不是一次已经测量的录音。可先读完，再合上页面按请求链复述。

0:00—0:30：项目性质、问题与职责

“这是我用于教学的 Java 21、Spring Boot 知识库服务，使用合成文档，默认运行在本机。我负责服务端身份约束、文档版本和检索证据返回。它要解释一个具体问题：文档更新、收紧权限或删除后，当前用户还能用哪份原文回答问题。项目没有企业客户和线上流量，下面说的是本地实现及公开验证范围。”

0:30—1:15：从请求入口讲到证据

“登录后服务端签发不透明 Bearer token，数据库存 token 哈希；后续请求通过会话关联数据库用户取得租户和角色。检索先连接文档的当前版本，排除删除墓碑，再按当前角色过滤。默认模式对问题与文档提取英文词项和中文二元词项，覆盖分数达到 0.6 才保留证据。回答使用最高分文档的原文，引用里有文档 ID、版本和完整正文；没有候选时返回 refused=true 和空引用。因此我把它称为本地词项检索与原文摘录。”

1:15—2:00：用一次权限变化说明关键取舍

“重点场景是公开文档变成 ADMIN 可见。测试先创建包含 cobalt 的 READER 文档，再携带 expectedVersion=1 更新为 ADMIN 的第二版；reader 继续搜 cobalt 应拒答，直接读取是 404。不能因为第一版曾公开，就回退到第一版。实现上只读取 current_version；更新和删除先锁定本租户文档行，再检查预期版本，旧值冲突返回 409。更新在事务中保存新版本并切换指针，删除写墓碑，历史仍保留。这里验证的是状态与可见性，没有承诺物理擦除。”

2:00—2:35：给出可以打开的验证证据

“公开报告记录默认 H2 路径 17 项测试通过，另有独立 Java 进程在 127.0.0.1:8085 的 23 次 HTTP 检查，包含应用进程重启后的版本和会话检查。包内有 JUnit XML、smoke 原始响应和源码哈希。这些数字分别对应不同验证口径，不能相加成准确率。它们支持已列场景的断言，也不代表断电恢复、线上负载或所有并发交错都已验证。”

2:35—3:00：把扩展与未测部分说清楚

“可选 Spring AI 与 pgvector 路径有真实向量库存储测试，使用三维确定性 fixture；公开报告中真实模型 API 和语义质量未测，而且回答仍是原文摘录。默认每份文档是一个检索单元，没有分块。下一步若扩展同义问法或检索质量，需要固定文档快照、题集和判断规则，再运行真实模型评测，才能讨论效果；当前没有性能和业务收益数字。”

五个追问的完整回答

追问一：客户端能否传 tenant 或 role，让自己看到其他租户？

示范回答：“调用者身份来自服务端会话，不由文档请求体或自定义 header 决定。Auth.security 用 Bearer 的 SHA-256 哈希查会话，并关联 app_users 读取 tenant 与 role。文档的 minRole 表示文档所需级别，不能把它理解成当前用户的身份。Knowledge.list 的 SQL 先限定租户、未删除和当前版本，再做角色检查；另一租户即使是 ADMIN，也不能读取这份文档。不存在或不可见的文档统一 404，reader 写入返回 403。公开测试 serverOwnsTenantAndRole 与 tenantIsolationForReadUpdateDeleteAndSearch 分别检查身份注入和跨租户操作。”

边界补充：“每个请求重新读取用户角色，所以角色修改影响既有 token 的后续请求；已经认证、正在执行中的请求以认证时身份为准。我不会把它说成能中断所有在途请求。当前是固定演示身份，生产注册、密码重置、TLS、限流和完整审计不在项目范围内。”

追问二：为什么更新后不查旧版本？两个编辑者同时提交怎么办？

示范回答：“历史存在不等于仍可访问。新版本可能已经收紧权限，文档也可能已删除；回退旧公开内容会绕过当前状态。Knowledge.list 只连接 kb_documents.current_version，并排除 deleted=TRUE。update 和 delete 在事务中，先按租户与未删除条件执行 FOR UPDATE 行锁，再读取当前可见文档，比较 expectedVersion。两个编辑者拿到同一版本时，先成功的更新会推进版本；后一个持旧值提交应得到 409，需要重新读取后决定是否修改。”

边界补充：“这是代码所采用的冲突处理方式。公开的 staleVersionConflicts 测试验证陈旧版本的更新与删除返回 409，不是所有并发时序的压力验证；permissionChangeCannotFallBackToPublicOldVersion 检查权限收紧后不回退。删除保留墓碑与历史，没有实现历史恢复接口。我也不会把单机事务描述成跨服务事务或完整分布式一致性。”

追问三：这是不是模型问答？score=1 能否说明回答完全正确？

示范回答：“默认 mode 是 local-lexical-extractive，没有调用 embedding 或聊天模型。Knowledge.tokens 提取词项，search 用命中的问题词项数量除以问题词项总数，空词项集合得 0，至少 0.6 才进入候选。命中时 answer 取排序后第一条证据的完整正文，quote 也来自保存的正文。score=1 只能说明提取出的查询词项全部出现，不能说明文档回答了问题，更不是答案正确概率。”

边界补充：“例如同一组词可能出现在无关语境，同义改写也可能没有共同词项；这两类都需要额外评测。无候选时 refused=true、citations=[]，说明没有满足当前规则的证据，不能声称系统已经判断所有语义问题都无答案。现有 citationsAreExactAndVersioned 与 unknownQuestionRefusesWithoutCitation 只验证引用一致和固定无命中输入，没有证明一般语义质量。”

追问四：既然有 Spring AI 与 pgvector，通过测试为什么还不能写语义 RAG 效果？

示范回答：“实现确实提供官方 EmbeddingModel 和 PgVectorStore 接入。使用真实模型的 ai 模式需要同时启用 Maven 的 -Pai 与运行时 ai profile，另行准备 PostgreSQL/pgvector 和模型配置；单独启 Maven profile 只是让相应代码参与编译。公开向量集成测试用真实 PostgreSQL，但 EmbeddingModel 是三维确定性 fixture：文本含 java 返回一组固定向量，否则返回另一组。它适合稳定检查向量存储、tenant/minRole metadata 过滤、更新删除和旧候选处理，没有验证模型如何理解自然语言。”

边界补充：“AiConfiguration.Gateway.search 做 metadata 过滤后，Knowledge.search 再对权威数据库的当前可见文档及版本进行核对，避免旧向量成为证据。公开报告最终 22 项里是 21 通过、1 跳过，跳过的是 LiveEmbeddingTest；liveModelApi 和 semanticRagQuality 都明确未测。0.75 是向量候选阈值，未做语义质量校准；该路径仍返回原文，没有聊天模型生成答案。”

追问五：你凭什么说项目做完了？如果继续做，先补什么？

示范回答：“我只说教学范围内已实现并有公开验证，不说生产可用。项目包有 README、API、实现和验证材料；公开报告能看到默认 17 项测试、最终 ai 编译验证 22 项及跳过项、独立进程 23 次 HTTP 检查。要核对具体主张，打开对应 JUnit 用例或 smoke 响应，而不是只看 passed 字段。报告与源码用 manifest 哈希对应，下载包也有 SHA-256，可以确认材料属于同一版本。这些是项目既有证据，不是读者自己的执行结果。”

边界补充：“后续若评估检索质量，我会先建立固定文档快照、问题和相关证据标注，把检索相关性、原文支持与回答正确性分开判断；真实模型调用需要另行运行并记录配置。若准备公开部署，则先补身份管理、凭据替换、TLS、限流和审计。这些是后续计划，当前没有完成证明。我不会给出尚未测量的吞吐、延迟，也没有真实客户收益或学员录用结果。”

填写示例与练习表

先将“项目已有事实”和“本人参与证据”分开记录。下表已填写作者示范的事实栏，读者操作栏说明应产出什么。作者的报告可以作为核对依据，不能替代本人复跑或修改记录。

| 练习项 | 作者示范：已经能核对的内容 | 你需要执行并记录 |
|

技术结论

1. 优先引用语言、框架或产品的官方文档、公开源代码和原始论文。
2. 涉及源码细节时说明 JDK、框架或产品版本；实现细节不直接当作跨版本承诺。
3. 先给可执行答案，再写适用条件、失败场景和替代方案。面试速记不能代替工程设计。
4. 示例代码、合成数据和真实测试结果分别说明。没有实际运行的数据不写成吞吐量、提升比例或成功率。

修订与时间

新文章使用实际撰写日期。旧文章只在实质修订时记录更新日期，不因重新构建网站刷新时间；无法确定的历史发布日期不补写。

本次优先修订了 HashMap 的版本与树化边界、Redis 的缓存一致性和持久化表述，并新增学习路线与实战专题。其他旧文仍可通过反馈继续完善。

案例与项目

• 教学项目、演示项目、个人实验与工作经历应分别描述。
• 简历里的“负责”“设计”“优化”对应本人实际完成的工作，不用教学项目冒充生产经历。
• 学员结果需要保留时间范围、服务内容与个人背景；涉及个人材料的新增展示需取得本人授权并去除不必要的个人信息。
• 不给训练营效果、招聘结果或收入作普遍承诺。

引用本站与提交纠错

实际转载文章与阅读组件的快照、许可证和修改情况，见 JavaGuide 参考与转载来源。转载文章保留原作者，复制时的来源说明也与本站文章分开。

引用时保留原文链接、文章标题和适用版本。错误反馈请提供“文章地址 → 原句 → 使用版本 → 依据或复现步骤”，提交到仓库 Issues。

版权与转载以原项目许可证及文章具体署名为准，外部图片或引用资料的权利归原作者。本站不会把第三方内容改名为自己的原创。

准备 知识库服务源码、验收手册和 可编辑练习单。先按项目 README 选择运行模式，全文使用合成文档，避免带入公司或个人敏感资料。

第 1 项：启动并确定实验条件

动作： 记录操作系统、JDK、源码版本、运行模式和启动命令。启动项目后发出一条正常请求与一条未认证请求。

保留： 启动日志、请求方法和路径、响应状态、响应摘要。只写“启动成功”不够，还要知道服务监听在哪里、使用什么身份、数据保存到哪里。

完成条件： 能解释启动成功与业务请求成功的区别。失败时先按使用帮助区分环境、依赖、端口与认证问题。

第 2 项：理解一条答案的证据

动作： 用项目示例文档提出一个可回答的问题，再问一个文档里没有答案的问题。把引用 ID 对应到原文。

保留： 问题、原文、返回内容、证据 ID 与无答案响应。

完成条件： 能说明“找到相似内容”“有充分证据”“生成了正确答案”是不同结论。本地检索模式没有模型生成时，只验收它实际提供的检索与摘录能力。

第 3 项：验证租户与角色

动作： 在两个租户准备同名但内容不同的文档，分别使用两个已认证身份提相同问题；再用普通角色请求受限文档。

保留： 身份所属租户、文档归属、请求及实际引用。不要把客户端传入的 tenantId 当作身份保障。

完成条件： 能确认进入返回结果的每条证据都属于允许访问的范围。代码中查找身份从认证结果到查询过滤的实际传递位置。

第 4 项：修改文档，查清旧值来自哪里

动作： 把一份规则从“年假五天”更新为“年假十天”，再查询同一问题。保留新旧文档标识与状态，不只看一段回答文字。

保留： 更新请求、当前版本、候选证据和实际引用。

完成条件： 能解释当前版本在哪里确定，旧内容为什么不应再次进入结果。需要增加向量入库故障时，按文档更新指南另外设计回放；没有执行的分支标为待验证。

第 5 项：删除与收紧权限

动作： 删除当前文档，再提相同问题，检查是否错误回退到旧版本。另用项目支持的方式收紧文档权限，重新查询。

保留： 删除或修改权限的响应、后续查询、旧版本状态与拒答结果。

完成条件： 分清“停止提供文档内容”和“所有副本已经物理清除”。外部向量库、对象存储、备份与会话历史需要各自的清理策略，不能用本地一条查询替代。

第 6 项：把失败写成可重放用例

动作： 从前面的步骤选择一个失败，整理最小输入。记录预期、实际、影响、修正与再次运行结果；全部正常时，也可以使用教学实验里的未过滤对照实现观察失败。

保留： 一份别人能按步骤重放的记录。错误改了就重新执行相同输入，保留前后结果。超时与重试设计可结合接口截止时间指南继续练习，不把设计建议写成已测性能。

完成条件： 读者能够区分原始日志、规则推导与未来改进。

第 7 项：讲清楚自己做了什么

动作： 用三分钟交代业务范围、本人修改、请求链路、一个失败分支和未完成部分。对照项目表达样例写一段练习经历。

保留： 源码版本、运行记录、用例表与讲解提纲。下载并运行公开项目可以写成学习实践，自己新增了什么需要单独说明。

完成条件： 面对“为什么这样过滤”“旧版本为什么不能回退”“如何知道修复生效”的追问，有代码或记录可以核对。

做完之后

可以到自测工作台检查相关知识，再把错题加入复习单。若仍有问题，按提问模板说明输入、预期、实际和已尝试办法。

• 7 天知识库验收练习：从启动到版本、权限、删除与结果记录。
• 知识自测与错题复习：答题后看解释，导出后续阅读与实践清单。
• 完整题目解析：不使用交互工具也可以直接查阅。

适用版本与边界

本文面向 Redis Open Source 7.2／7.4、关系数据库与应用自行维护的 Cache-Aside。只使用已有的 GET、SET EX、DEL 语义，不依赖新版本命令。数据库是事实来源；订单扣款、库存条件更新等正确性判断应落在数据库约束或事务中。

Redis 官方 Jedis 示例说明了写后失效。下文的 outbox 和故障处理是基于这些命令语义作出的工程设计推导，不是 Redis 自动提供的跨库事务。

1. 为什么写后删除仍可能读到旧值？

设商品原值为 v1，写请求准备更新为 v2。要区分以下路径，不能都归结为“Redis 删除失败”。

| 失败时序 | 直接后果 | 优先处理 |
|

父级决定插件能复用哪些已加载类型，插件自己的 URL 决定委派未命中后去哪里找。平台父级能减少对宿主应用依赖的可见性，应用父级便于共享宿主接口；应先确定接口由谁定义，再决定隔离范围。

常见故障是老插件扫描器启动就出现 ClassCastException，改完强转又找不到 JDBC 接口，最后读核心类资源时把 jrt: 当成本地文件路径。它们发生在不同层，逐项验证比盲目添加 JVM 参数更有效。

1. 把版本边界写进排查记录

| 项目 | JDK 8 常见 Oracle/OpenJDK 实现 | JDK 9+，包括 21 |
|

真实问题往往出在维护公共接口：给两个无继承关系的接口各加一个相同签名的默认方法，原本正常的实现类重新编译就报错；把静态工具方法当作实例方法调用，也会找不到符号。先确认方法属于哪一类，再判断调用者需要修改什么。

1. 按版本与调用方式看规则

| 方法写法 | 起始版本 | 方法体与使用方式 |
|

对已有 1—3 年 Java 经验的人，优先从熟悉业务中选择数据可合法使用、流程可演示、失败可验证的一小段，再根据实际效果扩展模块。

1. 从原站项目截取范围

项目介绍是场景参考，下面的实现范围是个人练习建议，不代表已有企业交付经历。

| 原站项目 | 首版只做什么 | Java 侧验收 | AI 侧验收与边界 |
|

模型的单次超时只覆盖调用链中的一段；排队、检索、SDK 重试和网关重试依次叠加，就可能让页面等待远超这一个参数。因此先限制整次请求的等待，再决定是否值得用余额换一次重试。

本文核心示例以 Java 21 执行；Spring 适配说明引用 Framework 6.2.x 的 MVC/WebClient API。Spring AI 官方入门文档 将 2.0.x 对应到 Spring Boot 4.0.x/4.1.x，不能把这里的 Framework 6.2.x 文档当作该组合的版本适配证明。使用 Spring AI 2.0.x 时，应按项目 BOM 实际解析出的 Framework 和客户端版本查配置；本文未验证这套 Spring 集成。

1. 先约定总预算，再给阶段设上限

假设练习接口总预算十秒，预留五百毫秒用于整理错误与响应。排队和检索用掉多少，模型就少多少；模型阶段上限六秒，但实际允许值为 min(阶段上限, 剩余时间 - 收尾预留)。这些数字是教学配置，不是测出的服务能力。

同进程用 System.nanoTime 的差值计时，避免系统时钟校准影响耗时。计时从入口开始，不能等连接拿到才开始。跨进程不能直接发送本机纳秒值。gRPC 的截止传播机制 会把截止换成已扣除耗时的剩余时长，避免直接比较不同机器的时钟。自定义 HTTP 头不会自动获得这些能力：发送前重算余额，接收时取上游余额与本地限制的较小值，再用本地单调时钟扣除后续耗时。接收端仅凭一个剩余时长无法精确知道在途耗时；需要额外的传输安全余量，并由上游自己的总截止约束等待。若选择绝对截止时间，则还需明确时钟同步与偏差处理规则，不能声称仅靠透传即可严格保证端到端截止。

2. 让每次调用重新取剩余时间

下载 TimeoutBudgetDemo.java。其 Budget.stage 在发起阶段前检查余额，retry 同时检查退避、最小尝试窗口和收尾预留。生产构造方式与核心计算为：

Budget budget = new Budget(Duration.ofSeconds(10), System::nanoTime);
Duration allowed = budget.stage(Duration.ofSeconds(6), Duration.ofMillis(500));

上面两行使用下载文件中的嵌套类；不要单独当作完整程序编译。阶段超时必须传入实际客户端，并由请求级定时任务处理“阶段运行中总截止到达”的情况。仅在调用前检查余额，不能中止已卡住的操作。

JDK HttpClient 的连接超时 约束建立新连接；HttpRequest.timeout 用于单次请求。Spring 的 WebClient 配置 还区分连接和响应配置。连接池等待、正文消费、流结束都要按所用客户端核验，不能把某个参数名当成整条链路保证。

3. 重试之前做三个判断

1. 故障可重试吗？ 只对策略允许的暂时故障有限重试，认证失败、参数错误不重试。把 SDK、业务、网关的重试次数合并核算，约定“最多两次尝试”包含第一次。
2. 操作允许重复吗？ 超时可能发生在对方执行成功之后。写工单等操作需要服务端持久化幂等键、请求摘要与执行状态，并能查询结果；本机 Map 或每次新建请求号不能保证幂等。纯生成虽未写业务库，也可能重复计费或调用工具。
3. 余额和输出允许吗？ 退避、下一次最小窗口与收尾预留之和必须小于剩余预算；一旦已向用户输出内容，默认禁止透明重试。否则同一答案会混入两次生成结果。

本机运行方式：

javac -encoding UTF-8 --release 21 TimeoutBudgetDemo.java
java -cp . TimeoutBudgetDemo

实际 stdout：

modelCapMs=6000
remainingMs=3500
retryWithBackoff=false
shortRetry=true
writeRetry=false
afterSseRetry=false
atDeadline=TimeoutException

这里用可控逻辑时钟，五百毫秒排队加六秒模型阶段后只剩三千五百毫秒，带一秒退避和三秒尝试的重试被拒绝。shortRetry=true 仅说明更短的教学窗口通过策略计算，不代表已经发出网络请求，更不代表重试会成功。

4. SSE 需要额外约定终止方式

分别约定首个业务事件期限、相邻业务事件的空闲期限和流总时长。心跳可以保持链路活跃，但不应重置“模型一直没产出内容”的计时，更不能延长总截止。代理缓冲与空闲超时需一起检查。

| 期限 | 从何时计时 | 何时重置 | 主要识别的失败 |
|

据此按“业务问题—个人改动—验证结果—适用条件”写两至三条贡献。只有本地实现，就写个人实践；只有阅读理解，就放在学习记录中。

1. 先核对职责

逐项列出自己独立实现、协作参与和仅了解的模块。协作内容说明自己的接口或交付物；公开项目介绍可用来理解场景，不能据此填写任职、上线规模或业务收益。先读站内 没有真实做过怎么描述，再检查主语是否准确。

给准备写进简历的贡献建立如下表格，不必为了填满表格增加组件。

| 准备表达的内容 | 至少准备什么证据 | 没有证据时如何处理 |
|

本文以 Spring AI 2.0.x、PostgreSQL/pgvector 为例；本次 API 核对依据为 Spring AI 2.0.2 官方参考文档，依赖仍应由项目 BOM 锁定，文档版本不代表本地已安装版本。下面的清单和状态机是应用设计建议，验收步骤尚未在你的服务运行。先按 RAG 评估指南 固定题集，再增加变更回放。

1. 为什么重新上传还会搜到旧规则？

原文从“年假五天”改为“年假十天”，重新切分后只剩一个片段。如果每次随机生成片段 ID，新片段入库不会自动带走旧的三个片段；即使复用部分 ID，多余片段仍可能残留。Spring AI ETL 负责读取、转换和写入，业务版本关系需要自己保存。

业务表以租户和文档 ID 为主键，记录当前版本、删除状态、权限版本；另建版本清单，保存内容哈希、切分配置、预期片段数和全部片段 ID。每片元数据带 tenantId/docId/version。片段 ID 按租户、文档、版本、切分配置和序号确定性生成 UUID，重试复用清单，避免重复入库。

2. 更新按什么顺序实现？

1. 保存变更身份。 服务端校验文档归属，保存原文快照和任务代次；同一内容、同一配置的重复事件复用任务。
2. 构建待发布版本。 解析、切分、生成向量并写入，按清单逐 ID 核对数量与内容哈希。部分批次失败保持旧版可读，失败批次可重试。
3. 切换发布。 校验任务仍是最新、文档未删除，以旧版本为条件更新当前版本；条件不符就停止发布并清理孤立片段，避免迟到任务覆盖新版。
4. 收尾对账。 在线检索限定当前版本；旧版片段异步删除，单文档缓存键包含查询、租户、权限范围、权限版本、文档 ID 和文档版本；跨文档答案还需绑定所依赖的文档版本集合，并在命中时复查可见性。定时对比清单与实际记录，补偿清理失败。

读取先查权威状态，再构造版本过滤；送入模型前再核对候选片段是否仍有效。查不到当前版就返回无证据，不回退旧版。公开文档改为 HR 限定时也要遵守这个顺序。过滤条件由服务端构造，PGvector 接入文档 说明了元数据过滤的转换方式。

“当前版本”是每篇文档自己的指针。单文档查询要同时限制 tenantId/docId/version；跨文档查询应在租户和权限范围内，按 (docId = A AND version = A当前版) OR (docId = B AND version = B当前版) 组合，不能用一个 version = v2 代表整个知识库。文档很多时，长过滤表达式会增加维护成本，可改用数据库中与权威状态关联的查询路径；这属于应用设计，不是 Spring AI 自动提供的版本管理。

| 阶段 | 权威指针/状态 | 存储中可能存在 | 读取允许使用 |
|

1. 建立可复查的题集

从 知识库项目架构 的离线入库与在线问答两条链路出发，先用 30—50 题做本地基线；这是练习规模。覆盖单段事实、多段归纳、无答案、过期版本和不同权限。同一问题可以配置不同身份，检查权限变化。

每题记录问题、测试身份、文档版本、参考片段、答案要点和预期行为。参考证据由人核对，不让模型自行生成后直接充当标准答案。将近似问法放在同一组，再按组划分调试集与保留集，减少同题改写泄漏。参考证据同时标注文档版本和原文位置；切分方式变化后，chunk ID 可能变化，应按原文证据映射判定命中，不能直接比较两次运行的 ID。

2. 定义指标和分母

下面是本地项目的建议口径。LangChain 官方教程区分答案正确性、回答相关性、证据支撑和检索相关性，可以据此拆开定位。官方评估教程

| 检查项 | 具体计算或核对方式 | 用途 |
|

适用 Java 21、Spring AI 2.0.x 的知识库服务；2026-11-06 核对的 Spring AI 官方参考 显示版本为 2.0.2，滚动文档后续可能变化，使用时应对照项目实际依赖。下面的排查顺序是应用层建议；文中原有本地验证仅运行固定记录分类器，未连接真实向量库或模型，本次文字修订未重新运行分类器。它处理一条失败请求，与 评估指南 的题集统计不同。

1. 保存一份足够定位的请求快照

接到“制度明明写了，机器人却回答不知道”，先保留请求号、脱敏问题、服务端租户与权限版本、文档版本、切分和嵌入模型标识，以及检索条件、候选片段 ID、最终送模片段 ID、提示词版本和引用。正文只在受控测试环境抽查，普通日志避免保存客户原文和令牌。

先人工确认问题在当前授权文档里有答案，标出参考片段；若事实只在旧版本或未授权文档里，正确行为可能就是拒答。Spring AI 可观测性 提供客户端、模型、嵌入与向量库的观测能力；业务还需关联片段与版本，不能把一条总耗时当作整条证据链。

2. 按第一处失败执行排查树

从上向下检查，命中就停止并补证据；修复后从头回放同一请求：

请求身份与文档授权有效？否 -> DENY：先阻断读取，复查授权和缓存键
  是 -> 参考片段已落库且解析文本完整？否 -> INGEST：查页码、表格、OCR、分块边界
    是 -> 查询/文档编码协议正确，向量空间与索引兼容？否 -> EMBEDDING：修正对应编码，按兼容性决定是否重建索引
      是 -> 参考片段在候选里？否 -> RETRIEVE：查过滤、查询改写、阈值、Top-K、索引
        是 -> 参考片段进入最终上下文？否 -> ASSEMBLY：查重排、去重、token 裁剪
          是 -> 上下文版本仍有效？否 -> VERSION：查版本筛选与缓存
            是 -> 回答事实逐项有本次证据支撑？否 -> GENERATE：查提示词、历史与引用绑定
              是 -> PASS：仅表示本条人工检查通过

查入库时，按参考片段 ID 读取存储正文，对照原始页，不以“上传成功”代替落库核对。查召回时，在隔离环境保持授权条件不变，先固定原始问题，再分别比较改写前后、阈值前后和重排前后的 ID 列表。一次只变一项；不能通过去掉租户过滤换取命中。

同样是“没有答出参考事实”，证据消失的位置决定了该改哪一层。以下对照假定身份、授权、入库与编码检查已通过，属于排查建议，不是新增实测结果：

| 参考片段的位置 | 优先解释 | 调整时的取舍 |
|

Java 语言与运行时

| 技术问题 | 专题文章 | 重点内容 |
|

适用版本与边界

本文依据 Spring Framework 6.2 文档，面向 JDK 17／21、代理模式、PlatformTransactionManager 管理的 JDBC 本地事务。假定业务表与 outbox 使用同一数据源和事务管理器。JTA、多数据源及响应式事务需要另外确认边界；不能把线程绑定事务的推理直接套到 Reactor 上下文。

1. 为什么“SQL 后面发通知”仍然太早？

设订单事务依次执行：更新订单 → 发送“已确认”通知 → 返回方法 → 数据库提交失败。数据库没有保留确认结果，通知却已经发出；普通数据库回滚无法撤回外部消息。

另一种时序是外层 A 调用 REQUIRED 方法 B。B 返回后 A 继续执行并失败回滚，B 的修改也随之撤销，因为它们共享物理事务。根据 Spring 传播机制文档，逻辑方法边界不等于独立物理提交边界。

| 观察位置 | 能确认什么 | 仍不能确认什么 |
|

适用版本与边界

本文按 OpenJDK 21 的 ThreadPoolExecutor 与平台线程说明，使用标准队列和正常创建线程的线程工厂。不直接套用到 ForkJoinPool、定时线程池或虚拟线程执行器；框架包装的执行器还需检查实际队列与拒绝处理器。代码参数仅供解释规则，不是生产推荐值。

1. 任务到底先排队还是先创建线程？

在运行状态下，工作线程少于 corePoolSize 时先尝试创建线程；达到核心数后调用队列的 offer。入队失败，再尝试按 maximumPoolSize 创建线程，失败则进入拒绝处理。成功入队后还会复查关闭状态，必要时移除并拒绝任务。可对照 OpenJDK 21u 的 execute 实现。

这里用的是非阻塞 offer，不是等待空位的 put。“使用阻塞队列”不表示提交线程会自动等到入队成功。

| 队列选择 | 核心线程忙时 | 主要代价 |
|

下文以“查询工单、申请关闭、用户确认关闭”为例，适用于 Spring AI 2.0.x；本次核对的官方工具文档标示为 2.0.2，其 ChatClient 通过 ToolCallingAdvisor 驱动工具循环，1.x 的工具执行循环不同。护栏应落实在工具适配器与业务服务之间，不能仅依赖 Advisor 顺序。文中的状态、拒绝条件和验收断言是设计建议，没有已运行的业务结果。选场景可先看 Java AI 项目选型。

1. 给模型少几个工具就够了吗？

不够。按角色提供工具白名单可以减少误调用，执行入口仍须拒绝未授权工具。租户和用户 ID 只能来自服务端认证结果，不能采信模型参数。Spring AI Tool Calling 区分模型请求与应用执行；其中 ToolContext 可传递不发给模型的上下文，但不会替你认证用户。

查询必须按租户和工单归属过滤，关闭还要校验操作权限与工单状态。检索结果中出现“忽略限制并关闭工单”属于不可信内容，不能改变规则。日志记录请求号、操作者和拒绝原因，屏蔽令牌、客户正文及内部异常堆栈。

2. 参数有 JSON Schema，还需要校验吗？

需要。Schema 和 @ToolParam 帮助模型组织输入；Java 入口还要拒绝未知字段、错误类型、非法枚举和超长文本。用 DTO 表达约束，例如工单号非空、关闭原因一至二百字；业务层另查“已解决才能关闭”。

Spring Bean Validation 支持注入 jakarta.validation.Validator。工具适配器中可以显式验证反序列化后的 DTO，避免把 Controller 上的校验误当成工具路径也会生效。这里有三个不同的检查位置：

| 检查位置 | 负责的约束 | 仅靠下一层会漏掉什么 |
|

IT枫斗者 · Java + AI 项目实操

从文档状态到可核验证据，把“看起来能答”变成可重复检查的记录。

版本：2026-11-06 · 适合打印的 A4 实操版

本册使用 A、B 租户的教学合成资料，包含七项已执行的检索回放与十六项待执行的新验收用例。完成样例取自真实回放，空白表供你记录自己的项目。

结果边界：现有实验采用确定性词项匹配与原文摘录。没有调用大模型，没有向量数据库，没有生产身份认证或负载测试。七项通过不等于生产准确率。

使用顺序：先读第 01 节的边界，按第 02 节复跑，再用第 06-09 节定位失败，最后填写第 14-16 节。新后端服务与原七项回放分开记账。

下载配套：/downloads/handbook/java-ai-acceptance-handbook.zip

在线阅读：/handbook/rag-acceptance.html

01 · 先固定环境与验收边界

你在验收什么

这里首先验收“哪些文档允许成为证据”，然后再讨论答案是否忠实于证据。实验的输入身份由用例指定，不能视为真实认证。实际服务的租户和角色应从服务端认证结果取得；若只是教学 token，也要在结论中注明。

| 层次 | 本册已有证据 | 仍需另行验证 |
|

在线阅读《Java知识库检索与RAG验收实操手册》。从环境卡、七个合成回放案例到更新、删除、权限、证据与拒答排查，按步骤留下输入、上下文和引用证据。

下载 A4 打印版 PDF · 下载配套 ZIP

| 材料 | 用途 |
|

第一次来，从哪里开始？

| 想阅读的内容 | 建议入口 | 内容说明 |
|

这里的对话均为原创教学场景，不对应真实公司面试、作者个人面试经历或录用结果。参考回答用于练习组织语言；涉及版本、代理方式、队列或事务资源时，要主动补充条件，不能把一段话套到所有项目。

两场完整演练，从哪里开始

| 演练 | 第一问 | 追问会走到哪里 | 本次产物 |
|

这是一场教学演练。我们不重新罗列线程池的所有参数，而是围绕同一段程序连续改变条件。先把每轮问题自己答一遍，再对照推理；答案最关键的部分往往是“在哪些条件下成立”。

开场：30秒参考回答

对运行中的标准 ThreadPoolExecutor，工作线程少于核心数时先尝试创建线程，达到核心数后先入队，入队失败才尝试扩到最大数，再无法接纳才走拒绝策略。因此最大数4不代表第3个任务就会新建线程。我还会确认队列容量、拒绝策略和关闭状态；过载时要让业务看到失败，并检查排队时间与下游承载能力。

本篇限定 JDK 21、平台线程、标准队列和正常创建线程的线程工厂；不套用到虚拟线程执行器、ForkJoinPool 或定时任务池。提交路径依据 JDK 21 ThreadPoolExecutor API，关闭与入队复查等细节可对照 OpenJDK 21u 源码的 execute 方法。

第一轮：先锁定题设，再推7次提交

面试官：核心线程数2、最大线程数4、ArrayBlockingQueue容量2，使用 AbortPolicy。一个线程连续 execute 提交7个任务，哪个被拒绝？

先追问题设：池处于运行状态，提交期间不关闭，没有其他提交者；每个任务都等待同一个初始值为1的门闩，全部提交完才放行，因此工作任务不会提前结束。线程能正常创建，配置不会中途变化。这正是本站 已有完整源码 的条件。

在这些条件下逐步推导：

| 提交任务 | 本次走哪条路径 | 提交后的工作线程数 | 队列项数 |
|

本篇是一场围绕“下单、写记录、发通知”的教学演练。每轮先预测数据库里最终留下什么，再解释原因。不能只说“注解失效了”，要指出哪次调用经过代理、哪个异常到达拦截器、谁拥有最终的提交边界。

开场：30秒参考回答

我会先确认调用是否经过事务代理、用哪个事务管理器，以及有没有外层事务。未修改规则时，RuntimeException和Error触发回滚，受检异常默认不触发；内部捕获后正常返回，也不能只凭曾经抛过异常判断回滚。同类自调用不会让内层注解重新生效，但可能仍处于外层事务。方法体返回不等于物理提交，提交成功也不等于消息已经送达。

版本、资源与题设先说清

截至 2026-11-06 联网核对：Spring官方版本政策将 7.0.x列为当前生产线，6.2.x开源支持已于2026年6月结束，商业长期支持另有安排。官方文档当前指向 7.0.10稳定版；预览版与仍能访问的旧版本文档不等于当前开源受支持版本。

为与本站题库和 事务边界指南衔接，以下仍按 Spring Framework 6.2语义、JDK 17／21、默认proxy模式、PlatformTransactionManager管理的JDBC本地事务演练。这是明确教学基线，不要求升级现有框架。假定订单与outbox共用一个数据源及同一事务管理器，不讨论JTA、多数据源或响应式上下文。

回滚题还假定没有定制全局规则、没有数据库或其他参与者提前标记回滚。Spring 6.2允许通过 @EnableTransactionManagement(rollbackOn = ALL_EXCEPTIONS)改变全局默认，因此“受检异常默认提交”必须附上配置条件。见 @Transactional配置说明。

第一轮：public方法上的注解，为什么还不够

面试官：一个Spring Bean的普通入口方法调用 this.save()；save是public且有 @Transactional，写一行订单后抛 IllegalStateException，会回滚吗？

先补条件：入口没有事务，也没有类级事务声明；JDBC连接为普通自动提交模式。

参考追答：这次自调用绕过代理，save上的注解没有建立事务。写入已自动提交，后面的Java异常不能把它撤销。应把事务入口放到另一个Bean，通过注入的代理调用；或者让外部经代理调用本来就应作为事务边界的入口。把方法改成public不会改变 this 的调用路径。Spring AOP官方说明

再追问：如果外层入口本身经代理开启了事务呢？ save仍在外层已有事务中执行，自调用并不会自动“脱离事务”。此时异常继续逃出外层，符合回滚规则，就会使外层回滚。若内层标 REQUIRES_NEW，自调用也不会凭这个注解另开事务。要在图里写清“外部 → 入口代理 → 目标入口 → this.save”，不能笼统回答“同类调用一定没事务”。

第二轮：只改变异常和捕获位置，结局如何变化

面试官：改为从外部经代理调用save，写入成功后抛异常。你能给出判断表吗？

以下每行都是独立场景，使用默认回滚规则；异常是手工抛出的Java异常，数据库执行本身没有失败：

| 变化 | 拦截器观察到什么 | 正常情况下最终状态 |
|

阅读提示

先掌握“概念定义 + 对比区别 + 常见坑”三种回答模板。
如果时间紧，优先看：面向对象、== 与 equals、String、接口 vs 抽象类。

Java基础

回答提示：是一种比较通俗的解释，比较好理解，如果‘参考答案’不太好记住，可以直接复习回答提示也可以。

1、面向对象和面向过程的区别是什么？

回答提示：

• 面向过程就像是做菜时按步骤来，先洗菜、切菜、炒菜，一步步完成。它关注解决问题的步骤和流程，直接用函数实现每个步骤，然后依次调用。
• 而面向对象则更像是把做菜看成一个整体，关注构成这个问题的各个“对象”，比如“锅”、“铲子”、“食材”等。每个对象有自己的属性和行为（方法），如“锅”有“加热”的方法。面向对象通过创建对象并调用它们的方法来解决问题，更强调事物的属性和行为，以及它们之间的关系。
• 总结来说，面向过程更直接，关注怎么做；面向对象更抽象，关注做什么和由谁来做。面向对象具有更高的复用性、扩展性和维护性，但可能性能稍低；面向过程则性能较高，但复用和维护可能较复杂。

参考回答：

• 面向过程和面向对象是两种不同的处理问题的角度。
• 面向过程更注重事情的每一个步骤及顺序。主要是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用
• 面向对象更注重事情有哪些参与者（对象）、及各自需要做什么。主要是把事物对象化，包括其属性和行为。通过调用不同对象之间的方法，以组合的方式解决问题。

2、面向对象的三大基本特征

回答提示：

• 封装：就是把数据和操作数据的方法“打包”在一起，形成一个独立的单元（类）。外界不需要知道内部的具体实现细节，只需要通过接口（类提供的方法）与之交互。这就像是一个黑盒子，我们只知道它的输入和输出，但不知道里面是怎么工作的。
• 继承:子类可以继承父类的属性和方法，这样就可以在不需要重新编写原有代码的基础上，扩展新的功能。比如，我们可以定义一个“动物”类，然后让“猫”和“狗”类继承它，从而复用“动物”类中的属性和方法。
• 多态:是同一个接口（方法）在不同的子类中有不同的实现。这样，我们就可以用同一个父类类型的引用来调用不同子类的方法，实现不同的功能。这增加了程序的灵活性和可扩展性。

继承，方法重写，父类引用指向子类对象

父类类型 变量名 = new 子类对象 ;

变量名.方法名();

参考回答：

• 三大基本特征：封装、继承、多态。
• 封装
• 封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项，提供对应的函数给外部进行调用，内部实现对外部调用不可见，外部调用无需修改或关心内部实现。
• 继承
• 继承基类的方法，并做出自己的改变和/或扩展，子类共性的方法或者属性直接使用父类的，而不需要自己再定义，只需扩展自己个性化的。
• 多态
• 基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同，父类中定义的属性和方法被子类继承后或者接口定义的方法被子类实现，通过重写使得父类和子类具有不同的实现，从而同一个属性或方法在父类及其各个子类中具有不同的含义。无法调用子类特有的功能。

3、方法重载和重写有什么区别？

参考回答（适用于 JDK 21）：

• 重载（overload）：方法名相同、参数列表不同；仅返回类型不同不构成重载。编译器根据参数表达式的编译期类型等规则选择签名。
• 重写（override）：子类为继承的实例方法提供符合规则的实现；调用已选定签名的实例方法时，再根据对象的运行时类型选择实现。静态方法是隐藏，不是重写；字段也不参与这种动态分派。

依据：JLS 21 §8.4.8、§8.4.9。

4、==和equals区别(了解)

回答提示：

• ==操作符：它主要用于比较基本数据类型的值是否相等，比如两个整数是否相等。对于引用数据类型，==比较的是两个对象的内存地址是否相同，即它们是否是同一个对象的引用。简单来说，==看的是“是不是同一个东西”。
• equals方法：它是Object类的一个方法，用于比较两个对象的内容是否相等。默认情况下，equals方法的行为和==对于引用类型是一样的，即比较内存地址。但是，很多类（如String、Integer等）都重写了equals方法，使其能够比较对象的内容是否相等，而不是内存地址。简单来说，equals看的是“内容是否一样”。

参考回答：

• ==：对于基本数据类型，直接比较值；对于引用数据类型，比较引用（内存地址）。
• equals()：首先检查两个对象是否为同一个对象的引用（这通常是通过==运算符完成的，但具体实现可能有所不同），如果不是，则根据类的具体实现来比较对象的内容。许多类（如String、Integer等）都重写了equals()方法以提供更有意义的比较逻辑。

5、equals() 既然已经能实现对比的功能了，为什么还要 hashCode() 呢？（了解）

回答提示：

• 想象一下你有一堆对象，你想要快速地找出里面是否有某个特定的对象。如果只用equals()方法逐个比较，效率会很低，因为equals()可能会比较对象的很多内部细节。
• 而hashCode()方法则是用来快速判断两个对象在逻辑上是否可能相等的一个“捷径”。如果两个对象的hashCode()值不同，那么根据hashCode()的设计原则，这两个对象在逻辑上一定不相等，我们甚至不需要调用equals()方法就可以知道结果。这样，我们可以先将对象存储或查找在基于哈希值的集合中（如HashSet、HashMap），大大减少了不必要的equals()调用，提高了效率。
• **hashCode()**方法通过提供一个快速的初步判断，帮助我们缩小了可能相等的对象的范围，与**equals()**方法一起工作，实现了高效的对象比较和查找。

参考回答：

• 因为重写的 equals() 里一般比较的比较全面比较复杂，这样效率就比较低，而利用 hashCode() 进行对比，则只要生成一个 hash 值进行比较就可以了，效率很高，那么 hashCode() 既然效率这么高为什么还要 equal() 呢？
• 因为 hashCode() 并不是完全可靠，有时候不同的对象他们生成的 hashcode 也会一样（生成 hash 值得公式可能存在的问题），所以 hashCode() 只能说是大部分时候可靠，并不是绝对可靠，所以我们可以得出结论：
• equals() 相等的两个对象他们的 hashCode() 肯定相等，也就是用 equals() 对比是绝对可靠的。
• hashCode() 相等的两个对象他们的 equals() 不一定相等，也就是 hashCode() 不是绝对可靠的。

6、String、StringBuilder和StringBuffer的区别？

回答提示：

• String是final修饰的，不可变，每次操作都会产生新的String对象.
• StringBuffer是在原对象上操作，是线程安全的，是synchronized修饰的。
• StringBuilder是在原对象上操作，是线程不安全的。
• 性能：StringBuilder > StringBuffer > String

参考回答：

• 字符串类型String是不可变的，即一旦创建后，其值不可被修改。相比之下，StringBuilder和StringBuffer是可变的，允许对其内容进行修改。其中，StringBuffer是线程安全的，而StringBuilder是非线程安全的。

7、String str=new String("IT枫斗者")创建了几个对象？

参考回答：

• 1个或者2个

new String("IT枫斗者");

• 相信很多小伙伴们听到的答案很多，有说创建了1个对象，也有说创建了2个对象。答案对，也不对，关键是要知道问题底层的原理。

String str1 = "IT枫斗者";  // 在常量池中

String str2 = new String("IT枫斗者"); // 在堆上

• 当直接赋值时，字符串“IT枫斗者”会被存储在常量池中，只有1份，此时的赋值操作等于是创建0个或1个对象。如果常量池中已经存在了“IT枫斗者”，那么不会再创建对象，直接将引用赋值给str1；如果常量池中没有“IT枫斗者”，那么创建一个对象，并将引用赋值给str1。
• 那么，通过new String(“IT枫斗者”);的形式又是如何呢？答案是1个或2个。
• 当JVM遇到上述代码时，会先检索常量池中是否存在“IT枫斗者"，IT枫斗者"这个字符串，则会先在常量池中创建这个一个字符串。然后再执行new操作，会在堆内存中创建一个存储“IT枫斗者”的String对象，对象的引用赋值给str2。此过程创建了2个对象。
• 当然，如果检索常量池时发现已经存在了对应的字符串，那么只会在堆内创建一个新的String对象，此过程只创建了1个对象。

8、接口和抽象类的区别？（最少要回答出1,2,3,5,7）

参考回答：

1. 定义与目的

• 接口：是一种行为规范或约定，它定义了对象应该做什么，而不关心对象具体如何做。接口没有实例字段和构造器；方法能否包含实现取决于版本和修饰符：Java 8 起支持 default、static 方法，Java 9 起还支持 private 方法。
• 抽象类：是一种不能被实例化的类，它提供了一种模板，用于被其他类继承并实现其中的抽象方法。抽象类可以包含方法的实现，也可以不包含（即抽象方法）。

2. 成员变量

• 接口：字段隐含为 public static final，必须初始化；引用不能重新赋值，但被引用的可变对象仍可能改变。
• 抽象类：可以包含字段、属性、方法（包括抽象方法和非抽象方法）、构造器等。

3. 方法

• 接口：未写 private、default、static 的接口方法隐含为 public abstract，不能有方法体；Java 8 起 default 实例方法和 static 方法有实现，Java 9 起 private 实例方法和 private static 方法也可以有实现。静态方法通过声明接口调用，私有方法不被实现类继承。
• 抽象类：方法可以是抽象的，也可以是非抽象的。抽象方法没有具体实现，需要在子类中重写；非抽象方法可以有具体实现。抽象类中的方法可以有不同的访问级别。

4. 实例化

• 接口：不能被实例化，它只能被类实现。
• 抽象类：不能被直接实例化，但可以通过其子类（如果子类不是抽象的）来实例化。

5. 继承与实现

• 接口：一个类可以实现多个接口，从而获取多个接口中的方法。这是接口实现多态性的一个重要方式。
• 抽象类：一个类只能继承一个抽象类（在大多数面向对象的编程语言中，如Java）。这种单继承的特性限制了抽象类的使用范围。

6. 扩展性

• 接口：新增抽象方法通常要求具体实现类补齐实现，不能笼统说“添加方法无需修改实现类”；新增 default 方法可以提供缺省行为，但仍要检查同签名默认方法冲突和既有业务语义。
• 抽象类：扩展性相对较差，如果添加新的抽象方法，所有子类都需要实现这个方法，这可能会影响到现有的代码。

7. 设计层面

• 抽象类：是对类的抽象，是一种模板式设计。它对整个类进行抽象，包括属性和行为，子类必定是抽象类的一种类型，继承是“是不是”的关系。
• 接口：是对行为的抽象，是一种辐射式设计。它是对类局部（行为）的抽象，接口实现是“有没有”的关系，比如一个类是否能实现某个接口，取决于它是否具备该接口所定义的行为

9、浅拷贝和深拷贝？

回答提示：

• 浅拷贝仍然指向原始对象的内存地址。这意味着，如果原始对象中的子对象发生了变化，浅拷贝得到的对象也会受到影响。浅拷贝适用于对象结构较简单，不包含复杂数据结构或不需要独立修改子对象的情况。
• 深拷贝递归地复制了对象内部的所有子对象或属性，创建全新的内存空间来存储这些对象。因此，深拷贝得到的对象与原始对象是完全独立的，对其中一个对象的修改不会影响到另一个对象。深拷贝适用于需要保持数据独立性和完整性的场景，如数据备份、多线程编程等。

参考答案：

1. 定义与本质

• 浅拷贝（Shallow Copy）：
• 创建一个新对象，然后将当前对象的非静态字段复制到该新对象，如果字段是值类型的，那么对该字段执行逐位复制；如果字段是引用类型的话，则复制引用但不复制引用的对象。
• 因此，原始对象及其副本引用同一个对象。

BeanUtils.copyProperties方法用于将一个bean的属性值复制到另一个bean中，前提是这两个bean之间有相同的属性名和兼容的属性类型。这种方法在处理JavaBean之间的数据转换时非常有用，尤其是在不同层（如数据访问层和服务层）之间传递数据时。

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

1、JAVA 四种引用类型(了解)

1. 强引用：

2. 描述：强引用是我们最常见的引用类型，只要一个对象具有强引用，它就不会被垃圾回收器回收。

3. 例子：

Object obj = new Object();

1. 在这个例子中，obj是一个强引用，指向Object的一个实例。只要obj还在使用，这个Object实例就不会被回收。

2. 软引用：

3. 描述：软引用是一种内存敏感的引用，如果一个对象只具有软引用，那么在内存空间不足时，垃圾回收器会考虑回收它。

4. 例子：

SoftReference<Object> softRef = new SoftReference<>(new Object());

1. 在这个例子中，softRef是一个软引用，指向一个Object实例。如果内存不足，这个实例可能会被回收。

2. 弱引用：

3. 描述：弱引用比软引用更加弱，它不足以阻止对象的垃圾回收。无论当前内存空间足够与否，只要垃圾回收器发现了只具有弱引用的对象，就会回收它。

4. 例子：

WeakReference<Object> weakRef = new WeakReference<>(new Object());

1. 在这个例子中，weakRef是一个弱引用，指向一个Object实例。无论内存空间如何，这个实例都可能被回收。

2. 虚引用：

3. 描述：虚引用是所有引用类型中最弱的一个。它无法阻止垃圾回收器的回收过程，也无法通过虚引用来获取对象的实例。它的主要作用是跟踪对象被垃圾回收的状态。

4. 例子：

PhantomReference<Object> phantomRef = new PhantomReference<>(new Object(), new ReferenceQueue<>());

1. 在这个例子中，phantomRef是一个虚引用，指向一个Object实例，并且关联了一个引用队列。这个实例随时可能被回收，而且回收时，phantomRef会被加入到关联的引用队列中。

2、类加载过程（按图顺序向面试官介绍，细节了解）

• 加载：加载是类加载过程中的一个阶段，这个阶段会在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的入口。注意这里不一定非得要从一个 Class 文件获取，这里既可以从 ZIP 包中读取（比如从 jar 包和 war 包中读取），也可以在运行时计算生成（动态代理），也可以由其它文件生成（比如将 JSP 文件转换成对应的 Class 类）。
• 验证 :这一阶段的主要目的是为了确保 Class 文件的字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
• 准备：创建类或接口的静态字段（包括 static final），并赋予类型默认值，如 int 为 0、引用为 null；不执行 Java 初始化表达式。这里描述的是 JVMS 的逻辑阶段，不承诺字段的物理位置。

class InitDemo {
    static int age = 26;
    static final int LIMIT = 6 * 7;
    static final String NAME = "IT枫斗者";
    static final Integer BOXED = 42;
    static final int RUNTIME = Integer.parseInt("42");
}

final 只限制再次赋值。按 JLS，只有以常量表达式初始化的基本类型或 String 类型的 final 变量才是常量变量；上例的 LIMIT、NAME 是，BOXED、RUNTIME 不是。Java 编译器通常为前两者生成 ConstantValue 属性，而后两者的赋值要执行 <clinit> 字节码。编译期记录常量值不等于运行时字段已在编译期分配和赋值。

规范顺序可简记为：准备：静态字段默认值 → 初始化过程：ConstantValue 赋值 → 执行 <clinit> 中的赋值与 static 块。JVMS 8 和 21 都将 ConstantValue 的赋值规定为初始化的一部分，且早于调用 <clinit>；不要把“所有 final 都在准备阶段赋最终值”当作规范。HotSpot 可在创建类镜像等较早的内部步骤提前设置常量字段，这是实现细节，不能据此改变规范的阶段定义（可对照 OpenJDK 21 javaClasses.cpp 的 initialize_static_field）。直接读取 InitDemo.LIMIT 通常使用编译进调用方的常量值，不触发 InitDemo 初始化；读取 BOXED 则会触发。

依据：JVMS 8 §5.4.2 / §5.5、JVMS 21 §4.7.2 ConstantValue、JLS 21 §4.12.4。

• 解析：JVM会在此阶段把类的二进制数据中的符号引用替换为直接引用。

• 符号引用：符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。

• 直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有 了直接引用，那引用的目标必定已经在内存中存在。

• 初始化 ：按初始化协议处理常量字段后，执行编译器汇集静态字段初始化表达式和静态块生成的 <clinit>()（若存在），例如将 age 从 0 赋为 26。它不是实例构造器 <init>；没有相应初始化代码的类可以没有 <clinit>。解析也可以按需延迟，不必全部完成后才初始化。

• 使用：对象都出来了，业务系统直接调用阶段。

• 卸载 ：类的生命周期不等于单个对象的生命周期；只有定义它的类加载器可被回收时，该类才可能卸载，并非业务用完就立即卸载。

3、类加载器种类以及加载范围

参考回答：

上图按 JDK 8 常见实现理解；JDK 9 模块化以后，应区分以下版本边界，不能直接套用扩展目录和 rt.jar。

| 类型 | JDK 8（Oracle/OpenJDK 常见实现） | JDK 9+，包括 JDK 21 |
|

阅读 Java 进阶之路 · 技术专题 · 项目源码 · 免费资源

公众号：IT枫斗者

在微信搜索 IT枫斗者，关注后继续阅读 Java 原理、源码解析、AI 应用工程和排障文章。点击下方关注按钮可以展开本站公众号二维码。

微信交流：itfdz666

微信：itfdz666。添加时备注“Java进阶”“AI项目”或“项目简历”，便于说明交流方向。

可以直接说正在看的文章、遇到的问题，或当前的基础和目标。比如：“我会写 Spring Boot 接口，想理解知识库里的权限过滤，应该先看哪个模块？”

如果需要定位一个具体问题，再按情况补充版本、错误信息或复现步骤：

| 问题类型 | 有助于沟通的信息 |
|

下载 Java 源码与回放结果

在自己电脑上运行

解压后，在文件所在目录执行：

java --version
java --source 21 RagEvidenceLab.java results.json

需要 JDK 21 或更新版本，不需要 Maven、第三方 Java 包和模型账号。results.json 是你这次运行的实际输出；下面的结果来自本站构建时执行的同一份源码。

看清对照实现漏了什么

语料包含 A、B 两个租户的年假规则、HR 限定文档、一份带删除标记的 VPN 文档和普通工单说明，全部是教学合成数据。

对照实现直接在全部文档和版本中按词项查找，遇到相同分数取前一条。它可能返回 A 的旧年假规则，也可能把 HR 文档放入普通员工的上下文。

修正实现分成三个独立步骤：

测试身份的租户
  → 按文档ID选择最新版本（保留删除状态）
  → 排除已删除、无权访问的文档
  → 词项匹配与原文摘录
  → 保存答案、引用来源和上下文文档ID

顺序很重要：如果先排除已删除的记录，再找最新版本，就可能重新选中已经被删除的旧版；如果先排除当前角色不可见的版本，也可能回退到旧的公开版本。

这次实际运行的结果

本次 Java 运行：21.0.12；合成场景 7 项。缺少过滤的对照实现通过 3 项，修正实现通过 7 项。

这些是下面七个固定场景的回放结果，用于检查代码行为，不表示真实 RAG 的准确率。

查看原始 JSON · 下载填写完成的 CSV

JSON 中保留运行时间、Java 版本、源码 SHA-256，以及每题的查询、身份、期望引用、对照结果和修正结果。可以用源码包复跑，对照自己的结果。

选一个失败场景追到代码

C03 使用普通员工身份查询“薪酬”。对照实现能找到 A/salary/v1，说明仅在回答之后隐藏文本已经太晚：敏感片段先进入了上下文。

修正实现的 currentVisibleDocs 在检索之前排除无权限文档，C03 得到 NONE 和“没有可用证据”。程序不仅比对最终答案，也逐一检查进入上下文的文档是否属于当前可见集合。

接下来怎样扩展

• 新增一个“公开文档改为 HR 限定”的版本，验证不会回退到旧公开版。
• 把演示身份改为服务端认证后的身份，阻止客户端自行选择角色和租户。
• 接入向量库时核对过滤是否真的生效，再加入无答案、错引用、模型超时与提示注入用例。

当前匹配器采用确定性词项匹配，答案是原文摘录；它没有向量检索、模型生成、真正的身份认证和线上负载。实验用于检查检索边界，不能代表完整 RAG 的质量。

需要按同样口径记录自己的项目，可以使用验收表填写样例和空白资料。

继续阅读与资料

继续阅读：文档更新与删除、工具调用权限与幂等。

Java 知识库检索验收

知识库能返回一段文字，仍可能返回了别的租户、旧版本或没有权限的内容。这个实验使用 Java 21 标准库，把问题缩小到检索阶段，比较缺少过滤和补齐过滤后的行为。

看源码思路与完整回放 · 下载可运行源码包

只需 JDK 21，无外部依赖、模型账号或 API Key。数据为合成规则，结果来自本地 Java 回放；实验没有接入模型生成或向量检索。

从实验走到项目

用 RAG 验收表填写样例记录一次回放，再根据知识库项目架构理解真实服务还需要哪些环节。云呼智服工单场景用于理解它可以嵌入的业务流程。

完整业务系统的实现范围、部署与生产验证应单独说明，不从这个小实验推导出生产能力。

这里完整列出 24 道原创单选题与解析。正文在构建时生成，关闭 JavaScript 也能阅读。先写下自己的选择，再对照答案，最后完成每题的下一步任务。

进入交互式学习工作台 · 题库版本：2026-11-06。每组 6 题。

题设中的代码、数量和故障时序用于学习判断，不代表本站或使用者的实际运行结果。固定题的作答不能预测就业或面试通过。实践任务需要你亲自执行，并保留真实记录。

题目目录

• Java 基础：把语言规则写成可运行的小例子，保留实际输出。
• 并发与事务：画出执行时序，再用受控的并发或回滚验证边界。
• AI 检索：固定文档与题集，逐题检查证据、版本和权限。
• 项目表达：整理个人职责、实现和可复查材料，明确尚未验证的部分。

Java 基础

把语言规则写成可运行的小例子，保留实际输出。

1. 字符串内容与引用

题目： 下面的两个判断分别输出什么？

String a = new String("java");
String b = new String("java");
System.out.println(a == b);
System.out.println(a.equals(b));

• A. true、true
• B. false、true
• C. true、false
• D. false、false

正确答案：B. false、true

解释： new String 创建新的 String 对象。两个引用的 == 判断对象身份，equals 判断字符串内容，所以依次为 false、true；不要把字符串常量池的示例直接套到显式 new 上。

适用版本与边界： Java SE 8—21；按 Java SE 21 语言规范核对。

进一步阅读：

• Java 基础：== 与 equals

可执行的下一步： 在本机创建 StringCheck.java，分别运行 new String 与字符串字面量两组比较，保存代码、JDK 版本和真实输出。

2. 相等对象的哈希约束

题目： 自定义 Key 覆写 equals，使业务编号相同的实例相等，却沿用 Object.hashCode。要使它可靠地用作 HashMap 的键，应做什么？

• A. 只把 HashMap 换成容量更大的
• B. 删除 equals，保留业务相等语义
• C. 按相同业务编号实现 hashCode，并保持键参与相等判断的字段稳定
• D. 在 get 前手动触发 GC

正确答案：C. 按相同业务编号实现 hashCode，并保持键参与相等判断的字段稳定

解释： equals 相等的对象必须有相同的 hashCode。哈希表先依据哈希定位，再比较键；还要避免入表后修改参与 equals/hashCode 的字段。扩容不能修复契约错误。

适用版本与边界： Java SE 8—21，Object/HashMap 契约；本题假设业务编号定义相等性。

进一步阅读：

• Java 集合
• HashMap 底层原理

可执行的下一步： 用两个编号相同的 Key 执行 put/get，补齐 equals/hashCode 后再次运行，并增加一次入表后改编号的反例。

3. 参数传递

题目： 执行下面的代码，调用方 xs 的内容是什么？

static void change(List<String> p) {
  p.add("B");
  p = new ArrayList<>(Arrays.asList("C"));
}
List<String> xs = new ArrayList<>(Arrays.asList("A"));
change(xs);
System.out.println(xs);

• A. [A]
• B. [A, B]
• C. [C]
• D. 编译失败

正确答案：B. [A, B]

解释： Java 按值传递；此处传入的是引用值的副本。p.add 改变同一个列表对象；给局部变量 p 重新赋值不改变调用方 xs 的指向，结果为 [A, B]。

适用版本与边界： Java SE 8—21；java.util.ArrayList/Arrays。

进一步阅读：

• Java 基础：参数传递

可执行的下一步： 将代码补进 main，打印调用前后列表；再写一个返回新列表的方法，由调用方显式接收返回值。

4. finally 改写返回值

题目： 下面的方法返回什么？

static int value() {
  try { return 1; }
  finally { return 2; }
}

• A. 1
• B. 2
• C. 先返回 1，再返回 2
• D. 必然抛出异常

正确答案：B. 2

解释： try 的 return 先产生待返回值，但 finally 仍会执行。finally 的 return 使原来的返回过程被替代，结果为 2；这种写法也可能掩盖异常，应避免。

适用版本与边界： Java SE 8—21，JLS 14.20.2 的 try-finally 完成规则。

进一步阅读：

• Java 基础：异常处理
• 异常问答

可执行的下一步： 运行原例，再删除 finally 中的 return 对比结果；把 try 改为抛出异常，观察 finally 返回如何掩盖它。

5. 固定长度列表

题目： Arrays.asList("A", "B") 返回的列表，哪项操作在本题条件下可以正常执行？

• A. add("C")
• B. remove(0)
• C. clear()
• D. set(0, "C")

正确答案：D. set(0, "C")

解释： Arrays.asList 返回由数组支持的固定长度列表，允许 set 替换元素，不支持改变长度的 add/remove/clear。本题列表非空；需要增删时用 new ArrayList<>(原列表)。

适用版本与边界： Java SE 8—21，Arrays.asList；不等同于 Java 9+ 的 List.of。

进一步阅读：

• Java 集合：List

可执行的下一步： 分别运行 set 和 add 并记录异常类型；再复制成 ArrayList 验证可增删，避免仅凭类名猜测能力。

6. GC 请求不是完成证明

题目： 执行 System.gc() 后，只根据下一行日志，能确定什么？

• A. 所有不可达对象均已回收
• B. 发生过一次完整的 Full GC
• C. 发出了尽力执行垃圾回收的请求，不能据此确认具体对象已回收
• D. 所有软引用均已清空

正确答案：C. 发出了尽力执行垃圾回收的请求，不能据此确认具体对象已回收

解释： System.gc() 是请求，API 不保证回收某个对象、回收数量或完成时间；JVM 也可能配置为忽略显式请求。判断回收行为应结合实际 JVM 配置、GC 日志和可观测数据。

适用版本与边界： Java SE 8—21；具体收集器行为和参数依 JVM 实现。

进一步阅读：

• JVM：引用与垃圾回收

可执行的下一步： 在 JDK 21 用 -Xlog:gc 运行最小分配示例，记录 JVM 参数和实际 GC 日志；把请求时刻与日志事件分开描述。

并发与事务

画出执行时序，再用受控的并发或回滚验证边界。

7. volatile 与复合操作

题目： 两个线程同时对 volatile int n 执行 n++，各执行 1000 次并 join。哪项判断成立？

• A. 最终一定是 2000
• B. volatile 保证可见性，但不使 n++ 整体原子化
• C. join 会补回丢失的递增
• D. 把 n 改为 long 就能保证原子递增

正确答案：B. volatile 保证可见性，但不使 n++ 整体原子化

解释： n++ 包含读、加、写，线程可能读取相同旧值而覆盖更新；volatile 不把整段操作变为原子操作。join 保证等待线程结束，不修复丢失更新。可使用 AtomicInteger.incrementAndGet 或共同锁保护。

适用版本与边界： Java SE 8—21，Java 内存模型；无其他同步保护的 n++。

进一步阅读：

• 并发与多线程

可执行的下一步： 用 CountDownLatch 同时启动两个递增线程并多次运行，再替换为 AtomicInteger；某次恰好得到 2000 也不能证明原代码正确。

8. 线程池先排队还是扩容

题目： 运行中的 ThreadPoolExecutor：core=2、max=4、有界队列容量=2。两个工作线程均被门闩阻塞，队列为空；此时再提交一个任务，且没有关闭和其他并发提交。会怎样？

• A. 先创建第 3 个工作线程
• B. 立即拒绝
• C. 先进入队列
• D. 由提交线程立即执行

正确答案：C. 先进入队列

解释： 工作线程达到 core 后优先尝试入队，入队失败才尝试扩容到 max。本题队列有空位，因此第三个任务先排队；max=4 不代表每次都立即扩容到 4。

适用版本与边界： JDK 21 ThreadPoolExecutor.execute；题设排除关闭和提交竞态。

进一步阅读：

• 线程池过载处理
• JavaGuide 线程池选读

可执行的下一步： 用门闩阻塞两个核心线程，逐个提交任务，记录 poolSize、queue.size 与拒绝时刻；结束时释放门闩并关闭线程池。

9. CallerRunsPolicy 的执行位置

题目： 线程池已饱和但未关闭，使用 CallerRunsPolicy。HTTP 请求线程调用 execute 提交任务，且没有自定义策略。任务由谁执行？

• A. HTTP 提交线程
• B. 一个必定新建的线程
• C. JVM 的 GC 线程
• D. 任务必定被丢弃

正确答案：A. HTTP 提交线程

解释： CallerRunsPolicy 在池未关闭时让调用 execute 的线程运行任务。这能减慢提交速度，也会占用 HTTP 请求线程，不能视为无成本的过载保护。池已关闭时该策略不运行任务。

适用版本与边界： JDK 21 ThreadPoolExecutor.CallerRunsPolicy；线程池饱和且未关闭。

进一步阅读：

• 线程池过载：拒绝策略

可执行的下一步： 在任务和请求入口打印线程名，复现饱和路径；再单独测试 shutdown 后提交，记录两条路径的差异。

10. Spring 同类调用边界

题目： Spring 默认代理模式，无既有事务。普通方法通过 this.save() 调用同一个 Bean 上标有 @Transactional 的 save。只靠这个注解，事务会新生效吗？

• A. 一定会
• B. 只要 save 是 public 就一定会
• C. 换成 RuntimeException 才会
• D. 不会，调用未经过事务代理

正确答案：D. 不会，调用未经过事务代理

解释： 默认代理模式只拦截经过代理的外部方法调用；this.save() 的自调用绕过代理，注解不能新建事务。若已有事务则是另一种题设；AspectJ 模式也需单独讨论。

适用版本与边界： Spring Framework 6.2、默认 proxy 模式、无外层事务；不讨论 AspectJ。

进一步阅读：

• Spring 事务边界
• Spring 问答

可执行的下一步： 把事务入口移到另一个 Bean 并经注入代理调用；写集成测试在写入后抛异常，用独立查询核对是否回滚。

11. 提交后事件的崩溃窗口

题目： 订单已提交，进程在 AFTER_COMMIT 监听器发送消息前崩溃。要使重启后仍能恢复投递，哪项方案针对这个窗口有效？

• A. 只把监听器改名
• B. 订单与 outbox 待办同库同事务保存，提交后由扫描器重试，接收方幂等
• C. 把内存队列容量翻倍
• D. 仅在日志中输出发送成功

正确答案：B. 订单与 outbox 待办同库同事务保存，提交后由扫描器重试，接收方幂等

解释： 内存中的提交后事件不能跨进程崩溃恢复。同库同事务的 outbox 将业务变更和投递意图一起提交，后台可重新扫描。发送成功但确认前崩溃仍可能重发，因此接收方需要幂等。

适用版本与边界： Spring Framework 6.2、JDBC 本地事务；订单与 outbox 使用同库及同一事务管理器。

进一步阅读：

• Spring 事务：提交后事件与 outbox

可执行的下一步： 设计两次故障注入：提交后未发送、发送后未确认。重启扫描器，检查最终投递及重复消息处理记录。

12. 写后删除仍有竞态

题目： 读请求 R 已从数据库取到旧值，暂停在回填前；写请求 W 提交新值并删除缓存；R 再回填旧值。哪项判断正确？

• A. 成功删除一次就消除了全部竞态
• B. Redis 单线程可阻止这个跨数据库时序
• C. 缓存可能重新出现旧值，需要按业务设计 TTL、版本校验或补偿
• D. 把删除放到数据库提交前就总能解决

正确答案：C. 缓存可能重新出现旧值，需要按业务设计 TTL、版本校验或补偿

解释： 缓存命令串行执行不能让数据库读取、提交与回填成为一个原子操作。本题时序能在删除成功后重新写入旧值。TTL 限制陈旧时长，版本检查和补偿需有明确实现与验证，不能宣称天然强一致。

适用版本与边界： Cache-Aside，Redis 6/7 与独立关系型数据库；未使用跨资源原子协议。

进一步阅读：

• 缓存失效与补偿
• Redis：缓存一致性

可执行的下一步： 用两个门闩复现 R 读旧值、W 提交删除、R 回填的顺序，记录观察窗口，再验证你选择的修复方案。

AI 检索

固定文档与题集，逐题检查证据、版本和权限。

13. 检索命中率的分母

题目： 10 个有答案且有权限的问题中，8 个的前 5 个片段命中至少一个参考片段；另有 2 个无答案题。本题定义的 Hit@5 是多少？

• A. 8/12
• B. 10/12
• C. 8/10
• D. 只看生成答案，无法计算

正确答案：C. 8/10

解释： 按题设，Hit@5 的分母是有答案且有权限的 10 题，分子是命中的 8 题，结果为 80%。无答案题应单独评价拒答；命中一个片段也不代表多段证据充分或答案必然正确。

适用版本与边界： 与框架无关的离线 RAG 评估；口径采用本站 RAG 评估指南，题设数字仅为计算示例。

进一步阅读：

• RAG 评估：指标与分母

可执行的下一步： 为自己的题集增加 hasAnswer、authorized 和 referenceChunkIds，分别列出检索命中与拒答结果，保留每题分母归属。

14. 权限过滤的位置

题目： 员工只能读部门 A 文档。检索服务把部门 B 的片段发送给模型后，才在浏览器隐藏引用。权限控制完成了吗？

• A. 完成，用户看不到引用即可
• B. 没有，服务端应让未授权内容不进入检索结果和模型上下文，并检查响应与日志
• C. 完成，只要在提示词写保密
• D. 只需降低 temperature

正确答案：B. 没有，服务端应让未授权内容不进入检索结果和模型上下文，并检查响应与日志

解释： 隐藏界面不能撤回已经发送给模型的数据。权限身份应来自可信服务端上下文，并约束检索、上下文、缓存和输出。提示词不能替代业务授权；验收还要检查日志及缓存键是否混用身份。

适用版本与边界： RAG 通用权限边界；Spring AI 1.x 接入时须核对实际版本的过滤接口。

进一步阅读：

• RAG 评估：权限
• 工具调用防护

可执行的下一步： 为同一问题配置 A/B 两种测试身份，保存召回片段 ID 与模型上下文，验证越权片段没有进入对应链路。

15. 删除文档后的验收

题目： 知识库删除接口返回成功，但旧分块、回答缓存和历史引用都未检查。能据此认定在线问答不再暴露该文档吗？

• A. 能，HTTP 200 证明所有链路已清理
• B. 能，只要删除文件名
• C. 能，等模型自行遗忘即可
• D. 不能，需要检查旧分块、缓存和引用的实际可达性与删除传播

正确答案：D. 不能，需要检查旧分块、缓存和引用的实际可达性与删除传播

解释： 文件删除成功只说明某个步骤完成。旧版本分块可能仍在索引中，缓存也可能继续返回旧答案；应按文档 ID、版本和权限检查检索、上下文及引用，并定义传播窗口。

适用版本与边界： 带向量索引和回答缓存的 RAG；删除 API 的语义按实际实现核对。

进一步阅读：

• RAG 文档更新与删除

可执行的下一步： 先准备能命中旧文档的问题，记录分块 ID；执行删除后重复检索、缓存命中与引用访问，记录残留及清理时间。

16. 评估集的近似问法泄漏

题目： 同一问题的五个近似改写被随机拆到调试集与保留集，然后反复根据保留集结果改提示词。更合理的处理是什么？

• A. 把近似问题按组划分，停止用保留集调参；被用来调参的保留题不能继续当独立验证
• B. 只改文件名，保留同样拆分
• C. 删除所有失败题
• D. 把调试集和保留集的结果直接相加

正确答案：A. 把近似问题按组划分，停止用保留集调参；被用来调参的保留题不能继续当独立验证

解释： 近似改写共享语义，分散到两组容易泄漏。按问题族分组可减少重叠；保留集一旦参与调参，就失去独立性，应补充新的独立样本并标注数据与配置版本。

适用版本与边界： 离线 RAG 评估方法，适用于不同模型和框架；不作线上效果保证。

进一步阅读：

• RAG 评估：题集与单变量调整

可执行的下一步： 为每题增加 familyId，按 familyId 划分集合并检查交集；保留调参记录，新增一批未看过结果的验收题。

17. 有引用不等于有依据

题目： 答案带了一个真实存在的引用，但片段没有提到答案中的退款期限。哪项结论成立？

• A. 引用存在，所以退款期限已被证实
• B. 相似度高就能证实期限
• C. 引用存在不证明该事实被支持，需要逐项核对证据，缺失时说明证据不足
• D. 只要回答流畅就可通过

正确答案：C. 引用存在不证明该事实被支持，需要逐项核对证据，缺失时说明证据不足

解释： 引用有效性和事实支撑是不同检查。片段可访问仍可能不支持答案中的具体期限；应核对事实、版本及授权，对证据不足的问题补检或拒答，而非补造规则。

适用版本与边界： RAG 通用事实核对；本题不假定特定模型或向量数据库。

进一步阅读：

• RAG 评估：证据支撑
• RAG 文档版本

可执行的下一步： 取一个回答，把事实陈述逐句列成表，给每句对应原文片段和版本；无依据的句子单独列为失败项。

18. 模型工具调用与授权

题目： 模型生成了符合 JSON Schema 的关闭工单参数，工单属于其他租户。服务端下一步应怎样做？

• A. 立即执行，Schema 已保证权限
• B. 使用可信登录身份检查租户及对象权限，不通过就拒绝执行
• C. 让模型再说一次确认即可
• D. 直接相信参数中的 tenantId

正确答案：B. 使用可信登录身份检查租户及对象权限，不通过就拒绝执行

解释： Schema 约束结构，不能证明调用者有权操作该对象。服务端应从可信会话取得身份，核对对象归属、业务状态和操作权限；确认、幂等与审计也需由业务层落实。

适用版本与边界： 模型工具调用的通用服务端边界；不依赖特定 function calling API。

进一步阅读：

• 工具调用：权限、参数、幂等

可执行的下一步： 为工具处理器增加跨租户请求测试，核对拒绝结果和数据库无变更；再测试同一幂等键重复请求。

项目表达

整理个人职责、实现和可复查材料，明确尚未验证的部分。

19. 哪些内容可写成个人成果

题目： 下面哪个表述只报告了题设已提供的可核对事实？

• A. 看过架构图，就写负责整套系统
• B. 教程介绍日活百万，所以写我的项目日活百万
• C. 未做压测，但写吞吐提升十倍
• D. 独立实现了练习项目的文档删除接口，附提交、删除用例及本地运行记录，并注明未上线

正确答案：D. 独立实现了练习项目的文档删除接口，附提交、删除用例及本地运行记录，并注明未上线

解释： 最后一项对应明确职责、产物、验证条件和部署边界。阅读教程不能证明个人负责系统，项目介绍的规模不能变成个人业绩，未经测试不能填写提升比例。

适用版本与边界： 项目与简历证据规范，适用于 2026 年本轮材料；非招聘评价标准。

进一步阅读：

• 项目经历与证据

可执行的下一步： 选一条自己的简历描述，逐项标注本人职责、代码或文档位置、实际验证和未完成边界；删掉无证据数字。

20. 性能数字的比较条件

题目： 两次耗时记录分别来自不同机器、不同题集，且一次排除了失败请求。能据此报告“优化后 P95 降低 40%”吗？

• A. 能，数字更小即可
• B. 不能，应统一对照条件并记录样本数、失败率及统计口径，再据实比较
• C. 只要换算成平均数就能
• D. 删掉慢请求即可

正确答案：B. 不能，应统一对照条件并记录样本数、失败率及统计口径，再据实比较

解释： 机器、负载、数据、配置及失败过滤差异会改变分布。要归因于优化，应控制条件并报告成功耗时的口径、样本数和失败率；未经这样的验证，题设不能支持 40% 的改善结论。

适用版本与边界： HTTP/检索链路的对照测量原则；无预设性能结果。

进一步阅读：

• 项目简历：数字与技术含义
• RAG 评估：耗时与失败

可执行的下一步： 写一份固定环境、题集、并发、预热、配置版本和失败处理方式的运行说明，保存两轮原始记录后再计算比较。

21. 数据不足时如何选项目

题目： 准备做企业知识库，但目前没有授权企业文档。哪项计划可以立即执行且边界明确？

• A. 用公开可用且许可允许的资料构建小范围检索练习，注明数据来源与未接入生产
• B. 编造一套真实企业客户数据
• C. 直接写已经服务多家企业
• D. 先承诺准确率 99% 再找数据

正确答案：A. 用公开可用且许可允许的资料构建小范围检索练习，注明数据来源与未接入生产

解释： 小范围、许可清晰且可获得的数据能支撑真实实现与验收。练习应明确数据及部署边界，不把合成或公开材料包装成生产客户结果，也不在评估前承诺准确率。

适用版本与边界： Java AI 项目范围规划；数据许可按所选资料单独核对。

进一步阅读：

• Java AI 项目选型
• Java AI 项目入口

可执行的下一步： 写一页项目范围：数据来源及许可、用户问题、Java 业务入口、AI 能力边界和最小验收，先实现其中一个闭环。

22. 故障描述需要什么材料

题目： 要说明“重复请求未重复扣减库存”，下面哪组材料最能直接支持这个具体结论？

• A. 一张服务启动截图
• B. 依赖清单含 Redis 和 MySQL
• C. 两次使用同一业务幂等键的请求、对应响应、事务及库存变更记录，并标注环境
• D. 只展示接口返回 200

正确答案：C. 两次使用同一业务幂等键的请求、对应响应、事务及库存变更记录，并标注环境

解释： 要证明重复请求的业务效果，需要把相同幂等键、请求、响应和实际数据变化串起来。组件名字或启动成功不证明幂等。结论仍限于已测场景；并发和崩溃路径要另测。

适用版本与边界： Java 后端项目验证；具体事务及幂等实现依实际数据库与框架。

进一步阅读：

• 项目经历：证据驱动追问
• 工具调用：重复执行与幂等

可执行的下一步： 保存一组连续重复请求和一组并发重复请求，核对库存只变化一次；再明确尚未覆盖的故障窗口。

23. 检索与微调的能力边界

题目： 项目只实现了文档切分、向量检索和把片段加入提示词，没有任何训练作业。哪项描述符合已实现内容？

• A. 完成了基础模型预训练
• B. 完成了模型微调
• C. 训练了企业专属大模型
• D. 实现了 RAG 检索增强链路；没有更新模型权重的证据

正确答案：D. 实现了 RAG 检索增强链路；没有更新模型权重的证据

解释： 将外部文档检索后加入上下文属于检索增强，不等于更新模型权重。没有训练作业、训练配置和权重产物，不应把 RAG 写成微调或预训练。

适用版本与边界： RAG 与训练的能力边界；模型供应商与框架无关。

进一步阅读：

• Java AI 项目选型：先跑检索
• 项目简历：核实技术含义

可执行的下一步： 画出入库与在线问答两条链路，逐段对应代码；在简历中用实际实现的能力名称替换夸大的训练表述。

24. 自测结果应如何使用

题目： 24 道固定题全部答对后，下面哪项下一步合理？

• A. 直接认定面试必过
• B. 选择一个仍缺实践证据的主题，执行下一步任务并整理真实记录
• C. 生成一个就业概率
• D. 把题目答对数写成线上项目成果

正确答案：B. 选择一个仍缺实践证据的主题，执行下一步任务并整理真实记录

解释： 固定题只能反馈这些题的作答情况，不能预测就业或面试结果。把解析中的知识落实为代码、时序图、回放记录和职责说明，才能补充可复查的学习材料。

适用版本与边界： 本工具 2026-11-06 题库；统计只描述当前题库内的作答。

进一步阅读：

• 项目简历与证据
• 学习路线

可执行的下一步： 从错题或尚无实践记录的主题挑一项，完成其具体任务；在复习单写下文件位置、实际现象与仍未解决的问题。

规则核对与后续学习

语言与 API 规则可核对 Java SE 21 语言规范、Java SE 21 API；线程池规则见 ThreadPoolExecutor API。Spring 题设采用 Spring Framework 6.2 事务文档。题设有明确版本限制时，按该限制复现。

工程题的具体判断口径见每题链接的站内指南。先完成一个代码例子、故障回放或证据表，再回到 学习工作台 保存自己的实践记录，或直接在自己的文档中整理。

无需 JavaScript 也能学习：静态阅读全部 24 题与完整解析。可以在自己的文档中先写答案，再对照解析，保存实际练习材料。

先选一个能完成的任务

| 主题 | 你会判断什么 | 完成后留下什么 |
|

默认版本的这些记录保存在你的设备，未启用远端上传，不代表全站总访问量。 下载点击不等于文件已经下载成功，复制微信号不等于已经添加好友或购买服务。

浏览器启用“请勿跟踪”（Do Not Track）时，不写入上述使用记录。你也可以在浏览器设置中清除本站存储；这会同时清除来源标签和记录。请不要在 UTM 参数中填写手机号、姓名、邮箱或简历信息。

评论使用原站的 Giscus/GitHub 服务，加载与登录遵循对应服务的隐私规则。是否登录和发表评论由你自行决定。

学习进度与错题

学习工作台根据你的作答保存本浏览器的进度和错题，便于继续复习。记录不包含姓名、简历或联系方式。可以导出复习单，或使用工作台的重置操作清理本工具的数据；换设备或清理站点存储后不保证保留。

成长路线另行保存所选目标与自己勾选的练习标记，仅用于在本浏览器继续学习，不上传。可以在成长路线中重置当前路线；其他路线和自测错题不会随之清空。勾选由自己决定，不代表网站验证了你的实践结果。下载的路线练习单是空白模板，不会自动包含浏览器中的标记。

可选站点统计

网站提供可选的第一方统计能力，默认未启用。站点运营者配置并启用后，可以接收页面路径、事件时间、随机会话标识、主题和预先约定的渠道代码，以及资料或咨询入口的点击路径。传输不包含页面查询参数、完整来源网址、答题内容、微信号或聊天内容，接收器不保存 IP 和 User-Agent 字段。

统计用途是核对哪些内容和资料被使用，不能据此推断你已经关注公众号、添加微信或购买服务。浏览器开启 Do Not Track 时不发送这些统计动作。若以后增加订阅、表单或其他数据用途，会在相应入口另行说明。

先下载项目源码，完整解压。已有网站源码时，项目位于 examples/knowledge-service。项目总览保留源码阅读路径、源码摘要与原有测试报告。

先知道这次会运行什么

默认实现是 H2 文件数据库 + 本地词项检索 + 原文摘录，返回模式为 local-lexical-extractive。英文按词项、中文主要按相邻双字切分；问题词项覆盖率至少 0.6 才返回引用，分数不是模型置信度。正文整体作为一个检索单元，答案直接取首条引用的原文。词项重合不保证真正回答了问题。

本单元不用 Docker、PostgreSQL 或模型密钥，也不要加 -Pai。既有 pgvector 实测使用真实数据库与三维确定性 fixture，证明存储、过滤和版本处理；真实模型调用、语义质量和生成回答未验收。源码的可选 AI 模式也没有聊天模型生成步骤。

2026-11-06 的教学命令实跑与源码核对范围见文末。以下“预期”是你运行时要比较的目标，不代表你电脑上已经通过。

1. 准备环境，找到正确目录

本页使用 PowerShell 命令，本次实跑环境为 Windows 上的 PowerShell 7.6.9；Windows PowerShell 5.1 未实跑。打开终端 A，进入含 pom.xml 的 knowledge-service 目录。仓库用户可用 Set-Location 'D:/zhuomian/qiuzhiwang_pro/examples/knowledge-service'；下载包用户换成自己的解压目录。

java -version
mvn.cmd -version
Test-Path ./pom.xml

预期：Java 为 21，Maven 为 3.9+，最后输出 True。还要核对 Maven 输出中的 Java version / runtime，避免它实际使用另一个 JDK。第一次启动需要联网下载 Maven 依赖。

2. 启动服务，隔离端口和数据库

项目默认配置是 127.0.0.1:8085、jdbc:h2:file:./data/knowledge;DB_CLOSE_ON_EXIT=FALSE;WRITE_DELAY=0。本教程改用 18085，每次生成一个独立临时目录。数据库 URL 用环境变量覆盖，端口用 Spring Boot 运行参数覆盖；不需要修改配置文件。

在终端 A 依次执行：

$ErrorActionPreference = 'Stop'
# 只探测端口是否空闲，不关闭任何已有服务。绑定失败就先停在这里。
$probe = [System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Loopback, 18085)
try { $probe.Start() } finally { $probe.Stop() }

$taskDir = Join-Path ([System.IO.Path]::GetTempPath()) ('knowledge-first-run-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $taskDir | Out-Null
$dbPath = (Join-Path $taskDir 'knowledge').Replace('\', '/')
$env:SPRING_DATASOURCE_URL = "jdbc:h2:file:$dbPath;DB_CLOSE_ON_EXIT=FALSE;WRITE_DELAY=0"
$taskDir  # 记下此目录，数据库在这里，不在项目的 data 目录。
mvn.cmd -B -ntp spring-boot:run '-Dspring-boot.run.arguments=--server.port=18085 --spring.profiles.active=default'

终端保持运行。预期日志显示 Tomcat 使用 18085、Hikari 的 H2 URL 指向刚才的临时目录，最后出现 Started Application。URL 不对就先停止本次启动再核对，避免写入旧库。这里显式使用运行 profile default，不要同时启用 ai。

打开终端 B，后续接口命令都在同一个终端 B 顺序执行，不要中途关闭，否则变量会丢失：

$ErrorActionPreference = 'Stop'
$base = 'http://127.0.0.1:18085/api'
$health = Invoke-RestMethod "$base/health"
$health

预期为 status = UP。浏览器也可打开 http://127.0.0.1:18085/ 查看控制台；本单元的可复核结果由下面的接口命令取得。网站页面不会自动启动或连接你的本机服务。

3. 登录教学身份，确认服务端认定的角色

这些固定密码仅限本机教学。空数据库启动时会初始化以下用户；不会自动导入样例文档。

| 用户 | 教学密码 | 租户 | 角色 | 本单元用途 |
|

这个项目把检索边界放进真实 HTTP 服务：登录取得服务端身份，写入有版本的文档，再检查“当前用户能用哪些原文回答这个问题”。源码围绕认证、数据库事务、文档状态和检索过滤展开，可以沿请求链路理解这些模块如何协作。

本页整理源码阅读路径、接口约定与已有验证证据。需要逐步启动时，可查本地运行与 API 调用说明，其中给出环境、身份、创建文档、版本更新、拒答和权限对照的完整命令。

默认模式采用 H2 文件数据库与本地词项检索，不需要模型密钥或 Docker。它返回原文摘录；语义向量检索使用单独的 Spring AI / pgvector 模式，运行条件与验证范围见下文和包内 README。

本地运行

需要 JDK 21 与 Maven 3.9+。下面是包内默认启动方式，默认端口为 8085、数据库为当前目录的 data/knowledge.mv.db。首次跟做请优先使用教程里的 18085 与临时数据库命令，不要同时执行两套启动步骤。

完整解压后进入 knowledge-service 目录，在 Windows 执行：

.\start.cmd
# 或者
mvn.cmd -B -ntp spring-boot:run

Linux/macOS 使用 sh start.sh。启动后打开 http://127.0.0.1:8085/，在项目控制台登录、添加文档并查询。健康检查路径为 /api/health。

本地演示用户写在包内 README。控制台默认使用 H2，数据保存在启动目录的 data/knowledge.mv.db；重启后可以继续查看。相同数据库文件不能同时由多个服务进程占用。

首次遇到依赖下载、端口或 JDK 问题，按使用帮助记录第一条错误。网站本身提供代码和说明，不会自动连接你电脑上的服务。

可以沿着哪条链路读源码？

| 环节 | 实现重点 | 验证要点 |
|

Java AI：向量检索与模型问答

Java AI 知识库项目把文档分块、嵌入接口、向量相似度与模型回答放在同一条请求链上。重点看模型调用怎样与租户权限、文档版本和证据引用衔接，以及失败、超时和流式输出怎样处理。

模型供应商需要自行配置。项目说明区分本地 HTTP 契约测试和真实模型验证，源码提供独立启动方式。

知识库检索服务

Java 知识库检索服务：认证、文档版本、权限与证据返回

基于 Java 21 与 Spring Boot，围绕“当前用户可以依据哪些文档回答问题”组织接口与存储。可以沿下面几条链路阅读源码：

• 认证与身份：登录、Bearer token、过期撤销，以及请求中的服务端租户和角色。
• 文档与事务：当前版本、历史版本、expectedVersion 并发冲突与删除墓碑。
• 检索与引用：授权后的候选集、当前状态复核、原文摘录、来源版本和无证据拒答。
• 向量接入：Spring AI / pgvector 独立模式，以及向量候选与权威文档状态的衔接。

默认模式使用 H2、词项检索与原文摘录。向量接入条件与已有测试范围在项目说明中单列，模型生成仍属于后续扩展。

源码与实现说明 · 下载源码包 · 本地运行说明 · 接口验证手册

机制实验与代码示例

| 内容 | 分析重点 | 阅读入口 |
|

一份填写完成的记录

| 字段 | 示例填写 |
|

从笼统描述开始

负责企业级 AI 知识库架构，使用 Java、RAG、多租户和权限控制，提升检索准确率。

这句话没有解释实现范围，“企业级”和“提升准确率”也缺少相应证据。

先填事实，再写项目条目

| 字段 | 填写内容 |
|

下载填写完成的验收 CSV · 核对原始 JSON

先把实验条件写完整

| 字段 | 本例填写 |
|

| 你要完成的事 | 看一份填好的 | 数据从哪里来 |
|

IO、并发与数据存储进阶

16 篇后端进阶教程覆盖 IO/NIO、AQS、ThreadLocal、CompletableFuture、虚拟线程、JDK 迁移、MySQL 的事务与锁，以及 Redis 复制、持久化和高可用。各篇给出机制解释、适用版本和参考资料。

下载后端工程阅读与源码包 · 文件清单与 SHA-256 · Java 示例统一运行记录

技术阅读目录

| 主题 | 在线阅读 | 适合了解什么 |
|

资料范围与源码说明

这组资料包含验收手册、空白用例、填写样例、检索实验记录与后端源码。手册说明引用、权限和文档更新等验收维度；样例与原始 JSON 展示合成文档上的预期来源、对照结果和修正结果。

可先阅读手册目录与在线正文，再结合下方删除场景理解文档最新状态、删除标记和权限过滤的关系。查看源码包时，以包内 README 的环境、启动方式和实现范围为准；记录中的 Java 版本与源码哈希用于识别对应实验。

需要动手时，可按检索实验说明复跑并保存自己的结果。教学实验只检查合成数据上的检索边界，模型生成、向量检索与真实认证需要另外验证；未执行的用例保留为空白。

资料预览：一条删除场景的实际记录

下表来自已有的 RAG 验收填写样例与本站检索实验，使用合成文档。

| 记录项 | 现有记录 |
|

资料内容与阅读方式

这组资料包含面试知识检查表、28 天复习计划、HashMap 复盘样例与线程池饱和实验。检查表按结论、原理、例子和边界组织回答；复盘样例展示如何从一个笼统结论追溯到版本条件与源码分支。

阅读时可先对照下方样例，再查阅单份资料。源码结论需要注明所用 JDK 版本与具体调用路径；实验说明和已有 stdout 可用于理解队列与拒绝策略，自己的运行结果应另行保存。

需要练习时，可任选一题记录原回答、核对源码或运行小例子，再补充修订说明。复习计划和记录模板按需使用，不是阅读或交流的前置要求。

资料预览：一份复盘如何填写

下表节选自已有的 HashMap 复盘样例。这是教学演练，供对照填写。

| 记录项 | 样例内容 |
|

模板内容与样例说明

这组资料围绕项目事实、个人职责、实现范围、验证证据与技术取舍组织项目经历。模板区分生产工作、个人项目、教学练习和设计方案；填写样例展示从笼统描述到可追问条目的改写过程。

可先阅读下方 Java 检索教学实验样例，再打开完整填写材料，对照代码位置、源码哈希与回放记录理解每条描述的依据。自己的条目只写亲自实现、参与或验证过的部分，并说明项目性质与实现边界。

需要整理经历时，再复制模板填写事实、证据和失败场景，或练习三分钟讲解。涉及性能数字时，保存基线、环境、样本与计算口径；没有测量依据就写功能与验证方法。

资料预览：已有实验如何写进项目条目

下表摘自 项目经历填写样例，对应本站 Java 检索教学实验。

| 模板字段 | 现有样例 |
|

内容目录与用途

| 内容 | 阅读用途 | 源码与资料 |
|

前六步是本地检索与后端验收主线，可按每周 8—10 小时、约六周安排。真实模型与生成另留时间，按环境和验证结果推进。还不能独立开发接口时，先补基础准备。

先看清你准备运行哪一层

| 层次 | 当前项目提供什么 | 这条路线怎样验收 |
|

如果还不能独立写接口或执行 SQL，先看成长阶段说明。这条路线整理已有基础，不承担从零学习全部后端知识的任务。

第一步：找一个答不清的点，把集合题写成代码

• 阅读： 先在自测工作台独立答一组 Java 题，再读HashMap 底层原理；参考面试复盘样例记录自己漏掉的条件。
• 任务： 用半小时画出一条接口的调用链，标出集合、事务、SQL 和外部调用。选一个真实缺口做小程序：例如用自定义 Key 验证两个相等对象能否取出同一个值，再修改已入表 Key 中参与哈希计算的字段，观察查找行为。先写预测再运行。
• 产物： 一段独立可运行的代码、JDK 版本、原回答、预期与实际输出，以及修订后的两分钟解释。
• 检查点： 能说明 equals、hashCode 与键是否变化分别影响什么；能沿自己使用的 JDK 源码定位依据。讨论树化时能说明容量和操作路径，不只背常量。
• 卡住怎么办： 暂停业务项目，只保留一个类、一个 Map 和两个 Key。打印哈希值与相等比较结果；看不懂源码先补Java 基础和集合框架，一次解决一个条件。

第二步：跟着一次线程池饱和往下问

• 阅读： 线程池面试专题、线程池过载指南，不熟悉线程协作时补多线程与并发编程。
• 任务： 按指南的门闩示例，配置核心线程 2、最大线程 4、有界队列 2 和 AbortPolicy。在门闩未释放时连续提交 7 个任务，先推导哪些任务创建线程、哪些排队、何时拒绝，再运行；结束时释放门闩并关闭线程池。
• 产物： 参数表、提交时序、自己的运行输出和拒绝分支处理说明。文章给出的输出只供对照，不替代本次执行。
• 检查点： 能解释“核心数满后先入队，队列接纳失败后再尝试扩容”；区分规则推导、实际观察与任务开始顺序。能回答入口收到拒绝时如何返回，为什么不能仍报成功。
• 卡住怎么办： 先原样运行最小示例，检查门闩是否提前释放、队列是否真有容量上限、是否使用同一拒绝策略。没有打印任务开始时间，就不推断全部执行顺序；不要用增加 sleep 掩盖时序问题。

第三步：确认事务到底在哪一层生效

• 阅读： 事务面试专题、Spring 事务提交边界，结合自己项目的 Spring 版本与事务配置阅读。
• 任务： 在练习数据库中准备一个有两次写入的 Service 方法，通过另一个 Bean 调用它。在第二次写入前抛出未捕获的运行时异常，从新请求或独立连接核对两次写入的结果；再在练习副本比较同类内部调用未经过代理的路径。每次恢复相同初始数据。
• 产物： Controller、Service、代理与数据库的调用图，事务配置，异常抛出位置，以及正常、异常两条路径的数据记录。
• 检查点： 能解释入口是否经过事务代理、异常是否传播、是否加入外层事务；知道方法体执行完与物理事务提交不同。涉及缓存或通知时，能指出数据库回滚无法撤销哪些外部动作。
• 卡住怎么办： 先缩到同一数据源、两个 Bean 和一个本地事务。检查异常是否被捕获、方法是否由 Spring 管理、测试外层是否另有事务；不要同时引入异步线程或多数据源。指南中的设计片段需要自己实现和验证。

第四步：把 SQL 和缓存放回同一条读写链

• 阅读： MySQL、缓存失效与旧值回填。
• 任务： 在本地 MySQL 固定一份数据、一个列表查询和排序条件，保存原 SQL 的普通 EXPLAIN，再比较一个候选索引的计划。接着画出“读未命中并取得旧值 → 写提交并删除缓存 → 读回填旧值”的交错时序；项目已有 Redis 时再实际回放，否则将该部分标为时序推导。
• 产物： 数据库版本、表结构、SQL、索引、数据分布与前后计划；一张缓存竞态图，注明已执行与未执行的部分。
• 检查点： 能说明索引服务了哪些过滤或排序条件，计划变化能证明什么；能区分删除失败、结果未知与删除成功后的旧值回填。没有重复测量就不写接口提速比例。
• 卡住怎么办： 去掉联表，只保留一个查询和一个索引；先确认实际使用的是 MySQL，不能把 H2 的结果写成 MySQL 实验。缓存先推演两个请求的先后关系，再决定是否需要实现补偿任务。

第五步：用日志和线程状态定位一次慢请求

• 阅读： JVM、场景题和线程池指南中的排障顺序。
• 任务： 在自己的本地练习接口中制造可控等待，例如等待门闩的下游桩；为同一请求关联入口、排队、执行与数据库耗时。核对当前 JDK 支持的诊断命令后采集线程状态，解除等待，再用同一输入复跑。
• 产物： 一份“现象 → 证据 → 假设 → 验证”的记录，附请求关联标识、时间线和相关线程栈，保留未证实的假设。
• 检查点： 能用等待位置解释本次慢请求，并说明解除等待后发生什么；不凭一次慢响应断言 CPU、GC 或数据库一定有问题。本地人为故障只说明这一条分支。
• 卡住怎么办： 先固定一个请求、一个等待点，确认日志能关联。拿不到诊断权限时保留应用时间线，注明缺少线程证据；指标不足就继续采集，不急于调线程数或堆大小。

第六步：用自己的材料做两轮模拟问答

• 阅读： 面试专题入口、面试复盘样例、项目故事与证据。
• 任务： 选前面两项亲自完成的实验或项目改动，录一分钟介绍与三分钟链路讲解。第一轮回答“为什么、怎么做、怎么验证”；第二轮继续问“失败怎么办、换一个条件还成立吗、本人改了什么”。独自练习也可以先写问题，隔一天再回答。
• 产物： 两轮录音或逐字提纲、五个追问、修订清单，以及下一次补做的一个实验。
• 检查点： 每个结论能定位到代码或记录，能主动说明 JDK、框架、数据与运行条件。答不清的地方能说出待验证项，而不是借用别人的项目结果。
• 卡住怎么办： 先对照一段代码讲清输入和输出，再补原理。把“并发不熟”改成“还不能解释队列满后的拒绝分支”这样的小问题，回到对应步骤补一份证据。

做到什么程度可以先告一段落？

至少保留一个集合实验、一个线程池实验、一份事务数据记录、一份 SQL 或缓存分析、一份慢请求排查，以及两轮问答复盘。记录里清楚区分实际运行、规则推导和待验证项，就能看出下一轮该补哪里；这些材料不代表全部面试题已经掌握。

把个人改动带入项目到简历路线，准备 AI 应用实践时进入Java 转 AI 路线。资料可从Java 面试资料查找，起点判断见成长阶段说明。

还没有可运行项目时，先完成Java 转 AI 路线的本地知识服务主线，或把自己的一个后端接口跑通。成长阶段说明可以帮助判断从哪里开始。

第一步：先把“我的部分”圈出来

• 阅读： 项目表达入口、项目简历指南，再看自己的代码、需求与提交记录。阅读材料帮助整理问题，职责以实际参与为准。
• 任务： 写清项目性质、使用者、需要解决的问题和运行范围；逐模块标注独立完成、协作参与、运行验证或仅阅读。选一至两项本人实际做过的动作，记录谁负责上下游、自己交付了什么。
• 产物： 职责与材料对应表：模块 / 我的动作 / 合作边界 / 代码或文档 / 已有验证 / 缺少的材料。项目性质按工作项目、个人项目、教学复现或设计方案如实填写。
• 检查点： 每个“负责”“实现”“优化”都能指出具体对象；团队已有能力与自己的改动分开。只运行过公开源码时，先写复现、阅读或验收，不写成从零开发。
• 卡住怎么办： 不从架构图找所有权，先找一个自己能完整解释的提交、一条接口或一次排查。工作代码不能公开时，整理允许展示的脱敏流程、接口约定和验证方法；仍无法说明的模块先不放入条目。

第二步：为一项动作补齐正常与失败证据

• 阅读： 项目简历资料与模板。知识服务可结合项目接口说明和验收手册；普通后端按自己接口契约选用场景。
• 任务： 为第一步的一项动作固定代码版本、数据和环境，先执行一条正常请求，再选两个适用的边界：非法输入、无权限、旧版本写入、重复请求或外部依赖失败。先写预期，执行后保存实际结果；发现问题先留原记录，修复后复跑同一输入。
• 产物： 一份证据索引，每项包含运行命令或操作、测试身份、数据来源、预期、实际响应、判定、本人改动和已知限制。无法执行的场景写原因与下一步。
• 检查点： 别人能根据记录在相同条件下重复操作，证据能支持准备写的结论。没有重复请求防护就不能宣称幂等；没有外部依赖就不填写“模型超时已通过”。截图可以辅助，原请求与响应仍需保留。
• 卡住怎么办： 把项目缩到一个接口和一份合成数据。测试无法复现时先记录条件差异；无法补证据时降低表述范围，把“已解决一致性问题”改成实际验证的具体分支，或暂时移除该结论。

第三步：改写条目，每一句都回到事实

• 阅读： 项目故事与证据、项目简历指南及项目表达填写样例。样例中的动作和成绩不是个人经历。
• 任务： 从“参与开发，使用 Spring Boot、Redis、AI”这样的笼统句子出发，按下面的结构写两至三条描述。每句话标出对应证据，检查主语、实现层次、数字与适用条件。
• 产物： 修改前后两版描述，以及“句子 → 证据位置”的索引。方括号只填自己的事实，缺少事实就删去相应部分。
• 检查点： 看得出具体问题、个人动作和验证办法，技术名称用于解释实现。性能或质量比例能说明环境、样本、基线、测量方法与分母；只有一次功能回放时，就只写本次功能验证。
• 卡住怎么办： 先用口语写“我改了哪一段，原来会怎样，现在怎么核对”，再压缩句子。没有量化指标可以描述边界和验证方法，不必凑提升百分比；没有个人改动就保留为学习与复现记录。

下面是待填写的结构，没有预设个人成果：

项目性质：[工作项目 / 个人实践 / 教学复现 / 设计方案]
为解决[具体问题]，我[实际完成或参与的动作]，
采用[关键做法与选择原因]；
在[环境、数据与输入]下，通过[命令、回放或核对方法]
得到[实际结果]，当前未覆盖[已知限制]。
证据：[提交、设计记录或运行结果位置]

知识服务条目尤其要分清这几层

| 自己实际完成什么 | 条目应说明什么 |
|

也可以直接阅读完整路线：Java 面试 · Java 转 AI · 项目到简历。先拿不准从哪里开始，就看成长阶段说明，按手头能拿出的材料判断。

选一条主线，先交付一件东西

| 当前情况 | 选择路线 | 建议排期与最终产物 |
|

| 现在能拿出什么 | 从哪里继续 |
|

| 现有产品 | 适用对象 | 交付形式 |
|

• 增加一级“进阶之路”入口，总目录按十二章组织 Java 基础、集合、并发、JVM、框架、数据库、分布式与 AI 应用。
• 授权公开文章补入各章，保留原作者与来源说明；推广入口统一接本站资源、公众号与服务。
• 总目录采用主题原有的文档阅读布局，左侧章节导航、正文阅读和页内目录配合使用。

2026-11-06：技术阅读入口调整

• 首页以六类技术知识、推荐文章和项目解析为主；首屏直接进入知识目录与技术专题。
• 重排导航和侧栏，Java、Spring、数据库、并发、AI 工程内容优先；学习路线、自测和练习移至辅助入口。
• Java、AI、专题与项目总览改为技术目录，按原理、实现与工程问题组织内容。保留原有文章、源码、资料和学习工具。

2026-11-06：成长路线与实战系列（先前更新）

• 学习栏目按“准备 Java 面试、从 Java 走向 AI 应用、把项目写进简历”提供路线入口。
• 成长路线支持在当前浏览器自记学习标记、继续未标记步骤，并提供三份可下载练习单。标记与自测错题分别保存。
• 新增“Java 面试追问实战”“项目经历修改室”，知识库项目增加首次启动的跟做单元。
• 资料、帮助和交流入口围绕具体问题衔接；第一次交流可以先说明基础、目标和一个卡点。

先前更新

• 完成站点品牌替换：Logo、favicon、页脚版权、GitHub 链接已更新为 IT枫斗者。
• FAQ 已改造成 Java Offer 训练营常见问题。
• 评论系统已切换到 Giscus，并接入 GitHub 登录评论。
• 搜索框移动端样式已统一优化。
• 项目已重构为单站点结构，支持直接在根目录运行和打包。

后续计划

• 持续补充 Java 八股、AI 应用开发、面试实战等内容。
• 根据真实搜索查询与读者问题，持续修订内容、资料和路线。
• 持续整理真实面试案例与训练营问答。

内容从语言基础延伸到后端框架、数据库、中间件、系统设计与 AI 应用。每个模块先列基础阅读，再接源码分析和工程专题。文章中的代码、适用版本和参考资料，帮助把概念放回具体实现中理解。

在线阅读免费开放。 配套的源码、手册和主题资料可以直接下载；技术更新和交流统一通过本站的IT枫斗者公众号与微信。

阅读顺序与知识地图

| 阅读阶段 | 主要内容 | 入口 |
|

JavaGuide 公开文章

上游仓库：Snailclimb/JavaGuide。固定快照：992dae31eade2a34ba8dbbbcf5ed9de5511325ec。完整Apache-2.0 许可证随站点及阅读包提供。

| 本站文章 | 原文 | 原作者 |
|

面试准备优先级是：主责模块必须讲深，非主责模块做到“边界清晰 + 上下游明白”。

面试官通常看什么

• 你是否真正承担过核心职责。
• 你能否说明模块上下游依赖和协作方式。
• 出问题时你是如何定位、沟通、推动落地的。

非主责模块准备到什么程度

• 能说明这个模块解决什么问题。
• 能说清和你主责模块的调用关系。
• 能描述典型故障时的协作流程。
• 不要求你背出对方模块的全部实现细节。

三步补齐跨模块认知

1. 画一张系统调用链，标出你负责位置。
2. 对每个上下游写一句“输入-处理-输出”。
3. 准备 2 个跨模块协作案例，重点讲推进过程。

推荐表达模板

我主责的是 X 模块，核心职责是 A/B/C。
和我最相关的上游是 U，下游是 D。
当时出现过一次 P 问题，我先在 X 模块定位，再和 U/D 对齐边界，
最终通过 R 方案解决，结果是 T 指标提升/故障恢复。

避免两种说法

• “这个不是我负责，我不清楚。”
• “所有模块我都很熟。”

第一种显得边界外全部失能，第二种容易被追问击穿。最稳妥是“主责深、协作清”。

同样的投入，按流程配合的人通常结果更稳定。不要把准备工作压到面试前集中爆发。

推荐推进流程

1. 简历定稿：岗位方向和项目描述先对齐。
2. 项目梳理：形成 1 分钟和 3 分钟两个版本。
3. 题库训练：高频问题先覆盖，再做追问训练。
4. 模拟面试：暴露表达盲点和知识断层。
5. 正式投递：按节奏推进，不盲投。
6. 面后复盘：把反馈沉淀为下一轮提升动作。

资料边界与协作规范

• 专属资料仅用于个人学习和面试准备，不外传。
• 提问请附上背景、现象和已尝试动作，便于快速定位。
• 重要问题优先结构化表达，减少来回沟通成本。

常见偏离与修正

• 偏离：简历刚改完就急投，项目还没讲顺。
  修正：至少完成一次模拟再投递。
• 偏离：面试前夜集中提问，焦虑堆积。
  修正：按周复盘，提前清理高频卡点。
• 偏离：只要答案，不做二次复述。
  修正：每次反馈后必须口头复述一遍。

配合的核心价值

流程不是束缚，而是帮你在高压期保持稳定输出。

你能在这里解决什么问题

• 源码能不能发、哪些内容可以公开交流。
• 非主责模块要准备到什么程度才够面试。
• 怎样提问效率最高、能更快拿到有效反馈。
• 焦虑期如何稳住节奏，不被细节拖垮。
• 如何与辅导流程配合，避免“临时抱佛脚”。
• 3 年及以上经验，项目该怎么选、怎么讲。

目录导航（建议阅读顺序）

1. 源码：保密边界与可交流范围。
2. 模块：主责深挖与跨模块认知。
3. 提问：高效提问模板与时间节奏。
4. 心态：面试准备期的心理与执行策略。
5. 配合：标准协作流程与注意事项。
6. 项目：项目选择与表达建议。

30 分钟速读路线

• 第 1 步（10 分钟）：读 源码 + 模块，先建立边界感。
• 第 2 步（10 分钟）：读 提问 + 配合，把协作效率提上来。
• 第 3 步（10 分钟）：读 心态 + 项目，形成可执行计划。

使用建议

• 每次遇到卡点，先回到对应 FAQ 章节找“标准动作”。
• 把“我觉得”改成“我验证过”，提问时附上已尝试内容。
• 每周至少复盘一次，把高频问题沉淀为你的个人话术库。

下一步

• 查看 Java+AI 项目介绍
• 进入 Offer 训练营
• 查看常见问题
• 了解如何报名

好问题不是“我不会”，而是“我做了什么、卡在哪里、希望得到什么帮助”。

提问前自查清单

• 问题是否可复现，现象是否能描述清楚。
• 你已经做过哪些排查，结果是什么。
• 你期望得到哪类帮助：思路、定位、还是表达优化。

推荐提问模板

【背景】我在准备/实现的是：
【现象】当前问题是：
【已尝试】我已经做了 1/2/3，结果分别是：
【卡点】我不确定的是：
【期望】希望得到：定位建议/讲解思路/面试表达优化

时间节奏建议

• 日常问题：集中整理后统一提问，效率最高。
• 紧急问题：先给最小复现信息，再补充上下文。
• 面试前夜：优先做复盘，不建议临时堆新问题。

不推荐的提问方式

• 零散抛结论，不给上下文。
• 只说“报错了”，不贴关键日志或重现路径。
• 临时突击式提问，把准备压力全部前置到最后一晚。

提问质量越高，反馈越快，你的迭代速度也会越快。

优先讲你真实工作中的主责项目，训练营项目更适合作为补充案例，而不是第一主讲项目。

为什么这样更稳

• 中高级面试更看重真实业务深度和长期责任范围。
• 你的主责项目更容易经受连续追问。
• 训练营项目用于补齐技术亮点，更合理也更自然。

三种可选策略

| 策略 | 适用人群 | 风险 | 建议 |
|

焦虑不是问题，失控的焦虑才是问题。准备期最重要的是把注意力放回“可执行动作”。

面试准备的三层重点

| 层级 | 你要做到什么 | 典型产出 |
|

公司真实项目源码通常受保密协议约束，不能对外传播。这个边界必须明确、必须遵守。

为什么不能外发源码

• 源码属于企业核心资产，涉及商业机密与知识产权。
• 合同和保密协议通常有明确约束，违规存在法律风险。
• 职业信誉比一次“展示细节”更重要，面试官也看重这点。

可以交流什么，不可以交流什么

| 类型 | 是否建议 | 说明 |
|

这篇怎么用效果最好

不要“一口气读完”，按下面节奏练：

1. 每次选 3~5 题，先读主答。
2. 再把追问连续说一遍，训练抗压表达。
3. 最后用“一句话加分总结”做收尾。

建议搭配 模拟面试问答 做实战演练。

推荐训练法

• 初级：每天 5 题，先保证主答流畅。
• 进阶：每天 3 题，主答 + 追问全链路回答。
• 冲刺：随机抽题，2 分钟内完整作答。

结构是：

• 主问题标准回答
• 面试官可能追问
• 你可以怎么答
• 一句话加分总结

这样你不只是能背“主答案”，还能接住面试官往下挖。

建议这样练，完读率和记忆率更高

1. 找同学或自己扮演面试官，按轮次提问。
2. 每轮只练 3~4 题，避免一口气刷完。
3. 录音后复盘三件事：是否跑题、是否冗长、是否有结论。

搭配 面试标准背诵稿 使用，效果更好。

使用目标

• 训练真实面试节奏，而不是只背单题答案。
• 训练连续表达能力（主答 + 追问 + 收尾）。
• 训练“听题后 5 秒组织答案”的反应能力。

这份稿子的定位

这是一份“高压场景速记稿”，目标是让你在短时间内形成稳定输出。
如果你要系统准备，建议配合 面试答案手册 与 20题逐题追问版。

先看这个，再开始背

如果你时间有限，先优先看三章：
「一、岗位认知类」->「四、RAG 全链路」->「十、项目表达能力高频题」。

这篇更适合当“系统词典”，不建议从头硬背。
建议搭配 20题逐题追问版 和 面试标准背诵稿 一起使用。

使用建议

1. 第一轮：按模块快速通读，建立整体地图。
2. 第二轮：挑高频题改写成你自己的版本。
3. 第三轮：和模拟问答结合，训练连续表达。

先明确底线

这篇的核心不是“教你包装成大佬”，而是教你 真实、稳妥、有边界 地表达。
目标是让你在追问下依然站得住，而不是靠夸大撑场面。

快速使用方式

1. 先看“一、最重要原则”和“二、话术模板”。
2. 再看“六、最容易露馅细节”，把高风险表达删掉。
3. 最后背“十、防露馅完整版”，改写成你自己的版本。

快速导航

1. 1分钟项目介绍版：高压场景保底输出。
2. 3分钟详细介绍版：结构化完整表达。
3. 项目亮点总结：回答“你这个项目有什么价值”。
4. 10个高频追问 + 标准回答：抗追问能力训练。
5. 最后收尾金句：形成面试记忆点。

你可以直接套成自己的项目经历。

技术目录

| 主题 | 阅读入口 | 重点内容 |
|

这个版本专门用于面试场景，回答以下高频问题：

• “你画一下这个系统架构”
• “你讲讲整体技术方案”
• “用户请求进来后链路怎么走”
• “离线入库和在线问答分别怎么设计”

演讲顺序建议

1. 先讲分层（五层模型）。
2. 再讲两条链路（离线入库 + 在线问答）。
3. 最后讲工程化能力（权限、安全、监控、降级）。

开班先沟通学习经历、已有项目、目标岗位和技术短板，再制定个人计划。每个路线节点按“明确重点 → 学习与整理 → 打卡反馈 → 路线检查 → 补讲与复测”推进。

陪跑不只检查是否记住答案，还会追问原因、使用场景、异常处理和验证方法。以工具调用为例，需要能说清模型如何提出调用请求、Java 后端如何校验参数和权限、业务接口如何执行、结果怎样保存，以及超时后如何避免重复执行。

报名前置与技术环境

陪跑营默认面向已经接触过 Java 语法、面向对象、集合、异常和基本 Web 开发的同学。以下内容会在开班前确认，不要求所有人一开始都熟练：

• Java 与 Spring 基础、数据库和常见后端接口开发。
• 目标岗位需要的 Java 版本、Spring Boot、Spring AI 或 LangChain4j 版本范围。
• MySQL、Redis、消息队列、Elasticsearch、向量数据库和模型服务的使用方式。
• 本地开发、第三方 API、云资源和数据安全要求。

具体版本、模型提供商、演示环境和可能产生的 API 或云资源费用，以当期项目和报名服务清单为准。

六段路线图

| 路线节点 | 学习内容 | 陪跑重点 |
|

陪跑营中的项目准备以“会讲、能答、讲得真实”为目标。项目材料用于理解业务和技术方案，面试表达必须结合自己的学习、实践和参与情况，不把未参与的开发经历包装成个人经历。

项目匹配方向

项目会结合目标岗位和个人经历选择，不要求所有人学习同一个业务。项目库中可参考以下方向：

| 方向 | 典型业务 | 重点陪跑能力 |
|

先判断是否适合

这套陪跑面向已经接触过 Java 后端、准备求职或转向 Java + AI 的同学。报名时会结合基础、项目、目标岗位和投入时间确定起点。

你可能存在以下问题

• Java 学过不少，但知识点零散：面试时难以把后端原理、AI 链路和项目表达串起来。
• 有 Java 后端项目，但讲不完整：说不清架构、个人职责、技术难点和异常处理。
• 接触过 AI，但讲不深：需要补充模型调用、RAG、Agent、工具执行、权限和失败恢复。
• 简历写了很多技术名词：项目一被追问，就不知道怎样说明自己的实际工作和掌握范围。
• 已经开始投递：需要同步准备项目表达、简历、多轮模拟面试和真实面试复盘。

报名时会结合你的 Java 基础、工作年限、已有项目、目标岗位、目标城市和每周可投入时间确定陪跑起点，不要求所有人从同一套内容重新学起。

报名后你会获得什么

• 个人基础与目标岗位评估；
• 个人学习重点与阶段任务；
• Java+AI岗位能力补强；
• 企业级项目库匹配与真实项目整理；
• 多个项目的业务、架构和面试表达陪跑；
• 两个主讲项目的深度讲解与追问准备；
• 一对一定制代写简历；
• 个人职业经历与岗位化自我介绍体系；
• 多轮模拟面试，直至符合面试标准；
• 真实面试问题复盘与针对性补强；
• 根据岗位与地区情况，优先推荐或内推给本地合作企业。

四步陪跑流程：从技术评估到面试上场

1. 技术评估

先了解你的 Java、Spring、数据库和 AI 基础，梳理已有项目和真实经历，再确认目标岗位、目标城市、近期面试安排和每周可投入时间。

这一阶段会明确：

• 哪些内容需要优先补强；
• 哪些内容可以快速检查或跳过；
• 当前距离目标岗位的面试要求还有哪些差距；
• 接下来应该先准备技术、项目还是面试。

2. 岗位能力补强

围绕目标岗位陪跑真正需要讲清楚的内容：

• Java 后端与 Spring；
• 模型调用与 Spring AI；
• RAG 与企业知识库；
• Agent、Tool Calling 与 MCP；
• 多模态应用；
• 权限、异常、稳定性、性能和部署。

陪跑过程中会安排资料学习、问题答疑、练习反馈、路线检查、薄弱项补讲和补讲后的再次检查。

这一阶段的目标是：能先说清技术结论，再解释原理和使用场景；能把技术放进具体项目请求链路；能说明 Java 后端、模型、知识库和工具如何配合；能回答权限、超时、重复请求、模型失败和服务不可用等问题。

3. 项目表达成型

结合目标岗位、工作年限和个人经历匹配多个企业级项目，其中两个作为主讲项目。

重点整理：

• 项目背景和业务目标；
• 系统架构和核心流程；
• Java 后端职责和 AI 接入点；
• 数据、权限、异常和稳定性处理；
• 项目经验的分层表达：项目概述、完整项目展开与技术细节说明；
• 项目技术难点、场景化问题复盘、高频追问和简历项目描述。

这一阶段的目标是：能讲清项目解决了什么业务问题，一次请求经过哪些服务，模型和 Java 后端分别负责什么，以及出现异常后如何处理。

4. 求职冲刺

进入简历、自我介绍、模拟面试、投递和真实面试复盘阶段：

• 一对一定制代写简历；
• 个人自我介绍、项目经历与岗位匹配表达整理；
• 多轮模拟面试，直至符合面试标准；
• 招聘平台资料、岗位筛选和 HR 沟通指导；
• 真实面试逐场复盘；
• 根据反馈继续补强技术和项目表达；
• 根据岗位与地区情况，优先推荐或内推给本地合作企业；
• 收到 Offer 后，协助比较岗位职责、薪资结构、地点和个人发展方向。

项目经验深度梳理与面试表达体系

我们会结合目标岗位、工作年限和个人经历，匹配多个企业级 Java+AI 项目，并确定两个重点展开的主讲项目。项目陪跑不是背诵项目名称或固定话术，而是围绕真实业务场景建立完整、可追问、能落地的项目表达体系：

• 业务背景与项目价值：项目服务什么业务，解决了什么核心问题，最终产生了哪些业务或技术价值；
• 系统架构与核心链路：系统由哪些模块组成，一次请求如何流转，模块之间如何协作；
• 个人职责与负责模块：明确个人负责的功能边界、核心代码、技术贡献和实际参与深度；
• 技术方案与实现细节：说明 Java 后端、AI 能力、数据存储、权限控制和外部服务如何配合；
• 技术难点与方案权衡：结合项目场景梳理性能、稳定性、并发、数据一致性、异常处理等关键问题，以及方案选择的原因；
• 问题排查与结果复盘：还原开发或上线过程中遇到的问题、定位过程、解决方案和最终效果；
• 面试表达与深度追问：根据面试官的提问深度，准备项目概述、完整展开、技术细节和场景化追问等不同层次的回答。

每个项目都会沿着“业务背景 → 项目目标 → 整体架构 → 核心流程 → 负责模块 → 技术实现 → 难点与方案权衡 → 问题排查 → 项目成果 → 面试追问”建立主线，并同步整理自我介绍衔接、简历描述和面试中的多层次表达。项目名称和业务方向会根据目标岗位匹配，具体以陪跑时确认的项目材料为准。

我们提供企业级项目库匹配与真实项目整理服务。项目选择会结合目标岗位、工作年限和个人经历；项目库用于学习和面试表达，简历中的项目会根据真实的企业级项目背景、项目架构、个人职责和参与范围进行优化升级，确保项目内容前后一致、表达专业，并能够经得起面试官的连续追问。

求职服务

• 一对一定制代写简历，并练习自我介绍；
• 多轮模拟面试，覆盖技术问题、项目深挖和综合表达，直至符合面试标准；
• 招聘平台资料、岗位筛选、HR 沟通和薪资表达指导；
• 根据岗位与地区情况，优先推荐或内推给本地合作企业；
• 对真实面试逐场复盘，安排下一轮针对性准备；
• 收到 Offer 后，结合岗位职责、薪资结构、地点和个人目标做比较。

附赠内容

• 附赠：提供常见 AI 八股文面试题及分析。
• 附赠：根据学员需求客制化适配，增加 AI 板块或个人工作内容。

具体提供形式和适配范围，以报名时确认的服务清单为准。

经过陪跑，你能做到

• 能先说清结论，再解释原理、实现流程和适用场景；
• 能把技术放进项目请求链路，说明数据、权限、异常和验证方式；
• 能讲清项目解决的业务问题、系统架构和个人职责；
• 能回答模型调用、RAG、工具执行、Agent、权限、超时和失败恢复等追问；
• 能根据面试场景，清晰完成两个主讲项目的概述、完整展开和技术深挖；
• 能让简历中的项目内容与真实学习、实践和个人掌握范围保持一致；
• 能根据模拟面试反馈继续补强，直到符合面试标准。

学习周期与投入方式

陪跑不是固定课表，而是根据个人基础、学习投入和求职进度推进。常见投入节奏如下：

| 每日投入 | 每周投入 | 参考周期 |
|

计算机与编程入门 → Java 基础 → 后端开发 → 企业级项目 → Java + AI 应用 → 简历优化与面试陪跑

适合哪些人

• 没有编程基础，希望从零开始学习软件开发。
• 非计算机专业，准备转向 Java 后端或 Java + AI 应用开发。
• 学过 Java，但知识零散，还不能独立完成一个功能。
• 看过课程、跟过项目，但遇到报错或需求变化时容易卡住。
• 不清楚数据库、接口、Spring 后端和前端之间如何配合。
• 缺少学习计划、作业反馈和持续跟进，希望有老师带着推进。
• 已有开发基础，想系统补齐后端工程能力、项目实践或 AI 应用能力。

如果你已经具备比较完整的 Java 后端经验，主要目标是面试冲刺，可以了解 Java + AI 训练营。私教带徒更适合希望从基础开始、逐步学习和实践的同学。

这套私教如何学习

学习不是从一开始就讲复杂框架、Agent 或企业级项目，而是按照知识之间的先后关系逐步推进。

每个阶段都会经过：

讲解知识 → 老师示范 → 一起拆解 → 独立练习 → 作业检查 → 错误修改 → 阶段复测

老师会根据练习和阶段检查的情况判断下一步怎么学。基础还不稳，就先补前置知识；某些内容已经掌握，就先验证后进入下一阶段。目标是让你逐步理解代码、独立完成任务，并能说明自己的实现思路。

完整学习路线

先通过这张路线图了解整体安排：从入学评估、Java 基础和后端开发，到 Java + AI 学习、项目实战，再到阶段检查与求职准备。

私教带徒学习路线总览，具体学习起点与推进节奏根据基础评估和阶段检查安排。

第一阶段：计算机与开发环境入门

• 文件、目录、压缩包、软件安装和环境变量；
• 命令行、进程、内存和端口等基础概念；
• 客户端、服务端、浏览器和网络请求；
• IP、域名、DNS、TCP、HTTP 和 HTTPS 入门；
• JDK、IDEA、Git 和 Maven 的安装与使用；
• Linux 常用命令和日志查看入门。

阶段目标：能够配置开发环境、运行简单程序，认识常见开发工具和基本操作，并对环境问题有初步排查思路。

第二阶段：编程思维与 Java 入门

• 变量、数据类型、输入输出和运算符；
• 条件判断、循环、数组和方法；
• 如何拆分需求、整理步骤和绘制简单流程；
• 如何阅读代码和理解程序执行顺序；
• 如何看懂报错信息，使用断点进行调试。

阶段目标：能够根据简单需求编写 Java 程序，解释代码的基本执行过程，并完成基础练习。

第三阶段：Java 核心与面向对象

• 类、对象、封装、继承、多态和接口；
• 构造方法、抽象类以及类之间的关系；
• String、日期时间、BigDecimal 和常用 API；
• List、Set、Map、泛型和集合遍历；
• 异常处理、文件读写、日志和单元测试；
• 线程、同步和线程池基础；
• 常见数据结构、查找、排序和算法入门。

阶段目标：能够完成结构相对清晰的 Java 程序，使用集合处理数据，理解常见异常并进行调试。

第四阶段：数据库与 Web 基础

• MySQL 数据库、表、字段、主键和数据类型；
• 增删改查、分页、排序、聚合和多表关联；
• 索引、事务和锁的基础概念；
• HTTP 请求、响应、状态码和 JSON；
• Cookie、Session 和登录状态入门；
• Java 访问数据库和处理查询结果；
• 接口参数设计、数据校验和基础联调。

阶段目标：能够根据简单业务设计表结构、编写常用 SQL，并理解一个请求如何通过接口读写数据。

第五阶段：Spring Boot 后端开发

• Spring 的 Bean、依赖注入和配置；
• Spring Boot 项目结构、启动和常用配置；
• Controller、Service 和数据访问层的职责；
• MyBatis 或 MyBatis-Plus 的常见用法；
• 统一返回、参数校验和异常处理；
• 登录身份、基础权限和接口文档；
• 接口测试和前后端联调。

阶段目标：能够创建并运行 Spring Boot 项目，完成常见业务接口，并处理参数错误、数据不存在和权限不足等情况。

第六阶段：工程化、测试与部署

• Git 代码提交、分支和历史记录；
• Maven 依赖管理、构建和打包；
• JUnit 和接口测试；
• 日志等级、异常记录和问题定位；
• Linux 文件、进程、端口和服务操作；
• Docker 与 Docker Compose 基础；
• 项目启动、部署和常见运行问题排查。

阶段目标：能够管理代码、运行测试、打包项目，理解基本部署步骤，并通过日志和运行状态排查常见问题。

第七阶段：微服务与中间件

• Redis 缓存与缓存更新；
• 消息队列、确认、重试和幂等；
• Elasticsearch 搜索和索引维护；
• Gateway、服务注册、配置和服务调用；
• 限流、熔断、超时与降级；
• 事务、补偿和数据一致性基础；
• 服务调用失败和消息异常的排查。

阶段目标：能够读懂基础的服务调用链路，说明缓存、消息和搜索的作用，并理解常见失败场景的处理方式。

第八阶段：大模型与 Java AI 应用入门

• 大模型的能力特点和使用边界；
• Prompt、上下文、Token 和多轮会话；
• 使用 Java 调用大模型；
• Spring AI 或 LangChain4j 的基础应用；
• 流式输出和结构化结果；
• 模型调用超时、失败、重试和降级；
• AI 服务与现有业务接口的协作方式。

阶段目标：能够使用 Java 接入模型，理解一次模型请求的基本过程，并处理常见调用异常。

第九阶段：RAG、工具调用与 Agent

• 文档清洗、切分、向量化和知识入库；
• 向量检索、混合检索、引用来源和效果检查；
• 知识权限和数据访问范围控制；
• Tool Calling 的参数校验和业务执行；
• Agent 与固定工作流的区别；
• MCP 的基本概念和使用场景；
• 人工确认、幂等、重试和失败恢复；
• 提示词注入、越权访问等安全问题。

阶段目标：能够解释模型、知识库和 Java 后端如何配合，并完成有权限控制和异常处理的基础 AI 功能。

项目实战：从 Java 后端到 Java + AI 应用

老师会先带你练习 Java、SQL 和接口开发，掌握基础后，再带你做完整的 Java 后端和 AI 应用项目。从看懂需求、设计数据库，到写代码、测试和部署，每一步都有讲解和答疑，遇到问题一起解决。

项目完成后，老师会帮你梳理自己做了什么、用到了哪些技术、解决了什么问题，再一起优化简历、练习项目讲解。后续还包括模拟面试、投递指导和真实面试后的复盘，陪你把找工作的每一步准备好。

训练项目一：企业服务交易与权益履约平台

这是一个围绕企业服务/课程售卖与履约管理的 Java 后端项目，覆盖从用户进入系统、检索服务、创建订单，到支付结果处理、权益开通、退款和权益回收的完整业务链路：

用户认证 → 服务目录与搜索 → 创建订单 → 支付回调 → 权益开通 → 退款审核与权益回收

项目一总体架构：从用户入口、交易履约模块到数据与可靠性底座。

总体图用于认识系统分层，下面的模块图进一步展开支付、消息、退款、搜索和权益这几条关键链路。桌面端可以查看完整细节，窄屏设备可横向查看。

核心模块流程图

支付与订单

支付通知先验签并校验金额、来源和订单状态，再按幂等规则更新支付记录与订单。重复通知不会重复执行业务；校验失败和处理异常会保留记录，便于排查与恢复。项目中的支付为训练环境模拟流程，不连接真实支付渠道。

可靠消息

业务事务先写入本地消息记录，再由投递任务发送消息；消费者记录处理状态，重复投递通过幂等校验避免重复执行，失败消息按策略重试并进入后续排查流程。

退款与权益

退款申请经过资格检查和人工审核后推进退款状态，退款结果再触发权益冻结或回收；异常情况进入补偿和审计链路，避免退款状态与可用权益长期不一致。

搜索一致性

服务数据变更后通过可靠事件更新搜索索引，并提供失败重试与全量重建路径。查询以业务数据为准，索引异常时可以发现差异并修复。

履约补偿

权益围绕待生效、可用、冻结、已使用和已回收等状态受控流转。订单支付和退款事件驱动状态变化，重复事件由幂等规则处理，状态不一致时通过补偿任务恢复。

项目按业务模块逐步开发，主要内容包括：

• 项目与公共能力：Maven 多模块、统一依赖、统一返回、异常处理、分页和请求追踪；
• 网关与认证：Gateway 路由、用户登录、JWT 鉴权和身份传递；
• 服务目录与交易履约：服务/课程管理、订单创建、模拟支付、履约状态和权益开通；
• 缓存与搜索：Redis 热点数据缓存、Elasticsearch 搜索、索引同步与重建；
• 可靠消息：本地消息记录、投递确认、消费幂等、重试和死信处理；
• 交易一致性：支付回调校验、重复通知、超时关单、退款状态和权益回收；
• 运营与恢复：退款审核、操作审计、失败记录、人工恢复和补偿；
• 测试与部署：接口测试、异常场景验证、日志排查、部署和运行说明。

项目重点会结合真实业务状态讲清楚：支付回调重复到达怎么办、消息发送成功但消费失败怎么办、退款成功但权益未回收怎么办、搜索索引和数据库不一致如何发现与修复。项目中的支付为训练环境模拟流程，不连接真实支付渠道。

项目二：康龄智慧养老护理平台

这是面向养老机构日常运营和护理管理的综合业务平台，围绕老人档案、家属会员、房间床位、入住合同、护理计划、健康评估、设备监测、报警处理和预约服务，把 Java 业务流程、Spring AI、Dify 和物联网能力组合到一条可追踪的业务链路中。

核心业务链路：

老人建档 → 健康评估 → 护理分级 → 房间床位 → 入住办理 → 合同管理 → 护理执行 → 设备监测 → 报警处理 → 家属服务与智能问答

项目总体架构：Vue 3 管理端和微信小程序通过 REST、SSE 访问 Spring Boot 后端；后端统一承接业务流程、权限、数据落库和审计；Spring AI、Dify 和华为云 IoTDA 分别承担知识问答、智能体工具调用和设备数据接入。

AI 与知识库

Spring AI 通过 ChatClient 调用大模型，使用 Redis 保存会话记忆，通过 QuestionAnswerAdvisor、TokenTextSplitter 和 RedisVectorStore 完成知识库增强问答，并通过 NursingProjectTool 查询护理项目。知识库链路为文档上传、OSS 保存、PDF 解析、文本切分、向量化和检索生成。

Dify 采用后端代理模式，前端不直接持有 API Key。平台提供流式聊天、会话列表、历史消息、会话删除和预约查询工具，并使用当前登录用户 ID 隔离会话。预约工具通过 getReservationByDay 查询指定日期的记录，同时返回查询日期、参数化 SQL、查询参数和业务结果，便于排查和审计。

物联网与报警

物联网模块基于华为云 IoTDA、Qpid JMS 和 AMQP 接收智能床位及其他设备上报数据。AmqpClient 建立连接并监听断线重连，设备消息通过线程池异步处理，写入设备最新状态、历史数据和报警处理链路。

项目开发内容包括：

• 老人、家属、房间、床位、入住、合同、护理、健康、设备、报警和预约等业务建模；
• Vue 3 Web 管理端和微信小程序端的角色化服务入口；
• Spring Security、JWT、BCrypt、角色权限和菜单权限控制；
• MySQL、MyBatis-Plus、Redis、阿里云 OSS 和 Quartz 等基础能力；
• Spring AI 知识库问答、护理项目工具调用和 SSE 流式响应；
• Dify 会话代理、预约查询工具、会话隔离和 SQL 可追溯；
• IoTDA 设备接入、异步消息处理、设备监测和报警规则；
• 覆盖权限不足、模型超时、无召回、重复请求、设备断线和下游服务失败等场景。

项目重点是由 Java 后端负责身份、权限、状态、数据落库和审计，AI 负责知识检索、业务查询和对话编排，物联网服务负责设备数据接入；涉及业务状态变化的操作仍由后端完成校验和事务处理。

项目学习的完整过程

每个项目都会按以下顺序推进：

| 项目阶段 | 学习与开发内容 | 阶段验收 |
|

这是一个面向研发团队的项目协同与研发管理平台，围绕项目、需求、任务、版本、待办事项和数据分析，帮助团队把需求进入、任务分派、开发执行、版本发布和过程复盘串成完整流程。

项目背景

研发团队在实际协作中通常同时面对项目立项、需求评审、任务拆分、开发执行、版本发布和过程复盘。信息散落在即时通讯、表格和多个系统中时，负责人难以掌握整体进度，需求变更容易遗漏，延期任务也缺少及时提醒。研发管理平台（研云通）以项目和研发流程为主线，把需求、任务、版本、成员、待办和效能数据统一起来，帮助团队形成可追踪、可协同、可复盘的研发管理闭环。

业务概述

平台服务于产品经理、项目经理、研发人员、测试人员和管理者。用户可以创建项目和需求，经过评审后拆分为可执行任务，再分配负责人、设置优先级和截止时间。开发过程中持续更新任务状态，系统根据版本计划和依赖关系生成待办提醒；需求变更、缺陷修复和发布结果统一留痕，最终沉淀为研发效能报表。

主要业务场景包括：

• 项目、需求、任务、缺陷和版本的统一管理；
• 需求评审、任务分派、状态流转和延期升级；
• 个人待办、团队看板、版本燃尽和研发效能统计；
• 成员、角色、组织、标签和项目权限的细粒度控制；
• 发布记录、操作日志、变更记录和历史数据追溯。

技术架构选型

1. 整体架构

采用前后端分离的企业级架构，前端负责项目看板、表单和统计图表，Java 后端按项目、需求、任务、版本和系统管理划分业务模块。核心服务通过统一认证、权限校验、事务控制和审计日志保证数据安全，提醒、统计和索引更新等耗时操作通过消息队列异步处理。

2. 后端技术

• Spring Boot：构建项目、需求、任务和版本管理接口；
• Spring Cloud Alibaba：支持服务注册、配置管理、网关路由和服务治理；
• Spring Security + OAuth2：实现登录认证、角色权限和项目级数据隔离；
• MyBatis / MyBatis-Plus：完成复杂查询、批量更新和数据持久化；
• MySQL：保存项目主数据、任务状态、版本记录和审计信息。

3. 中间件与工程能力

• Redis：缓存项目看板、成员权限和热点统计，配合分布式锁避免重复操作；
• RabbitMQ / RocketMQ：异步发送待办提醒、状态通知和统计任务；
• Elasticsearch：支持需求、任务、缺陷和操作记录的全文检索；
• XXL-JOB：定时生成日报、周报、逾期提醒和效能统计；
• Vue + Element UI：构建项目看板、任务列表和管理后台。

主要业务模块

1. 项目与需求管理

维护项目基本信息、成员、里程碑和需求池，支持需求创建、评审、拆分、优先级调整、关联版本和变更记录。

2. 任务管理

将需求拆分为开发、测试、设计和运维任务，支持负责人分配、工时填写、依赖关系、状态流转、延期原因和批量操作。

3. 版本管理

维护版本计划、发布日期、需求范围和发布状态，关联版本内任务，生成完成率、延期率和燃尽趋势。

4. 待办与提醒

根据任务截止时间、状态变化、审批结果和版本节点生成个人及团队待办，通过站内信、邮件或企业微信进行提醒和升级。

5. 权限与组织管理

按组织、项目、角色和资源控制访问范围，区分项目负责人、产品、研发、测试和只读成员的操作权限。

6. 数据分析与报表

统计需求吞吐量、任务完成率、平均处理时长、延期分布、版本交付情况和成员工作负载，为管理层提供研发效能依据。

7. 日志审计与系统维护

记录登录、数据变更、权限调整和导出行为，提供参数配置、字典管理、健康检查、备份和故障排查能力。

技术要点与应用价值

• 使用状态机和版本号控制需求、任务、发布状态，避免并发更新覆盖；
• 通过幂等键、消息重试和失败补偿保证提醒与统计任务不重复、不丢失；
• 将业务事实、统计口径和权限范围分开设计，确保报表结果可解释；
• 通过统一项目数据模型打通产品、研发、测试和管理者视角，减少重复维护；
• AI 可用于需求摘要、任务拆分建议和周报生成，正式状态变更仍由 Java 事务服务控制。

陪跑价值与学习收获

你会从需求池、任务拆解、版本发布和研发效能分析入手，理解一个研发团队为什么需要一套真正可协同、可追踪的项目管理平台。陪跑过程中，不只是认识模块，还会把项目、需求、任务、成员、版本和待办之间的关系讲清楚，建立一套可以落到代码和面试表达里的业务模型。

• 学会把复杂研发流程拆成领域对象、状态机、权限和提醒规则。
• 掌握项目协同中常见的事务、异步通知、数据统计和操作审计设计。
• 形成一套可用于简历、面试和项目演示的“业务背景—技术方案—难点处理”表达。

你将带走的成果

• 一张能讲清项目全貌的架构图和主流程图。
• 一套围绕需求、任务、版本和待办的模块拆解思路。
• 一份可直接改写到简历和面试自我介绍中的项目亮点清单。

核心业务流程

平台围绕“创建项目与需求 → 拆分任务并分配负责人 → 开发过程更新任务状态 → 需求变更与版本管理 → 自动提醒与异常升级 → 验收发布并归档 → 生成研发效能报表”建立研发协同闭环。

模块流程图

任务管理

公共模块

基础模块

待办事项提醒

数据分析与报表

版本管理

状态自动流转

系统维护与支持

需求管理

项目管理

业务模块

| 模块 | 主要能力 |
|

这是一个面向售后与客服场景的工单中台，解决重复问题多、流转链路长、人工答复不统一、知识更新慢的问题。项目把用户咨询、工单分派、知识检索、坐席答复和结案统计整合起来。

项目背景

客服中心通常同时接入电话、在线聊天、公众号、小程序和邮件等渠道，客户问题、订单信息、知识文档和历史工单分散在不同系统中。坐席需要反复查询资料，复杂问题还要转交技术、仓储或售后部门，容易出现重复回答、分派错误、超时和处理结果无法追踪的问题。云呼智服工单中台把多渠道诉求、知识库、坐席工作台和工单流程统一起来，形成可量化的服务闭环。

业务概述

平台面向客户、客服坐席、班组长、技术支持和售后管理人员。客户可以自助查询常见问题和工单进度，坐席可以查看客户画像、历史订单和推荐知识，复杂问题通过工单自动或手动分派给责任部门。系统持续记录首响时间、处理时长、转派次数、解决率和满意度，为服务质量改进提供依据。

主要业务场景包括：

• 多渠道接入客户咨询并统一生成会话；
• FAQ、产品手册和历史案例检索，辅助坐席快速答复；
• 工单创建、分派、转派、挂起、升级、结案和评价；
• 超时提醒、SLA 监控、回访任务和服务质量分析；
• 优质答复审核后回流知识库，持续优化服务内容。

技术架构选型

1. 整体架构

采用微服务和前后端分离架构，渠道接入、会话管理、工单中心、知识检索、通知和报表按业务域拆分。统一网关负责鉴权与路由，工单状态和 SLA 由后端服务控制，AI 作为坐席辅助层提供意图识别、知识检索和答复草稿。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建工单、客户、知识和统计服务；
• Spring Security + OAuth2：实现坐席、主管、技术和客户的角色权限控制；
• MySQL：保存客户、会话、工单、审批和评价数据；
• MyBatis：支持工单列表、多条件筛选、批量处理和复杂报表查询。

3. 中间件与 AI 能力

• Redis：缓存会话上下文、客户画像和热门 FAQ，配合分布式锁实现幂等；
• RabbitMQ / RocketMQ：异步发送工单通知、超时升级和知识更新消息；
• Elasticsearch + 向量库：支持 FAQ、手册和历史案例的关键词与语义检索；
• XXL-JOB：执行 SLA 扫描、回访任务、日报统计和失败补偿；
• Spring AI：实现 RAG 问答、意图分类、摘要生成和工具查询。

主要业务模块

1. 多渠道接入与会话中心

统一接入 Web、App、公众号、电话转文本等渠道，生成会话、客户身份和上下文，保证重复消息可识别、可合并。

2. 坐席工作台

集中展示客户画像、订单信息、历史工单、推荐知识和处理动作，AI 生成可编辑的答复草稿，坐席确认后再发送。

3. 工单中心

支持工单创建、分类、优先级、责任人、转派、挂起、升级、结案和评价，使用状态机确保流程状态合法。

4. 自助服务门户

客户可以查询 FAQ、提交工单、查看处理进度、补充材料和评价结果，降低重复咨询压力。

5. 审批与协同流转

通过流程节点、会签、加签和退回机制处理退款、技术升级、补偿等复杂业务，保留每一步审批记录。

6. 搜索、统计与质检

支持工单全文检索、服务时长统计、一次解决率、满意度、投诉趋势和坐席工作量分析。

7. 权限、审计与运维

控制客户和工单数据的可见范围，记录登录、查看、导出和处理行为，配合监控、任务调度和告警完成日常运维。

技术要点与应用价值

• 使用幂等键、状态版本号、消息重试和死信队列保证工单不丢不重；
• 使用 SLA 时间窗口和升级规则自动识别超时工单，减少人工盯办；
• RAG 返回知识来源、版本和更新时间，低置信度时转人工，避免模型直接编造答案；
• 结案后的优质答复进入审核队列，审核通过后再切分、向量化和发布；
• 通过工单数据和服务指标帮助企业定位高频问题、流程瓶颈和培训重点。

陪跑价值与学习收获

客服工单是最容易让人感受到业务复杂度的场景之一：同一个问题可能从多个渠道进入，经过机器人、坐席、技术、仓储和售后多次流转，最后还要接受 SLA 和满意度检验。你会沿着一条真实的服务链路，把 AI 问答、知识库检索和 Java 工单流程连接起来，看到一个客服系统如何从“能回答”升级到“能闭环”。

• 学会设计多渠道会话、工单状态机、超时升级和幂等控制。
• 掌握 RAG 知识库、坐席辅助、消息重试和服务质量分析的落地方式。
• 能清楚说明 AI 负责什么、Java 业务服务负责什么，以及人工确认如何介入。

你将带走的成果

• 一套可演示的咨询受理、工单处理、结案评价和知识回流链路。
• 一份客服中台的技术难点与性能优化清单。
• 一套适合 Java+AI 岗位的项目介绍和面试追问准备。

业务背景与建设目标

客服中心往往同时承接电话、在线聊天、公众号和小程序等多个入口。相同问题反复出现，坐席需要在多个系统之间查询客户、订单和历史工单；当问题需要转交技术、仓储或售后部门时，责任边界和处理时限也容易失控。云呼智服工单中台将多渠道咨询统一接入，把知识库、坐席工作台、工单中心和服务质量分析放到同一条业务链路中。

平台围绕“咨询受理、问题识别、知识检索、坐席确认、工单分派、超时提醒、结案评价、知识回流”建立服务闭环。AI 负责理解用户意图、提取问题要素、检索 FAQ 和历史案例、生成答复草稿；Java 服务负责客户身份、工单状态、责任人、SLA、事务和审计，确保辅助建议不会绕过正式工单流程。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个面向园区运营方、物业团队、安保人员、企业员工和访客的综合运营管理平台。平台把安防监控、物业服务、门禁控制、车辆管理、智能设备接入、数据报表和运维审计统一到同一套业务底座中，让园区从“多个系统各自运行”升级为“统一入口、统一事件、统一协同、统一分析”。

项目的核心价值不是单独增加一个看板，而是把用户请求、设备事件、业务工单和运营数据串成可追踪的闭环。AI 能力作为辅助层，用于知识检索、事件摘要、异常归纳和运营问答；正式的权限校验、状态流转、数据写入和审计留痕仍由 Java 业务服务负责。

项目背景

现代园区同时包含园区运营方、物业、安保、企业员工、访客和大量智能设备。视频监控、门禁、停车、物业报修、设备告警和能耗数据如果分散在多个系统中，管理人员很难统一判断事件影响，也无法快速联动责任部门。智慧园区综合运营管理平台以“统一接入、统一事件、统一协同、统一分析”为目标，支撑园区安全、服务和运营管理。

业务概述

平台围绕园区内的人、车、物、事和环境建立统一数据底座。用户或设备产生事件后，系统完成身份校验、规则判断、责任分派、消息通知、现场处理、复核验收和结果归档。物业人员处理报修和服务工单，安保人员处理门禁与告警，运营人员通过看板查看园区运行指标，管理层根据趋势分析进行资源调度。

主要业务场景包括：

• 视频、门禁、停车和 IoT 设备统一接入；
• 访客预约、人员通行、车辆识别和异常告警；
• 物业报修、巡检、派单、验收和满意度评价；
• 能耗、设备、安防和服务工单的多维度统计；
• 事件联动、消息通知、操作审计和运维监控。

技术架构选型

1. 整体架构

采用微服务、前后端分离和事件驱动架构。统一网关承接管理端、企业端、访客端和设备端请求，安防、物业、门禁、车辆、设备和报表按业务域拆分。设备事件通过消息队列进入事件中心，再由规则引擎匹配处理流程，保证实时接入与业务处理解耦。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建园区业务微服务；
• Spring Security + OAuth2：实现园区、企业、物业、安保和访客的分级授权；
• MySQL + MyBatis：保存人员、组织、设备、工单、通行和事件数据；
• Elasticsearch：支持事件、工单、访客和设备日志的快速检索。

3. 中间件与数据能力

• Redis：缓存设备状态、门禁权限、停车位和热点看板数据；
• RabbitMQ / RocketMQ：异步处理设备事件、告警通知、工单和统计任务；
• MQTT / HTTP 适配器：接入门禁、摄像头、停车和传感器等设备；
• XXL-JOB：执行巡检计划、数据汇总、告警升级和报表生成；
• Vue + Element UI + ECharts：建设运营工作台和可视化驾驶舱。

主要业务模块

1. 安防监控

接入视频和安防事件，支持实时查看、异常识别、分级告警、责任人通知和处置结果复核。

2. 物业管理

维护楼宇、房间、设备和服务目录，支持报修、巡检、派单、处理、验收和评价闭环。

3. 门禁与访客管理

配置人员、企业、访客和临时通行权限，记录进出日志，对异常时段、异常区域和重复通行进行告警。

4. 车辆与停车管理

接入车牌识别和停车场数据，管理车辆档案、停车位、预约、进出记录和停车流量。

5. 智能设备与数据处理

统一维护设备台账、协议、状态和采集数据，对离线、故障和异常指标进行清洗、入库和通知。

6. 事件中心与消息协同

把设备告警、人工上报和物业请求统一转换为事件，按照规则分派给责任部门，支持升级、转派和多渠道通知。

7. 报表与可视分析

从安防、物业、设备、能耗和车辆维度生成运营报表、趋势图、排行和领导驾驶舱。

8. 权限、审计与运维

实现多租户、组织、角色和资源权限控制，记录敏感操作和数据导出，提供服务健康检查、监控、备份和故障处理。

技术要点与应用价值

• 设备事件和人工工单统一建模，避免设备告警与人工处理各自形成孤岛；
• 通过消息队列、事件去重和失败重试支撑大批量设备接入；
• 对门禁、车辆和物业数据实行分域授权，确保不同企业和管理角色只能访问必要数据；
• AI 可用于园区制度问答、工单摘要、异常归纳和运营指标解释，正式控制动作仍由后端服务执行；
• 平台适用于产业园、写字楼、住宅社区、教育园区等多种园区场景。

陪跑价值与学习收获

智慧园区把安防、物业、门禁、车辆和 IoT 设备放在同一张业务地图上，天然包含多角色协作、实时事件处理和复杂权限控制。你会从园区运营方、物业人员、安保人员、企业员工和访客的不同视角理解需求，再把设备事件、人工工单、服务请求和运营报表串成完整闭环，适合用来建立企业级项目的整体视野。

• 学会拆分园区运营中的业务域、设备域、事件域和数据分析域。
• 掌握 IoT 数据接入、告警联动、工单流转、权限隔离和运营看板的设计方法。
• 理解 AI 在制度问答、事件摘要和异常归纳中的辅助边界，避免把模型输出当成业务事实。

你将带走的成果

• 一套能够覆盖“感知—判断—派单—处置—复盘”的园区项目讲解框架。
• 一份微服务、消息队列、缓存、审计和运维监控的技术落点清单。
• 一套适合中高级 Java 面试的复杂场景追问答案。

项目全景

模块流程图

安防监控

物业管理

门禁控制

车辆管理

用户认证与权限管理

智能设备与数据处理

数据报表与可视分析

日志管理与审计

消息通知与任务调度

系统维护与运维管理

总体技术架构

分层职责

| 层次 | 主要职责 | 技术 / 组件 |
|

这是一个面向学生和家长的升学咨询平台，解决“信息多但难理解、政策多但解释难、院校多但选择难”的问题。系统通过数据检索、规则解释和报告生成，为用户提供更易理解的志愿建议。

项目背景

学生和家长在升学决策中需要同时理解成绩、位次、选科、批次、院校、专业、招生计划、政策和地域偏好。信息来源多、政策更新快、专业限制复杂，单纯依赖静态列表或泛化聊天回答，很难给出可解释、可复核的建议。志愿魔方 AI 升学咨询平台将学生档案、院校专业数据、政策知识和咨询记录统一管理，为学生、家长和顾问提供辅助决策能力。

业务概述

用户登录后建立学生档案，录入成绩、位次、选科、地区、兴趣和目标专业。系统根据硬性条件筛选院校和专业，再结合冲稳保策略、历史数据和政策要求生成候选方案。AI 负责政策问答、方案解释、风险提示和报告整理，顾问可以复核、修改并向学生发送最终方案。

主要业务场景包括：

• 学生信息、成绩、位次和选科档案管理；
• 院校、专业、招生计划、录取数据和政策版本维护；
• 志愿筛选、冲稳保分层、方案对比和风险提示；
• 政策原文检索、招生章程问答和时间节点提醒；
• 咨询报告生成、顾问复核、家校沟通和历史记录追踪。

技术架构选型

1. 整体架构

采用前后端分离和模块化服务架构，学生端、家长端和顾问端共用统一业务服务。规则服务负责成绩、选科和批次等确定性条件过滤，数据同步服务负责院校与政策版本更新，AI 服务只对检索结果进行解释和生成，不直接修改学生档案或提交志愿。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建用户、档案、院校、推荐和报告服务；
• Spring Security + OAuth2：保护学生敏感数据和顾问工作台；
• MySQL + MyBatis：保存学生档案、院校专业、政策、方案和咨询记录；
• Elasticsearch：支持院校、专业、政策和历史案例的多条件检索。

3. 中间件与 AI 能力

• Redis：缓存热门院校、筛选条件、会话和临时方案；
• MQ：异步执行数据同步、报告生成、通知和失败重试；
• 向量库 + RAG：检索招生章程、政策原文和专业说明并返回引用；
• XXL-JOB：定时更新政策、录取数据、风险规则和统计报表；
• Vue + ECharts：展示方案对比、分数趋势和成长报告。

主要业务模块

1. 学生档案管理

维护学生成绩、位次、选科、地区、兴趣、目标专业和家庭偏好，支持档案版本和隐私权限。

2. 院校专业数据中心

管理院校、专业、招生计划、选科要求、学费、就业方向和历史录取数据，并保留来源与生效版本。

3. 志愿筛选与方案生成

按照硬性条件过滤候选项，再按冲、稳、保层次组合方案，展示匹配理由、限制条件和风险项。

4. 政策知识库与 AI 问答

对政策、招生章程和专项计划进行切分、向量化和版本管理，回答时展示来源、发布时间和适用范围。

5. 成长与咨询报告

生成方案摘要、院校对比、专业解释、风险清单和待确认问题，顾问可在线修改并留下复核记录。

6. 会员、消息与系统管理

管理学生、家长、顾问和机构角色，支持报告通知、时间节点提醒、数据导出和审计查询。

技术要点与应用价值

• 所有推荐结果关联成绩区间、选科要求、政策依据和数据版本，做到可解释；
• 对政策过期、计划变更、专业限制和材料要求单独提示风险；
• 通过异步任务生成长报告，避免用户长时间等待；
• 学生成绩、联系方式和咨询记录按机构、顾问和学生进行数据隔离；
• AI 只提供辅助方案，最终选择和正式提交必须由学生、家长或顾问确认。

陪跑价值与学习收获

升学咨询看似是推荐页面，背后却包含成绩、位次、选科、批次、招生计划、政策版本和风险提示等大量数据关系。你会把规则筛选、政策检索、推荐解释和报告生成组合成一条可信的咨询链路，理解 AI 应用如何在敏感决策场景中做到有依据、可复核、能交给人工确认。

• 学会处理时效数据、规则版本、推荐条件和风险提示。
• 掌握 RAG 政策问答、带引用的推荐解释和异步报告生成。
• 建立“AI 辅助建议 + Java 规则校验 + 人工最终确认”的安全边界。

你将带走的成果

• 一套从学生画像到方案对比、风险提示和报告交付的业务流程。
• 一份可用于面试的推荐系统、知识库和权限设计亮点。
• 一套能体现 Java 后端与 AI 应用结合能力的项目表达。

业务背景与建设目标

升学咨询同时涉及成绩、选科、批次、院校、专业、招生章程、地域偏好和职业方向等多类信息。数据来源多、政策更新快，用户又希望看到清晰的推荐依据和风险提示，单纯依靠静态院校列表或泛化聊天回答很难形成可靠的咨询体验。

志愿魔方 AI 升学咨询平台将学生档案、院校专业数据、招生政策、历史录取信息和咨询记录统一管理，形成“条件采集、候选筛选、规则解释、风险提示、方案对比、报告生成、人工复核”的服务链路。平台输出的是带依据的辅助方案，最终选择仍由学生、家长或专业顾问确认，适合展示数据服务、规则引擎和生成式 AI 的组合应用。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个面向园区运营的综合服务平台，围绕企业入驻、空间服务、设备报修、活动通知、政策解读和服务工单展开。AI 的作用是帮助用户更快找到服务入口，并减少人工咨询负担。

项目背景

运营服务平台面向金融或大型企业的运营团队，处理账单、额度、风险、客户注销和结果推送等高频业务。上游系统提供的数据格式不一，运营人员需要经过校验、审批、重复单检测和批量处理后，再将结果同步给下游系统。如果缺少统一的平台，业务容易依赖人工表格，处理过程难追踪，异常也难以及时发现。

业务概述

平台接收账单、额度申请、风险客户和注销信息等上游数据，完成文件解析、客户信息校验、业务规则匹配、审批流转、结果更新和下游推送。运营人员在统一工作台处理任务，管理者查看业务量、处理时长、异常率和报表结果，系统对关键操作进行权限控制和审计留痕。

主要业务场景包括：

• 大批量账单导入、解析、校验、对账和差错处理；
• 临时或固定额度申请、资质校验、审批和结果同步；
• 风险客户提报、风险报表和跨模块客户信息共享；
• 客户注销挽留策略、跟进记录和结果分析；
• 批量报表、下游推送、任务调度和异常重试。

技术架构选型

1. 整体架构

采用微服务与分布式模块化架构，按账务、额度、风险、挽留、系统管理和公共能力拆分服务。服务之间通过 OpenFeign 同步调用，通过 RabbitMQ 异步传递账单结果、审批通知和报表任务，网关统一处理认证、路由和流量控制。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：承载业务服务和统一接口；
• Nacos：服务注册、配置管理和动态参数；
• MyBatis-Plus：实现批量入库、条件查询和分页处理；
• MySQL：保存账单、客户、额度、风险和审批数据；
• EasyExcel：流式解析大批量账单，降低内存占用。

3. 中间件与工程能力

• Redis：缓存客户、额度和风险热点数据，使用分布式锁防止重复审批；
• RabbitMQ：异步处理结果推送、报表生成和通知消息；
• Elasticsearch：保存历史账单，支持按卡号、币种和时间快速检索；
• Sentinel：进行限流、熔断和降级；
• Seata：保障跨服务业务的一致性；
• XXL-JOB + Jenkins：完成对账、统计、推送和自动化部署。

主要业务模块

1. 账务服务

接收并解析账单文件，执行字段校验、客户匹配、调账审批、余额更新、差错处理和历史查询。

2. 额度调整

接收微信端和后台申请，进行灰名单、征信和客户资质校验，完成重复单检测、审批、额度更新和结果通知。

3. 风险提报

管理风险客户、风险类型、处理状态和关联额度信息，生成风险清单和管理报表。

4. 注销挽留

根据客户额度、风险和历史行为生成挽留任务，记录联系过程、策略执行和最终注销结果。

5. 审批、调度与报表

统一管理流程节点、审批实例、任务权限和版本，异步生成大数据量报表并推送给相关人员。

6. 系统管理与审计

提供用户、角色、菜单、参数、日志和任务权限管理，记录数据导入、审批、推送和导出行为。

技术要点与应用价值

• 使用 EasyExcel 监听器和批量入库支持大文件处理，避免一次性加载造成内存溢出；
• 使用流程定义、实例、节点和版本模型支撑不同业务的可配置审批；
• Redis 分布式锁与数据库唯一索引共同防止重复审批和重复推送；
• 通过 Sentinel、Seata、消息重试和补偿任务提升分布式系统稳定性；
• 报表、历史账单和下游推送异步化，降低前台等待时间，提升运营处理效率。

陪跑价值与学习收获

园区运营平台连接企业、物业、运营人员和设备服务商，业务往往不是一个页面就能完成，而是由服务目录、资源预约、设备报修、审批、通知和运营分析共同组成。你会沿着“服务发起—智能分流—工单协同—结果评价—运营复盘”的路径，理解服务中台如何支撑园区持续运营。

• 学会把企业服务、空间资源、设备状态和工单流程统一建模。
• 掌握多角色权限、配置化服务目录、设备告警联动和异步通知。
• 理解 RAG、Tool Calling 在查询、摘要和服务建议中的可控用法。

你将带走的成果

• 一套园区服务中台的业务地图、模块边界和接口拆分思路。
• 一份围绕状态机、SLA、幂等、消息重试和审计的难点清单。
• 一套适合简历、作品集和面试演示的项目亮点。

业务背景与建设目标

现代园区往往同时服务园区运营方、物业、企业员工、访客和设备运维人员。企业入驻、会议室预约、政策咨询、空间报修、活动报名和设备巡检分散在不同群组或系统中，运营人员需要重复回答问题、手工派单并追踪处理结果，服务质量很难稳定复制。

园区智枢智能运营服务平台把企业服务目录、空间资源、设备状态、服务工单、通知活动和园区制度统一到一个运营中台。平台以“统一入口、智能分流、工单协同、过程留痕、运营分析”为主线，AI 负责知识问答、意图分类、工单摘要和服务建议，正式的资源占用、费用、权限和工单写操作由 Java 服务完成。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个围绕快递异常治理的业务平台，核心处理延误、丢件、破损、错投、投诉等问题。AI 负责辅助识别异常类型、查找历史处置方式和给出建议，Java 后端负责正式流转和闭环。

项目背景

城市管理部门每天会接收到大量道路、环境、设施、井盖、照明和公共安全事件。传统模式依赖电话、表格和人工派单，容易出现事件分类不准、责任部门不清、处理进度不可见和结果无法复盘的问题。智慧城市管理平台通过统一事件中心、巡查管理、自动派遣和设备接入，把城市治理从被动处理升级为全过程协同。

业务概述

平台服务于城市管理中心、街道部门、巡查人员、处置单位和管理者。事件可由市民、热线、移动端、摄像头和传感器上报，系统完成分类定级、规则匹配、自动派遣、现场处理、复核验收和归档统计。巡查和专项普查任务与事件中心联动，管理者通过驾驶舱查看区域、类型、时效和部门绩效。

主要业务场景包括：

• 多渠道城市事件上报、分类、定级和定位；
• 巡查计划、路线、任务执行和异常反馈；
• 井盖、路灯、摄像头和环境传感器等设备接入；
• 规则派遣、跨部门协同、现场处置和复核验收；
• 城市设施、环境、安全和治理指标的统计分析。

技术架构选型

1. 整体架构

采用微服务、事件驱动和前后端分离架构，统一网关接入管理端、移动巡查端、公众上报端和 IoT 设备。事件中心负责接收和标准化数据，规则服务负责分类和派遣，工单服务负责状态流转，分析服务负责指标汇总和可视化。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建事件、巡查、派遣和治理服务；
• Spring Security：统一认证和部门、区域、角色权限控制；
• MySQL + MyBatis：保存事件、任务、设施、巡查和处理记录；
• Elasticsearch：支持城市事件、地址、设施和历史案例的全文检索。

3. 中间件与数据能力

• Redis：缓存区域、设施、派遣规则和热点统计；
• MQ：解耦事件接入、规则计算、通知、索引和报表任务；
• IoT 接入层：处理设备心跳、状态、告警和采集数据；
• XXL-JOB：执行巡查计划、超时扫描、统计和数据同步；
• Vue + ECharts：建设事件地图、部门看板和领导驾驶舱。

主要业务模块

1. 事件上报与受理

接收公众、热线、移动端、巡查和设备事件，统一生成事件编号，记录位置、图片、类型、优先级和来源。

2. 自动派遣与工作流

根据事件类型、区域、责任部门、人员负载和 SLA 自动派遣，支持转派、退回、协同、升级和流程回溯。

3. 巡查与专项普查

制定巡查路线、计划和周期任务，记录现场签到、问题发现、照片和处理反馈，形成普查报告。

4. 城市治理与设施台账

管理道路、井盖、路灯、公共设施和环境指标，关联事件、维修记录和设备状态。

5. IoT 数据采集

接入摄像头、传感器和智能设备，进行数据清洗、状态监控、离线检测和异常告警。

6. 协作、消息与统计

为部门、街道和处置单位提供协作消息、任务提醒、事件查询、趋势分析和绩效报表。

7. 权限、审计与运维

按区域、部门和角色隔离数据，记录事件查看、派遣、结案和导出行为，提供监控、备份和故障处理能力。

技术要点与应用价值

• 通过规则引擎把事件类型、区域和部门职责转化为可配置的派遣规则；
• 通过事件状态机和 SLA 计时保证从上报到验收的过程透明；
• 通过 IoT 设备告警与人工工单联动，形成感知、派遣、处理和复盘闭环；
• 通过 Elasticsearch 和统计聚合支持海量历史事件快速查询；
• 多部门协同、权限隔离和完整审计满足城市治理的数据安全要求。

陪跑价值与学习收获

快递异常治理不是简单地登记投诉，而是要把异常识别、责任判断、任务派遣、协同处理、客户沟通和结果复盘连成闭环。你会从一条异常件开始，逐步理解平台如何面对多来源数据、跨部门协同和高频状态变化，并把治理结果沉淀为可复用的规则和案例。

• 学会设计异常事件模型、责任链路、工单状态和自动派遣规则。
• 掌握消息驱动、批量数据处理、历史案例检索和多维度统计分析。
• 形成对“识别准确、处理及时、过程可追溯、结果可复盘”的系统化理解。

你将带走的成果

• 一套从异常上报到结案评价的完整业务讲解路径。
• 一份包含性能、可靠性、权限和数据治理的技术方案。
• 一套能够体现真实企业协作经验的面试表达素材。

业务背景与建设目标

快递业务链路长、参与方多，异常可能发生在揽收、分拨、运输、派送和签收任一环节。延误、破损、丢件、错投和客户投诉通常需要关联运单轨迹、网点信息、客服记录和历史赔付规则。如果只靠人工逐单查询，处理时间长，责任判断和服务口径也容易不一致。

驿链智治快递异常治理平台围绕“异常发现、证据汇聚、责任研判、协同处置、客户反馈、复盘分析”建设统一工作台。平台将物流轨迹、异常规则、投诉工单和历史案例串联起来，AI 用于异常分类、轨迹摘要、相似案例检索和回复草稿，Java 后端负责责任流转、赔付审批、时限控制和最终结果落库。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个信贷尽调与审批辅助平台，解决资料多、尽调慢、审批信息分散、风险判断依赖经验的问题。AI 用于辅助摘要、检索和风险提示，但最终审批必须由人确认。

项目背景

银行和金融机构的信贷业务涉及客户申请、材料采集、尽职调查、授信审批、放款和贷后跟踪。传统流程依赖人工收集和阅读大量材料，信息分散在移动端、审批系统和附件中，容易出现资料缺失、重复录入、风险提示不及时和审批过程难追溯等问题。融策信贷尽调与审批辅助平台以移动化、流程化和可审计为目标，提高客户经理和审批人员的处理效率。

业务概述

客户经理在移动端登录后创建客户和贷款申请，上传身份证明、经营资料、征信和担保材料。系统根据产品规则执行完整性校验和客户调查任务，审批人员查看尽调报告、风险指标和历史记录后进行多级审批。放款后同步贷款状态、还款信息和贷后任务，所有关键操作都保留证据链。

主要业务场景包括：

• 客户建档、贷款申请、材料上传和补件；
• 客户调查、访谈记录、经营核验和尽调报告；
• 授信额度、利率、期限和风险规则审批；
• 放款前校验、放款审批、资金发放和状态同步；
• 贷后跟踪、异常提醒、合规审计和历史查询。

技术架构选型

1. 整体架构

采用移动端、管理端和后端服务分离的微服务架构。申请、材料、尽调、授信、放款和贷后按业务域拆分，统一认证服务负责身份和权限，流程服务负责审批节点和状态流转，消息服务负责通知、同步和任务调度。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建信贷业务微服务；
• Spring Security + OAuth2：实现客户经理、审批员、复核员和管理员权限控制；
• MySQL / Oracle：保存客户、申请、材料索引、审批和还款数据；
• MyBatis：支持复杂查询、审批列表和批量同步。

3. 中间件与 AI 能力

• Redis：缓存客户摘要、风险规则和审批任务，配合锁保证幂等；
• MQ：异步处理材料解析、征信同步、审批通知和贷后任务；
• 对象存储：保存材料原文件和版本信息；
• OCR / RAG：提取材料字段、检索制度和生成尽调摘要；
• XXL-JOB：执行征信同步、逾期扫描、报表和补偿任务。

主要业务模块

1. 客户与信贷申请

维护客户、联系人、产品、申请金额、期限和用途，校验重复申请、黑名单和基础准入条件。

2. 材料中心

支持材料分类、上传、版本、有效期、缺失检查、OCR 提取和人工修订，记录每次查看和下载行为。

3. 贷款调查

生成调查任务和核查清单，记录访谈、经营场所、财务信息、担保情况和尽调结论。

4. 授信审批

支持多级审批、会签、退回、补件、额度调整和风险规则命中，审批意见与依据完整留痕。

5. 放款与贷后

执行放款前校验、资金发放、状态同步、还款跟踪和贷后检查，异常情况进入人工处理队列。

6. 权限、通知与审计

按机构、岗位和客户范围控制访问，发送审批、补件和异常通知，记录敏感材料查看和审批操作。

技术要点与应用价值

• 材料、规则、审批意见和额度结果形成完整证据链，支持事后复核；
• 通过版本号、幂等键和事务控制解决补件、退回、重复提交和并发审批问题；
• AI 只提供材料摘要、条款检索和疑点提示，额度、利率、审批和放款必须人工确认；
• 通过异步解析和消息重试提升大批量材料处理能力；
• 通过脱敏、数据隔离、操作审计和导出控制满足金融合规要求。

陪跑价值与学习收获

信贷尽调和审批是最能体现企业级系统严谨性的场景之一。资料接收、OCR 解析、风险核验、补件、会签、审批和贷后跟踪每一步都要求有依据、有权限、有留痕。你会在这个项目中理解 AI 如何帮助处理材料和信息，而真正的额度、利率、审批和放款动作如何由 Java 服务和人工确认共同守住边界。

• 学会设计材料中心、风险规则、审批状态机、版本控制和审计模型。
• 掌握文档解析、RAG 检索、风险摘要、异步任务和失败补偿。
• 能够回答金融项目最关心的数据安全、合规、幂等和人工兜底问题。

你将带走的成果

• 一套可讲清“资料—尽调—审批—决策—贷后”的金融业务流程。
• 一份围绕合规、安全和可靠性的高级项目亮点清单。
• 一套适合中高级 Java+AI 岗位的面试深挖素材。

业务背景与建设目标

信贷业务需要同时核验客户基本信息、经营状况、财务资料、征信记录、抵押担保和历史往来。传统尽调过程依赖人工阅读大量材料，审批意见分散在表格、邮件和系统备注中，容易出现资料遗漏、口径不一致和风险提示不及时的问题。

融策信贷尽调与审批辅助平台以客户、授信申请、材料、尽调任务、风险规则和审批节点为核心对象，建立从资料接收、OCR / 文档解析、风险核验、尽调报告、多人会签、审批决策到贷后跟踪的全流程。AI 只提供材料摘要、条款检索、疑点提示和报告草稿，任何额度、利率、审批和放款动作都必须在权限和人工确认边界内完成。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个新能源充电运维平台，处理设备状态监控、故障码识别、异常工单、远程运维和监管上报等问题。AI 的作用是帮助运维人员更快定位问题和检索处理方案。

项目背景

新能源汽车充电网络同时连接用户、充电桩、运营商、支付渠道和监管平台。用户需要快速找到可用充电桩并完成扫码充电，运营人员需要掌握设备状态、订单、故障和收益，设备厂商还需要远程升级和维护。桩云智维新能源充电运维平台将用户服务、订单交易、设备运维和监管数据统一起来，支撑充电业务稳定运行。

业务概述

用户通过 PC、小程序或 App 定位附近充电站，查看桩状态、预约并扫码启动充电。平台校验用户、设备和占用状态后创建订单，持续接收充电进度和电量数据，结束充电后完成计费、支付和结算。设备异常自动生成告警和工单，运营人员可以远程查看、重启或升级设备，监管和第三方系统通过接口同步数据。

主要业务场景包括：

• 充电站、充电桩、枪口和实时状态管理；
• 用户定位、扫码、预约、启动、暂停和结束充电；
• 订单计费、钱包、优惠、支付回调和对账；
• 设备故障、远程控制、FOTA 升级和运维工单；
• 运营报表、政府监管、第三方支付和数据分析。

技术架构选型

1. 整体架构

采用用户端、运营端和设备端分离的微服务架构。用户服务、设备服务、订单服务、支付服务、运维服务和数据服务通过网关统一接入，设备侧通过 MQTT 或厂商协议接入，订单与支付使用消息队列解耦，确保设备状态和交易链路互不阻塞。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建充电、订单、支付和运维服务；
• Spring Security + OAuth2：实现用户、运营商、维修人员和管理员权限控制；
• MySQL：保存用户、桩、订单、支付、工单和配置数据；
• MyBatis：支持订单查询、计费规则和运营统计。

3. 中间件与设备能力

• Redis：缓存桩状态、站点信息、预约占用和用户会话；
• MQTT / MQ：传递设备心跳、充电进度、告警和控制指令；
• 分布式锁：防止重复预约、重复启动和重复支付回调；
• XXL-JOB：执行对账、订单关单、设备巡检和升级任务；
• Vue / 小程序 / App：提供用户充电和运营管理界面。

主要业务模块

1. 充电桩服务

维护站点、桩、枪口、协议和实时状态，支持定位、可用性查询、占用和设备心跳监控。

2. 订单管理

处理预约、启动、充电中、结束、异常和关闭等状态，关联电量、时长、服务费和优惠规则。

3. 钱包与支付

支持余额、充值、支付、退款、优惠券、支付回调、对账和异常补偿，保证金额和订单状态一致。

4. FOTA 与运维工单

管理设备版本、升级批次、灰度策略、升级结果和失败回滚，设备故障自动生成运维工单。

5. 会员、资源与权限

维护会员等级、车辆、发票、站点资源、运营商和维修人员权限。

6. 监管、集成与分析

对接政府监管、支付、地图和第三方平台，统计充电量、利用率、故障率、收入和设备健康度。

技术要点与应用价值

• 通过订单状态机、支付幂等和消息补偿保证充电交易不重复、不丢失；
• 设备状态采用心跳、事件和定时校验多种方式确认，避免页面显示过期状态；
• 远程控制和 FOTA 升级必须经过设备校验、权限校验和操作回执；
• 通过 Redis、MQ 和异步报表支撑高峰期用户访问和海量设备数据；
• 用户服务、设备运维和监管数据统一沉淀，帮助运营商优化站点和设备资源。

陪跑价值与学习收获

充电运维平台同时面对设备在线状态、用户订单、钱包支付、故障告警和远程升级，既有互联网交易链路，也有物联网设备控制。你会把设备数据和用户服务放在同一个系统里理解，掌握如何在高并发、弱网络和高风险操作场景下保证业务稳定与操作安全。

• 学会设计充电桩接入、订单状态、支付幂等、告警工单和远程操作审批。
• 掌握 MQTT / 消息队列、Redis、分布式锁、任务调度和设备状态同步。
• 理解远程升级、异常重试和人工确认在设备类系统中的必要性。

你将带走的成果

• 一套从用户找桩、充电、结算到故障处理的完整项目故事线。
• 一份互联网交易与 IoT 运维结合场景的技术难点清单。
• 一套可以直接用于简历和面试的性能、安全与可靠性表达。

业务背景与建设目标

充电网络由充电桩、充电站、运营平台、支付系统和监管接口共同组成。设备离线、通信异常、过温、充电中断和计费异常等问题既影响用户体验，也会带来运维成本和安全风险。运维人员需要同时查看实时状态、历史故障、固件版本、工单记录和现场处理手册。

桩云智维新能源充电运维平台将站点、设备、枪口、订单、告警、工单和远程操作统一管理，形成“设备接入、状态监测、异常识别、工单派发、远程诊断、现场处理、结果复盘”的运维闭环。AI 用于故障码解释、告警聚合、处理手册检索和工单摘要；远程重启、参数变更、FOTA 和停机等高风险动作由 Java 服务执行权限校验、二次确认和审计。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个 CRM 智能销售助手，围绕客户跟进、商机推进、销售话术、产品介绍和常见异议处理展开。AI 不是单独聊天，而是嵌入销售工作流，帮助销售更快做判断和记录。

项目背景

销售团队的客户资料、线索来源、沟通记录、报价方案和回款信息经常分散在 CRM、表格和即时通讯中。销售需要持续判断客户阶段和下一步动作，管理者需要了解商机质量、转化率和团队预测，信息缺失会导致客户遗忘、商机停滞和复盘困难。杏云 CRM 智能销售助手把客户管理和 AI 辅助能力融入销售工作流。

业务概述

平台服务于销售人员、销售主管、售前顾问和管理者。线索进入后，系统完成客户去重、分配、建档和跟进计划；销售记录电话、拜访、会议和报价，商机按照阶段推进并触发提醒。AI 根据客户画像、产品资料和历史互动生成会议摘要、跟进建议、话术草稿和异议处理思路，正式的客户数据、商机状态和报价审批由 Java 服务控制。

主要业务场景包括：

• 客户、联系人、标签、来源和负责人统一管理；
• 线索分配、商机阶段、赢率、预计成交和跟进计划；
• 产品资料、报价版本、竞品信息和合同协同；
• 客户画像、通话摘要、话术建议和下一步行动；
• 销售漏斗、转化率、跟进周期、回款和团队预测分析。

技术架构选型

1. 整体架构

采用前后端分离和按业务域拆分的服务架构，客户、线索、商机、产品、跟进、合同和分析模块通过统一网关提供服务。AI 服务负责检索资料和生成建议，业务服务负责客户权限、商机状态、审批、数据落库和审计。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建客户、商机、跟进和分析服务；
• Spring Security + OAuth2：控制组织、团队、负责人和共享客户范围；
• MySQL：保存客户、联系人、线索、商机、报价和回款数据；
• MyBatis / MyBatis-Plus：支持复杂筛选、漏斗统计和批量导入。

3. 中间件与 AI 能力

• Redis：缓存客户画像、会话上下文、热点产品和提醒任务；
• MQ：异步处理跟进提醒、导入、同步、统计和通知；
• Elasticsearch + 向量库：检索产品手册、报价政策、竞品资料和历史案例；
• XXL-JOB：执行商机超期提醒、日报、周报和数据同步；
• Spring AI：实现摘要、话术、知识问答和受控工具调用。

主要业务模块

1. 客户与联系人

维护客户基本信息、联系人、行业、区域、标签、来源和归属，支持客户去重、合并和共享。

2. 线索与商机

管理线索池、分配规则、商机阶段、预计金额、赢率、竞争信息和下一步计划，阶段变化自动触发任务。

3. 跟进工作台

记录电话、拜访、会议、纪要和客户反馈，AI 生成摘要与行动项，销售确认后转为正式跟进记录和待办。

4. 产品与方案

管理产品、版本、价格、报价、竞品和合同模板，查询和报价动作受角色权限与审批规则约束。

5. 销售助手

检索产品知识、客户历史和异议案例，生成话术、方案说明和风险提示，支持人工编辑和引用来源。

6. 经营分析与审计

统计销售漏斗、阶段转化、成交周期、回款和团队目标，记录客户查看、导出、报价和权限变更行为。

技术要点与应用价值

• 客户数据按组织、团队、负责人和共享规则隔离，避免越权查看；
• 将客户事实、交易数据和 AI 建议分开存储，模型不能自行补全金额和承诺；
• 通过状态机、提醒任务和待办机制让建议真正转化为销售行动；
• RAG 返回产品资料版本和适用范围，低置信度时转人工确认；
• 统一漏斗、回款和阶段口径，为管理者提供可追踪的经营分析。

陪跑价值与学习收获

CRM 的价值不在于保存客户资料，而在于帮助销售持续推进商机、减少遗漏、提高转化。你会围绕线索、客户、跟进、商机、报价、回款和经营分析建立完整的销售工作台，再把 AI 话术、会议摘要和下一步建议嵌入真实工作流，让 AI 输出真正能够转成行动。

• 学会设计客户数据隔离、线索分配、商机阶段和跟进提醒。
• 掌握 RAG 产品知识问答、话术生成、会议摘要和受控工具调用。
• 理解如何区分系统事实、模型建议和销售人员最终确认的承诺。

你将带走的成果

• 一套从获客到回款的 CRM 业务链路和数据模型。
• 一份销售助手的 AI 接入、权限控制和审计设计方案。
• 一套更贴近真实工作场景的 Java+AI 项目面试表达。

业务背景与建设目标

销售团队的客户资料、通话记录、拜访纪要和报价信息通常分散在 CRM、表格和即时通讯中。销售需要持续判断客户阶段、下一步动作和成交风险，管理者则要关注商机质量、跟进节奏和团队预测。如果缺少统一的过程记录，客户容易遗忘、商机容易停滞，复盘也很难依赖真实数据。

杏云 CRM 智能销售助手围绕“客户建档、线索分配、跟进记录、商机推进、方案推荐、合同协同、回款跟踪和经营分析”搭建销售工作台。AI 根据客户画像、历史互动和产品资料提供下一步建议、话术草稿、异议处理和会议摘要，Java 服务负责客户权限、商机状态、审批、数据落库和销售过程审计。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个面向运维与平台团队的 AIOps 平台，解决告警太多、重复告警多、定位慢、知识散、应急流程不统一的问题。AI 负责归纳和检索，Java 负责告警流转、规则执行和统计归档。

项目背景

微服务、容器、数据库、中间件和云资源持续产生指标、日志、链路、变更和告警。一个故障往往会在多个系统中同时产生大量重复告警，值班人员需要先判断影响范围，再查找 Runbook、发布记录和历史案例，定位速度高度依赖个人经验。观澜 AIOps 智能告警分析平台通过统一接入、告警治理和知识沉淀，帮助运维团队建立稳定的故障响应流程。

业务概述

平台接入业务系统和第三方监控数据，对信号进行标准化、去重、聚合、抑制和升级，形成统一的告警事件。值班人员在预警工作台查看影响服务、拓扑关系、最近变更和历史案例，系统给出根因候选和 Runbook 建议，处置结果、时间线和复盘结论沉淀到知识库。

主要业务场景包括：

• 指标、日志、链路、变更和工单数据统一接入；
• 重复告警合并、噪声抑制、优先级调整和升级；
• 服务拓扑、影响范围、变更关联和根因候选分析；
• 值班排班、协同群组、Runbook 和工单联动；
• MTTA、MTTR、告警量、恢复率和服务趋势分析。

技术架构选型

1. 整体架构

采用事件驱动和可观测性架构，数据接入、规则计算、告警中心、拓扑服务、分析服务和通知服务独立部署。采集数据进入消息总线后进行标准化和规则计算，告警状态由事件中心统一维护，AI 只读取授权数据生成摘要和诊断建议。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建告警、规则、拓扑和分析服务；
• Spring Security：控制租户、服务、值班组和敏感运维数据访问；
• MySQL：保存告警、规则、服务、变更、工单和审计数据；
• Elasticsearch：存储日志、事件、时间线和历史案例，支持高速查询。

3. 中间件与 AI 能力

• Kafka / RabbitMQ：承载监控信号、告警事件和通知消息；
• Redis：保存时间窗口、去重指纹、拓扑缓存和抑制状态；
• 时序数据库：保存指标和资源趋势数据；
• 向量库 + RAG：检索 Runbook、历史故障和复盘案例；
• XXL-JOB：执行告警扫描、聚合、报表和知识同步。

主要业务模块

1. 数据接入与信号管理

适配指标、日志、链路、云资源和第三方系统，统一字段、服务标识、时间和严重等级，支持失败重试和补偿。

2. 预警工作台

集中展示待确认、处理中、已恢复和已关闭告警，支持确认、分派、升级、协同和处置时间线。

3. 规则管理

配置阈值、组合条件、时间窗口、抑制规则、升级规则和版本，支持测试、灰度和回滚。

4. 服务拓扑与风险分析

维护应用、主机、数据库和中间件依赖关系，结合变更记录和告警时间计算影响范围和根因候选。

5. 应急处置与通知

管理值班表、群组、Runbook、工单和多渠道通知，生产执行动作需要权限、审批和回执校验。

6. 报表、审计与运维

统计告警量、重复率、响应时长、恢复时长和服务趋势，记录规则变更、告警处理、工具调用和数据导出。

技术要点与应用价值

• 每次告警合并、抑制和升级都记录规则、时间窗口和关联对象，保证降噪可解释；
• 通过指纹、时间窗口和状态机解决重复告警、延迟恢复和乱序消息问题；
• AI 输出根因候选和证据，不能直接重启服务或修改生产配置；
• 故障时间线和人工结论经审核后沉淀为 Runbook，持续降低重复排障成本；
• 通过 MTTA、MTTR 和告警趋势帮助团队评估稳定性治理效果。

陪跑价值与学习收获

AIOps 项目直接面对线上系统的稳定性问题：告警来自不同平台，重复、噪声和关联关系让定位变慢，值班人员还要在压力下查 Runbook、看变更和组织处置。你会把告警接入、降噪聚合、拓扑分析、根因建议和复盘知识串成闭环，理解 AI 如何帮助运维人员更快判断，而不是替代生产操作。

• 学会设计告警去重、抑制、升级、恢复和事件状态机。
• 掌握指标、日志、链路、变更、服务拓扑和 Runbook 的关联方式。
• 理解生产环境中的 Tool Calling、审批、回执和安全边界。

你将带走的成果

• 一套从告警产生到故障复盘的 AIOps 项目讲解框架。
• 一份体现可观测性、异步处理、降噪策略和可靠性的技术亮点。
• 一套适合平台研发、后端和 AI 工程岗位的面试素材。

业务背景与建设目标

微服务、容器、数据库、中间件和云资源持续产生监控指标、日志、链路和告警。单个故障往往会在多个系统中产生大量重复告警，值班人员需要先判断影响范围，再查找 Runbook、变更记录和历史案例，定位速度高度依赖个人经验。

观澜 AIOps 智能告警分析平台把指标、日志、链路、变更和工单统一接入，以“采集、去重、聚合、分派、诊断、处置、复盘”为主线建立运维闭环。AI 用于告警摘要、相似事件检索、根因分析建议和 Runbook 问答，Java 服务负责规则计算、告警状态、责任人、应急流程和审计，确保自动化动作可控。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个面向制造业的 MES 平台，核心处理生产计划、工艺协同、设备诊断、质量管理和异常闭环。AI 的作用是辅助诊断设备问题、解释工艺规则和给出调度建议。

项目背景

制造企业的生产计划、工艺、设备、质量、物料和人员信息往往分散在 ERP、设备系统和纸质记录中。生产计划变化后，现场无法及时同步；设备异常发生后，维修、质量和计划部门缺少统一协同；产品出现问题时，也难以快速追溯原料、工序和设备。智造星图 MES 生产调度与设备诊断平台面向生产现场建立统一的执行与分析平台。

业务概述

平台接收订单和生产计划，按照产线、设备、工艺和人员能力生成排产任务。生产过程中记录工序执行、设备状态、物料消耗和质量检验，异常停机或质量超限时触发告警和处置流程。管理人员通过看板查看生产进度、设备健康、良率、在制品和异常趋势，维修人员根据设备手册和历史案例完成诊断和维护。

主要业务场景包括：

• 生产订单、工艺路线、排产计划和工单管理；
• 设备台账、实时状态、点检、保养和故障诊断；
• 工序报工、质量检验、不良处理和批次追溯；
• 物料、人员、产线和现场任务协同；
• 生产效率、良率、设备利用率和异常趋势分析。

技术架构选型

1. 整体架构

采用生产执行、设备接入、质量管理、追溯分析和系统管理分域的架构。生产计划和工单服务处理核心事务，设备接入服务接收实时数据，消息总线传递状态和告警，分析服务生成生产和设备看板，AI 服务辅助查询工艺和维修知识。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建生产、设备、质量、追溯和分析服务；
• Spring Security：控制工厂、车间、产线、班组和岗位权限；
• MySQL：保存订单、工单、工艺、设备、质量和追溯记录；
• MyBatis：支持生产报工、批次查询和复杂统计。

3. 中间件与数据能力

• Redis：缓存设备状态、工艺参数、排产计划和看板数据；
• MQTT / Kafka / RabbitMQ：接收设备数据并异步传递告警和状态；
• Elasticsearch：检索维修记录、工艺文件、质量案例和追溯信息；
• XXL-JOB：执行点检、保养、报表和数据归档任务；
• Spring AI + 向量库：检索工艺规范、设备手册和维修案例。

主要业务模块

1. 生产计划与调度

维护订单、工艺路线、产能、设备和班次，根据交期、优先级和资源约束生成排产和工单。

2. 生产执行与报工

记录工单接收、开工、暂停、完工、报工、物料消耗和人员操作，确保生产状态及时同步。

3. 设备管理与诊断

维护设备台账、点检、保养、维修和故障记录，采集运行指标并生成健康度和诊断建议。

4. 质量管理与追溯

配置检验项目、抽检规则和不良等级，关联批次、工序、人员、设备和原料，支持问题反查。

5. 工艺与知识库

管理工艺文件、作业指导书、设备手册和质量规范，AI 根据权限检索并解释相关内容。

6. 看板、告警与系统管理

展示产量、良率、设备利用率、在制品和异常趋势，支持消息通知、权限控制、日志审计和运维监控。

技术要点与应用价值

• 通过设备事件、生产工单和质量记录建立统一时间线，支持问题定位和批次追溯；
• 设备状态更新采用幂等、顺序控制和断线补偿，避免实时数据覆盖或丢失；
• 排产建议保留人工确认，AI 只提供解释和候选方案，不直接改变生产计划；
• 通过异步计算和缓存提升大屏、报表和历史追溯查询性能；
• 将生产现场数据沉淀为可分析指标，帮助企业提升交付、良率和设备利用率。

陪跑价值与学习收获

MES 连接生产计划、工艺、设备、质量和物料，是最能体现“系统要真正服务现场”的项目类型。你会从订单和排产出发，看到工序执行、设备状态、质量检验、异常停机和产品追溯如何互相影响，并理解数据实时性、流程可视化和业务一致性的重要性。

• 学会拆解生产调度、工艺管理、质量追溯、设备诊断和人员权限。
• 掌握实时数据接入、任务状态同步、异常告警和报表分析。
• 能够从业务价值、技术架构和现场落地三个层面讲清 MES 项目。

你将带走的成果

• 一套从生产计划到成品追溯的制造业业务流程。
• 一份围绕并发、数据一致性、设备接入和可视化的技术方案。
• 一套适合中高级 Java 项目的简历描述和面试回答。

业务背景与建设目标

制造企业需要同时管理订单、生产计划、工艺路线、物料、设备、人员和质量标准。计划变更、设备停机、来料异常或质量波动都会影响交付，传统依赖纸面记录和人工沟通的方式难以保证生产现场、计划部门和质量部门使用同一套实时数据。

智造星图 MES 生产调度与设备诊断平台以“订单分解、排产下发、工艺执行、设备采集、质量检验、异常处置、追溯分析”为核心链路，将生产现场数据和管理流程统一起来。AI 负责工艺知识问答、设备故障码解释、异常摘要和排产建议，Java 服务负责工单、批次、质量判定、设备状态和生产数据的正式落库。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个面向售后和订单服务的智能客服助手，主要处理订单查询、退款退货、发票规则、售后政策和常见问题。AI 负责理解问题、检索知识和生成草稿，Java 负责真正的订单和工单处理。

项目背景

门店、外卖、团购和会员业务同时运行时，订单、库存、支付、后厨、桌台和售后容易出现状态不一致。收银员需要快速完成点单和收款，后厨需要准确接收制作任务，顾客需要查询订单、退款和售后进度，总部还要掌握多门店经营情况。星购售后智能客服与订单助手将交易、履约、售后和智能服务连接起来。

业务概述

系统接入堂食、外卖、团购和线上商城订单，完成商品、库存、优惠和会员校验后生成统一订单。支付成功后，订单进入后厨制作、出餐、配送或自提流程；退款、退货、缺货和投诉等问题进入售后工单。AI 通过 FAQ、订单查询工具和政策知识库辅助客服快速处理问题，正式退款和库存变更由 Java 业务服务控制。

主要业务场景包括：

• 门店收银、扫码点单、外卖、团购和多渠道订单接入；
• 商品、库存、优惠、桌台、后厨和出餐状态协同；
• 聚合支付、退款、结算、对账和异常补偿；
• 会员、积分、优惠券、售后工单和客户评价；
• 门店经营报表、异常预警和总部多店管理。

技术架构选型

1. 整体架构

采用订单中心、商品中心、库存中心、支付中心、门店中心、售后中心和客服中心拆分的架构。统一网关承接收银端、顾客端、客服端和管理端请求，订单状态通过消息事件同步给后厨、库存、会员和财务系统。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建订单、支付、库存、售后和客服服务；
• Spring Security：实现门店、收银员、客服、店长和总部管理员权限；
• MySQL：保存商品、订单、支付、库存、会员和售后数据；
• MyBatis：支持订单查询、经营统计和批量处理。

3. 中间件与 AI 能力

• Redis：缓存商品、库存、桌台、优惠和会话数据；
• RabbitMQ / Kafka：异步处理订单事件、支付通知、库存同步和客服消息；
• Elasticsearch：检索订单、商品、售后案例和 FAQ；
• XXL-JOB：执行对账、自动关单、库存校准和经营报表；
• Spring AI：实现政策问答、订单查询、客服摘要和售后分流。

主要业务模块

1. 门店收银与订单中心

支持堂食、外卖、团购和线上订单统一接入，完成商品、门店、价格、优惠和配送方式校验。

2. 订单与后厨协同

管理待支付、已支付、制作中、待取餐、配送中、完成、取消和售后状态，向后厨和配送端推送任务。

3. 聚合支付与结算

接入微信、支付宝和第三方渠道，处理支付回调、退款、分账、日结、对账和异常补偿。

4. 库存、桌台与会员

维护库存、锁定、扣减、回滚、桌台、会员、积分、优惠券和消费记录。

5. 售后客服与知识库

客服查询订单和规则，AI 检索 FAQ、售后政策和历史案例，生成答复草稿并按复杂度转人工。

6. 总部管理与经营分析

提供多门店、商品、权限、营业额、客单价、退款率、库存异常和经营趋势分析。

技术要点与应用价值

• 通过订单状态机和事件幂等保证收银、支付、后厨和售后状态一致；
• 支付回调、退款和库存扣减使用唯一业务号、分布式锁和补偿任务防止重复执行；
• 高峰期采用缓存、消息队列和读写分离提升收银和订单查询能力；
• AI 只读取授权订单和知识，退款、改价、库存变更必须经过 Java 服务校验；
• 通过经营报表和异常预警帮助门店发现缺货、退款、出餐和服务质量问题。

陪跑价值与学习收获

售后客服与订单助手把门店、顾客、支付、库存、后厨和客服连接在一起，任何一个状态不同步都可能影响用户体验。你会从订单查询、退款售后、规则解释和工单协同切入，理解电商与线下门店业务如何共用一套可靠的订单和服务底座。

• 学会处理多渠道订单、支付回调、库存扣减、退款和售后状态流转。
• 掌握 FAQ / RAG 问答、订单查询工具、客服摘要和人工转接。
• 理解高频交易场景下的幂等、补偿、消息可靠投递和权限审计。

你将带走的成果

• 一套从下单、履约到售后闭环的项目故事线。
• 一份客服 AI 与交易系统结合的技术难点清单。
• 一套适合初中高级 Java 开发者的项目讲解与简历亮点。

业务背景与建设目标

电商售后问题通常与订单状态、支付方式、物流节点、商品类目和售后政策直接相关。用户希望快速知道“能不能退、退到哪一步、什么时候到账”，客服则需要在订单系统、仓储系统和政策文档之间来回查询。纯 FAQ 只能回答固定问题，直接让模型调用订单接口又会带来权限和误操作风险。

星购售后智能客服与订单助手将订单查询、售后规则、退款退货、发票服务、客服工单和用户通知整合起来。AI 负责识别意图、补齐查询条件、检索政策和生成回复草稿；Java 后端通过订单、售后和支付服务完成权限校验、状态判断、幂等控制和正式写操作，形成“问答解释 + 业务办理 + 工单兜底”的完整链路。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一个面向 ERP 和财务分析场景的助手，帮助用户更快理解报表、经营指标、财务制度和预算口径。AI 负责解释和归纳，Java 负责权限、流程和数据落库。

项目背景

集团企业的财务数据通常来自总账、应收应付、采购、销售、库存、预算和多个子公司系统。管理者需要查看利润、现金流、费用、预算执行和经营指标，但不同系统的数据口径、期间和权限并不一致，人工合并报表耗时长，差异也难以追溯。数策 ERP 财务报表分析助手将财务数据、指标规则、制度知识和组织权限统一起来。

业务概述

平台接收业务系统和子公司的财务数据，进行格式校验、科目映射、规则匹配和凭证审核。系统自动对账并识别差异，完成集团数据合并后生成利润表、资产负债表、现金流量表和经营分析报表。用户可以用自然语言查询指标、解释口径和查看明细，AI 输出必须关联数据来源、计算期间和权限范围。

主要业务场景包括：

• 子公司、业务系统和 Excel 财务数据接入；
• 科目、指标、公式、组织和会计期间的统一管理；
• 凭证生成、审核、自动对账和差异处理；
• 集团数据合并、报表生成、预算执行和经营分析；
• 财务制度问答、自然语言问数、报表解释和审计追踪。

技术架构选型

1. 整体架构

采用数据接入、规则中心、凭证中心、对账中心、报表中心、分析中心和权限审计分层的架构。数据接入服务负责多来源数据标准化，指标服务负责口径和计算，报表服务负责查询与导出，AI 服务负责受控问数和结果解释。

2. 后端技术

• Spring Boot / Spring Cloud Alibaba：构建 ERP 财务业务服务；
• Spring Security：实现集团、子公司、部门、岗位和数据范围权限；
• MySQL / Oracle：保存凭证、科目、指标、报表和审计数据；
• MyBatis：支持复杂财务查询、合并计算和批量处理。

3. 中间件与 AI 能力

• Redis：缓存指标定义、组织权限和热点报表；
• MQ：异步处理数据导入、报表生成、对账和通知；
• Elasticsearch：检索凭证、制度、报表和经营明细；
• XXL-JOB：执行月结、对账、合并、报表和归档任务；
• RAG + Tool Calling：检索制度和指标口径，生成经过校验的查询条件。

主要业务模块

1. 数据接入与合并

接收业务系统、子公司和 Excel 数据，完成格式校验、科目映射、重复检测、批量入库和错误反馈。

2. 报表设计与指标中心

配置报表维度、指标公式、数据来源、计算周期、版本和责任人，支持拖拽设计和权限化发布。

3. 规则配置与凭证管理

维护会计规则、审批规则、凭证模板和审核流程，记录凭证生成、修改、审核和作废历史。

4. 自动对账

按金额、科目、期间、单据号和业务来源进行匹配，识别未达账、重复账和差异项，支持人工确认和调整。

5. 数据分析与自然语言问数

支持同比、环比、预算执行、区域、产品和客户维度分析，AI 将问题转换为受控查询意图并返回指标解释。

6. 检索、调度与安全审计

提供凭证、制度、报表和明细检索，异步执行大报表导出和月结任务，记录查看、分享、导出和权限变更行为。

技术要点与应用价值

• 每个指标保存定义、公式、数据来源、生效版本和责任人，保证口径统一；
• 自然语言只生成经过校验的查询意图，真实数据访问通过权限服务和参数化 SQL 执行；
• 大范围、多维度报表通过 MQ 和 XXL-JOB 异步生成，支持进度、重试和失败补偿；
• 分析摘要关联原始报表、过滤条件和计算周期，财务人员可快速回到明细复核；
• 通过集团合并、自动对账和经营分析减少人工整理，让财务数据更快服务管理决策。

陪跑价值与学习收获

ERP 财务分析真正难的地方，是同一个指标可能有不同口径、不同组织权限和不同统计周期。你会围绕报表、指标、预算、制度和经营分析搭建一条可复核的数据链路，理解 AI 如何帮助管理者问数和读报表，同时保证正式数据仍由规则、权限和审计体系说了算。

• 学会设计指标定义、公式版本、数据权限、报表钻取和异步导出。
• 掌握财务制度 RAG、自然语言问数、受控 SQL 和异常指标摘要。
• 能够回答数据安全、口径一致、结果复核和大报表性能优化等问题。

你将带走的成果

• 一套从数据汇总到报表解释、经营洞察和复核留痕的业务流程。
• 一份 ERP + AI 项目中权限、指标、检索和异步任务的技术方案。
• 一套能够体现企业级数据思维的简历与面试表达。

业务背景与建设目标

ERP 中的财务数据通常来自总账、应收应付、采购、销售、库存和预算等多个模块。管理者关心收入、毛利、现金流、费用率和预算执行，但不同部门对指标口径、统计周期和数据权限的理解可能不一致。单纯把报表导出后交给人工分析，难以做到实时解释、统一口径和可追溯复核。

数策 ERP 财务报表分析助手将经营指标、报表数据、财务制度、预算规则和组织权限统一组织起来，形成“指标查询、口径解释、报表钻取、异常发现、经营摘要、人工复核”的分析链路。AI 用于自然语言问数、制度问答、指标解释和分析摘要，Java 服务负责数据权限、指标计算、查询审计和正式报表生成。

业务模块与关键流程

| 业务模块 | 核心能力 | Java / AI 落点 |
|

这是一套面向 Java 后端、Java AI 应用开发和求职表达的企业级项目库。重点不是堆技术名词，而是帮助你讲清楚业务场景、核心流程、Java 后端职责、AI 接入点、权限审计和落地边界。

以下内容展示的是部分公开项目。实际项目库不止这些，更多未公布项目会根据你的工作年限、岗位方向、简历背景和面试目标单独匹配。

进入项目陪跑前，你会先看到什么

这套项目库服务于想把 Java 后端、AI 应用和真实业务表达串起来的开发者。每个项目都按“业务背景 → 核心流程 → Java 技术落点 → AI 使用边界 → 难点与面试表达”组织，先让你看懂业务，再带你拆解系统，最后把项目讲到面试官愿意继续追问的程度。

你会看到的不是孤立的技术名词，而是可以被验证、被演示、被写进简历的完整项目故事：谁在使用系统，为什么要做这套系统，数据如何流转，哪些动作必须由后端控制，AI 在哪里提升效率，以及系统遇到异常时如何兜底。

每个项目详情页都按项目资料文档展开：项目背景、业务概述、技术架构选型、主要业务模块、技术要点与应用价值，并配套主流程图、模块流程图、面试讲法和简历表达。

通过陪跑，你会获得

• 一套真实业务视角：从用户、角色、流程和业务目标出发，建立项目全貌。
• 一套可落地的技术路径：把 Spring Boot、微服务、Redis、MQ、Elasticsearch、RAG、Agent 等技术放到具体模块里理解。
• 一套可复用的面试表达：能用清晰的结构讲背景、职责、难点、结果和取舍。
• 一套可以持续升级的作品：从基础版本开始，逐步补齐权限、审计、监控、AI 和工程化能力。

如果你正在准备 Java 后端、Java+AI、企业应用开发或中高级岗位，这里可以作为选项目、拆项目和准备面试的入口。先选择一个与你目标岗位接近的场景，再沿着流程图和模块说明逐步深入。

按人群选项目

| 人群 | 推荐项目 | 选择理由 |
|

阅读提示

建议按“线程基础 -> 并发三特性 -> 锁与 AQS -> 线程池 -> 线上排障”顺序复习。
面试回答时尽量带一个真实场景（如高并发下延迟抖动、线程池打满、锁竞争）。

本文以 Java SE 21 的规范和 API 为基准；基础 JMM、监视器和并发工具的语义也适用于 JDK 8/17。虚拟线程仅讨论 JDK 21，HotSpot 锁优化属于实现细节，需区分版本。

推荐训练法

1. 先过题目清单，确认知识覆盖面。
2. 每题先用 20~40 秒口述结论，再补机制细节。
3. 对高频题（CAS、synchronized、线程池）做二次复述。

1、什么是进程、线程、协程？

回答提示：

• 进程提供资源与地址空间隔离；平台线程由操作系统调度，Java 虚拟线程由 JVM 调度到承载它的平台线程上。
• 协程通常是用户态轻量执行单元；具体调度和切换成本取决于实现，不能直接等同于 Java 线程。

参考回答：

• 一个进程可包含多个线程，线程共享进程资源但执行路径独立。
• 协程常用于高并发 IO 场景，通过用户态调度减少线程切换开销。

2、线程状态有哪些？

回答提示：

• Java 线程状态：NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED。

参考回答：

• BLOCKED 专指等待进入或重新进入对象监视器（synchronized），不是所有等锁场景；ReentrantLock 竞争时通常通过 park 进入 WAITING 或 TIMED_WAITING。
• RUNNABLE 包含正在执行和等待处理器等操作系统资源的情形，不能仅凭它判断 CPU 正忙。状态定义见 Thread.State（Java 21）。

3、创建线程有哪些方式？

1. 继承 Thread。
2. 实现 Runnable。
3. 实现 Callable，交给执行器提交并通过 Future 取结果；Callable / Future 本身不会创建或启动线程。
4. 通过 ExecutorService 提交任务，由具体执行器决定线程管理方式。

JDK 21 可使用 Thread.ofVirtual().start(task) 或 Executors.newVirtualThreadPerTaskExecutor()。虚拟线程适合大量等待 IO 的任务，不会让 CPU 计算本身变快，也不应池化；下游并发限制可用 Semaphore。见 Oracle 虚拟线程指南。

4、并发三大特性是什么？

回答提示：

• 原子性：操作不可分割。
• 可见性：通过 happens-before 等同步关系，保证一个线程的写入对另一个线程的相应读取可见，不是任意共享变量都能“立即看到更新”。
• 有序性：程序执行顺序受约束。

参考回答：

• synchronized 可保证原子性和可见性；volatile 保证可见性并约束重排序。

机制上，同一监视器的解锁 happens-before 后续加锁；对同一 volatile 变量的写 happens-before 后续读，并通过传递性发布此前写入的普通字段。这不意味着所有指令都禁止重排，而是重排不能破坏规范保证的可观察行为。count++ 包含读、加一、写回，即使 count 为 volatile，多个线程仍可能覆盖结果；计数可用 AtomicInteger.incrementAndGet()。见 JLS 21 §17.4.5。

5、什么是 CAS？优缺点是什么？

回答提示：

• CAS：比较并交换，原子指令，常用于无锁并发。
• 优点：可用于实现无锁更新，避免为单次更新挂起线程；吞吐优势取决于竞争程度。
• 缺点：可能遇到 ABA，重试循环会消耗 CPU；单次 CAS 更新一个位置，多字段不变量需锁或将不可变状态封装后用 AtomicReference 整体替换。

参考回答：

• compareAndSet 失败返回 false，不会自行无限重试；调用方或上层原子更新方法决定是否循环。竞争激烈时应评估重试成本。见 atomic 包说明。

6、什么是 ABA 问题？如何解决？

回答提示：

• 值从 A -> B -> A，CAS 看起来没变但过程已变。
• 可用版本号机制解决，如 AtomicStampedReference。

7、synchronized 的底层和使用范围

回答提示：

• 修饰实例方法：锁对象实例。
• 修饰静态方法：锁 Class 对象。
• 修饰代码块：锁指定对象。

参考回答：

• synchronized 是可重入、独占的监视器同步；正常返回或异常退出同步区域都会释放监视器。HotSpot 的锁表示与优化不是语言保证，不能把“偏向锁 → 轻量级锁 → 重量级锁”当成所有 JDK 的固定流程。JDK 15 已默认禁用并弃用偏向锁，见 Oracle JDK 15 发布说明。

8、volatile 能保证什么？不能保证什么？

回答提示：

• 能保证可见性和一定有序性。
• 不能保证复合操作原子性（如 count++）。

9、ReentrantLock 和 synchronized 有什么区别？

1. ReentrantLock 支持可中断加锁、超时尝试、公平锁。
2. synchronized 语法简单，JVM 层优化充分。
3. 复杂并发控制（多条件队列）更适合 ReentrantLock。

10、什么是 AQS？

回答提示：

• AQS（AbstractQueuedSynchronizer）是并发同步框架核心。
• 通过原子更新的 int state 与 FIFO 等待队列组织竞争；子类定义获取/释放状态的规则，AQS 负责排队、阻塞与唤醒。常说的 CLH 队列是其队列设计来源，不能据此断言锁一定公平。

参考回答：

• ReentrantLock、Semaphore、CountDownLatch 的内部同步器都基于 AQS。入队不等于严格按先后获得锁，是否允许新线程插队取决于获取逻辑。见 AQS API。

11、wait / notify / notifyAll 和 sleep 的区别

1. wait 必须在持有该对象监视器时调用（同步方法或同步块均可），只释放该对象的监视器，不释放持有的其他锁。
2. sleep 让当前线程暂停一段时间，不释放已持有的监视器，也不提供同步可见性保证。
3. notify 任意选择一个等待线程，不承诺随机或公平；notifyAll 通知全部等待线程。两者同样要求持有该对象监视器，且不会立刻释放它。被通知线程重新获得监视器后才能从 wait 返回。

等待必须放在条件循环中：虚假唤醒或其他线程抢先消耗条件，都要求重新判断。以下为机制片段，ready 的读写均须由同一个 monitor 保护，调用方法需声明或处理 InterruptedException：

// 等待方
synchronized (monitor) {
    while (!ready) {
        monitor.wait();
    }
    // 在锁内处理依赖 ready 的共享状态
}
// 通知方
synchronized (monitor) {
    ready = true;
    monitor.notifyAll();
}

见 Object.wait / notify（Java 21）。

12、CountDownLatch、CyclicBarrier、Phaser 的区别

• CountDownLatch：一次性门闩，常用于主线程等待子任务结束。
• CyclicBarrier：可复用屏障，常用于多线程分阶段对齐。
• Phaser：更灵活，支持动态注册与多阶段同步。

13、Semaphore 适合什么场景？

回答提示：

• 控制同时访问资源的数量，典型场景是连接池资源保护。它限制的是并发数，不直接保证每秒请求数；成功获取许可后应在 finally 中释放。

14、ThreadLocal 的作用和风险

回答提示：

• 作用：线程隔离上下文（如用户信息、追踪ID）。
• 风险：在线程池中不清理会导致上下文串到后续任务，也可能长期保留对象。请求上下文宜在 try/finally 中 remove()；线程隔离只隔离变量绑定，若多个线程绑定同一个可变对象，对象本身仍需同步。

15、为什么要用线程池？

1. 降低线程创建/销毁开销。
2. 控制并发度，保护系统资源。
3. 便于统一监控和治理。

16、线程池核心参数有哪些？

• corePoolSize
• maximumPoolSize
• keepAliveTime 及其时间单位 unit
• workQueue
• threadFactory
• RejectedExecutionHandler

在运行状态下，execute 的核心顺序是：

少于 corePoolSize → 尝试新建工作线程
否则 → 尝试入队
入队失败 → 尝试扩至 maximumPoolSize
仍无法接收（或池已关闭）→ 拒绝处理

入队后还需复查池状态，避免关闭竞态漏处理任务。无界队列通常让任务积压而非触发扩容，因此仅调大 maximumPoolSize 往往无效；有界队列才能同时约束积压量。默认仅超出核心数的空闲线程超时退出，开启 allowCoreThreadTimeOut(true) 且超时为正数后核心线程也可退出。详见 ThreadPoolExecutor 官方说明。

17、线程池拒绝策略有哪些？

1. AbortPolicy：直接抛异常。
2. CallerRunsPolicy：池未关闭时由提交线程执行，被关闭后丢弃任务。
3. DiscardOldestPolicy：池未关闭时移除队列头任务，再尝试提交新任务；并非丢弃正在执行或全局最旧的任务。
4. DiscardPolicy：静默丢弃被拒绝的任务。

静默丢弃通过 submit 提交的任务可能让对应 Future 一直无法完成，不能再无期限等待它。

18、线程池参数怎么估算？

回答提示：

• CPU 密集：线程数接近 CPU 核数。
• IO 密集的平台线程池可按等待/计算时间比例估算初值；“2N”没有通用保证，还受下游容量、连接数与内存约束。

参考回答：

• 实际工程要结合压测、队列积压、RT 与 CPU 使用率动态调参。

19、JMM 是什么？为什么需要它？

回答提示：

• JMM 是 Java 内存访问规则，统一不同硬件平台的并发语义。
• 解决可见性、有序性和跨平台一致性问题。

20、乐观锁和悲观锁怎么理解？

• 悲观锁：先加锁再操作，冲突场景更稳。
• 乐观并发控制：读取状态并计算候选结果，再通过 CAS 或版本条件原子地校验并提交；失败后重试或放弃。不能先修改共享数据再事后校验，也不保证读多写少时一定更快。

21、如何定位线上并发问题？

1. 先看监控：线程数、CPU、队列长度、拒绝次数。
2. 再看 JVM：jstack、jcmd、GC 日志。
3. 最后看代码：锁粒度、线程池配置、共享变量访问。

22、面试表达模板（可直接复述）

• 我会先判断是“计算瓶颈”还是“并发控制瓶颈”，再决定优先调线程池还是降锁竞争。
• 对线程池我会重点盯队列积压和拒绝策略，避免任务堆死。
• 对锁问题我会通过线程 dump 定位阻塞链，再做锁粒度优化或改无锁结构。

继续阅读与资料

继续追问：线程池为何不扩容，队列与拒绝如何影响调用方。

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

本文的具体机制以 MySQL 8.4 / InnoDB、Redis 7.x、RabbitMQ 4.4、Maven 3.9.x 和 Caffeine 3.x（Java 11+）为适用范围；其他组件需结合所用版本确认 API 与投递语义。代码为机制示意，未在数据库或中间件环境运行。

1、如何设计一个订单号生成服务

• 看数据量的大小：在设计订单号生成服务时，需要充分考虑数据量的大小，以确定生成的ID所需的位数。这可以避免位数不足导致存储问题，同时确保足够的位数以防止影响索引检索效率。
• 不重复、唯一性：订单号应有数据库唯一约束兜底。UUID 是概率唯一；Snowflake 依赖节点编号不冲突，并处理时钟回拨和序列耗尽；数据库序列或 Redis 自增还需评估故障恢复、持久化和主从切换时的重复风险，不能仅凭算法名称承诺全局唯一。
• 考虑高可用：通过多节点部署、负载均衡、健康检查等技术手段，确保服务在面对故障时能够保持可用状态，避免影响其他服务。
• 易于理解：为了方便排查问题，需要考虑到订单号的格式和组成，可以使用时间戳、随机数、用户ID等信息来拼接订单号。
• 安全性：不能让别人通过订单号看出公司的经营状况，比如你的订单就是流水号的话，那么别人就可以从订单号推测出你公司的整体运营状况。

2、订单超时自动取消功能如何设计

• 定时任务：通过定时任务隔一段时间扫表，对于过期超时的订单数据更新状态为已取消。这种方式容易实现；缺点就是定时任务是固定时间间隔的，所以一些订单并不能及时到点的去立马取消，可能过期了一两分钟才被定时任务扫描到；而且这种方式也增加了数据库的压力，当表里数据越来越多之后，扫描的时间也会越来越长。所以这种方式适合对时间要求不高的，数据量也不是很多的业务场景。
• DelayQueue延迟队列：DelayQueue是JDK提供的一个无界队列，订单生成以后，设置过期时间放入定义好的DelayQueue，然后创建一个线程，在线程中通过while(true)不断的从DelayQueue中获取过期的数据。这种方式不依赖数据库，也不依赖其他组件，实现也方便；但是DelayQueue是一个无界队列，如果放入的订单数据过多，就会造成OOM。所以这种方式适合数据量比较小的，万一丢失了影响也不大的业务场景。
• Redisson：RDelayedQueue 可将任务延迟转入目标队列，具体 API 以项目使用的 Redisson 版本为准。Lua 能保证单次脚本执行期间不被其他命令穿插，但不能保证业务处理不重复；消费者仍需处理重试、宕机与幂等。
• MQ延迟消息：订单创建后发送延迟任务，到期再查数据库中的订单状态。RocketMQ 的延迟能力和精度取决于版本；RabbitMQ 可用 TTL + 死信交换机构造延迟链路，不一定需要插件。容量取决于部署、消息大小和保留时间，不能笼统承诺“万亿级”。需处理订单落库与发消息之间的失败窗口，例如事务内写 outbox，再可靠投递、重试和对账。
• MQ的死信队列：RabbitMQ 4.4 中，消息 TTL 到期、长度超限或消费者拒绝且不重新入队等情形可触发死信；需配置死信交换机及路由。延迟队列中放的是超时检查任务，支付行为不直接消费这条任务。不同 TTL 混排时，过期消息可能要到队首才被清理和死信化，不能当作精确定时器。参见 RabbitMQ TTL。
• Redis过期监听：notify-keyspace-events Ex 开启过期事件通知，但 Redis 7.x 的通知基于 Pub/Sub，断线期间消息会丢失；事件在实际删除键时产生，不保证 TTL 到点立即触发，且只携带键名。适合作为辅助信号，不能作为取消订单的唯一可靠来源。参见 Redis 键空间通知。

超时任务可能重复或晚到，支付回调也可能同时执行。以 MySQL 8.4 / InnoDB 为例，把状态与截止时间放进同一条条件更新：

UPDATE orders
SET status = 'CANCELLED'
WHERE id = ? AND status = 'PENDING' AND expire_at <= CURRENT_TIMESTAMP;

只有影响行数为 1 才是本次成功取消；支付回调也须从 PENDING 条件迁移，避免先读后写覆盖终态。若取消还要释放库存，可在同一数据库事务内完成，跨服务则记录可靠事件并幂等执行。支付平台已扣款而本地订单已取消时，还需查单和退款补偿。定期按状态、到期时间索引扫描作为兜底。InnoDB 的更新会加锁并判断更新条件，参见 锁定读与并发更新。

3、如何设计一个购物车功能

• 购物车系统的主要功能是在用户选择商品后，在下单之前保存用户的意向商品、数量等信息，以便用户进行统一支付。购物车的操作主要包括加入购物车、查看购物车以及通过购物车下单等。
• 一般情况下，在存储购物车信息时，并不需要保存商品的所有详细信息，只需记录一个SKU ID，并加上数量、时间等字段即可。商品的库存、价格、介绍等信息可以在渲染购物车时实时查询和计算。
• 对于未登录用户，购物车信息可以临时缓存在客户端，使用Cookie或LocalStorage等技术进行存储。以下是一个JSON格式的未登录用户购物车存储示例：

{
    "cart": [
        {
            "SKUID": 10086,
            "timestamp": 1666513990,
            "count": 2
        },
        {
            "SKUID": 10010,
            "timestamp": 1666513990,
            "count": 10
        }
    ]
}

• 已登录用户的购物车需要使用持久化存储，可以选择数据库或Redis缓存。如果使用数据库，可以创建表格存储user_id、sku_id、count、time_stamp等业务字段。如果使用Redis，可以在未登录用户购物车的基础上添加user_id作为key，如下所示：

{
    "KEY": 12343123,
    "VALUE": [
         {
            "SKUID": 10086,
            "timestamp": 1666513990,
            "count": 2
        },
        {
            "SKUID": 10010,
            "timestamp": 1666513990,
            "count": 10
        }
    ]
}

• 使用Redis和数据库各有优势：Redis性能更高，响应时间更短，能支撑更多并发请求；而MySQL具有较高的数据可靠性和支持丰富的查询方式和事务机制。

4、如果让你设计一个秒杀系统，怎么设计？

一个秒杀系统面临着多个独特的挑战，设计的时候应该考虑以下问题：

1. 高并发瞬时流量：

在处理秒杀场景的高并发瞬时流量时，系统的稳定性和可用性成为关键挑战。通常，我们会在整体架构设计上采取逐层的流量过滤策略，确保系统能够有效处理巨大的请求压力。

客户端可通过按钮防重复点击、退避重试等方式减少无效请求，但攻击者能绕过客户端，真正的准入控制和限流必须由网关及服务端执行。

接下来，通过CDN（内容分发网络）和Nginx进行统一接入，不仅可以实现负载均衡和流量分发，还可以配置黑白名单、IP限流等策略，进行更细粒度的流量过滤。

在服务端，通过Nginx配置的流量过滤和前端的丢弃策略，可以减轻服务端的压力。服务器层面也可以配置各种限流策略，例如基于Sentinel的动态限流，自定义的限流算法等。

此外，针对一些查询操作和写操作，可以使用缓存来提高性能。在缓存方面，本地缓存的响应速度更快，近端缓存效果优于远端缓存，可以有效抵挡部分请求。

由于秒杀业务本身允许一定的失败率，通过层层过滤，我们可以在前端、Nginx、服务器等层次上过滤更多的流量，提升系统的稳定性，确保在高并发情况下仍能提供可用的服务。

2. 热点数据：

秒杀系统常面临热点数据问题，特别是在大家抢购同一商品时，该商品成为热点数据。这带来了高频的查询请求和非常频繁的写请求，尤其是在库存扣减等操作上。

针对热点数据，主要的解决方案包括拆分和缓存。

首先是拆分，即将热点数据分割成多个相对冷门的数据，并通过负载均衡将不同请求分散到不同的数据上，以降低单一数据的请求压力。

其次是利用缓存。通常，对于秒杀业务，可以提前预知哪些数据会成为热点，因此可以提前进行缓存的预热。这不仅包括在Redis等缓存中的预热，还应在本地缓存上执行预热，以避免Redis的热key问题。在处理热点数据时，充分利用缓存可以有效减轻数据库的负担，提高系统的响应速度。

通过拆分和缓存的组合应用，能够有效缓解热点数据带来的高并发压力，提升系统的稳定性和性能。

3. 数据量大：

秒杀系统经常面临高频的下单操作，导致最终产生的订单量巨大，进而带来了查询效率低的问题。

针对这个挑战，有几种可行的解决方案：

• 加缓存： 在查询订单时可以引入缓存，将常被查询的订单数据缓存在内存中，以提高查询效率。可以使用分布式缓存如Redis等。
• 使用Elasticsearch（ES）： 当订单数据量庞大时，可以考虑使用Elasticsearch进行存储和检索。ES对于大规模文档的全文搜索和分析非常高效，适用于订单数据的查询。
• 分库分表： 当单一数据库无法承载巨大的订单数据时，可以考虑采用分库分表的方式，将订单数据分散存储在多个数据库或表中，提高查询性能。
• 数据归档： 对于历史订单数据，可以实施数据归档策略，将过早的历史数据归档到冷数据存储中，减轻热数据存储的压力。这样可以保证查询性能，同时降低存储成本。

选择适当的方案取决于具体业务需求和系统架构。可能需要综合考虑缓存的实时性、ES的搜索能力、分库分表的扩展性以及数据归档的存储成本等因素。

4. 库存的正确扣减：

在秒杀业务中，由于高频的并发库存扣减操作，提升库存扣减的性能并确保准确性是一项极为重要的任务。稍有不慎可能导致超卖、少卖等严重问题。

为了解决这个问题，可以采取以下策略：

1. 优化数据库事务： 通过合理设置数据库事务隔离级别，减小事务的范围，降低锁竞争，提高并发处理能力。合理使用事务的提交点，确保扣减库存和生成订单等关键操作的原子性。
2. 使用乐观锁： 在数据库层面引入乐观锁机制，通过版本号或时间戳等方式进行标记，减少锁的争用，提高并发性能。热点库存冲突率高时，乐观锁重试也会放大压力，应限制重试次数并按负载选择方案。
3. 分布式锁： 对于分布式系统，可以引入分布式锁，确保同一时刻只有一个请求能够扣减库存。分布式锁可以有效避免并发写入冲突。
4. 异步扣减： 将库存扣减操作异步化，通过消息队列等方式将扣减请求发送到异步处理队列中。这样可以降低同步扣减的压力，提高系统整体吞吐量。
5. 缓存预减：在 Redis 内通过 Lua 原子执行“检查可用库存不少于购买量，再扣减”；库存不足直接拒绝，不能等库存为负才到数据库扣减。预留成功后还需可靠落单，失败补偿和超时释放必须幂等。脚本原子性不等于 Redis 与数据库之间的事务原子性，参见 Redis Lua 执行机制。
6. 定时任务回补：只对已成功预留但最终取消或失败的订单释放库存，以预留记录和状态迁移作为依据，重复任务不能重复回补；未扣减成功的请求不应增加库存。

以上策略的选择应根据具体业务需求和系统架构来决定。综合考虑事务隔离级别、数据一致性、系统复杂度等因素，可以设计出更高效和稳定的库存扣减方案。

5. 黄牛抢购：

在秒杀业务中，由于商品存在差价，吸引了大量黄牛参与抢购，因此如何识别并阻挡这些黄牛的下单行为显得至关重要。

首先，防刷的核心在于检测可能是黄牛的用户，这涉及到风控领域，通常需要借助算法模型。通过分析用户的IP、设备信息、网络数据、行为模式等，可以推算出可能是黄牛的用户。

一旦识别出潜在的黄牛用户，需要对他们的流量进行防控。这可以通过以下手段实现：

• 用户ID黑名单： 将识别出的黄牛用户ID加入黑名单中。Nginx和业务系统都可以在流量过滤时检查黑名单，如果用户在黑名单中，直接拒绝请求。
• IP地址、设备限流： 对于黄牛用户的IP地址和设备进行限流。例如，限制某个IP地址在一段时间内只能下单几次。这可以利用令牌桶、漏桶等限流算法来实现。
• 借助限流工具： 利用诸如Nginx、Sentinel、Guava等限流工具，直接在系统层面进行流量控制。这些工具提供了强大的限流功能，能够有效防止过量的请求。

通过综合利用黑名单、限流算法和专门的防刷工具，可以提高系统对黄牛的防控能力，确保秒杀活动的公平性和稳定性。

6. 重复下单：

在秒杀业务中，用户频繁尝试下单支付可能导致重复下单问题，占用额外库存，最终导致少卖的情况。因此，需要采取一些手段来避免重复下单。

可给同一次业务请求分配幂等键，服务端通过唯一约束或原子写入绑定请求与订单，重试时返回原订单。页面 token 相同本身不能保证幂等，还需服务端原子处理并校验请求参数一致。

此外，在秒杀业务中通常存在限购策略，因此可以结合业务场景，判断用户是否已有在途订单，通过限购方式来防止用户重复下单。

然而，上述过程中可能存在并发情况，导致token检测和订单重复性判断时的并发问题。幂等性不必依赖显式分布式锁，也可由数据库唯一约束与事务保障。

通过引入锁机制，可以确保在并发场景下，同一用户不会重复下单。可以采用分布式锁，数据库乐观锁，或者业务层面的锁机制，并结合订单唯一约束、事务和失败恢复，防止重复扣减库存和生成重复订单。这有助于维护系统的稳定性和数据的准确性。

7. 对普通交易的影响：

秒杀通常作为电商网站的一个功能，往往与其他业务一同部署，包括服务器、缓存和数据库等资源。为避免秒杀业务对普通交易造成过大的影响，需要考虑隔离策略。

隔离可以采用逻辑隔离和物理隔离两种方式，具体实施视业务需求而定。

1. 物理隔离： 物理隔离是指将秒杀业务的前后端服务以及数据存储完全分离。这样可以确保秒杀活动对其他业务的影响最小化。前后端服务可以单独部署，甚至使用不同的服务器集群，以确保资源独立。
2. 逻辑隔离： 在应用层面进行逻辑隔离，即通过对数据进行标记或打标签的方式来区分秒杀订单和普通订单。例如，在订单和商品数据上添加标记，明确标识出哪些是秒杀订单。这样方便查询和分析，但标签本身不隔离资源竞争；还需独立线程池、连接池配额、队列和限流，防止秒杀耗尽普通交易资源。

综合考虑业务场景和系统复杂度，可以选择适当的隔离策略。物理隔离更彻底，但成本和复杂度也更高。逻辑隔离则相对灵活，能够在业务层面实现隔离效果，同时降低了部署和维护的难度。

5、应用程序中存在包冲突的情况下，怎么发现和解决

包冲突是指在应用程序中引入的不同版本的库或依赖之间存在冲突，可能导致编译错误、运行时异常或其他不稳定行为。解决包冲突通常需要以下步骤：

1. 诊断冲突： 确定哪些包发生了冲突，以及冲突的具体原因。可以通过查看编译日志、运行时异常信息或使用工具来分析依赖关系。
2. 查看依赖关系： 使用构建工具或依赖管理工具查看项目的依赖关系。对于Java项目，可以查看Maven的依赖配置文件。了解每个依赖项的版本以及它们之间的关系。
3. 升级或降级依赖版本： 如果发现包冲突是由于不同依赖项使用了相同库的不同版本而引起的，可以考虑升级或降级相关依赖项的版本，以便它们使用相同的库版本。
4. 排除依赖项： 对于某些依赖项，可以使用排除（exclusion）机制来排除特定的传递性依赖项。这样可以防止冲突的库被引入。
5. 在Maven中，可以使用 <exclusions> 元素：

<dependency>
    <groupId>example</groupId>
    <artifactId>example-artifact</artifactId>
    <version>1.0</version>
    <exclusions>
        <exclusion>
            <groupId>conflicting-group</groupId>
            <artifactId>conflicting-artifact</artifactId>
        </exclusion>
    </exclusions>
</dependency>

1. 使用类加载器隔离： 对于较为复杂的场景，可以考虑使用类加载器隔离机制，将不同版本的库加载到不同的类加载器中。这样可以在同一应用中使用不同版本的库而不会发生冲突。但需要注意，类加载器隔离可能引入新的问题，需要谨慎使用。
2. 统一兼容版本：优先遵循框架 BOM 和兼容矩阵，通过 dependencyManagement 统一版本；不要盲目把所有依赖升级到最新版。
3. 使用依赖检查工具：Maven Enforcer 的 dependencyConvergence 规则可检查依赖收敛，但不是依赖锁文件。Maven 3.9.x 通常按“路径最近优先，同深度先声明优先”仲裁传递依赖；dependencyManagement 管理版本并不自动引入依赖。可用 mvn dependency:tree -Dverbose 查看实际解析路径，定位运行时 NoSuchMethodError 等问题后再排除或统一版本。参见 Maven 依赖机制。

6、跨节点join查询如何实现

在分布式系统中，跨节点的Join查询是一个具有挑战性的问题，因为传统的关系数据库系统通常设计为在单一节点上执行Join操作。在分布式环境下，有一些常见的解决方案：

1. 数据复制： 将涉及到Join操作的表数据在分布式环境中的每个节点上都复制一份。这样，每个节点可以在本地执行Join操作而无需跨节点通信。这种方法虽然简单，但会导致数据冗余和一致性的问题。
2. 分布式Join算法： 开发专门的分布式Join算法，使得在分布式环境下也能高效执行Join操作。例如，MapReduce框架就提供了一些分布式Join的实现。这需要对数据进行划分和分布式计算。
3. 使用分布式数据库： 选择支持分布式Join的分布式数据库系统。一些分布式数据库提供了内建的分布式Join支持，可以在分布式环境中高效地执行Join查询。
4. 分片和合并： 将Join操作分解为可在每个节点上执行的部分，然后在一个中心节点上合并结果。这种方式需要设计合适的数据分片策略和结果合并机制。
5. 数据缓存： 在每个节点上缓存可能用于Join的数据片段，以减少跨节点通信的需求。这需要根据查询模式预先缓存可能用到的数据。
6. 消息传递： 使用消息传递机制，将涉及Join的查询分解为子查询，分发到各个节点执行，然后将结果进行合并。这需要有效的通信机制和任务协调。
7. 全局索引： 在所有节点上建立全局索引，以加速Join查询。这需要维护一致的全局索引，可能带来额外的维护成本。

7、Excel中百万级数据怎么导入到数据库

在处理百万级数据从Excel读取并插入到数据库的场景中，涉及到多方面的问题，需要综合考虑性能、内存占用、错误处理等因素。以下是一个可能的解决方案：

1. 内存溢出问题

使用流式读取方式，分批处理Excel数据。可使用 Apache POI 5.x 的 XSSF SAX/Event API 读取 .xlsx；SXSSF 主要用于流式写出，不是流式读取接口。现有 EasyExcel 项目也应采用监听器分批处理，避免在回调中累积全部行；流式读取并不能消除共享字符串、业务缓冲等内存开销。参见 Apache POI 读取与写出说明。

1. 性能问题

考虑多线程处理，使用线程池同时读取不同的sheet，以提升并发性能。对于数据插入操作，借助多线程和数据库的批量插入功能，进一步提高性能。

1. 错误处理

• 数据检查： 在读取和插入之前进行数据检查，处理数据格式错误、不一致等问题。
• 异常处理： 在插入过程中，对异常进行处理。采用自动重试机制，一定次数内尝试重新插入。记录日志以便后续分析。
• 数据重复处理： 设置Excel中某几个字段为数据库唯一性约束，处理数据重复问题。可以选择覆盖、跳过或报错，根据业务需求选择合适的方式。

整体方案

1. 用事件式读取逐行解析 Excel；默认单线程读取，确需并发时使用独立读取资源，避免多个线程共享非线程安全的工作簿对象。
2. 数据分批插入，设置一个批次大小，当达到批次大小时执行一次批量插入操作。
3. 使用有界队列（如指定容量的 ArrayBlockingQueue）连接读取与写入，写入变慢时阻塞生产者形成背压；无界的 ConcurrentLinkedQueue 即使线程安全也可能耗尽内存。失败重试需有导入批次/行标识，避免已提交批次被重复写入。

通过这种方案，能够在相对较短的时间内处理百万级数据的读取和插入，同时保证了内存的有效利用和错误处理的可靠性。具体的实现可以基于以上思路，结合实际项目需求和技术栈进行调整。

8、缓存预热怎么实现

在系统中进行缓存预热是为了提高系统性能和响应速度的一种策略。常见的缓存预热方案包括：

1. 启动过程中预热

一种常见的实现方式是在系统启动时进行缓存预热，特别适用于本地缓存。在Spring应用程序启动时，可以通过监听应用启动事件或在初始化阶段，将需要缓存的数据加载到缓存中。Spring提供了多个事件和扩展点，如ApplicationReadyEvent、CommandLineRunner、InitializingBean、@PostConstruct等，可用于执行预热逻辑。

2. 定时任务

定时任务是在系统运行过程中通过设定的时间间隔更新缓存，以确保缓存中的数据保持最新。在Spring中，可以使用@Scheduled注解轻松实现定时任务，适用于需要动态更新的情况。

3. 用时加载

请求到达后才加载属于懒加载，会让首次请求承担回源延迟；严格意义的预热是在流量到来前主动加载热点。示例代码如下：

public Data fetchData(String key) {
    // 先检查缓存中是否存在数据
    Data cachedData = cache.get(key);

    if (cachedData == null) {
        cachedData = loadFromSource(key); // 业务数据源
        if (cachedData != null) {
            cache.put(key, cachedData);
        }
    }
    
    return cachedData;
}

4. 缓存加载器

某些缓存框架提供了缓存加载器的机制，当缓存中不存在数据时，自动调用加载器加载数据到缓存中。例如，在Caffeine中可以使用LoadingCache实现，简化了缓存预热的逻辑。示例代码如下：

import com.github.benmanes.caffeine.cache.Caffeine;
import com.github.benmanes.caffeine.cache.LoadingCache;
import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

@Service
public class MyCacheService {

    private final LoadingCache<String, String> cache;
    
    public MyCacheService() {
        this.cache = Caffeine.newBuilder()
                .refreshAfterWrite(1, TimeUnit.MINUTES)  // 写入满1分钟后，再次访问时触发异步刷新
                .build(key -> loadDataFromSource(key));  // 使用加载器加载数据
    }
    
    public String getValue(String key) {
        return cache.get(key);
    }
    
    private String loadDataFromSource(String key) {
        return "value-for-" + key; // 示例占位，实际应查询数据源
    }
}

Caffeine 3.x 的 refreshAfterWrite 只使条目具备刷新资格，访问才触发异步刷新，期间通常返回旧值；不是每分钟自动扫描刷新。LoadingCache 构造时也不会自行加载全部数据，主动预热需调用 getAll(hotKeys) 等。参见 Caffeine Refresh。

9、表数据量大的时候只能分库分表？

当MySQL中的单表数据量庞大时，考虑分库分表通常是为了提升数据库吞吐量和查询效率。然而，分库分表方案的实现较为复杂，且可能引发一系列问题，如跨库事务、分页查询等。在采取分库分表之前，应优先考虑以下方案：

1. 数据库优化： 通过优化数据库结构、使用合适的索引、调整SQL语句等手段，可以有效提升查询性能。在2000万数据量级别，合理使用索引和进行表结构设计优化能够显著改善数据库性能。
2. 缓存： 减轻数据库压力可以通过缓存实现。在近端引入本地缓存或分布式缓存，能够迅速返回结果并减轻数据库负担，提高系统性能。
3. 分区：MySQL 8.4 分区仍是同一逻辑表，不减少总数据量或自动扩容到多台服务器。收益依赖查询条件能否触发分区裁剪，以及按分区归档/删除等维护需求；应结合 EXPLAIN 验证实际访问分区。参见 MySQL 分区裁剪。
4. 数据归档： 定期清理不再需要或不再活跃的数据，将其归档到辅助存储中（如历史表、离线数仓），可以减少数据量，进而提升数据库效率。
5. 分布式数据库： 考虑采用分布式数据库系统，充分利用多个节点分散数据，提高系统性能和容量。尽管分布式数据库成本较高，但相较于分库分表的改造而言，是否有收益需要根据事务语义、访问模式、迁移成本和实测结果判断。

这些方案在实施时需要根据具体业务场景和需求进行综合考虑，选择最适合的优化方案，以达到性能提升的效果。

10、线上发现一个接口响应很慢，怎么排查问题

• 监控工具：可以使用性能监控工具来实时监控接口的响应时间、吞吐量和错误率等指标。常见的监控工具：Arthas、Prometheus、Grafana、AppDynamics等。
• 日志分析：查看接口的日志文件，关注接口的执行时间、请求参数和响应结果等消息。同构分析可以找到执行时间较长的接口，以及可能导致慢接口的原因。
• 接口性能测试：通过模拟多用户并发请求，观察接口的响应时间和吞吐量等指标，找出慢响应的接口。常见的性能测试工具：JMeter、LoadRunner等。
• 数据库查询分析：如果接口涉及数据库查询，通过数据库查询分析工具（如EXPLAIN语句）来检查查询执行计划，确保数据库查询效率。
• 代码剖析：对接口代码进行剖析，了解代码中的性能瓶颈和耗时操作，通过剖析结果找到影响性能的代码段，进行优化，常见的剖析工具：Java Profiler、VisualVM等

11、MQ里面数据到达1000万的时候，怎么尽快消费掉

• 增加消费者数量: 消息堆积了，消费不过来了，那就把消费者的数量增加一下，让更多的实例来消费这些消息。
• 提升消费者消费速度：排查数据库、外部调用和锁等待等瓶颈，采用受控并发和批处理。业务提交成功后再确认；仅放进内存线程池就返回成功，会在进程崩溃时丢任务。若先落本地持久化任务表，需保证可恢复扫描和幂等执行。RabbitMQ 4.4 的确认语义参见 消费者确认。
• 降低生产者的生产速度：如果生产者可控的话，可以让生产者生成消息的速度慢一点。
• 清理过期消息：有一些过期消息、或者一直无法成功的消息，在业务做评估之后，如果无影响或者影响不大其实是可以清理的。
• 调整 RocketMQ 的配置参数: RocketMQ 提供了很多可配置的参数，例如消息消费模式、消息拉取间隔时间等，可以根据实际情况来调整这些参数，从而优化消息消费的效率。
• 增加Topic队列数: 如果一个 Topic 的队列数比较少，那么就容易出现消息堆积的情况。可以通过增加队列数来提高消息的处理并发度，从而减少消息堆积。

12、涉及到订单超卖问题怎么解决

订单超卖：就是当有两个并发线程同时查询库存商品，这时数据库中商品库存就剩1个，所以两个线程得到的库存数量都是1，然后经过库存校验之后分别开始进行库存扣减，最终导致库存被扣减成负数。

• 悲观锁：在同一显式事务内执行 SELECT ... FOR UPDATE、校验和扣减，事务提交或回滚后释放锁；仅在自动提交模式执行一次查询，不能保护后续独立更新。
• 乐观锁：更新条件同时校验版本和 stock >= quantity，成功后递增版本；版本匹配本身不代表库存充足，冲突时应有界重试或返回失败。
• 限流：对订单的创建进行限流，防止短时间内大量订单的涌入，从而减小并发冲突的可能性。可以使用令牌桶算法或漏桶算法来实现限流；

限制同一IP在一定时间内只能发送一个请求。可以通过在网关中自定义全局过滤器来实现IP限流；

限制接口每秒只接受一定数量的请求。可以使用Sentinel的限流功能；

• 库存预留：在用户下单时，先检查库存是否足够，并将一部分库存标记为已预留状态。在订单支付完成后再确认扣减库存。
• 缓存：单条 DECRBY 或负数 INCRBY 虽然原子，却允许扣成负数；检查与扣减应放进同一 Lua 脚本，并处理缓存与数据库之间的可靠同步和补偿。
• 消息队列：异步处理可以削峰，但多消费者不天然串行，全局有序也不是默认保证。仍需原子扣减、幂等处理与失败补偿；限流只是减压，不能代替库存正确性约束。

单库库存扣减可先采用下面的条件更新（MySQL 8.4 / InnoDB，sku_id 为主键，购买量必须为正整数）：

UPDATE inventory
SET stock = stock - ?
WHERE sku_id = ? AND stock >= ?;
-- 第一个和第三个参数都是同一购买量；影响行数为 1 才允许继续创建订单。

检查与扣减在同一条更新内完成，InnoDB 通过记录锁协调并发，避免两个请求都根据旧库存通过检查。扣减和订单写入应在同一事务内提交，写单失败则回滚；幂等键唯一约束防止同一请求重复扣减。跨库订单不能直接套用本地事务结论，需要库存预留、可靠消息与补偿机制。

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

Spring

版本说明：以下容器与事务机制以 Spring Framework 6.2.x、Spring Boot 3.5.x 为基线；旧版组件另行注明。

1、SpringBean的作用域
参考回答： singleton：默认作用域，每个容器内每个 Bean 定义对应一个实例，不是整个 JVM 只有一个对象。共享可变状态仍需并发控制。
prototype：每次向容器获取该 Bean 时创建新实例；直接注入单例 Bean 时，仅在该单例创建时解析一次，不会随业务方法调用重新创建。需要按次获取可注入 ObjectProvider<T> 并调用 getObject()。
request：每次HTTP请求都会创建一个新的Bean实例。每个请求的Bean实例对于该请求是唯一的。这个作用域仅在基于Web的Spring ApplicationContext中有效。适用于处理HTTP请求的控制器或服务。
session：在一个HTTP会话（Session）中，定义一个Bean实例。对于同一用户的所有请求，都将使用相同的Bean实例。这个作用域也仅在基于Web的Spring ApplicationContext中有效，适用于保存用户特定的数据或状态。
application：每个 ServletContext 一个实例；websocket：每个 WebSocket 会话一个实例。历史 globalSession 属于旧 Portlet 支持，Spring 6.2 的 Servlet 应用没有这个内置作用域，也不会自动等同于 session。参见 Bean 作用域。
2、SpringBean的生命周期
参考回答： 实例化：容器依据 BeanDefinition，通过构造器、工厂方法等创建对象；构造器依赖在此时解析。BeanFactoryPostProcessor 在常规 Bean 实例化前处理 Bean 定义，不是每个 Bean 实例化中的回调。非懒加载单例通常在上下文刷新时预实例化。
属性赋值：Spring IoC容器在创建Bean的过程中，会将Bean在XML文件中配置的属性值和BeanDefinition中的属性值设置到Bean中。这个过程也称为依赖注入（DI），可以通过构造方法注入、Setter方法注入等方式完成。
Bean后处理器（BeanPostProcessor）处理：在Bean的实例化和属性赋值之后，Spring会调用BeanPostProcessor的postProcessBeforeInitialization方法，对Bean进行进一步的处理。这是一个可选的步骤，开发者可以通过实现BeanPostProcessor接口并覆盖相应的方法来定义自己的处理逻辑。
初始化：通常按 @PostConstruct → InitializingBean.afterPropertiesSet() → 自定义 init-method 的顺序执行（同一个方法不会重复调用）。@PostConstruct 由后置处理器在初始化前阶段触发；Spring 6 使用 jakarta.annotation.PostConstruct。
实例化后处理：在Bean完成初始化之后，Spring会再次调用BeanPostProcessor的postProcessAfterInitialization方法，对Bean进行最后的处理。这也是一个可选的步骤，开发者可以在这里添加一些额外的逻辑，例如对Bean进行代理等。
使用：此时Bean已经准备就绪，可以被应用程序使用了。Spring容器会管理Bean的生命周期，并在需要的时候将其提供给应用程序。
销毁：受容器管理的单例在正常关闭时依次执行 @PreDestroy、DisposableBean.destroy()、自定义 destroy-method。prototype 创建后交给调用者，容器不自动执行其销毁回调。参见 生命周期回调。
3、Spring AOP原理
参考回答： Spring AOP（Aspect Oriented Programming，面向切面编程）的原理主要基于动态代理模式，用于在不修改原有业务代码的前提下，为多个目标对象统一管理并增加额外功能。其核心概念包括切面（Aspect）、连接点（Join Point）、通知（Advice）等。
切面（Aspect）：封装横切关注点的模块，由切点与通知等组成；切点决定匹配哪些方法执行，通知定义何时执行什么逻辑。
连接点（Join Point）：Spring AOP 只支持 Spring Bean 的方法执行连接点，不支持构造器调用或字段访问；更广的连接点属于 AspectJ 的能力。
通知（Advice）：通知包括各种类型的切面代码，如前置通知、后置通知、环绕通知、异常通知和最终通知等。这些通知会在连接点执行时被触发。
Spring AOP以动态代理技术为主要方式进行织入。具体来说，当目标对象的方法被调用时，Spring AOP会检查该方法是否是一个连接点。如果是，则会在方法执行前后（或者方法执行过程中）织入相应的通知代码。这些通知代码可以在不修改原有业务代码的情况下，为目标对象增加额外的功能。
4、Spring事务传播机制
参考回答： REQUIRED（默认）：
如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
SUPPORTS：
如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
MANDATORY：
如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
REQUIRES_NEW：
创建独立物理事务，并挂起当前事务；内外事务可分别提交或回滚，但异常若继续传播仍可能触发外层回滚。外层资源未释放，内层可能再占用连接，需要关注连接池容量。
NOT_SUPPORTED：
以非事务方式运行，如果当前存在事务，则把当前事务挂起。
NEVER：
以非事务方式运行，如果当前存在事务，则抛出异常。
NESTED：
如果当前存在事务，通常在同一个物理事务内创建保存点，内层失败可回滚到保存点；外层整体回滚时内层结果也一起回滚。无事务时按 REQUIRED 开启事务。该能力依赖事务管理器及资源支持，常见于 JDBC 保存点，不能假设 JPA/JTA 均支持。参见 事务传播机制。
5、什么是Spring的循环依赖问题？（了解）
参考回答： Spring的循环依赖问题是指在Spring容器中，两个或多个Bean之间相互依赖，形成了一个循环引用的情况。具体来说，当一个Bean A依赖于另一个Bean B，而Bean B又依赖于Bean A时，就可能出现循环依赖的问题。
6、什么是spring三级缓存以及如何解决循环依赖（重要）
参考回答： singletonObjects 保存完成创建的单例；earlySingletonObjects 保存已取得的早期引用；singletonFactories 保存获取早期引用的 ObjectFactory。工厂捕获已实例化的对象，按需返回原对象或早期代理，不会再次构造 Bean。这些是容器对象缓存，不是数据库查询缓存。详细机制见下方保留的“Srping 一级、spring二级、三级缓存是如何解决循环依赖的”章节。
6、spring事务失效的原因？
参考回答： 方法不可代理：注解名为 @Transactional。Spring 6.0 起，基于类的事务代理默认支持 protected 和包可见方法；JDK 接口代理要求 public 且在接口中声明。private 方法不能被代理，类代理也不能增强 final 方法，不能笼统说非 public 都无效。
类没有被Spring管理：Spring事务是由AOP机制实现的，AOP机制的本质就是动态代理。从Spring IOC容器获取bean时，Spring会为目标类创建代理，从而支持事务。如果类没有被Spring容器管理（例如，没有添加@Service、@Component等注解），则Spring无法为目标类创建代理，事务也会失效。
异常被捕获且未正确处理：默认情况下，Spring只有在方法抛出运行时异常或者错误时才会回滚事务。如果事务方法内部抛出了异常，但该异常被catch语句捕获且没有重新抛出，或者捕获的异常类型不是运行时异常，那么事务将不会回滚。
事务属性设置不当：如果在Spring的事务管理中，事务的传播特性（propagation）或回滚规则（rollbackFor）设置不当，也可能导致事务失效。例如，如果在一个支持当前事务的方法中调用了需要新事务的方法，并且后者方法抛出了异常，但异常并未被Spring识别为需要回滚事务的异常，那么后者的事务将不会回滚。
数据库配置问题：如果数据库配置不支持事务（例如，使用了不支持事务的数据库引擎），或者数据库本身就是不支持事务的，那么Spring事务也会失效。
调用同一个类中的方法：默认代理模式下，this.inner() 绕过代理，即使 inner 标有 @Transactional，也不会触发它的传播或回滚规则；如果 outer 已开启事务，inner 的数据库操作仍可能参与外层事务。应通过另一个受管 Bean 的代理调用需要独立事务边界的方法。参见 声明式事务。
事务嵌套使用不当：在一个已经开启了事务的方法中再次开启事务，对于Spring的PROPAGATION_REQUIRED模式（默认模式），它只会用原来的事务，这可能导致预期之外的行为。
7、spring bean是否为线程安全的？
参考回答： 作用域不等于线程安全。单例可以是无状态且线程安全的；共享可变字段需同步或并发设计。prototype 即使每次获取都创建新对象，也可能被单例长期持有或传给多个线程，不能据此保证无共享。
8、spring中用到的设计模式？
参考回答： 工厂模式（Factory Pattern）：
Spring使用工厂模式通过BeanFactory、ApplicationContext等接口创建并管理对象实例。这种方式将对象的创建与使用解耦，使得程序更加灵活和可扩展。
单例模式（Singleton Pattern）：
Spring中的Bean默认都是单例的，即在整个Spring IoC容器中，每个Bean只会有一个实例。这通过Bean的scope属性进行控制，当scope为singleton时，即表示使用单例模式。
代理模式（Proxy Pattern）：
在AOP（面向切面编程）和remoting中被广泛使用。Spring AOP的实现基于动态代理模式，可以在运行时动态地将代码切入到类的指定方法、指定位置上。
模板方法模式（Template Method Pattern）：
解决代码重复问题。Spring中例如JdbcTemplate就是模板方法模式的体现，它封装了数据访问的底层操作，定义了数据访问的骨架，使得开发者可以只关注自己的业务SQL。
前端控制器模式（Front Controller Pattern）：
Spring MVC中的DispatcherServlet就是前端控制器模式的实现，它负责接收请求，并根据请求信息调用相应的处理器（Controller）进行处理。
依赖注入模式（Dependency Injection Pattern）：
贯穿于BeanFactory和ApplicationContext接口的核心理念。通过依赖注入，Spring可以在运行时动态地将一个对象所需要的外部依赖注入到该对象中，从而降低了代码的耦合度。
装饰器模式（Decorator Pattern）：
在Spring中，BeanWrapper是一个很好的装饰器模式的例子。它允许你在运行时动态地给一个对象添加一些额外的职责。
委派模式（Delegation Pattern）：
在Spring MVC中，DispatcherServlet就是一个典型的委派模式的例子。它接收请求，但并不处理请求，而是将请求委派给相应的控制器进行处理。
策略模式（Strategy Pattern）：
在Spring中，HandlerMapping接口的实现类就使用了策略模式。它定义了一个处理请求的接口，具体的处理策略由实现类来完成。
适配器模式（Adapter Pattern）：
在Spring MVC中，HandlerAdapter接口的实现类就使用了适配器模式。它将不同的处理器（Controller）适配成统一的接口，使得DispatcherServlet可以统一调用。
观察者模式（Observer Pattern）：
在Spring的事件驱动模型中，使用了观察者模式。当某个事件发生时，会通知所有注册的观察者（Listener）进行处理。
能说一部分就行了
9、Spring IOC
参考回答： Spring IoC（Inversion of Control，控制反转）是Spring框架的核心特性之一。它的基本思想是将对象的创建和管理过程从应用程序代码中抽离出来，由Spring容器负责创建和管理对象之间的依赖关系。通过这种方式，应用程序代码不再需要直接创建和管理对象，而是向Spring容器发出请求，由容器负责创建和返回所需的对象。
Spring IoC的主要优点包括：
降低耦合性：通过IoC容器来管理对象之间的依赖关系，使得系统更加模块化、可测试和易于扩展。
提高灵活性和可维护性：由于对象的创建和管理由Spring容器负责，因此可以更加灵活地配置和修改对象的行为。同时，由于代码不再包含对象的创建和管理逻辑，因此可以更加专注于业务逻辑的实现，提高代码的可维护性。
支持多种配置方式：Spring IoC支持多种配置方式，包括XML配置、注解配置和Java配置等。这些配置方式可以根据项目的实际需求进行灵活选择和使用。
在实现Spring IoC时，有三种主要的方式：
使用XML实现Spring IoC：通过编写XML配置文件来定义和配置Bean，将配置信息集中在一个XML文件中进行管理。
使用注解方式实现Spring IoC：通过在类和方法上添加注解来定义和配置Bean，使得配置更加简洁、直观，并且减少了对XML文件的依赖。
使用JavaConfig实现Spring IoC：通过编写Java配置类来定义和配置Bean，将配置信息集中在一个Java类中，提供了一种更加面向对象和类型安全的配置方式。
10、spring AOP在项目中的应用场景？
参考回答： 日志记录：在系统中记录日志是非常重要的，可以使用AOP来实现日志记录的功能。通过在方法执行前、执行后或异常抛出时记录日志，可以方便地跟踪系统的运行情况和问题排查。
事务管理：在数据库操作或其他需要事务管理的操作中，使用AOP可以将事务管理的逻辑与业务逻辑分离，使得事务的控制更加简单和集中。通过AOP，可以在方法开始前开启事务，在方法执行完毕后提交或回滚事务，以确保数据的一致性和完整性。
安全控制：在系统中包含某些需要安全控制的操作，如登录、修改密码、授权等，可以使用AOP来实现安全控制的功能。通过AOP，可以在方法调用前进行安全性检查，例如检查用户的权限或身份验证，以确保只有授权用户可以访问特定的方法或资源。
性能监控：在系统运行过程中，有时需要对某些方法的性能进行监控，以找到系统的瓶颈并进行优化。通过AOP，可以在方法调用前后记录方法的执行时间，以监控和优化系统的性能。
缓存控制：在系统中有些数据可以缓存起来以提高访问速度，可以使用AOP来实现缓存控制的功能。通过AOP，可以在方法执行前查询缓存中是否有数据，如果有则返回，否则执行方法并将方法返回值存入缓存中。
异常处理：使用AOP，可以集中处理方法中抛出的异常，例如将异常转换为统一的错误码或进行日志记录。这有助于更好地管理和监控异常，并降低异常对系统的影响。
参数校验和转换：使用AOP，可以在方法调用前对方法的参数进行校验和转换，以确保参数的有效性和符合业务要求。这有助于减少因参数问题导致的错误和异常，并提高系统的健壮性。
12、Spring中如何开启事务？
参考回答： 编程式事务：
编程式事务是通过编程的方式自己去实现事务，比如事务的开启、提交、回滚操作，需要开发人员自己调用commit()或者rollback()等方法来实现。
这种事务管理方式需要在逻辑代码中手动书写事务控制逻辑，因此是侵入性的。它的缺点是代码复用性差，每一个事务都需要自己编写事务逻辑，可能会造成代码冗余。然而，它的优点在于事务边界更容易控制，可以在业务的任意位置进行事务提交或者回滚操作。
声明式事务：
声明式事务则是通过配置或注解的方式，将事务管理逻辑与业务逻辑进行分离，由Spring框架来自动处理事务的开启、提交和回滚。
使用声明式事务时，通常在受管业务类或方法上标注 @Transactional，通过代理调用后由事务管理器按传播规则开启或参与事务。默认仅 RuntimeException 和 Error 导致回滚，受检异常需配置 rollbackFor；捕获异常也不代表一定可提交，事务可能已被标为 rollback-only。
普通 Spring Java 配置通常还需 @EnableTransactionManagement 和适当的事务管理器；Spring Boot 在满足自动配置条件时会启用事务管理，不必重复添加该注解。
13、Spring ioc在项目中的应用场景？（了解）
参考回答： 解耦与模块化：
在复杂的系统中，各个组件之间可能存在复杂的依赖关系。使用Spring IoC，可以将这些依赖关系交由Spring容器管理，使得组件之间的耦合度降低，提高了系统的模块化程度。
依赖注入：
Spring IoC支持依赖注入（Dependency Injection, DI），这意味着Spring容器会自动将所需的依赖项注入到对象的实例中。这使得开发者无需在代码中手动创建和管理依赖对象，从而简化了代码并提高了可读性。
配置集中管理：
Spring IoC允许开发者将配置信息（如数据库连接信息、第三方服务接口地址等）集中在一个或多个配置文件中（如XML文件、Java配置类或YAML文件）。这样，当配置信息需要变更时，只需修改配置文件而无需修改代码。
插件化开发：
在一些大型系统中，可能需要支持多种插件或扩展。通过使用Spring IoC，可以将这些插件或扩展作为独立的组件进行开发，并通过配置文件或注解将它们集成到系统中。这使得插件的添加、删除和替换变得更加容易。
测试支持：
在测试过程中，可能需要模拟或替换某些组件的依赖项。Spring IoC提供了方便的测试支持，允许开发者在测试环境中注入模拟对象或测试数据，从而验证系统的正确性。
动态代理：
Spring IoC结合AOP（Aspect-Oriented Programming，面向切面编程）可以实现动态代理。动态代理允许开发者在不修改原始代码的情况下，为类添加额外的功能（如日志记录、事务管理、性能监控等）。这使得系统的功能扩展变得更加灵活和方便。
容器化应用：
在云原生和微服务架构中，应用通常以容器的形式部署。Spring IoC作为Spring框架的核心特性之一，可以与容器化技术（如Docker、Kubernetes等）很好地结合使用。通过Spring IoC管理应用的依赖关系，可以确保应用在容器化环境中能够正常运行并与其他服务进行交互。
14、SpringBoot和Spring的区别是什么？（了解）
参考回答： 设计理念：Spring是一个全面的框架，它提供了许多功能，但同时也增加了项目的复杂度。相反，Spring Boot旨在简化Spring应用程序的初始搭建和开发过程，尽可能自动配置Spring应用程序。基于“约定优于配置”的原则，Spring Boot简化了项目的配置流程。
创建独立应用：Spring Boot可以创建独立的Spring应用程序。它集成了Tomcat、Jetty和Undertow等服务器，并且不需要部署它们。这意味着开发者可以直接打包他们的应用程序为一个可执行的JAR或WAR文件，从而简化了部署过程。
配置：在Spring中，我们需要进行大量的XML配置、JavaConfig和注解处理，以整合各种组件。而在Spring Boot中，它使用了特定的方式来进行配置，极大地简化了这些文件的配置过程。例如，Spring Boot引入了“starters”的概念，这些是预先配置好的Maven依赖项，可以简化Maven配置。
嵌入式容器：Spring Boot嵌入了一个Web服务器（如Tomcat、Jetty或Undertow），这使得应用程序可以作为一个独立的可执行JAR或WAR文件运行，而不需要单独的服务器或容器。
自动配置：Spring Boot的强大之处在于其自动配置功能。它通过检查项目的类路径、属性设置和其他条件，自动为你配置Spring应用程序。例如，如果你在类路径中添加了H2数据库，Spring Boot会自动为你配置一个内存数据库。
依赖管理：在Spring Boot中，你只需要引入相应的starter依赖，就可以快速地整合第三方库和框架。这种依赖管理方式使得项目结构更加清晰，减少了版本冲突的可能性。
15、springBean的初始化过程？
参考回答： Bean的定义：
在Spring配置中定义Bean的信息，包括类名、属性、作用域等。
Bean的加载和解析：
Spring容器启动时，加载并解析配置文件或注解，生成BeanDefinition对象。
实例化Bean：
根据BeanDefinition，通过反射创建Bean实例。如果是单例Bean，会被缓存起来。
依赖注入：
为Bean注入所需的依赖，方式包括构造器注入、setter方法注入和字段注入。
初始化前处理：
如果存在BeanPostProcessor，调用其postProcessBeforeInitialization方法，对Bean进行初始化前的定制化处理。
调用初始化方法：
执行Bean的初始化方法，可能包括：
实现InitializingBean接口的afterPropertiesSet方法。
在配置中指定的init-method方法。
使用@PostConstruct注解的方法。
初始化后处理：
如果存在BeanPostProcessor，调用其postProcessAfterInitialization方法，对Bean进行初始化后的定制化处理，如AOP代理等。
Bean的就绪和使用：
经过上述步骤，Bean已完全初始化，可以通过getBean()方法获取并使用。
16、如何在Spring启动过程中做缓存预热？
参考回答： 监听应用启动事件：Spring框架提供了多种方式来监听应用启动事件，以便在应用启动后执行特定的逻辑。你可以使用@EventListener注解或实现ApplicationListener接口来监听ApplicationReadyEvent事件。当这个事件被触发时，意味着Spring应用已经启动并准备好接受请求了。
使用CommandLineRunner或ApplicationRunner：如果你不想直接监听ApplicationReadyEvent事件，你也可以使用CommandLineRunner或ApplicationRunner接口。这两个接口都定义了一个run方法，Spring Boot会在所有Spring Beans都初始化完成之后调用这个方法。
使用@PostConstruct注解：方法在依赖注入后、Bean 初始化阶段执行，不是构造函数结束后立即执行；此时整个应用未必已就绪，不应依赖该 Bean 的事务代理进行预热。ApplicationReadyEvent、CommandLineRunner 和 ApplicationRunner 均属于 Spring Boot API。
17、spring中常用注解？
参考回答： 组件注解：
@Component：用于标识一个类为Spring的组件，可以被自动扫描并注册为Bean。
@Controller：用于标识一个类为控制器层（Controller）组件，通常用于处理HTTP请求。
@Service：用于标注业务逻辑层组件，即Service层。
@Repository：用于标识一个类为数据访问层（DAO）组件，用于操作数据库。
@RestController：结合@Controller和@ResponseBody，用于标识一个类为RESTful风格的控制器，用于返回JSON或XML数据。
注入注解：
@Autowired：由Spring提供，用于自动注入依赖。它默认按类型匹配的方式在容器查找匹配的Bean，当有且仅有一个匹配的Bean时，Spring将其注入到标注的变量中。
@Qualifier：与@Autowired配合使用，用于在存在多个相同类型的Bean时，指定要注入的Bean的名称或限定符。
@Resource：与@Autowired类似，但除了按类型匹配外，还支持按名称匹配。
@Value：用于注入配置文件中的值或表达式的结果，例如注入一个字符串或数字常量。
Java配置类相关注解：
@Configuration：用于标识一个类为配置类，通常与@Bean一起使用，以替代传统的XML配置文件。
@Bean：注解在方法上，声明当前方法的返回值为一个Bean，用于在配置类中定义Bean。
切面（AOP）相关注解：
@Aspect：声明一个切面，用于定义通知（Advice）和切点（Pointcut）。
@Before、@After、@AfterReturning、@AfterThrowing、@Around：这些注解用于定义通知，分别表示在方法执行前、后、返回后、抛出异常后和环绕方法执行通知。
其他常用注解：
@RequestMapping：用于映射Web请求到特定的处理器方法。
@PathVariable：用于从URI模板变量中解析值，并绑定到方法参数上。
@RequestParam：用于从请求参数中解析值，并绑定到方法参数上。
@RequestBody：用于将HTTP请求正文转换为Java对象。
@ResponseBody：用于将Java对象转换为HTTP响应正文。
18、spring中注入方式？
参考回答： set()方法注入；
构造器注入：①通过index设置参数的位置；②通过type设置参数类型；
静态工厂注入；
实例工厂；
19、spring中单例Bean是线程安全的吗？
参考回答： 单例本身不保证线程安全，也不必然不安全；关键是是否共享可变状态及如何同步。优先让服务保持无状态，将请求数据放在方法局部变量中；仅将 singleton 改成 prototype 不能修复所有并发问题，尤其是直接注入单例时仍只注入一次。
20、SpringMVC的执行流程?
用户发送请求至前端控制器 DispatcherServlet。
DispatcherServlet 收到请求调用 HandlerMapping 处理器映射器。
处理器映射器找到具体的处理器(可以根据 xml 配置、注解进行查找)，生成处理器及处理器拦截器(如果有则生成)一并返回给 DispatcherServlet。
DispatcherServlet 调用 HandlerAdapter 处理器适配器。
HandlerAdapter 经过适配调用具体的处理器(Controller，也叫后端控制器)
Controller 执行完成返回 ModelAndView。
HandlerAdapter 将 controller 执行结果 ModelAndView 返回给 DispatcherServlet。
DispatcherServlet 将 ModelAndView 传给 ViewReslover 视图解析器。
ViewReslover 解析后返回具体 View。
DispatcherServlet 根据 View 进行渲染视图（即将模型数据填充至视图中）。
DispatcherServlet 响应用户。

21、解释一下DispatcherServlet的作用？(了解)
DispatcherServlet是Spring MVC的前端控制器，它负责接收所有的HTTP请求，并根据请求的类型和内容，将请求分发到相应的Controller进行处理。同时，它也负责将Controller返回的结果传递给视图进行渲染。
22、Spring MVC的主要组件？（了解）
Spring MVC的主要组件包括DispatcherServlet（前端控制器）
HandlerMapping（处理器映射器）
HandlerAdapter（处理器适配器）
Controller（控制器）
ModelAndView（模型和视图）
ViewResolver（视图解析器）。
23、SpringMVC 的常用注解有哪些？
@RequestMapping ：用于处理请求 url 映射的注解，可用于类或方法上。用于类上，则表示类中的所有响应请求的方法都是以该地址作为父路径；
@RequestBody ：注解实现接收 HTTP 请求的 json 数据，将 json 转换为 Java对象；
@ResponseBody ：注解实现将 Controller 方法返回对象转化为 json 对象响应给客户
24、@Controller注解的作用？（了解）
在Spring MVC 中，控制器Controller 负责处理由DispatcherServlet 分发的请求，它把用户请求的数据经过业务处理层处理之后封装成一个Model ，然后再把该Model 返回给对应的View 进行展示。在Spring MVC 中提供了一个非常简便的定义Controller 的方法，你无需继承特定的类或实现特定的接口，只需使用@Controller 标记一个类是Controller ，然后使用@RequestMapping 和@RequestParam 等一些注解用以定义URL 请求和Controller 方法之间的映射，这样的Controller 就能被外界访问到。此外Controller 不会直接依赖于HttpServletRequest 和HttpServletResponse 等HttpServlet 对象，它们可以通过Controller 的方法参数灵活的获取到。
@Controller 用于标记在一个类上，使用它标记的类就是一个Spring MVC Controller 对象。分发处理器将会扫描使用了该注解的类的方法，并检测该方法是否使用了@RequestMapping 注解。@Controller 只是定义了一个控制器类，而使用@RequestMapping 注解的方法才是真正处理请求的处理器。单单使用@Controller 标记在一个类上还不能真正意义上的说它就是Spring MVC 的一个控制器类，因为这个时候Spring 还不认识它。那么要如何做Spring 才能认识它呢？这个时候就需要我们把这个控制器类交给Spring 来管理。有两种方式：
在Spring MVC 的配置文件中定义MyController 的bean 对象。
在Spring MVC 的配置文件中告诉Spring 该到哪里去找标记为@Controller 的Controller 控制器。
25、Spring事务的实现方式和原理以及隔离级别？
在使用Spring框架时，可以有两种使用事务的方式，一种是编程式的，一种是申明式的， @Transactional注解就是申明式的。
首先，事务这个概念是数据库层面的，Spring只是基于数据库中的事务进行了扩展，以及提供了一些能让程序员更加方便操作事务的方式。
比如通过代理调用 @Transactional 方法时，同一线程、同一事务资源且参与同一事务的 SQL 可统一提交或回滚；新线程、独立事务和其他数据源不会自动纳入这一原子边界。
事务拦截器读取事务属性，委托 PlatformTransactionManager 获取、提交或回滚事务；以 JDBC 新事务为例通常会关闭连接的自动提交，不能将这一细节泛化为所有事务管理器。正常返回也可能因 rollback-only 标记而回滚。
当然，针对哪些异常回滚事务是可以配置的，可以利用@Transactional注解中的rollbackFor属性进行配置，默认情况下会对RuntimeException和Error进行回滚。
spring事务隔离级别：
ISOLATION_DEFAULT：这是个 PlatfromTransactionManager 默认的隔离级别，使用数据库默认的事务隔离级别。
ISOLATION_READ_UNCOMMITTED：读未提交，允许事务在执行过程中，读取其他事务未提交的数据。
ISOLATION_READ_COMMITTED：读已提交，允许事务在执行过程中，读取其他事务已经提交的数据。
ISOLATION_REPEATABLE_READ：防止脏读和不可重复读，但按隔离级别定义仍可能有幻读，实际行为取决于数据库实现和读取方式。
ISOLATION_SERIALIZABLE：保证并发执行的效果等价于某个串行顺序，不代表数据库必须让所有事务物理上逐个执行。

阅读提示

这页建议按“进程线程 -> 内存 -> 调度 -> IO”顺序复习。
面试时优先说结论和场景，再补原理细节，回答会更像真实项目参与者。

适用范围：操作系统机制以带 MMU 的 Linux 为例；Linux API 语义参考 Linux man-pages，调度补充区分 Linux 6.6 起的变化。Java 示例以 Java SE 21 为基线，区分平台线程和 Java 21 正式引入的虚拟线程，不把 JVM 内存区域当作所有语言的操作系统概念。

快速导航

1. 先掌握：进程/线程、用户态/内核态、上下文切换。
2. 再掌握：死锁、内存分页、页面置换。
3. 冲刺补强：IO 模型、零拷贝、调度策略。

1、进程和线程的区别是什么？

回答提示：

• 进程是资源分配的基本单位，线程是 CPU 调度的基本单位。
• 操作系统线程共享进程的地址空间、打开的文件等资源，各有寄存器上下文和栈。Java 层面，堆和方法区由线程共享，程序计数器与 JVM 栈线程私有；本地方法栈由具体 JVM 实现决定，不能将这些 JVM 术语直接推广到其他语言。
• 进程切换成本通常高于线程切换，因为涉及更多资源状态的保存与恢复。

参考回答：

• 进程更像“独立车间”，线程更像“车间里的工人”。
• 多进程隔离性更好，稳定性高；多线程通信更方便，开销更小。
• Java 平台线程常通过线程池复用，减少创建和销毁成本。Java 21 虚拟线程由 JVM 调度到承载它的少量平台线程上，适合大量等待 IO 的任务，通常每任务创建一个虚拟线程，无须池化虚拟线程；CPU 密集任务仍受可用 CPU 限制。

依据：JVMS 21 运行时数据区、Java 21 虚拟线程指南。

2、并发和并行有什么区别？

回答提示：

• 并发：同一时间段内处理多个任务，宏观同时，微观可能轮流执行。
• 并行：同一时刻多个任务同时执行，通常依赖多核 CPU。

参考回答：

• 单核 CPU 主要是并发，多核 CPU 能实现并行。
• 面试中可以补一句：我们平时说“并发编程”，工程上通常是“并发 + 并行”混合场景。

3、什么是用户态和内核态？为什么要区分？

回答提示：

• 用户态权限受限，不能直接访问硬件和关键内核资源。
• 内核态权限高，可以执行特权指令和硬件操作。
• 通过权限隔离提升系统稳定性和安全性。

参考回答：

• 应用代码大多运行在用户态，涉及磁盘、网络、进程管理等能力时，通过系统调用陷入内核态。
• 这种分层设计避免了业务程序直接操作硬件导致系统崩溃。

4、什么是系统调用？

回答提示：

• 系统调用是用户程序访问内核服务的标准入口。
• 常见系统调用：read、write、open、close、fork。

参考回答：

• 应用层无法直接操作设备，必须通过系统调用由内核代为执行。
• 一次真正的系统调用会进入内核并返回用户态，但不一定切换到另一个线程：权限级别切换与调度上下文切换是两回事。调用阻塞或发生抢占时才可能调度其他线程。

5、线程上下文切换为什么昂贵？

回答提示：

• 需要保存和恢复寄存器、程序计数器、栈指针等上下文。
• 工作集变化或迁移到另一 CPU 可能降低缓存命中率；同一进程的线程共享地址空间，切换并不必然刷新 TLB，也不会必然清空 CPU 缓存。地址空间切换及 TLB 保留策略取决于 CPU 和内核实现。
• 切换本身不做业务计算，属于纯开销。

参考回答：

• 并发不是线程越多越好。线程数过高会把时间花在切换而非计算上。
• 在 Java 项目中应结合任务类型和 CPU 核数配置线程池，而不是盲目放大。

6、进程通信（IPC）方式有哪些？

回答提示：

• 匿名管道（Pipe）：Linux 中是单向字节流，常通过继承文件描述符用于有亲缘关系的进程；双向通信可用两条管道。命名管道（FIFO）可供具有相应权限的无亲缘关系进程打开。
• 消息队列：按消息传递，解耦较好。
• 共享内存：速度快，但要配合同步机制。
• 信号量：用于并发控制。
• Socket：既可用于跨主机通信（TCP/UDP），也可通过 Unix domain socket 用于本机 IPC。

管道语义依据：Linux pipe(7)。

参考回答：

• 本机高性能场景常用共享内存 + 锁；跨机器服务通信一般使用 Socket（如 TCP）。

7、线程同步方式有哪些？

回答提示：

• 互斥锁：同一时刻只允许一个线程访问临界区。
• 读写锁：读共享、写独占，适合读多写少。
• 信号量：控制并发访问资源数量。
• 条件变量：线程间等待/通知协作。

参考回答：

• Java 中常见实现对应 synchronized、ReentrantLock、ReadWriteLock、Semaphore、Condition。
• 选型关键是冲突比例、是否可中断、公平性和可重入需求。

8、死锁产生的条件与避免方式

回答提示：

• 四个必要条件：互斥、请求并保持、不可剥夺、循环等待。
• 破坏任意一个条件即可避免死锁。

参考回答：

• 工程上可通过统一加锁顺序破坏循环等待；使用可超时的锁时，超时后必须释放已持有的锁并退出或退避重试。单纯缩小临界区只降低冲突，不能保证消除死锁。
• 排查时可结合 jstack、线程 dump、监控告警定位阻塞链路。

9、什么是虚拟内存？为什么需要它？

回答提示：

• 给每个进程提供独立的虚拟地址空间；其中可以有未映射的空洞，虚拟地址连续也不代表物理页连续。
• 通过页表映射到物理内存，实现隔离、扩展和按需加载。

参考回答：

• 虚拟地址空间可以大于物理内存，但不保证所有申请都能成功、所有页面都能同时驻留。按需分配、文件映射和可选的 swap 支持不同的内存使用方式；虚拟内存不等于交换分区。
• 代价是地址转换和缺页处理会引入额外开销。

机制上，CPU 优先用 TLB 缓存地址翻译；TLB 未命中时查页表，并不意味着一定缺页。合法但尚未驻留的页面可由内核分配物理页或从文件/swap 调入后重试指令；非法地址或权限违规不能靠调页解决，在 Linux 用户进程中通常表现为 SIGSEGV。

虚拟地址 → TLB / 页表 → 物理页
                     ↘ 页面不在内存 → 缺页处理 → 建立映射 → 重试

依据：Linux 内存管理概念。

10、页面置换算法有哪些？

回答提示：

• FIFO：先进先出，实现简单但可能出现 Belady 异常。
• LRU：淘汰最近最少使用页面，效果较好但实现成本更高。
• LFU：淘汰访问次数最少页面，适合热点稳定场景。

参考回答：

• 实际系统往往采用 LRU 近似算法，在性能和命中率之间折中。

11、常见 CPU 调度算法

回答提示：

• 先来先服务（FCFS）：简单但可能导致短任务等待长任务。
• 短作业优先（SJF）：平均等待时间较优，但依赖任务时长预测。
• 时间片轮转（RR）：公平性好，适合分时系统。
• 多级反馈队列：结合优先级和时间片，工程中较常见。

参考回答：

• 服务端系统更关注吞吐和响应延迟平衡，通常使用更复杂的动态调度策略。Linux 6.6 起，公平调度类开始从 CFS 转向 EEVDF：先选尚欠 CPU 时间的合格任务，再比较虚拟截止时间。这不是把整个 Linux 调度器替换成一种算法；实时调度类仍有各自策略。

依据：Linux EEVDF 调度器说明。

12、IO 模型有哪些？

回答提示：

• 阻塞 IO：以 socket 的 read 为例，无数据时可等待，返回时数据已复制到用户缓冲区；也可能返回 EOF、错误或少于请求量的数据。
• 非阻塞 IO：当前无法继续时返回 EAGAIN/EWOULDBLOCK；可以重试，也可以结合就绪通知，避免忙轮询。
• IO 多路复用：一个线程监听多个连接（select/poll/epoll）。
• 异步 IO：内核完成 IO 后通知用户线程。

参考回答：

• 高并发网络服务常用 IO 多路复用，Java 里对应 NIO 的 Selector/Reactor 思路；NIO 也包含阻塞模式的通道，不能把全部 NIO 都等同于非阻塞。

Linux 的 epoll_wait 通知的是“可以尝试 IO”，不负责将数据复制到用户缓冲区，等待事件时本身可以阻塞；随后仍需调用 read/write。异步 IO 的完成通知则表示提交的操作已经完成。对于边缘触发（ET），通常配合非阻塞描述符，持续读写直到 EAGAIN，避免遗漏仍待处理的数据。

依据：Linux epoll(7)、read(2)。

13、什么是零拷贝？

回答提示：

• 目标是减少用户态和内核态之间的数据复制次数。
• Linux sendfile 在内核中传输文件描述符间的数据，避免传统 read + write 经用户缓冲区中转；mmap 将文件映射到地址空间，但随后普通 write 仍可能发生数据复制，不能仅凭用了映射就断言全程零复制。

参考回答：

• 零拷贝可以降低 CPU 开销并提升吞吐，特别适合大文件传输和高流量网关场景。它不意味着数据完全不移动，也不保证消除内核内部复制；效果取决于传输路径及硬件能力。需要在用户态压缩、加密或改写正文时，不能直接套用原样发送文件的路径。
• sendfile 成功也可能只发送部分字节，必须按实际返回值推进偏移并处理重试。

依据：Linux sendfile(2)。

14、面试高频追问怎么答得更像真实项目参与者？

回答提示：

• 回答结构建议：结论 -> 机制 -> 线上场景 -> 权衡。
• 有真实测量时给出线程池大小、QPS、延迟和测试条件；没有测量时明确说明是机制分析，不编造项目经历或效果数字。

机制分析示例：

• 如果增大线程池后延迟反而升高，可以检查 CPU 使用率、可运行线程数与上下文切换，再排查锁竞争、IO 等待和下游容量。
• 若证据指向 CPU 饱和，继续增加线程通常不能提升算力；若主要是 IO 等待，则还需结合下游并发上限评估线程数。
• 这只是分析路径，是否改善吞吐或延迟需要实际测量后才能判断。

阅读提示

并发题建议按“锁 -> 可见性 -> 原子性 -> 线程池”顺序复习。
每道题尽量补一句“线上场景”或“性能权衡”，会更像真实工程实践。

适用版本：语言语义与并发 API 以 Java SE 21 为依据，基础用法同样适用于 JDK 8/17。对象头和锁实现另行限定为传统 HotSpot 布局及历史实现，不能作为所有 JVM、所有版本的固定结构。

synchronized的用法

1、synchronized的用法

1. 修饰实例方法

当synchronized用于修饰一个实例方法时，该方法被称为同步方法。这意味着在同一时刻，只有一个线程可以进入该方法的代码块。这种同步是基于对象的实例锁，即每个对象都有一个锁，当线程进入一个对象的同步方法时，它必须先获得该对象的锁。如果另一个线程已经持有该对象的锁，则该线程必须等待，直到锁被释放。

public synchronized void syncMethod() {
    // method body
}

2. 修饰静态方法

修饰静态方法时，同步是基于类对象（Class对象）的锁。这意味着所有实例共享同一把锁。当一个线程进入一个静态的同步方法时，它获得的是该类的锁。如果其他线程已经持有该类的锁，则新来的线程必须等待。

public static synchronized void staticSyncMethod() {
    // method body
}

3. 修饰代码块

当synchronized用于修饰一个代码块时，它允许你指定一个锁对象。这种方式提供了更细粒度的控制，因为它允许你只同步访问特定资源和数据部分的代码。代码块中的代码在执行时必须持有指定的锁对象。

private final Object lock = new Object(); // 同一实例的调用共享同一把锁

public void someMethod() {
    synchronized(lock) {
        // code block
    }
}

锁必须被访问同一共享状态的线程共同使用；方法内每次 new Object() 得到不同的锁，无法实现调用之间的互斥。实例锁与该类的 Class 锁也是两把不同的锁。

2、锁升级

（1）、内存布局 （对象的内存布局）

在 Java 中，每个对象的内存布局是由 Java 虚拟机（JVM）的具体实现决定的，例如 Oracle HotSpot JVM。这里，我们可以讨论 HotSpot JVM 中普通（非数组）对象的典型内存布局。对象的内存布局通常包括三部分：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

1. 对象头（Object Header）

以下按 64 位 HotSpot、传统对象头说明：对象头包含标记字（Mark Word）和类型指针；这不是 Java 语言规范规定的布局。

• Mark Word：这部分通常占用 8 字节，用于存储对象自身的运行时数据，如哈希码、锁信息（锁状态标记、线程持有的锁等）、垃圾收集信息（如年龄、是否存活等）。
• Class Pointer：这部分通常也占用 4 字节（默认情况下)

2. 实例数据（Instance Data）

实例数据部分占用的字节数取决于对象的具体字段。Java 数据类型的字节如下：

• boolean 和 byte：1 字节
• char 和 short：2 字节
• int 和 float：4 字节
• long 和 double：8 字节
• 引用类型（如对象引用）：在 64 位 JVM 中通常是 4 字节（使用压缩指针时）或 8 字节。

字段的排列可能会由 JVM 进行优化，以减少由于内存对齐引起的空间浪费。

3. 对齐填充（Padding）

为了使对象的总大小是 8 字节的倍数（这里假定 HotSpot 对象对齐为 8 字节；并非内存寻址的最小单位），JVM 可能会在实例数据之后添加一些填充字节。这样做是为了确保内存对齐，有助于提高 CPU 缓存的效率。

示例

考虑一个简单的 Java 对象：

public class Example {
    int a;    // 4 字节
    boolean b; // 1 字节
}

在这个例子中，对象的内存布局可能如下：

• 对象头：12 字节（压缩类指针）或 16 字节（非压缩）
• 实例数据：int 4 字节 + boolean 1 字节 = 5 字节
• 对齐填充：为了使总大小为 8 字节的倍数，压缩类指针时需要添加 7 字节，非压缩类指针时需要添加 3 字节的填充（按这里的简化字段布局计算）。

这样，总的大小可能是 24 字节（12+5+7，使用压缩类指针的情况）或 24 字节（16+5+3，未使用压缩指针）。

Java 示例：简单的 Person 类

考虑下面的 Java 类 Person，它有两个字段：name 和 age。此示例将帮助我们理解类型指针在不涉及继承的情况下如何工作。

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void printInfo() {
        System.out.println("Name: " + name + ", Age: " + age);
    }

    public static void main(String[] args) {
        Person person = new Person("John Doe", 30);
        person.printInfo();  // 输出: Name: John Doe, Age: 30
    }
}

类型指针的作用

当我们创建 Person 类的一个实例时：

1. 对象创建：JVM 在堆内存中为 Person 对象分配空间。这块空间包括对象头、实例数据（name 和 age），以及可能的一些填充字节来满足内存对齐要求。

2. 对象头：对象头包含了几个重要的组成部分，其中关键的部分是类型指针。

3. 类型指针：这个指针指向 Person 类的元数据。该元数据包含了有关 Person 类的各种信息，如字段布局、方法表、类加载器信息等。

4. 使用类型指针：

5. 当调用 person.printInfo() 方法时，即使这个例子没有显示继承和多态，类型指针仍然起到关键作用。JVM 使用类型指针查找到 Person 类的元数据，进而定位到 printInfo() 方法的实际代码。

6. 类型指针关联的是类元数据；实际调用可能经过解释器、虚方法分派或 JIT 内联。它本身不保证任意热部署都能成功，类重定义还受 JVM 的能力与限制约束。

（2）、markword 里面具体存的是什么东西

3、synchronized早期为什么叫做重量级锁

在JDK早期 synchronized被称之为重量级锁，是因为我的JVM也是在用户态，有线程向jvm申请锁的时候，那我们JVM需要向操作系统申请锁，那这个过程涉及到从用户态切换到内核态，再从内核态切换到用户态，所以称synchronized为重量级锁。

比较底层的实现（操作系统层面）

当一个 Java 线程尝试进入一个由 synchronized 关键字保护的同步块或方法时，它首先需要获得锁。如果锁已被另一个线程持有，尝试获取锁的线程需要等待。在 Java 的早期实现中，这种等待是通过操作系统的互斥量（Mutex）实现的。这意味着以下几个步骤：

• 锁请求：当线程无法立即获取锁时，JVM 会在用户态下发出一个系统调用，请求操作系统的互斥量。
• 状态切换：执行系统调用（如请求互斥量）涉及从用户态切换到内核态，因为互斥量的管理是在操作系统内核中处理的。
• 等待和唤醒：线程在内核控制的等待队列中阻塞，直到锁变为可用。当锁释放时，操作系统负责唤醒等待的线程，这通常再次涉及从内核态回到用户态的切换。

4、锁升级过程

随着 Java 平台的发展，特别是从 JDK 6 开始，对 synchronized 锁的实现进行了优化。引入了如轻量级锁和偏向锁等技术，使得许多锁操作现在可以完全在用户态下完成，避免了频繁的模式切换。当锁竞争不激烈时，这些优化可以显著减少锁的开销。

下面是 JDK 8 HotSpot 开启偏向锁时的历史实现示意，并不是每次加锁都必须经过的状态链。JDK 15 已默认禁用并废弃偏向锁，因此不要用此流程解释 JDK 17/21 的默认行为。锁位、栈锁记录和膨胀条件属于实现细节，不属于 synchronized 的语言契约。参见 Oracle JDK 15 发布说明：Biased Locking。

无锁状态

• 锁状态: 当没有线程尝试获取对象的锁时，对象处于无锁状态。无锁并不意味着对象不能被锁定，而是表明当前没有锁定行为。
• 标记位: 在无锁状态下，对象头的标记位通常设置为01（在开启偏向锁的情况下），这表示这个对象可以进入偏向锁状态。

偏向锁

偏向锁是为了优化单个线程多次获取同一个锁的情况。当第一次有线程获取锁时，JVM会将对象头标记为偏向这个线程，以后该线程进入和退出同步块时不需要进行全面的同步。

• 锁状态: 对象头偏向第一个获得它的线程。
• 标记位: 对象头的标记位设置为偏向锁模式，其中包括偏向线程的ID。状态位是01，偏向标志位设置为1，后面跟着偏向的线程ID。

轻量级锁

在历史偏向锁实现中，其他线程访问可能触发偏向撤销或重偏向，并不必然升级为轻量级锁。轻量级锁的工作原理是在每个线程的栈帧中创建一个锁记录（Lock Record），它包含了锁对象指针。

• 锁状态: 当锁对象已被线程锁定，但没有其他线程争用它时，使用轻量级锁。
• 标记位: 轻量级锁的状态位为00，锁指针指向线程栈上的锁记录。

重量级锁

当轻量级锁的自旋锁尝试失败，即有多个线程竞争同一个锁时，轻量级锁会升级为重量级锁。这时，JVM会在操作系统层面挂起其他试图获取这个锁的线程。

• 锁状态: 涉及操作系统帮助管理线程阻塞和唤醒的重量级锁。
• 标记位: 重量级锁的状态位通常为10，对象头的锁指针指向一个监视器对象（Monitor），该对象包含了锁的所有者、等待锁的线程列表等信息。

补充内容：

在Java中，轻量级锁升级到重量级锁的自旋次数并没有一个固定的标准，因为这个值可以根据JVM的具体实现和运行时的调优参数而变化。不过，一般来说，HotSpot JVM中有几个因素决定了自旋的次数：

自旋是运行时实现策略，不能按“固定重试 10 次后必然膨胀”理解；竞争情况、JVM 版本和锁模式都会影响处理方式。历史参数 -XX:PreBlockSpin 也不应作为 JDK 17/21 通用调优选项。

synchronized在java代码层面表示

package com.javatiaozao;

public class Main {
    public static void main(String[] args) {
        Object o = new Object();
        synchronized (o) {
            System.out.println("我已经上锁了");
        }
        System.out.println("Hello world!");
    }
}

synchronized在 JVM 字节码层面表示

0 new #2 <java/lang/Object>
3 dup
4 invokespecial #1 <java/lang/Object.<init> : ()V>
7 astore_1
8 aload_1
9 dup
10 astore_2
11 monitorenter
12 getstatic #3 <java/lang/System.out : Ljava/io/PrintStream;>
15 ldc #4 <我已经上锁了>
17 invokevirtual #5 <java/io/PrintStream.println : (Ljava/lang/String;)V>
20 aload_2
21 monitorexit
22 goto 30 (+8)
25 astore_3
26 aload_2
27 monitorexit
28 aload_3
29 athrow
30 getstatic #3 <java/lang/System.out : Ljava/io/PrintStream;>
33 ldc #6 <Hello world!>
35 invokevirtual #5 <java/io/PrintStream.println : (Ljava/lang/String;)V>
38 return

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

本文以 Elasticsearch 8.19（自建集群） 为基准；MySQL 对比以 MySQL 8.0 为准。示例采用 Kibana Dev Tools 请求格式，未在实际集群执行。

1、ES是什么，为什么要用ES

ES是一个开源的分布式搜索和分析引擎，它被设计用于快速、灵活地搜索和分析大量数据。

• Elasticsearch提供出色的全文搜索能力，适用于需要对大量数据进行高效搜索和查询的应用场景，使用倒排索引技术，能够快速高效地执行文本搜索，支持模糊搜索等。可以用来解决使用数据库进行模糊搜索时存在的性能问题；
• Elasticsearch能够提供近实时的搜索和分析结果（写入成功不代表立即可被搜索到），适用于对数据的及时性有要求的场景;
• 支持多种数据类型，适用于处理不同结构和格式的数据，使其更灵活和通用;

和Mysql相比：

• MySQL 的查询性能取决于索引与查询方式，不能笼统认为大数据量下一定慢。LIKE '%关键词%' 通常无法通过普通 B-tree 索引进行有效的范围定位；全文检索则应比较各自的全文索引能力。
• MySQL 8.0 的全文索引支持 CHAR、VARCHAR、TEXT，也支持全文解析器：例如内置的 ngram 解析器可处理中文、日文和韩文。ES 的优势在于更丰富的分析器、相关性查询与分布式搜索能力，而不是 MySQL“不支持分词”。参见 MySQL 8.0 官方全文搜索说明 和 ngram 解析器。

2、ES索引的构建

Elasticsearch采用Rest风格API，因此其API就是一次http请求，你可以用任何工具发起http请求。

可以通过RESTful API或相关的客户端库来操作创建索引。

创建索引的请求格式：

• 请求方式：PUT
• 请求路径：/索引库名
• 请求参数：json格式：

PUT /articles
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 2
  },
  "mappings": {
    "properties": {
      "title": { "type": "text", "analyzer": "standard" },
      "status": { "type": "keyword" }
    }
  }
}

number_of_shards 是主分片数量；number_of_replicas 是每个主分片的副本数，因此这里共需分配 9 个分片副本（3 主 + 6 副）。同一主分片及其副本不能放在同一节点，至少需要 3 个符合分配条件的数据节点才能全部分配；单节点使用这组设置会留下未分配副本，集群呈 yellow。主分片数通常在创建时确定，副本数可以动态调整，不能把副本数误当作集群节点数。

text 会经过分析器生成词项，适合全文检索；keyword 适合状态等精确匹配字段。standard 并不等于面向中文的专用分词器，应按语言和检索需求选择分析器。参见 Create index API。

3、ES为啥查询这么快

• 倒排索引：Elasticsearch使用倒排索引结构，这是一种能够快速定位文档的数据结构。倒排索引通过记录每个词项(terms)出现在哪些文档中来加速搜索。相比于传统的行式数据库存储结构，倒排索引在文本搜索场景中的性能更好。
• 分布式搜索引擎：Elasticsearch是一个分布式系统，可以在多个节点上运行。它将数据分成多个分片，每个分片可以独立运行在不同的节点上。这种分布式架构允许Elasticsearch并行处理查询请求，提高了查询的速度和扩展性。
• 缓存机制：节点查询缓存可复用符合条件的 filter 上下文查询结果；分片请求缓存默认主要缓存 size: 0 的请求结果，例如聚合。缓存有准入、失效和容量限制，不是所有查询都会命中。操作系统文件缓存也会影响读取速度。
• 按访问方式组织数据：JSON 是请求和文档的表示形式，本身不保证检索快。全文检索主要利用倒排索引；排序、聚合通常利用 doc_values，它在索引时构建，按文档组织字段值。默认不应为了对 text 排序而直接启用耗堆内存的 fielddata，可使用 keyword 子字段。

近实时性描述的是数据何时对搜索可见，不是查询执行速度。refresh 会使新 segment 可被搜索读取，不要求先完成一次完整的 Lucene commit；它不能等同于持久化保证。8.19 自建集群默认每秒 refresh，但默认只对最近 30 秒内收到过搜索请求的索引周期刷新，这也不是严格的一秒延迟承诺。需要写后搜索可见时，可使用 refresh=wait_for 等待刷新，避免每次写入都强制 refresh=true 产生大量小 segment。

PUT /articles/_doc/1?refresh=wait_for
{ "title": "distributed search", "status": "published" }

GET /articles/_search
{ "query": { "match": { "title": "search" } } }

上例在写入成功返回后再执行搜索；wait_for 等待的是搜索可见性，不是跨 MySQL 与 ES 的事务提交。分片并行也有网络与结果归并成本，分片越多不一定越快。

官方资料：近实时搜索、refresh 参数、节点查询缓存、分片请求缓存、doc values。

4、倒排索引

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。 而倒排索引，恰恰相反，它是从词出发，记载这个词在哪些文章中存在。

倒排索引不只是 FST，而是包含词项词典、词项定位结构和倒排列表（postings）等部分。倒排列表记录包含某词项的文档 ID，还可按字段配置记录词频、位置等信息，用于评分和短语查询。

以 Lucene 9.12 的 Lucene90 BlockTree 格式为例，词典按块存储，FST 用来索引词项前缀并定位词典块；随后从词典找到对应的 postings。FST 通过共享路径压缩词项索引，帮助快速定位，但它本身不是完整的文档倒排列表。具体文件格式随 Lucene codec 和版本变化，不能把这一实现概括为所有版本的唯一结构。

文档 1: distributed search
文档 2: search engine
          ↓ 分析后建立词项与文档的关系
词项 distributed → [1]
词项 search      → [1, 2]
词项 engine      → [2]

查询 search 时先定位词项，再读取其倒排列表；多词查询可对列表求交或求并，而不必逐篇扫描全文。match 会先分析查询文本，term 则直接匹配索引中的词项，不能把两者当作相同的全文搜索方式。

参见 Lucene 9.12 BlockTree 官方说明。

5、ES中的数据和数据库同步的问题

• 同步双写：写 MySQL 后再写 ES，任意一步失败都可能产生不一致；单纯顺序调用不会获得跨系统原子性，需要补偿、重试和对账。
• 异步双写：使用 MQ 异步写 ES，削峰并降低请求链路耦合，但数据库提交与消息发送之间仍有失败窗口。可采用事务 outbox：在同一数据库事务内写业务数据和待发送事件，再由独立任务投递 MQ；消费者需支持重复消息和失败重试。
• 定时扫表：通过 updated_at 等变更标记扫描增量，时效性受调度间隔影响。只用时间戳水位可能漏掉同时间记录或晚提交事务，需要重叠扫描、去重与对账；物理删除后的行无法再被扫到，需软删除标记或独立删除事件。
• 基于 Binlog 的 CDC 同步：读取已提交的数据库变更，可直接写 ES，也可经 MQ 消费后写入 ES。它仍有传输、消费和 refresh 延迟，属于最终一致性方案，需处理初始全量与增量衔接、消费位点和日志保留期。

通常以 MySQL 主键作为 ES _id，重复投递同一记录时覆盖同一文档；但固定 ID 只能避免重复文档，不能阻止旧事件覆盖新状态。还需按同一业务键保证顺序，或使用可单调比较的业务版本和 ES 外部版本控制；删除事件也应纳入顺序设计。批量写入时逐项检查 Bulk 响应的失败并重试，不能仅凭 HTTP 200 判定整批成功。

这些是同步架构的设计建议，ES API 本身不提供与 MySQL 的分布式事务。官方 API 依据：Index API 的 ID 与版本控制、Bulk API 响应与单项错误。

适用版本： 本文以 Java SE 21 HashMap API 和 OpenJDK jdk-21-ga 源码 为核对基准。JDK 8 引入链表与红黑树结合的实现；文中的 JDK 1.7/1.8 对比用于解释历史变化。树化细节属于实现策略，不是 Map 接口对所有 JDK 的承诺。

1、HashMap 的底层数据结构是什么？

回答提示：

• JDK 1.7：数组 + 链表。
• JDK 8 起（本文核对 JDK 21）：数组 + 链表 + 红黑树。
• 当桶内链表过长且容量达到条件时，链表会树化，提高查询效率。

参考回答：

• HashMap 的底层是哈希桶数组，桶里存放 Node<K, V>。
• 发生哈希冲突时，桶中通过链表或树组织节点；链表插入触发树化检查后，还要满足表容量条件，具体边界见第 6 题。

图示表达桶与节点的关系。图中文字“数组容量 >64”为旧示意；JDK 21 在数组长度小于 64 时优先扩容，至少 64 才进入树化分支。链表触发检查的计数与具体方法有关，以第 6 题的源码说明为准。

2、HashMap 的默认初始化参数有哪些？

回答提示：

• 默认初始容量：16。
• 默认负载因子：0.75。
• 扩容阈值：capacity * loadFactor。

参考回答：

• 默认情况下，HashMap 在第一次 put 时初始化数组容量为 16。
• 普通 put 新增映射后，若元素个数超过阈值（容量 * 负载因子），触发扩容，容量通常翻倍。

这里的默认情况指无参构造；创建空对象时不会立刻分配长度为 16 的数组。size 是整个 Map 的键值对数量，容量是桶数组长度；覆盖已有 key 不增加 size。例如默认表容量为 16、阈值为 12，在没有冲突引发提前扩容的情况下，插入第 13 个不同 key 才因超过负载阈值扩容。

3、HashMap 的 put 流程是怎样的？

回答提示：

1. 计算 key 的 hash。
2. 定位桶下标（位运算）。
3. 桶为空直接插入。
4. 桶不为空则比较 key：相同覆盖，不同挂链表/树。
5. 判断是否需要树化或扩容。

参考回答：

• put 核心逻辑就是“算桶位 + 冲突处理 + 阈值判断”。
• 冲突时先比较 hash 和 equals，相同 key 走覆盖；不同 key 追加到链表尾或红黑树。

JDK 21 对非空 key 的哈希做高位扰动，再用 (n - 1) & hash 定位桶，n 为数组长度。定位到同一桶不代表 key 相等；自定义 key 应保持 equals/hashCode 一致，放入后不要修改参与这两个方法计算的字段，否则可能无法按原 key 查到数据。

4、HashMap 的 get 流程是怎样的？

回答提示：

1. 计算 key 的 hash 并定位桶。
2. 先比较头节点。
3. 若是链表则遍历匹配。
4. 若是红黑树则按树查找。

参考回答：

• get 的时间复杂度在理想情况下接近 O(1)，冲突严重时会退化。
• JDK 8 起通过树化降低极端冲突下链表查询的退化风险，树桶的复杂度边界见第 7 题。

get(key) 返回 null 既可能表示 key 不存在，也可能表示对应的 value 为 null；需要区分时用 containsKey(key)。

5、哈希冲突怎么处理？

回答提示：

• HashMap 主要采用拉链法（链地址法）。
• 同一个桶位的不同 key 通过链表或红黑树组织。

参考回答：

• 哈希冲突不可避免，关键是“冲突后怎么组织”。
• HashMap 采用“数组 + 链/树”结构，把冲突元素放在同一个桶中并继续检索。

6、链表什么时候转红黑树？红黑树什么时候退化回链表？

回答提示：

• 8：树化检查阈值，但要结合插入入口的计数方式理解。
• 64：允许树化的最小桶数组长度，不是 Map 元素个数。
• 6：扩容时树桶拆分后，每一侧转回链表的节点数阈值；普通删除使用另一套判断。

参考回答：

在 OpenJDK 21 中，需要分清以下路径：

| 路径 | 实际条件与边界 |
|

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

回答提示：是一种比较通俗的解释，比较好理解，如果‘参考答案’不太好记住，可以直接复习回答提示也可以。

适用版本：本文以 Java SE 21 API 为准；ArrayList 容量增长细节以 OpenJDK 21 实现为例，属于实现细节而非接口保证。历史实现差异另行标注。

1、Java中的集合类有哪些？如何分类的？(此问题基本不会被问到，但是要大体理解整个集合的内容，如果能记住此问题（灵活记住），面试集合的基础问题基本都可以回答)

回答提示：

• List（列表）：List接口及其实现类用于存储一组有序的元素。元素可以重复，且可以通过索引访问。常见的List实现类有ArrayList、LinkedList等。ArrayList基于动态数组实现，访问元素速度快；LinkedList基于双向链表实现，已定位节点或操作两端时插删为 O(1)，按索引定位仍需 O(n)。
• Set（集合）：Set接口及其实现类用于存储不重复的元素；是否有确定遍历顺序取决于实现。Set不允许出现重复元素，因此常用于去重操作。常见的Set实现类有HashSet、TreeSet等。HashSet基于哈希表实现，不保证遍历顺序；LinkedHashSet 通常按插入顺序遍历；TreeSet基于红黑树实现，元素会按照自然顺序或者自定义顺序排序。
• Queue（队列）：Queue接口及其实现类用于在处理前保存元素，出队顺序由实现决定，通常是 FIFO，但优先队列并非如此。常见的Queue实现类有LinkedList（也实现了List接口）、PriorityQueue等。LinkedList可以用作双端队列；PriorityQueue是一个基于优先级堆的无界队列，元素的排序方式可以通过比较器来定义。
• Map（映射）：Map接口及其实现类用于存储键值对。键是唯一的，每个键都映射到一个值。常见的Map实现类有HashMap、TreeMap等。HashMap基于哈希表实现，键值对存储无序；TreeMap基于红黑树实现，键会按照自然顺序或者自定义顺序排序。

参考回答：

• 集合类存放于 java.util 包中，常见接口包括 List（列表）、Set（集）、Queue（队列）和 Map（映射）。List、Set、Queue 都属于 Collection 体系；Queue 不是 List 的子接口，Map 是独立体系。
• Collection：Collection 是集合 List、Set、Queue 的最基本的接口。
• Iterator：迭代器，可以通过迭代器遍历集合中的数据
• Map：是映射表的基础接口

• 上图可辅助理解；接口关系以文字和官方 API 为准。Java 21 还引入了表达确定遍历顺序的 SequencedCollection、SequencedSet、SequencedMap 等接口。ArrayList 常见扩容约为 1.5 倍，具体边界见第 3 题。

官方资料：Collection、Set、Queue。

2、那些集合是线程安全的？

参考回答：

1. Vector：一个线程安全的List实现，它的大部分方法都是同步的，因此可以在多线程环境中使用。不过，由于同步操作会带来性能开销，所以在不需要线程安全的场合，建议使用ArrayList。
2. Hashtable：一个线程安全的Map实现，它同样是同步的，可以在多线程环境中使用。与HashMap相比，Hashtable的性能可能稍差一些，因为同步操作会增加额外的开销。
3. Stack：一个线程安全的栈实现，它也是同步的，可以在多线程环境中使用。单线程栈通常优先使用 Deque 的实现（如 ArrayDeque）；ArrayDeque 本身不保证线程安全。
4. ConcurrentHashMap：线程安全的 Map 实现（不是 HashMap 的子类）。OpenJDK 7 使用 Segment 分段锁；OpenJDK 8 起主要使用 CAS 和桶级 synchronized 协调更新，普通 get 通常不加锁。不允许 null 键或值，不能把吞吐量优势视为所有负载下的保证。
5. CopyOnWriteArrayList：一个线程安全的List实现，它通过在写操作时复制整个数组来实现线程安全。这种策略适用于读多写少的场景，因为写操作会涉及到复制整个数组，所以性能开销较大。

线程安全的方法不等于任意复合操作都原子化。例如 if (!map.containsKey(k)) map.put(k, v) 有检查与写入之间的竞争窗口，可使用 ConcurrentHashMap.putIfAbsent(k, v) 完成原子条件插入。多键操作仍不构成事务。

官方资料：ConcurrentHashMap、Stack。

3、ArrayList的扩容机制是什么？

回答提示：

• 初始容量：OpenJDK 21 的无参构造器使用共享空数组，首次添加时通常分配容量 10；new ArrayList<>(n) 则按显式容量处理，不能混为一谈。
• 扩容触发：当向ArrayList中添加元素，且当前元素数量达到容量上限时，就会触发扩容操作。
• 扩容策略：ArrayList的扩容策略是增长大约50%的容量。
• 数组复制：扩容过程中，ArrayList会创建一个新的、更大容量的数组，并将原有数组中的所有元素复制到新数组中。

参考回答：

• 以 OpenJDK 21 为例，容量不足时，优先增长量是 oldCapacity >> 1，新容量还必须满足本次操作的最小需求，并处理数组长度上限。批量添加时，最小需求可能超过约 1.5 倍的容量。增长策略属于 JDK 类库实现细节，不能归因于 JVM 随意选择倍数。
• 扩容会分配新数组并复制已有元素引用，不会克隆元素对象。一次扩容需要 O(n) 复制，连续尾部添加的均摊时间复杂度为 O(1)。size 是实际元素个数，capacity 是内部数组长度。

无参构造：size=0，内部空数组
首次 add：size=1，capacity=10
第 11 次逐个 add：容量 10 → 15，复制原有引用后写入
第 16 次逐个 add：容量 15 → 22（15 + (15 >> 1)）

这是根据源码推导的普通逐个追加示意，假定中途未调用 ensureCapacity、trimToSize 等方法，不是运行测量结果。

官方资料：OpenJDK 21 ArrayList 源码（构造器、grow、add）。

4、ArrayList和linkedList的区别？

回答提示：

• 内部实现：ArrayList是基于动态数组实现的，底层数组存放连续的元素引用，引用指向的对象不保证连续；而LinkedList则是基于双向链表实现，元素通过指针相互连接。
• 随机访问：ArrayList支持快速随机访问，时间复杂度为O(1)；LinkedList则需要遍历，时间复杂度为O(n)。
• 内存占用：LinkedList每个节点除了存储数据外，还需要存储指向前一个和后一个节点的指针，因此比ArrayList更占内存。
• 使用场景：ArrayList适用于需要频繁进行随机访问的场景；LinkedList 的优势限于两端操作或已通过迭代器定位后的局部插删；按索引插删仍有 O(n) 的定位成本。

参考回答：

• ArrayList：基于动态数组，适合按下标访问；中间插删需移动后续引用，通常为 O(n)。预估元素数量并指定合理容量可以减少扩容，但是否快于其他结构应结合实际负载判断。
• LinkedList：基于双向链表，按索引访问会从较近的一端遍历。两端插删或迭代器已定位后的插删为 O(1)，按索引插删整体通常仍为 O(n)。
• 遍历 LinkedList 可使用增强 for、iterator 或 listIterator，总体为 O(n)。应避免 for (int i = 0; i < list.size(); i++) list.get(i)，反复按索引定位会使整体退化为 O(n²)。问题在于 get(i)，并不是 for 语法本身。indexOf 同样需要线性查找，找不到时返回 -1。

官方资料：LinkedList（实现与索引访问说明）。

5、HashMap和HashTable有什么区别？

回答提示：

• 线程安全性：HashMap是非线程安全的，而HashTable是线程安全的。HashTable通过synchronized关键字实现同步，但可能导致性能下降。
• null值处理：HashMap允许null作为键和值，而HashTable不允许。
• 性能：由于HashMap不需要考虑线程同步，通常性能更高。

参考回答：

区别 ：

线程安全性

• HashMap方法没有synchronized修饰，线程非安全，HashTable线程安全；

空键和空值：

• HashMap允许key和value为null，而HashTable不允许

历史遗留：（了解）

• Hashtable 是 Java 1.0 中的遗留类，虽然仍然可以使用，但通常建议使用 HashMap，并结合 java.util.concurrent 包中的现代并发类来处理多线程问题。
• HashMap 是在 Java 2 中引入的，设计更现代化，使用也更加灵活。

迭代器：(了解)

• HashMap 使用的是快速失败（fail-fast）的迭代器，如果在创建迭代器后对集合进行了结构上的修改（除了使用迭代器自身的 remove 方法外），迭代器可能抛出 ConcurrentModificationException；fail-fast 只是尽力检测错误，不能作为并发正确性的保证。
• Hashtable 的 keySet()、entrySet() 等集合视图也提供 fail-fast 迭代器；只有 keys()、elements() 返回的旧式 Enumeration 不是 fail-fast。枚举期间结构被修改，结果未定义，并不意味着枚举可安全并发使用。

性能：（了解）

• 在没有线程安全需求的场景中，HashMap 通常比 Hashtable 性能更高，因为它没有同步的开销。

官方资料：Hashtable（迭代器、Enumeration 与线程安全）。

阅读提示

集合题核心是三条线：整体分类、常用容器对比、HashMap 原理。
回答时尽量带复杂度和适用场景，避免只背定义。

本文以 Java SE 17 API、OpenJDK 17u 实现为核对基准；JDK 7/8 仅用于历史对比。扩容倍率、树化阈值属于实现细节，不是所有 Java 实现必须遵守的 API 契约。

Java集合

回答提示：是一种比较通俗的解释，比较好理解，如果‘参考答案’不太好记住，可以直接复习回答提示也可以。

1、Java中的集合类有哪些？如何分类的？(此问题基本不会被问到，但是要大体理解整个集合的内容，如果能记住此问题（灵活记住），面试集合的基础问题基本都可以回答)

回答提示：

• List（列表）：List接口及其实现类用于存储一组有序的元素。元素可以重复，且可以通过索引访问。常见的List实现类有ArrayList、LinkedList等。ArrayList基于动态数组实现，访问元素速度快；LinkedList基于双向链表实现，首尾插删为 O(1)，包含按索引定位的插删通常为 O(n)。
• Set（集合）：Set接口及其实现类用于存储一组不重复的元素；是否有迭代顺序由实现决定（如 LinkedHashSet 保留插入顺序、TreeSet 排序）。Set不允许出现重复元素，因此常用于去重操作。常见的Set实现类有HashSet、TreeSet等。HashSet基于哈希表实现，元素存储无序；TreeSet基于红黑树实现，元素会按照自然顺序或者自定义顺序排序。
• Queue（队列）：Queue接口及其实现类通常按先进先出（FIFO）组织元素，但并非全部如此，例如 PriorityQueue 按优先级取出队首，迭代也不保证排序。常见的Queue实现类有LinkedList（也实现了List接口）、PriorityQueue等。LinkedList可以用作双端队列；PriorityQueue是一个基于优先级堆的无界队列，元素的排序方式可以通过比较器来定义。
• Map（映射）：Map接口及其实现类用于存储键值对。键是唯一的，每个键都映射到一个值。常见的Map实现类有HashMap、TreeMap等。HashMap基于哈希表实现，键值对存储无序；TreeMap基于红黑树实现，键会按照自然顺序或者自定义顺序排序。

参考回答：

• 集合框架主要位于 java.util，并发集合主要位于 java.util.concurrent。Collection 下有 List、Set、Queue 等接口，Queue 不属于 List；Map 是独立的接口层次。
• Collection：Collection 是集合 List、Set、Queue 的最基本的接口。
• Iterator：迭代器，可以通过迭代器遍历集合中的数据
• Map：是映射表的基础接口

• 一定要牢牢记住这张图，大多比较浅的面试题都是从这上面问的。 ArrayList 在 OpenJDK 17u 中通常以约 1.5 倍作为优先增长量，但仍需满足最小所需容量和数组大小限制

2、那些集合是线程安全的？

参考回答：

1. Vector：一个线程安全的List实现，它的大部分方法都是同步的，因此可以在多线程环境中使用。不过，由于同步操作会带来性能开销，所以在不需要线程安全的场合，建议使用ArrayList。
2. Hashtable：一个线程安全的Map实现，它同样是同步的，可以在多线程环境中使用。与HashMap相比，Hashtable的性能可能稍差一些，因为同步操作会增加额外的开销。
3. Stack：一个线程安全的栈实现，它也是同步的，可以在多线程环境中使用。官方建议优先使用 Deque 接口表达栈操作；单线程常用 ArrayDeque，它本身不保证线程安全。
4. ConcurrentHashMap：一个线程安全的 Map 实现（不是 HashMap 的子类，且不接受 null 键和值）。早期版本（JDK 1.7 及以前）使用分段锁（Segment Locking）技术来提升并发性能，JDK 1.8 以后则使用了更加细粒度的锁，如空桶插入使用 CAS，非空桶更新通常在桶首节点上使用 synchronized，树桶另有协调机制。在多线程环境下，ConcurrentHashMap 的并发性能通常优于 Hashtable 以及通过 Collections.synchronizedMap(new HashMap<>()) 包装得到的同步 HashMap，因为后两者都是对整个 map 加锁，从而限制了并发能力，而 ConcurrentHashMap 则支持更高的并发访问。
5. CopyOnWriteArrayList：一个线程安全的List实现，它通过在写操作时复制整个数组来实现线程安全。这种策略适用于读多写少的场景，因为写操作会涉及到复制整个数组，所以性能开销较大。

这些容器的线程安全不代表任意多步业务操作都是原子的。例如 ConcurrentHashMap 的“读取后加一再写回”应改用 merge(key, 1, Integer::sum) 等原子方法；同步包装集合的遍历还需要按官方要求在包装对象上加锁。CopyOnWriteArrayList 的迭代器读取创建时的数组快照，不反映后续写入，也不支持迭代器自身的增删改。

3、ArrayList的扩容机制是什么？

回答提示：

• 初始容量：OpenJDK 17u 的无参 new ArrayList<>() 先使用共享空数组，首次添加元素时通常分配容量 10；new ArrayList<>(0) 则首次添加时只需容量 1。容量与 size() 不同。
• 扩容触发：当向ArrayList中添加元素，且当前元素数量达到容量上限时，就会触发扩容操作。
• 扩容策略：ArrayList的扩容策略是增长大约50%的容量。
• 数组复制：扩容过程中，ArrayList会创建一个新的、更大容量的数组，并将原有数组中的所有元素复制到新数组中。

参考回答：

• OpenJDK 17u 通常优先增长 oldCapacity >> 1，即新容量约为旧容量的 1.5 倍；如果该增长不足以容纳批量添加所需元素，则至少满足最小所需容量，并处理数组长度上限。扩容通过复制元素引用到新数组实现，不会复制元素对象本身。尾部追加的均摊时间为 O(1)，单次扩容为 O(n)。增长策略由类库实现决定，不由 JVM 规范规定。

4、ArrayList和linkedList的区别？

回答提示：

• 内部实现：ArrayList是基于动态数组实现的，元素引用存放在同一数组中（元素对象本身不保证连续）；而LinkedList则是基于双向链表实现，元素通过指针相互连接。
• 随机访问：ArrayList支持快速随机访问，时间复杂度为O(1)；LinkedList则需要遍历，时间复杂度为O(n)。
• 内存占用：LinkedList每个节点除了存储数据外，还需要存储指向前一个和后一个节点的指针，因此比ArrayList更占内存。
• 使用场景：ArrayList适用于需要频繁进行随机访问的场景；而 LinkedList 在首尾操作、或已由迭代器定位到位置后插删时才有 O(1) 的链接调整优势；按索引插删仍需 O(n) 定位。

参考回答：

• ArrayList：基于动态数组，连续存放元素引用，适合下标访问（随机访问），扩容机制：因为数组长度固定，超出长度存数据时需要新建数组，然后将老数组的数据拷贝到新数组，如果不是尾部插入数据还会涉及到元素的移动（往后复制一份，插入新元素），预估容量可减少扩容复制；尾部追加通常具有较好的局部性，但性能结论应结合实际负载测量
• LinkedList：基于双向链表，首尾操作为 O(1)；按索引访问会从较近的一端遍历，最坏 O(n)，不能笼统地说所有插删都更快
• 遍历 LinkedList 可用增强 for 或 Iterator，整体 O(n)；应避免 for (int i = 0; i < list.size(); i++) list.get(i) 这种反复按索引访问的写法，其完整遍历为 O(n²)。indexOf 返回未找到时的 -1，也需线性查找。

5、HashMap和HashTable有什么区别？

回答提示：

• 线程安全性：HashMap是非线程安全的，而HashTable是线程安全的。HashTable通过synchronized关键字实现同步，但可能导致性能下降。
• null值处理：HashMap允许null作为键和值，而HashTable不允许。
• 性能：由于HashMap不需要考虑线程同步，通常性能更高。

参考回答：

区别 ：

线程安全性

• HashMap方法没有synchronized修饰，线程非安全，HashTable线程安全；

空键和空值：

• HashMap允许key和value为null，而HashTable不允许

历史遗留：（了解）

• Hashtable 是 Java 1.0 中的遗留类，虽然仍然可以使用，但通常建议使用 HashMap，并结合 java.util.concurrent 包中的现代并发类来处理多线程问题。
• HashMap 是在 Java 2 中引入的，设计更现代化，使用也更加灵活。

迭代器：(了解)

• HashMap 使用的是快速失败（fail-fast）的迭代器，如果在创建迭代器后对集合进行了结构上的修改（除了使用迭代器自身的 remove 方法外），迭代器通常会抛出 ConcurrentModificationException，但这是尽力检测，不能据此保证并发安全。
• Hashtable 的 keys()、elements() 返回非 fail-fast 的 Enumeration；keySet()、entrySet() 等集合视图返回的 Iterator 则是尽力检测的 fail-fast 迭代器。

性能：（了解）

• 在没有线程安全需求的场景中，HashMap 通常比 Hashtable 性能更高，因为它没有同步的开销。

HashMap底层原理

HashMap底层原理 （了解）

• 无参 HashMap 默认负载因子为 0.75，桶数组延迟到首次插入时分配，默认长度 16。通常在新增映射后 size > threshold 才扩容，阈值通常为 capacity × loadFactor；默认容量 16 时，第 13 个不同的键触发负载阈值扩容。这里统计的是映射数，不是已占用桶数。扩容通常将数组长度翻倍，并重新分配桶位置，不是按 hashCode 排序；CPU 能执行乘法，采用位运算不是因为“不支持乘法”。
• JDK 7 使用数组加链表；自 JDK 8 起增加红黑树桶。以 OpenJDK 17u 的普通 put 路径为例：向已有 8 个节点的链表追加第 9 个不同键时尝试树化；数组长度至少 64 才树化，否则优先扩容。其他插入路径应结合具体源码判断，不能把阈值常量 8 简化成“第 8 个节点必树化”。

底层数据结构

• HashMap 的数组槽位称为桶，保存桶首节点的引用；每个节点才是一个 key-value 映射。在 Java7 中叫 Entry，Java8 中叫 Node。 因为它本身所有的位置都为 null，在 put 插入的时候会根据 key 的 hash 去计算一个 index 值。比如，我 put （"枫斗者"，666），在 HashMap 中插入 "枫斗者" 这个元素，通过 hash 算法算出 index 位置是 3。这时的结构如下所示，还是个数组。

| | | | 枫斗者 | | | | |
|

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

适用范围：ARP 示例以 IPv4 以太网为例；TCP 连接状态以 RFC 9293（2022）为准；拥塞控制先讲 RFC 5681 的经典算法；HTTP 方法语义依据 RFC 9110（2022），并区分 HTTP/1.1、HTTP/2 与 HTTP/3。协议机制不等于某个操作系统或框架的默认配置。

1、网络7层架构是什么？

• 应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
• 表示层（数据）：主要解决用户信息的语法表示问题，如加密解密
• 会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，这是参考模型的职责划分，实际 Web 登录验证通常由应用层实现
• 运输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制等
• 网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的传输
• 数据链路层（帧）：包含 MAC 等子层，将上层数据封装成帧，用MAC地址访问媒介，错误检测；是否纠错或重传取决于具体链路协议
• 物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等

2、TCP/IP 四层模型？

• 应用层：对应于OSI参考模型的（应用层、表示层、会话层）。
• 传输层: 对应OSI的传输层，为应用进程提供端到端通信；TCP 提供可靠、有序的字节流，UDP 不保证交付或顺序。
• 网际层：对应于OSI参考模型的网络层，主要解决主机到主机的通信问题。
• 网络接口层：与OSI参考模型的数据链路层、物理层对应。

3、请简单说下ARP协议的工作过程？

• 主机先查路由表确定出口与下一跳：同链路通信通常解析目的主机的 MAC；跨网段通信解析网关的 MAC，而不是远端主机的 MAC。
• 若 ARP 缓存已有下一跳 IPv4 地址对应的有效 MAC，直接封装以太网帧；否则在本地链路广播 ARP Request，询问谁拥有这个下一跳地址。
• 拥有该地址的主机通常单播回复 ARP Reply；发送方更新缓存后发送数据。请求重试仍无响应时，本次邻居解析失败，不等于能断定远端主机已关机。

4、请简单说下ARP协议的工作过程？

这一题可结合跨网段示意理解：IP 目的地址与以太网帧的目的 MAC 不一定属于同一台设备。

A: 192.168.1.10/24  →  网关: 192.168.1.1  →  B: 192.168.2.20/24
A 查路由后 ARP 查询 192.168.1.1
A 发出的帧：目的 MAC = 网关 MAC；内部 IP 包：目的 IP = B

ARP 广播不会由路由器转发到远端子网。接收方会根据已有缓存和是否为请求目标更新映射，不能简单理解为“非目标设备一律忽略所有信息”。ARP 不提供身份认证；IPv6 使用 ICMPv6 邻居发现而不是 ARP。参见 RFC 826 的生成与接收算法、RFC 4861。

5、TCP和UDP什么区别？

• TCP 面向连接，提供可靠、有序的字节流，不保留应用消息边界；应用需用长度字段或分隔符等方式划分消息。UDP 无连接并保留数据报边界，自身不提供重传、排序、流量控制或拥塞控制；应用或上层协议可补充这些能力（如 QUIC）。TCP 的可靠性也不意味着网络中断后仍保证成功交付，应用仍须处理连接错误。

6、详细说下 TCP 三次握手的过程？

• 三次握手
• TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。

• 最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A（Client） 主动打开连接，B（Server） 被动打开连接。
• 一开始，B 的 TCP 服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。
• 第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq = x。本例 SYN 不携带数据；协议允许 SYN 携带数据，但在连接确认前不能将数据交付应用。SYN 标志本身消耗一个序号。这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。
• 第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。本例 SYN+ACK 不携带数据，SYN 本身同样消耗一个序号。这时 TCP 服务端进程进入 SYN-RCVD（同步收到）状态。
• 第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态；B 在收到有效的第三次握手 ACK 后才进入 ESTABLISHED。

7、为什么两次握手不可以呢？

• 为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。比如下面这种情况：A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。
• 对于上面这种情况，如果不进行第三次握手，B 发出确认后就认为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
• 如果采用了三次握手，由于 A 实际上并没有发出建立连接请求，对于已无对应连接的旧 SYN+ACK，A 通常回复 RST，使 B 清理半连接；若无有效回应，B 也会在重试超时后清理。第三次握手让 B 确认 A 收到了自己的初始序号。

8、为什么不需要四次握手？

• 有人可能会说 A 发出第三次握手的信息后在没有接收到 B 的请求就已经进入了连接状态，那如果 A 的这个确认包丢失或者滞留了怎么办？
• 第三次握手已经确认了双方的初始序号，不需要再为纯 ACK 增加一次握手。若最后的 ACK 丢失，B 仍处于 SYN-RCVD，可重传 SYN+ACK，A 再回复 ACK；后续带有效确认号的数据也可能完成确认。若持续丢包，则重试最终超时，建立连接仍可能失败。参见 RFC 9293 §3.5。

9、详细说下 TCP 四次挥手的过程？

• 数据传输结束后，通信的双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。

• 第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。
• 第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待 B 发出的连接释放报文段。
• 第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。
• 第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。在本例的正常关闭路径中，B 先于 A 关闭；TIME-WAIT 用于应对最后 ACK 丢失后的 FIN 重传，并让旧报文过期。ACK 与 FIN 可以合并，因此关闭不一定恰好四个报文段；同时关闭和 RST 中止也不遵循这一示例路径。

10、TCP 协议是如何保证可靠传输的？

• 数据包校验：通过校验和检测传输差错，但无法检出所有可能的变化，也不提供抗篡改认证，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
• 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
• 丢弃重复数据：对于重复数据，能够丢弃重复数据；
• 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。可以采用延迟确认，但并非所有 ACK 都延迟，失序报文等场景通常需及时反馈；
• 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
• 流量控制：TCP 连接的接收端缓冲空间有限，大小可以由实现动态调整。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

11、谈下你对 TCP 拥塞控制的理解？使用了哪些算法？

• 拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。
• 拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
• 为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
• RFC 5681 描述的经典 TCP 拥塞控制包含四种相互配合的算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。
• 慢开始：
• 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的负荷情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 以字节计；在持续有数据、ACK 正常返回且未受其他限制时，慢开始阶段每 RTT 近似翻倍。初始窗口并非固定为 1 MSS；RFC 6928 的实验性方案允许最多 10 MSS（还受字节上限约束），实际取值依实现而定。
• 拥塞避免：
• 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即经典拥塞避免阶段每 RTT 大约增加 1 MSS，而不是增加 1 字节；这不是所有拥塞控制算法的统一增长规则。
• 快重传与快恢复：
• 在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。
• 经典快重传在收到三个重复 ACK 时推断报文段丢失并重传，无须等到重传超时。重复 ACK 也可能由重排序产生，因此这是一种丢包推断；没有快重传并不意味着定时器会让整个连接立即暂停。
• 经典 Reno 快恢复在调整 ssthresh 和 cwnd 后继续利用 ACK 反馈发送，避免每次丢包都退回慢开始；多包丢失时恢复效率可能降低。现代实现还可结合 SACK、RACK-TLP 等机制，不能把“收到三个重复 ACK”当成唯一丢包检测条件。

参考：RFC 5681 §3、RFC 6928 §2、RFC 8985。

11、说下 GET 和 POST 的区别？

• GET 请求目标资源的表示；POST 请求目标资源按其自身语义处理提交的内容，例如创建订单、提交表单，并不限于更新资源。两者都各自是一次 HTTP 请求。即使用 Expect: 100-continue 先等临时响应再发送内容，也仍是同一次请求；TCP 分包次数不等于 HTTP 请求次数。
• GET 是安全且幂等的方法：安全指客户端不请求改变资源状态，幂等指多次相同请求的预期服务器效果与一次相同，并非每次响应内容必须相同。访问日志等副作用不违背安全语义。POST 不保证幂等，业务可用幂等键等机制防止重复下单。
• 查询参数位于 URI 的 query 部分，不是请求头字段；在 HTTP/1.1 中通常出现在请求行。POST 同样可以带查询参数，请求体也不限于表单。GET 请求内容没有普遍定义的语义，可能被中间件拒绝，不宜依赖 GET body 传参。
• %E4%BD%A0%E5%A5%BD 是“你好”的 UTF-8 字节的百分号编码，不是 Base64，也不是加密。表单编码 application/x-www-form-urlencoded 将空格编码为 +；这一规则不能泛化到所有 URI 部分。
• POST 不自带加密，传输机密性依赖 HTTPS。URL 参数更容易出现在历史记录和访问日志中，但请求体也可能被记录，敏感数据的保护不能只靠更换方法。
• HTTP 没有规定 GET/POST 的统一大小上限；URI、请求头、请求体均受客户端、代理和服务器配置限制。POST 并非无限大。

方法语义适用于 HTTP/1.1、HTTP/2、HTTP/3；报文在线路上的表示不同。参见 RFC 9110 §9.2–9.3、RFC 3986 §2.1。

12、什么是 Cookie 和 Session ？

• 什么是 Cookie？

• HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，浏览器会根据 Domain、Path、Secure 等属性及浏览器的 Cookie 策略决定是否随请求发送它。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

• Cookie 主要用于以下三个方面：

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）

• 个性化设置（如用户自定义设置、主题等）

• 浏览器行为跟踪（如跟踪分析用户行为等）

• 什么是 Session？

• Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。服务端 Session 通常在超时或显式失效时结束，关闭浏览器不等于服务端立即销毁 Session。常见机制是浏览器携带会话 ID，服务端据此查找状态；多实例部署需考虑共享存储或会话路由。

13、Cookie 和 Session 的区别？

• 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
• 存取方式的不同，Cookie 值须符合协议字符约束，非 ASCII 数据需先编码；Session 可保存的数据类型取决于框架与存储，分布式存储通常还要求可序列化，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 的有效期由服务端管理；关闭浏览器可能丢失会话 Cookie，但不会直接通知服务端销毁 Session，浏览器恢复功能也可能保留它。
• 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，但客户端持有的会话 ID 被窃取后仍可能遭到会话劫持，需结合 HTTPS、Secure、HttpOnly 等保护。
• 存储大小不同， RFC 6265 建议通用客户端至少支持每个 Cookie 4096 字节（名称、值与属性合计），实际限制依浏览器而定；这不是业务可依赖的无限配额。Session 容量受服务端内存、存储与框架限制。

Cookie 的存储、发送规则与容量建议参见 RFC 6265 §5–6。

14、对称加密与非对称加密有什么区别？

• 对称加密：指加密和解密使用同一密钥，优点是运算速度较快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有：AES 等。

• 非对称加密：指的是加密和解密使用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常见的非对称加密算法有RSA。

15、Http请求的过程与原理?

• HTTP 是应用层协议，可以传递 HTML、图片、JSON 等表示。下面以新建连接的 HTTP/1.1 为例；HTTPS 还需 TLS 握手，HTTP/2 通常复用 TCP 连接，而 HTTP/3 使用基于 UDP 的 QUIC，不能套用 TCP 三次握手。

• Http请求过程

• 客户端进行DNS域名解析，得到对应的IP地址

• 根据这个IP，找到对应的服务器建立连接（三次握手）

• 建立TCP连接后发起HTTP请求（一个完整的http请求报文）

• 服务器响应HTTP请求，客户端得到html代码

• 客户端解析html代码，用html代码中的资源(如js,css,图片等等)渲染页面。

• HTTP/1.1 默认使用持久连接，可复用以继续请求资源；仅在需要关闭时才释放 TCP 连接，不是每个响应后都四次挥手。DNS、连接和资源也可能命中缓存或复用。

版本依据：RFC 9112 §9、RFC 9114。

16、说说ARP与RARP 的区别？

• ARP（Address Resolution Protocol）和RARP（Reverse Address Resolution Protocol）都是用于在网络通信中进行地址转换的协议，但它们在功能、工作方式和用途上有一些区别。

• 功能不同：

• ARP协议用于将IP地址转换为MAC地址。在通信过程中，当一台主机需要知道另一台主机的MAC地址时，它可以使用ARP协议查询目标主机的MAC地址。

• RARP协议则用于将MAC地址转换为IP地址。在启动过程中，当一台主机需要知道自己的IP地址时，可以向网络中发送RARP请求，以获取自己的IP地址。

• 工作方式不同：

• ARP协议是一种广播协议。当主机需要知道另一台主机的MAC地址时，它在本地局域网上广播一个ARP请求包，只有目标主机会响应并将自己的MAC地址发送回来。

• RARP 客户端在本地链路广播请求，由维护 MAC 到 IP 映射的 RARP 服务器应答，不要求客户端事先知道服务器地址。

• 用途不同：

• 由于现代操作系统和网络设备能够自动分配IP地址，RARP协议的使用已经相对较少。

• ARP协议在现代网络通信中仍然扮演着重要的角色，用于解析目标主机的MAC地址。

• 总体而言，ARP和RARP在网络中的地址解析过程中有各自的功能和应用场景，不能把二者当成可互换的地址配置方案；RARP 的广播请求机制见 RFC 903。

17、TCP/IP原理？

• TCP/IP 协议不是 TCP 和 IP 这两个协议的合称，而是指因特网整个 TCP/IP 协议族。从协议分层模型方面来讲，TCP/IP 由四个层次组成：网络接口层、网络层、传输层、应用层。

• 网络访问层(Network Access Layer)
• 网络访问层(Network Access Layer)在 TCP/IP 参考模型中并没有详细描述，只是指出主机必须使用某种协议与网络相连。
• 网络层(Internet Layer)
• 网络层(Internet Layer)是整个体系结构的关键部分，其功能是使主机可以把分组发往任何网络，并使分组独立地传向目标。这些分组可能经由不同的网络，到达的顺序和发送的顺序也可能不同。高层如果需要顺序收发，那么就必须自行处理对分组的排序。互联网层使用因特网协议(IP，Internet Protocol)。
• 传输层(Transport Layer-TCP/UDP)
• 传输层(Transport Layer)使源端和目的端机器上的对等实体可以进行会话。在这一层定义了两个端到端的协议：传输控制协议(TCP，Transmission Control Protocol)和用户数据报协议(UDP，User Datagram Protocol)。TCP 是面向连接的协议，它提供可靠的字节流传输和对上层应用的连接服务。为此，除了基本的数据传输外，它还有可靠性保证、流量控制、多路复用等功能；TCP 本身不提供加密和应用身份认证。UDP 是面向无连接的不可靠传输的协议，主要用于不需要 TCP 的排序和流量控制等功能的应用程序。
• 应用层(Application Layer)
• 应用层(Application Layer)包含所有的高层协议，包括：虚拟终端协议(TELNET，TELecommunicationsNETwork)、文件传输协议(FTP，File Transfer Protocol)、电子邮件传输协议(SMTP，Simple Mail Transfer Protocol)、域名服务(DNS，Domain Name Service)、网上新闻传输协议(NNTP，Net News Transfer Protocol)和超文本传送协议(HTTP，HyperText Transfer Protocol)等。

18、说下CDN 原理？

• CDN 一般包含分发服务系统、负载均衡系统和管理系统
• 分发服务系统
• 其基本的工作单元就是各个 Cache 服务器。负责直接响应用户请求，将内容快速分发到用户；同时还负责内容更新，保证和源站内容的同步。根据内容类型和服务种类的不同，分发服务系统分为多个子服务系统，如：网页加速服务、流媒体加速服务、应用加速服务等。每个子服务系统都是一个分布式的服务集群，由功能类似、地域接近的分布部署的Cache 集群组成。在承担内容同步、更新和响应用户请求之外，分发服务系统还需要向上层的管理调度系统反馈各个Cache 设备的健康状况、响应情况、内容缓存状况等，以便管理调度系统能够根据设定的策略决定由哪个 Cache 设备来响应用户的请求。
• 负载均衡系统：
• 负载均衡系统是整个 CDN 系统的中枢。负责对所有的用户请求进行调度，确定提供给用户的最终访问地址。
• 使用分级实现。最基本的两极调度体系包括全局负载均衡（GSLB）和本地负载均衡（SLB）。
• GSLB 根据用户地址和用户请求的内容，主要根据就近性原则，确定向用户服务的节点。一般通过 DNS 解析或者应用层重定向（Http 3XX 重定向）的方式实现。
• SLB 主要负责节点内部的负载均衡。当用户请求从 GSLB 调度到 SLB 时，SLB 会根据节点内各个Cache 设备的工作状况和内容分布情况等对用户请求重定向。SLB 的实现有四层调度（LVS）、七层调度（Nginx）和链路负载调度等。
• 管理系统：分为运营管理和网络管理子系统。
• 网络管理系统实现对 CDN 系统的设备管理、拓扑管理、链路监控和故障管理，为管理员提供对全网资源的可视化的集中管理，通常用 web 方式实现。
• 运营管理是对 CDN 系统的业务管理，负责处理业务层面的与外界系统交互所必须的一些收集、整理、交付工作。包括用户管理、产品管理、计费管理、统计分析等。

阅读提示

这页题量很大，建议先吃透 4 条主线：Kafka 是什么 -> 为什么快 -> 可靠性怎么保 -> 顺序与幂等如何落地。
面试回答时先给结论，再给关键参数（如 acks、ISR、offset），最后补一个业务场景。

本文以 Apache Kafka 4.0.x 与官方 Java 客户端为基准；消费者分配讨论普通 consumer group（subscribe），不涵盖 Share Group。历史版本差异另行注明。

推荐训练法

1. 第一遍只看问题标题，先建立知识地图。
2. 第二遍优先掌握“可靠性、顺序性、重复消费”三块高频追问。
3. 第三遍用 2 分钟口述 1 题，训练可表达性。

什么是消息中间件？（了解）

• 消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。
• 消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

Kafka是什么？有什么作用？（了解）

• Kafka 是一个分布式的流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用

• 主要功能体现于三点：

• 消息系统：kafka与传统的消息中间件都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，kafka还提供了大多数消息系统难以实现的消息顺序性保障及回溯性消费的功能。

• 存储系统：kafka把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效的降低了消息丢失的风险。这得益于其消息持久化和多副本机制。也可以将kafka作为长期的存储系统来使用，需要按容量配置保留策略；日志压缩只保留每个 key 的最新状态（删除标记也有保留期限），不等于永久保留所有历史事件。

• 流式处理平台：kafka为流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理框架，比如窗口、连接、变换和聚合等各类操作。

Kafka中有哪几个组件?

• 主题：Kafka主题是一堆或一组消息。
• 生产者：在Kafka，生产者发布通信以及向Kafka主题发布消息。
• 消费者：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。
• 经纪人：在管理主题中的消息存储时，我们使用Kafka Brokers。

Kafka Replicas是怎么管理的？（了解）

• AR:分区中的所有 Replica 统称为 AR
• ISR:所有与 Leader 副本保持一定程度同步的Replica(包括 Leader 副本在内)组成 ISR
• OSR:与 Leader 副本同步滞后过多的 Replica 组成了 OSR
• Leader 负责维护和跟踪 ISR 集合中所有 Follower 副本的滞后状态，当 Follower 副本落后过多时，就会将其放入 OSR 集合，当 Follower 副本追上了 Leader 的进度时，就会将其放入 ISR 集合。
• 默认情况下，只有 ISR 中的副本才有资格晋升为 Leader。

kafka的消费者是pull(拉)还是push(推)模式，这种模式有什么好处？

• Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从broker 拉取消息。
• 优点：pull模式消费者自主决定是否批量从broker拉取数据，而push模式在无法知道消费者消费能力情况下，不易控制推送速度，太快可能造成消费者奔溃，太慢又可能造成浪费。
• 缺点：如果 broker 没有可供消费的消息，将导致 consumer 不断在循环中轮询，直到新消息到到达。为了避免这点，broker 长轮询由 fetch.min.bytes 指定期望最小字节数，fetch.max.wait.ms 限制等待时间；二者与应用 poll(Duration) 的等待上限不同。

kafka维护消息状态的跟踪方法（了解）

• 在同一个消费者组内，同一分区在稳定分配时只交给一个消费者；不同组可以独立消费同一分区。已提交 offset 代表下一条待消费位置，区别于客户端已拉取的位置。
• offset 不等于业务完成凭证。先提交再处理，崩溃后可能跳过未处理消息；先处理再提交，二者之间崩溃会重放。位移跟踪不会自动消除丢失或重复。

kafka判断一个节点还活着的有那两个条件？

• 存活与同步资格是两件事。旧 ZooKeeper 模式依赖 broker 的 ZooKeeper 会话；Kafka 4.0 已移除该模式。KRaft 中 broker 向活动 controller 发送心跳，超时会被围栏（fence）。
• follower 是否留在 ISR 还取决于复制进度，未在 replica.lag.time.max.ms 允许时间内追上 leader 会被移出 ISR。进程存活不代表能承担干净的 leader 切换。

参见官方 KRaft 与 ZooKeeper 差异。

讲一讲 kafka 的 ack 的三种机制

Java 客户端使用 acks（request.required.acks 是旧客户端名称），4.0 默认 all：

• 0：不等待 broker 响应，无法确认是否收到记录，客户端通常也无法据此重试。
• 1：leader 写本地日志后响应，不等 follower 复制；此时 leader 故障可能丢失已确认记录。
• all（-1）：等待当前 ISR 确认，不是等待全部配置副本。配合 min.insync.replicas 约束最少 ISR 数量，不足则拒绝写入，不能宣称绝不丢失。

参见官方 acks 与幂等配置。

kafka 分布式（不是单机）的情况下，如何保证消息的顺序消费?

• Kafka 中发送 1 条消息的时候，可以指定(topic, partition, key) 3 个参数，partiton 和 key 是可选的。
• Kafka 分布式的单位是 partition，同一个 partition 用一个 write ahead log 组织，所以可以保证FIFO 的顺序。不同 partition 之间不能保证顺序。因此你可以指定 partition，将相应的消息发往同 1个 partition，并且在消费端，同组稳定分配时，1 个 partition 只交给 1 个 consumer，就可以实现这些消息的顺序消费。
• 另外，你也可以指定 key（比如 order id），具有同 1 个 key 的所有消息，会发往同 1 个partition，分区数与策略不变时，同 key 可保持分区内日志顺序；消费端还须按分区串行处理。关闭幂等且有多个在途请求时，生产重试可能乱序。

kafka 如何不消费重复数据？比如扣款，我们不能重复的扣。

• 幂等生产者：producer ID、epoch 和分区序列号避免同一生产会话重试导致重复写入；应用再次 send 同一业务事件仍可产生两条记录。4.0 无冲突配置时默认启用，要求 acks=all、retries>0、max.in.flight.requests.per.connection<=5。
• 事务：Kafka 可原子提交输出记录与消费位移，消费端使用 isolation.level=read_committed 隔离未提交和已中止的事务记录。这适用于 Kafka 到 Kafka 的处理，不能直接将外部数据库扣款纳入 Kafka 事务。
• 业务幂等：用事件 ID 建唯一约束，将“写去重记录”和“更新余额”放在同一数据库事务中，再提交 Kafka 位移；重放时约束阻止再次扣款。调用外部支付接口还需对方支持幂等键。
• 手动提交 offset：处理完成再提交仍有“业务成功、提交前崩溃”的重放窗口；提交失败也需处理，手动提交本身不去重。

poll(offset=42) -> 数据库事务：去重记录 + 扣款 -> commit offset=43
                                      |
                               提交前崩溃：重放 42
                               唯一约束阻止重复扣款

参见官方 交付语义 和 隔离级别。

partition的数据文件（offffset，MessageSize，data）（了解）

• 标题中的 (offset, MessageSize, data) 只能作为旧格式的简化记忆，不是 Kafka 4.0 的完整布局。自 0.11 起的 magic=2 格式以 RecordBatch 为单位，含 baseOffset、batchLength、CRC、属性、时间戳、producer ID/epoch、序列号等；批内 Record 使用 offset delta，还可包含 key、value、headers。
• offset 是分区内逻辑位置，不是文件字节地址；日志压缩清理后可能有空洞，不能保证指定 offset 仍有记录。batchLength 也不是单条消息体大小。
• 分区日志分成多个 segment：.log 存数据，.index 是 offset 到文件位置的稀疏索引，.timeindex 辅助按时间查找。先按 base offset 定位 segment，再查索引并顺序扫描日志。

参见官方 消息格式 与 日志实现。

kafka如何实现数据的高效读取？（顺序读写、分段命令、二分查找）

• Kafka实现数据的高效读取主要依赖于其独特的设计，包括顺序读写、分段存储和二分查找等机制。具体来说：

• 顺序读写：Kafka采用顺序写入的方式，新消息会被追加到已有消息的末尾。这种写入模式减少了磁盘I/O操作的随机访问，大大提高了写入效率。同样，读取时也是顺序读取，这与磁盘的物理特性相契合，进一步提升了读取性能。

• 分段存储：Kafka将每个partition划分为多个segment，每个 segment 包含日志与索引文件，按大小或时间等条件滚动，实际大小不固定。这样设计避免了管理大文件的复杂性，同时方便了对旧数据的清理。每个segment文件独立存储，使得数据管理和维护更加高效。

• 二分查找：Kafka为每个segment维护了一个索引文件，其中存储了消息的offset和物理位置的映射关系。当需要查找特定offset的消息时，Kafka会利用二分查找算法先定位 segment，再在稀疏索引中找不大于目标 offset 的最近位置，随后顺序扫描日志，从而实现了高效的数据访问。

• 此外，Kafka还通过内存缓存、消息压缩等技术手段进一步提升了数据的读取效率。内存缓存使得Kafka可以将索引文件的部分内容保留在内存中，加速查找操作；而消息压缩则减少了磁盘和网络带宽的使用，使得数据在传输和存储时更加高效。

Kafka 消费者端的 Rebalance 操作什么时候发生？（了解）

• 在Kafka中，消费者端的Rebalance操作主要发生在以下几种情况，以确保消费者组能够公平且高效地分配订阅主题的分区：

• 消费者组成员变化：当有新消费者加入消费者组或现有消费者离开（无论是正常关闭、崩溃还是长时间未发送心跳被判定为“死亡”）时，会触发Rebalance。这是因为消费者组的成员变化可能导致分区分配不再均衡。

• 订阅主题分区数变化：如果消费者组订阅的任一主题的分区数发生变化（如分区增加；Kafka 不支持直接减少已有主题的分区数），也会触发Rebalance。这是为了根据新的分区情况重新分配消费者与分区之间的关系。

• 消费者组订阅变化：当消费者组订阅的主题列表发生变化，比如消费者取消了对某些主题的订阅，同样可能引发Rebalance。

• 协调者故障或变化：负责管理消费者组的协调者（Coordinator）如果发生故障，或者消费者组被重新分配给了另一个协调者，不必然触发分区重分配，状态恢复时可继续原分配。

• Rebalance过程是一个协调消费者组内成员重新分配分区的过程，它确保了消费者组能够动态地适应变化，保持高效的消息处理能力。然而，频繁的Rebalance可能会对性能产生负面影响，因此在设计和使用Kafka时，需要合理设置相关参数和配置，以减少不必要的Rebalance操作。

4.0 的 group.protocol 默认是 classic；选择 consumer 协议后使用新的增量协调机制，不能将所有再均衡都理解成全组停顿。经典协议使用 session.timeout.ms、heartbeat.interval.ms，新协议的心跳与会话超时由服务端相关参数控制。处理过慢超过 max.poll.interval.ms 也会影响组成员资格。手动 assign 不参与这种自动分区分配。参见官方 消费者配置。