重要技术概念：学习导航入口

1 IoC（控制反转）/ DI（依赖注入）

面试必答要点

• 定义：对象的创建和管理权从代码手动 new 转交给 Spring 容器，这叫"控制反转"；容器主动把依赖对象"注入"到需要的地方，这叫"依赖注入"。
• 三种注入方式：构造器注入（推荐，不可变、可测试）、@Autowired 字段注入（简洁但不推荐）、Setter 注入（很少用）。
• 为什么构造器注入更好？依赖不可变（final）、防止循环依赖在编译期暴露、方便单元测试时直接 new 对象传入 mock（模拟替身对象）。

2 Spring Boot 自动配置（Auto-Configuration）

面试必答要点

• 原理：Starter（启动器依赖） 通过 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（Spring Boot 3.x）注册自动配置类。
• 条件注解：@ConditionalOnClass（类路径有某个类时生效）、@ConditionalOnMissingBean（没有用户自定义 Bean（由 Spring 容器管理的对象） 时才创建默认的）。
• Spring Boot 与 Spring 的区别：Boot 是 Spring 的"脚手架"，提供约定优于配置、自动配置、内嵌服务器、Starter 依赖管理。

3 分层架构（Layered Architecture）

面试必答要点

• 各层职责：Controller（接收请求/参数校验）、Service（业务逻辑）、Repository（数据访问）、Entity（领域模型）。
• Service 为何分接口与实现？面向接口编程——方便测试时 Mock、方便未来替换实现（如从 MySQL 切到 MongoDB）。
• DTO vs Entity 的区别？Entity 映射数据库表，可能包含敏感字段（如 password）；DTO（Data Transfer Object，数据传输对象） 只暴露前端需要的数据，防止敏感信息泄露。项目中 User.password 加了 @JsonIgnore，同时通过 DTO 做了双重保护。

flowchart TD
调用方[前端 / 调用方] --> 边界[DTO / 接口边界]
边界 --> 控制器[Controller 层]
容器[Spring 容器] --> IoC[IoC / DI：统一管理对象]
IoC --> 自动配置[自动配置：按条件补齐默认 Bean]
自动配置 --> 控制器
自动配置 --> 服务[Service 层]
自动配置 --> 仓库[Repository 层]
控制器 -.依赖注入.-> 服务
服务 -.依赖注入.-> 仓库
控制器 --> 服务
服务 --> 仓库
仓库 --> 数据库[(数据库)]

4 Lombok 常用注解与原理

面试要点

• 常用注解：@Data（getter/setter/equals/hashCode/toString）、@Builder、@RequiredArgsConstructor、@Slf4j。
• 实现原理：基于 APT（Annotation Processing Tool，注解处理工具） 在编译期修改 AST（Abstract Syntax Tree，抽象语法树） / 生成字节码，运行期无额外反射成本。
• 注意事项：@Data 的 equals/hashCode 对实体类可能引发问题；Builder 与继承需要额外处理（如 @SuperBuilder）。

5 WebSocket

为什么这里要用 WebSocket？（项目视角，面试很爱问）

• 因为这是“异步任务通知”场景：大题库导出不是一个请求里几百毫秒就能完成的小操作，而是可能持续数秒甚至更久的后台任务。接口先返回 taskId，真正的导出在异步线程里慢慢跑。
• 前端需要“被动接收结果”，而不是“主动反复打听”：如果不用 WebSocket，前端就只能每隔 1 秒轮询一次“导出好了没？”。用户一多，就会产生大量无意义的查询请求。
• 这个场景更像“通知中心”：导出完成、导出失败、部分图片加载失败，这些都是典型的“后端主动通知前端”的消息，而不是前端每次都发请求来拿。
• 项目需要“定向通知某个用户”：WebSocketConfig 同时配置了 /topic（广播）和 /queue（点对点），并设置了 /user 前缀；AsyncExportService 用 convertAndSendToUser(..., "/queue/export-complete", ...) 把完成通知精确推给当前用户，而不是广播给所有人。

为什么不是轮询（Polling）？

• 轮询能做，但浪费：假设一个导出任务要 30 秒，前端每秒查一次，就会多出 30 个请求；如果同时 100 个用户在导出，就是 3000 个“只是问进度”的额外请求。
• 轮询实时性也不稳定：轮询间隔太短，服务器压力大；间隔太长，用户感知卡顿。WebSocket 则是“有消息立刻推”。
• 轮询更像兜底，不像主方案：项目里保留了按 taskId 查询任务状态的 HTTP 接口，这更适合页面刷新后补查、异常兜底，而不是作为主实时通道。

为什么不是 SSE？

• SSE 更适合“连续单向数据流”：比如 AI 打字机输出，一直往前端吐文本，天然是服务器 → 浏览器的单向流。
• 导出任务更像“事件通知”而不是“连续文本流”：它更关注“开始了 / 完成了 / 失败了 / 有告警”，并且项目还需要用户级点对点消息语义，所以 STOMP（Simple Text Oriented Messaging Protocol，面向文本的简单消息协议） + WebSocket 更顺手。
• 换句话说：AI 聊天那种“连续生成内容”适合 SSE；导出任务这种“后台跑完后通知指定用户”的场景，更适合 WebSocket。

面试必答要点

• vs HTTP：全双工 + 持久连接 vs 半双工 + 请求-响应。
• 握手：先用 HTTP Upgrade 升级协议。
• STOMP 协议：在 WebSocket 之上提供发布/订阅消息语义。
• SockJS 兜底：项目在 /ws 端点上启用了 withSockJS()，用于兼容某些不支持原生 WebSocket 的环境或代理场景。
• 补一句术语：SockJS（WebSocket 兼容降级库） 的价值，不是“更高级”，而是原生长连接走不通时还能给浏览器一个可退化方案。
• 项目一句话总结：“导出任务是异步后台作业，前端需要被动接收定向通知，因此选 WebSocket 作为主实时通道；状态查询接口保留为兜底；AI 连续文本流则使用 SSE。”

6 SSE（Server-Sent Events）

面试必答要点

• SSE vs WebSocket：SSE 单向（服务器→客户端），基于 HTTP，更轻量，自动重连；WebSocket 双向。
• 为什么 AI 用 SSE？AI 输出是单向流（模型→用户），不需双向，SSE 更合适。
• 心跳保活：深度思考模型可能静默数十秒，后端每 15-30 秒发 HEARTBEAT 维持连接，防 Nginx/浏览器断连。

7 RESTful API 设计

• 接口风格：REST（Representational State Transfer，表述性状态转移） 强调按资源来设计 HTTP 接口，而不是把动作全堆进 URL。
• HTTP 方法语义：GET（查询）、POST（创建）、PUT（全量更新）、PATCH（部分更新）、DELETE（删除）。
• 状态码：200（成功）、201（创建成功）、204（无内容）、400（参数错误）、401/403（认证/权限）、404（不存在）、500（服务器错误）。
• 幂等性：GET/PUT/DELETE 应该幂等（多次调用效果一样），POST 不幂等。
• 工程化细节：统一错误模型（errorCode/traceId）、分页/排序/过滤参数规范、接口版本（URL/Header）与向后兼容策略。

8 OkHttp 客户端管理与资源清理

面试要点

• 客户端本体：OkHttpClient（OkHttp 客户端实例） 不只是“发 HTTP 请求的工具对象”，它本身还承载连接池、超时、调度和资源复用策略。
• 连接池与并发：合理使用 ConnectionPool（连接池），并在需要时结合 Dispatcher（请求调度器）（maxRequests/maxRequestsPerHost）做并发节流，避免突发请求压垮下游。
• 超时策略：connectTimeout/readTimeout/writeTimeout/callTimeout 分层设置，读写与总调用超时分开。
• 关闭姿势：应用停止时主动清理连接池与执行器（如 connectionPool().evictAll()、dispatcher().executorService().shutdown()）。
• 复用原则：OkHttpClient 应复用而非每次 new；按“调用场景 / 策略维度”拆分实例，以隔离超时、连接池和调用节奏。

9 OpenAPI/Swagger 接口文档

面试要点

• 核心协议与工具链：OpenAPI（接口描述规范） 负责定义接口文档的标准结构，Swagger（基于 OpenAPI 的接口文档工具链） 负责把它展示成可调试页面。
• 核心收益：接口自描述、可视化调试、自动同步参数/响应模型，减少“口口相传”式文档偏差。
• 鉴权展示：配置 SecurityScheme（安全方案声明）（如 Bearer JWT）后可在文档中直接携带 token 调试受保护接口。
• 分组与版本：按模块/版本分组暴露文档，避免单页过大并支持演进。

10 WebFlux 响应式编程（Mono / Flux / 背压）

面试必答要点

• 响应式模型：非阻塞 I/O，线程不等待 I/O 完成而是注册回调后立即释放，适合高并发 I/O 密集场景（如 AI 流式输出）。对比传统 Servlet：一个请求占一个线程，线程会在 I/O 期间阻塞等待。
• Mono<T> vs Flux<T>：Mono（0 或 1 个异步结果） 表示 0 或 1 个异步元素（类比 CompletableFuture）；Flux 表示 0 到 N 个元素流 —— AI 逐字输出就是 Flux（0 到 N 个异步元素流）。
• 背压（Backpressure）：Backpressure（背压） 表示订阅者通知发布者“我现在最多能处理多少”，防止生产者速率远超消费者导致内存溢出。这是响应式编程相比纯异步回调/Future 的核心优势。
• 混用阻塞操作的禁忌：不能在 WebFlux 响应式链中直接调用阻塞操作（如 JPA 同步查库），否则阻塞 Netty（Java 网络框架） 事件循环线程，造成严重性能问题。阻塞调用需通过 subscribeOn(Schedulers.boundedElastic()) 切换到阻塞线程池。
• 适合 vs 不适合：SSE 流式响应、实时推送、高并发 HTTP 代理 ✅；传统数据库 CRUD 密集型应用（需配套响应式 DB 驱动 R2DBC（响应式关系数据库驱动） 才有收益，否则增加复杂度而无性能提升）❌。

11 拦截器（HandlerInterceptor）vs 过滤器（Filter）

面试必答要点

sequenceDiagram
participant 客户端
participant 过滤器
participant 前端控制器
participant 拦截器
participant 控制器
participant 服务层

客户端->>过滤器: 发起 HTTP 请求
过滤器->>前端控制器: 放行到 Spring MVC
前端控制器->>拦截器: 执行 preHandle
拦截器->>控制器: 通过后进入 Controller
控制器->>服务层: 调用业务逻辑
服务层-->>控制器: 返回处理结果
控制器-->>拦截器: Controller 执行结束
拦截器->>拦截器: 执行 postHandle
前端控制器-->>拦截器: 响应即将完成
拦截器->>拦截器: 执行 afterCompletion
前端控制器-->>过滤器: 输出 HTTP 响应
过滤器-->>客户端: 返回响应

• 三个回调时机：preHandle()（请求前，返回 false 则中断后续处理）、postHandle()（Controller 执行后、视图渲染前）、afterCompletion()（请求完全结束后，适合资源清理）。
• 注册方式：实现 WebMvcConfigurer.addInterceptors() 注册，配合 addPathPatterns()/excludePathPatterns() 精确控制生效路径。

12 JWT 双 Token 机制

面试必答要点

• JWT 结构：Header.Payload.Signature 三部分，Base64 编码，用密钥签名防篡改。
• 关键声明（Claims（声明集合））：exp/iat/nbf 控制有效期；sub 表示主体；可选 jti 用于“单 token 可撤销/防重放”。
• 为什么双 Token？AccessToken 短期有效（性能好，无需查库）+ RefreshToken 长期（安全性好，可吊销）。AccessToken 过期后用 RefreshToken 换新的。
• RefreshToken 轮换（Rotation）：每次刷新都签发新的 RefreshToken 并使旧的失效；可做“复用检测”（旧 token 再次出现即判定泄漏，强制登出）。
• 宽限期（Grace Period）：防止移动端网络延迟导致多个请求并发刷新 Token 冲突。
• vs Session（服务端会话）：JWT 在“纯验签”模型下可做到无状态（不需要服务端存储），天然支持分布式；但线上为了踢下线 / 并发会话控制 / 防重放，也常会配合 Redis 做会话治理（混合式，见下方 13B）。Session 天然有状态，需要 Session 共享方案。

stateDiagram-v2
    [*] --> 未登录
    未登录 --> 已签发Token对 : 登录成功 / 通过密码或2FA
    已签发Token对 --> Access有效 : 客户端持有 Access + Refresh
    Access有效 --> 正常访问 : 携带 AccessToken 请求接口
    正常访问 --> Access有效 : 验签通过 / 继续访问
    Access有效 --> Access过期 : exp 到期
    Access过期 --> 刷新中 : 携带 RefreshToken 请求 /refresh
    刷新中 --> 新Token对 : Refresh 合法 + 轮换成功
    新Token对 --> Access有效 : 返回新的 Access + Refresh
    刷新中 --> 宽限复用 : 并发刷新命中宽限期
    宽限复用 --> 新Token对 : 返回同一组新 Token
    刷新中 --> 重新登录 : Refresh 非法 / 过期 / 复用检测失败
    Access有效 --> 会话撤销 : 管理员踢下线 / 会话失效
    会话撤销 --> 重新登录 : 后续请求被拒绝
    重新登录 --> 未登录

sequenceDiagram
    participant Client as 客户端/脚本
    participant Auth as 认证服务
    participant Redis as Redis/DB
    participant API as 业务API

    Note over Client,Auth: 阶段一：首次登录颁发
    Client->>Auth: 用户名+密码登录
    Auth->>Redis: 校验密码
    Redis-->>Auth: 用户信息
    Auth->>Auth: 生成AccessToken(短期)+RefreshToken(长期)
    Auth-->>Client: 返回Token对
    
    Note over Client,API: 阶段二：常规业务请求
    Client->>API: 携带AccessToken请求
    API->>API: 本地验签(无需查库)
    API-->>Client: 返回业务数据
    
    Note over Client,API: 阶段三：无感刷新
    Client->>API: AccessToken过期
    API-->>Client: 401 Unauthorized
    Client->>Auth: 携带RefreshToken刷新
    Auth->>Redis: 校验RefreshToken有效性
    Auth->>Auth: 生成新Token对(轮换)
    Auth-->>Client: 返回新Token
    Client->>API: 重试原请求
    
    Note over Client,Auth: 阶段四：高并发防护
    par 并发刷新场景
        Client->>Auth: Thread1: Refresh请求
        Client->>Auth: Thread2: Refresh请求
        Client->>Auth: Thread3: Refresh请求
    then 宽限期处理
        Auth->>Redis: 标记旧Token为已失效(宽限期)
        Auth-->>Thread2: 返回新Token(复用)
        Auth-->>Thread3: 返回新Token(复用)
    end

13 Spring Security 过滤器链（Filter Chain）

面试必答要点

• OncePerRequestFilter：保证每个请求只经过一次过滤的基类，JWT 过滤器继承它。
• 认证流程：请求 → JwtAuthenticationFilter 解析 Token → 提取 username → 加载 UserDetails → 验证 Token → 设置 SecurityContextHolder（安全上下文持有器） → 后续过滤器/Controller 可获取认证信息。
• 为什么禁用 CSRF？CSRF 防护主要针对“浏览器自动携带 Cookie 凭据”的场景。
  • 本项目主链路：AccessToken 放在 Authorization Header 中，通常不是浏览器跨站自动附带的凭据，因此 CSRF 风险显著降低（但仍需防 XSS（Cross-Site Scripting，跨站脚本攻击））。
  • 注意边界：如果 RefreshToken/AccessToken 通过 Cookie 承载，或存在跨站 Cookie，则仍需考虑 CSRF（SameSite/CSRF Token 等）。这点在 12 的“易混点”也有提示。

flowchart LR
    subgraph 登录建立身份
        A[客户端提交用户名/密码/2FA] --> B[AuthController]
        B --> C[AuthenticationManager]
        C --> D[AuthenticationProvider]
        D --> E[UserDetailsService + PasswordEncoder]
        E --> F[签发 AccessToken + RefreshToken]
    end

    F --> G[客户端后续携带 AccessToken]

    subgraph 请求回流校验
        G --> H[CORS / 浏览器入口]
        H --> I[Security Filter Chain]
        I --> J[JwtAuthenticationFilter]
        J --> K[SecurityContextHolder]
        K --> L[授权判断]
        L --> M[Controller / Service]
    end

    M --> N[返回业务响应]

flowchart TB
    A[HTTP Request] --> B[Servlet FilterChain]
    B --> C[DelegatingFilterProxy]
    C --> D[FilterChainProxy]
    D --> E{命中 SecurityFilterChain?}
    E -->|否| X[直接放行到 MVC]
    E -->|是| F[RateLimitingFilter]
    F --> G[JwtAuthenticationFilter]
    G --> H[UsernamePasswordAuthenticationFilter
作为插入点参照]
    H --> I[其他 Security Filters]
    I --> J[DispatcherServlet]
    J --> K[HandlerInterceptor]
    K --> L[Controller]

    style F fill:#fef3c7,stroke:#d97706
    style G fill:#e0f2fe,stroke:#0284c7
    style H fill:#f0fdf4,stroke:#16a34a

HTTP Request
  ↓
Servlet 容器 FilterChain
  ↓
DelegatingFilterProxy（委派过滤器代理：把“容器 Filter”桥接到“Spring Bean Filter”）
  ↓
FilterChainProxy（过滤器链代理：Spring Security 的总入口，负责选择要执行的安全链）
  ↓
SecurityFilterChain（安全过滤器链：一组 Filters + 匹配条件）
  ↓
[按固定顺序执行若干 Security Filters]
  ↓
DispatcherServlet（Spring MVC 的核心分发器） → Controller

RateLimitingFilter
  ↓  （Redis 计数器：超过阈值直接返回 429）
JwtAuthenticationFilter
  ↓  （解析 Authorization: Bearer ... ，验签/验类型/验会话，失败返回 401）
UsernamePasswordAuthenticationFilter
  ↓  （典型表单登录过滤器；本项目主要走 JWT，因此它更多是“插入点参照物”）
... 后续授权过滤器 ...
  ↓
Controller

13D 授权模型（RBAC / ABAC）

最准确的结论是：认证解决“你是谁”，授权模型解决“你能访问哪一层、哪一个对象”

登录成功只代表系统知道当前请求是谁，不代表这个人就能访问任何资源。授权模型真正回答的是：这个用户在当前场景里，凭什么访问这个接口、这个按钮、这条记录、这份知识、这个工具。

• RBAC（基于角色的访问控制）：先给角色授权限，再把角色分给用户。它适合后台管理、固定岗位、菜单型系统，规则清晰、维护成本低。
• ABAC（基于属性的访问控制）：不只看角色，还看用户属性、资源属性、环境属性和动作属性，例如“只有本租户老师能看自己班级今天生成的报告”。
• 一句人话：RBAC 更像‘你是什么岗位’，ABAC 更像‘你在什么条件下能做这件事’。

为什么只靠角色经常不够？

• 角色只能回答粗粒度权限：例如“你是不是管理员”“你能不能进这个模块”。
• 资源级问题必须看对象归属：订单是不是你的、导出任务是不是你创建的、知识库是不是你有权限访问的，这些都不是单靠“admin / user”能稳住的。
• 真实系统通常是组合拳：先用 RBAC 做大门权限，再用 ABAC / 资源归属做细粒度判断。

工程里最容易犯的错误是什么？

• 把登录态误当授权：用户只要带了合法 Token 就直接查任意 id，这正是第 104 个“越权漏洞”最常见的成因。
• 只在前端藏按钮：按钮不显示、菜单不渲染，不等于后端接口真的被保护住了。
• ACL / 多租户只校验一半：很多系统只校验 tenantId（租户标识），却没校验部门、角色、资源共享范围和操作类型，结果还是会串数据。

13A Spring Security 认证内部链路（AuthenticationManager → Provider → UserDetailsService）

先用大白话理解

• 它不是 Controller 自己查库比密码：登录请求会先交给 AuthenticationManager（认证管理器），它像“总调度员”，决定由谁来完成认证。
• DaoAuthenticationProvider 做什么？它像“具体办事的人”——负责调用 UserDetailsService（用户详情服务） 查用户，再用 PasswordEncoder（密码编码器） 校验密码。
• UserDetailsService 做什么？只负责“把用户资料查出来”，不负责验密码。项目里还能根据输入自动判断是用户名、邮箱还是手机号。
• 认证通过后发生什么？Spring 会生成一个 Authentication（认证结果对象） 对象放进 SecurityContextHolder（安全上下文持有器），后面的接口就知道“这个请求是谁”。

面试怎么讲更清楚

• 职责拆分：AuthenticationManager 负责调度，AuthenticationProvider（认证提供者） 负责具体认证，UserDetailsService 负责查用户，PasswordEncoder 负责验密码 —— 各司其职，扩展性强。
• 项目价值：今天支持“用户名/邮箱/手机号 + 密码”，以后若加短信登录、OAuth2（开放授权 2.0）、企业 SSO（Single Sign-On，单点登录），本质上也是新增一种 Provider，而不是推倒重写整套登录逻辑。
• 高频追问：401 表示“还没登录”，403 表示“登录了但没权限”；这两个码经常被混淆。

sequenceDiagram
    actor Client as 客户端
    participant Controller as AuthController
    participant Manager as AuthenticationManager
    participant Provider as DaoAuthenticationProvider
    participant UserSvc as UserDetailsService
    participant DB as 用户库
    participant Encoder as PasswordEncoder
    participant Context as SecurityContextHolder

    Client->>Controller: 提交用户名/邮箱/手机号 + 密码
    Controller->>Manager: authenticate(token)
    Manager->>Provider: 选择并委派认证
    Provider->>UserSvc: loadUserByUsername(...)
    UserSvc->>DB: 查询用户
    DB-->>UserSvc: UserDetails
    UserSvc-->>Provider: 返回用户详情
    Provider->>Encoder: matches(raw, encoded)
    alt 密码不匹配
        Encoder-->>Provider: false
        Provider-->>Controller: AuthenticationException
        Controller-->>Client: 401 未认证
    else 密码匹配
        Encoder-->>Provider: true
        Provider-->>Manager: 已认证 Authentication
        Manager-->>Controller: Authentication
        Controller->>Context: 写入认证结果
        Controller-->>Client: 登录成功 / 签发 Token
    end

13B JWT 会话治理进阶（不只是“双 Token”）

先用通俗话理解

• 基础双 Token 像“两把钥匙”：一把短期进门（AccessToken），一把长期续期（RefreshToken）。
• 会话治理更像“门禁系统”：不仅知道你有没有钥匙，还知道你是哪个设备、从哪登录、现在在线几个端、要不要远程踢下线。
• 为什么要做这层？因为真正的线上系统，不只关心“能不能登录”，还关心“能不能控会话、撤会话、防盗用、防重放”。

项目里的关键实现点

• 会话元数据：把 deviceType、ipAddress、userAgent、createdAt、lastActiveTime 等信息放进 Redis Hash（Redis 哈希结构），后台可查看活跃会话。
• 同设备去重：同一设备重复登录时，优先把旧会话撤掉，避免“一个手机登录出 3 个会话”。
• 并发会话控制：超过最大会话数时，不是简单报错，而是踢掉最旧会话，保证新登录能成功。
• 防重放：RefreshToken 不是“能反复刷”的永久钥匙。项目用 Redis 的原子“先检查、再标记”方式保证它一次性使用，防止同一个 Token 被并发重复刷新。
• 即时失效：项目把 sessionId 放进 AccessToken，并在请求进入 JwtAuthenticationFilter 后（验签通过后）去 Redis 校验会话是否仍活跃；这样被踢下线后，旧 AccessToken 也能尽快失效，不必傻等过期。（兼容性：若旧 Token 不带 sessionId，可按策略选择放行/提示升级）
• 可用性权衡：当 Redis 故障时，认证链路可能选择 fail-open 或 fail-close —— 前者更偏可用性，后者更偏安全性，这是架构取舍题。

flowchart TD
    登录成功[登录成功] --> 签发[签发 AccessToken + RefreshToken + sessionId]
    签发 --> Redis会话[Redis 写入会话元数据]
    Redis会话 --> 正常请求[后续请求携带 AccessToken]
    正常请求 --> 验签[JWT 验签]
    验签 --> 校验会话{Redis 中会话仍活跃?}
    校验会话 -->|是| 放行[建立身份并放行]
    校验会话 -->|否| 拒绝[拒绝请求 / 要求重新登录]

    Redis会话 --> 同设备去重{同设备重复登录?}
    同设备去重 -->|是| 撤旧会话[撤销旧 session]
    同设备去重 -->|否| 并发控制
    撤旧会话 --> 并发控制{超过最大并发会话数?}
    并发控制 -->|是| 踢最旧[踢掉最旧会话]
    并发控制 -->|否| 正常请求
    踢最旧 --> 正常请求

    正常请求 --> 刷新流程{AccessToken 过期?}
    刷新流程 -->|否| 放行
    刷新流程 -->|是| 校验刷新[RefreshToken 一次性校验]
    校验刷新 -->|通过| 轮换[轮换新的 Access/Refresh]
    校验刷新 -->|失败| 拒绝
    轮换 --> Redis会话

    管理员操作[管理员踢下线 / 手工撤销] --> 会话失效[标记 session 失效]
    会话失效 --> 校验会话

13C 安全审计日志与敏感信息脱敏

用一句话理解

• 普通业务日志是为了“排 Bug”，安全审计日志是为了“出事后能还原现场、定位责任、做合规追踪”。两者不是一回事。

面试要点

• 该记什么？登录成功/失败、验证码校验成功/失败、密码修改、Token 刷新、会话撤销、管理员敏感操作、限流命中、非法 Token 拦截等。
• 为什么要单独分流？安全日志的重要性和保留策略通常不同于业务日志，单独输出更便于审计、检索和告警。
• 为什么必须脱敏？日志本身也可能变成泄露源。项目里对用户名/邮箱/手机号做掩码，就是为了“能排查，又不把隐私原文写进去”。
• 绝对不要记什么？明文密码、完整 Token、完整验证码、完整身份证号/手机号/邮箱等敏感信息。
• 一个简单判断标准：如果日志被外包同事、运维或日志平台看到，会不会直接泄密？如果答案是“会”，那就说明日志写法有问题。

14 BCrypt 密码加密

面试必答要点

• 为什么不用 MD5（消息摘要算法 5）/SHA（安全哈希算法）？容易被彩虹表破解、无盐值、计算太快易被暴力破解。
• BCrypt 特点：自带随机盐值、计算慢（可调代价因子）、每次加密结果不同但都能正确验证。
• 格式：$2a$10$xxxxx —— 算法版本 / 代价因子（2的10次方轮） / 盐+哈希结果。

15 CORS（跨域资源共享）

面试必答要点

• 同源策略：浏览器安全机制，协议+域名+端口完全一致才算同源。
• 简单请求 vs 预检请求：GET/POST（满足条件时）为简单请求；PUT/DELETE 或带自定义 Header 的请求会先发 OPTIONS（预检请求方法） 预检。
• 关键：当 allow-credentials（允许携带凭据）: true 时，Access-Control-Allow-Origin（允许来源响应头） 不能用通配符 *，必须指定具体域名。

16 限流（Rate Limiting）

面试必答要点

• 常见算法：固定窗口计数器（项目的 Redis 实现）、滑动窗口、漏桶、令牌桶（Guava RateLimiter）。
• 为什么两种策略？全局 API 用 Redis 计数器（支持分布式部署）；AI 单机调用用令牌桶（平滑限流，不突发）。
• Fail-open vs Fail-close：项目在 Redis 异常时选择放行（fail-open），优先保证可用性。
• HTTP 429 Too Many Requests —— 限流时返回的标准状态码。

17 文件上传安全校验

面试要点

• 大小限制：服务端强制限制单文件/总请求大小，防止大文件拖垮内存与磁盘。
• 类型校验：扩展名白名单 + MIME（媒体类型） 校验 + 魔数（文件头）校验，避免伪装文件绕过。
• 存储策略：随机文件名、禁止原始文件名拼接路径、防路径穿越；存储目录与静态资源隔离。
• 风控加固：限流、鉴权、病毒扫描/内容审计按需求接入。

18 登录失败锁定（暴力破解防护）

面试必答要点

• 实现原理：每次失败执行 Redis INCR（自增命令） + 设置 TTL（生存时间）（如 15 分钟），计数达到阈值（如 5 次）则 isBlocked() 返回 true，拒绝后续登录请求。
• Key 设计：IP + 用户名/邮箱 组合 —— 既防单 IP 批量枚举不同账号，也防同一账号被来自不同 IP 的分布式爆破。
• vs 限流（Rate Limiting）的区别：限流面向 API 请求频率（保护服务稳定性）；登录锁定面向账号安全（防止凭据被暴力枚举），两者互补使用。
• 状态流转：loginFailed() 计数 → 超阈值 isBlocked() 返回 true → 登录成功时 loginSucceeded() 清除记录恢复正常。
• 信息安全细节：锁定响应只提示"剩余尝试次数"或"账号已临时锁定"，不暴露具体计数实现，防攻击者精确绕过机制。

19 邮箱验证码 / 双因素认证（2FA）

面试必答要点

• 验证码生命周期：生成随机码 → 存入 Redis（设置 TTL，如 5 分钟）→ 发送邮件 → 用户提交 → 比对 + 一次性消费（验证成功即删除 Redis key，防重放攻击）。
• 2FA 登录流程：密码验证通过 → 发送邮件验证码（临时 Token 标记待验证状态）→ 前端提交验证码 → 核验通过后才签发完整 JWT。安全级别远高于单因素认证。
• 防刷策略：canSendVerification() 结合 Redis 频率限制（如同一用户 60 秒内只能发 1 次）；与限流组合使用，防验证码接口被批量请求轰炸。
• Spring 邮件发送：JavaMailSender（Java 邮件发送器） + SMTP（Simple Mail Transfer Protocol，简单邮件传输协议） 配置；MimeMessage（多媒体邮件对象） 发送 HTML 格式邮件，SimpleMailMessage（简单文本邮件对象） 发送纯文本邮件。
• 安全细节：验证码错误时统一返回"验证码错误或已失效"，不区分"验证码不存在"还是"已过期"，防止信息枚举攻击。

20 ORM / JPA / Hibernate

面试必答要点

• JPA vs Hibernate：JPA 是规范（接口），Hibernate 是实现（类）。
• GenerationType.IDENTITY：主键由数据库自增生成。
• ddl-auto（自动维护表结构策略） 模式：update（自动更新表结构）、create（每次重建）、validate（仅验证）、none（关闭）。
• @PreUpdate：JPA 生命周期回调，项目用它自动更新 updateTime。
• N+1（1 次主查询再触发 N 次关联查询） 问题：查 1 条主记录触发 N 次关联查询 → 用 @EntityGraph（实体图抓取策略） / JOIN FETCH（关联预抓取查询） / 批量加载解决。

21 Spring Data JPA Repository

面试必答要点

• 接口无实现类却能工作？Spring Data 运行时通过 JDK 动态代理（运行时生成接口代理对象） 根据方法名自动生成 SQL。
• 方法命名规则：findBy + 属性名 + 条件关键字（And、Or、OrderBy、Between）。
• JPQL（Java Persistence Query Language，面向实体的查询语言） vs 原生 SQL：JPQL 面向实体对象（可移植），原生 SQL 面向表（性能优化用）。
• 分页：Pageable（分页参数对象） 参数 + Page<T> 返回值，自动处理 LIMIT/OFFSET（偏移分页语法）。

flowchart TD
请求[业务请求进入 Service] --> 仓库[Repository 接口]
仓库 --> 代理[Spring Data 代理实现]
代理 --> JPA[JPA 规范]
JPA --> Hibernate[Hibernate 实现]
Hibernate --> 实体[Entity 映射]
Hibernate --> 连接池[HikariCP 连接池]
连接池 --> 数据库[(MySQL / 数据库)]
数据库 --> 查询结果[结果返回并组装对象]
查询结果 --> 请求

21A 深分页（Deep Pagination）与 Cursor / Seek Pagination

面试必答要点

• 问题本质：LIMIT 100000, 10 不是真的“直接定位到第 100001 条”，而是数据库往往需要扫描并丢弃前面大量记录，导致 CPU、IO 和排序成本都上升。
• Seek Pagination（基于定位键继续翻页） / Cursor Pagination（基于游标继续翻页）：不要说“我要第 N 页”，而是说“我要上一条记录之后的数据”。典型写法是按稳定排序键（如 id、create_time + id）查询：WHERE id > lastId ORDER BY id LIMIT 10。
• 为什么更快？因为数据库可以沿着索引继续往后扫，而不是从头数到 10 万再丢弃，复杂度和稳定性都更适合大数据量滚动翻页。
• 排序键要求：排序必须稳定且最好唯一；如果只按 create_time 排序，时间相同的记录会跳页或重复，常见做法是用 create_time, id 联合排序。
• 延迟关联（Deferred Join（先查主键再回表关联））：如果列表页字段很多、关联很多，可以先只查主键列表，再按主键批量回表或关联查询详情，避免“深分页 + 大宽表”一起拖垮 SQL。

22 HikariCP 连接池

面试必答要点

• 为什么需要？TCP（传输控制协议） 连接建立开销大（三次握手+认证），复用连接避免反复创建销毁。
• 核心参数：maximum-pool-size（最大连接数）、minimum-idle（最小空闲）、connection-timeout（获取超时）。
• 连接泄漏检测：leak-detection-threshold=60000 → 连接借出超 60 秒未归还则告警。

23 乐观锁（Optimistic Locking）

面试必答要点

在软件开发中，当多个用户或线程同时操作同一份数据时，会遇到并发控制（Concurrency Control：多人同时改同一份数据时，系统保证不乱套的一套方法）问题。 如果没有控制，可能出现竞态条件（Race Condition：执行顺序不确定，导致最终结果随机出错），典型现象是丢失更新：两个人都基于旧数据改，后提交的人把先提交的覆盖掉。

1）先对比：悲观锁（Pessimistic Locking）

• 核心思路：认为冲突是大概率事件，所以在读/改之前先把记录“锁住”。
• 工作原理：线程 A 修改某条数据时，在 SQL 层申请排他锁，例如 SELECT ... FOR UPDATE；A 未提交前，线程 B 访问同一行会被阻塞（Block：线程暂停等待资源）。
• 优缺点：一致性强、冲突时直接排队；但会增加等待/锁开销，且可能引入死锁（Deadlock：互相等对方释放资源，大家一起卡住）。
• 适用场景：写多、冲突成本极高（如核心记账链路）。

2）乐观锁（Optimistic Locking）怎么工作？（结合项目）

乐观锁的核心思路是：认为冲突发生概率较低，不提前加真正的数据库锁，而是在提交更新的最后一刻做“版本校验”。 常见做法是在表里加一个版本号（version / @Version）字段。

1. 读取数据：线程 A 读取记录，同时读到当前版本号（例如 version = 1）。
2. 准备更新：线程 A 在内存里修改字段，准备写回数据库。
3. 校验并提交：更新时把“旧版本号”带到 WHERE 条件里（典型 SQL 如下）。
4. 冲突处理：如果期间有线程 B 先提交，把 version 改成了 2，那么 A 的更新将影响 0 行 → ORM（对象关系映射：把对象操作翻译成 SQL 的框架）抛出 OptimisticLockException（或类似异常）。

UPDATE spaced_repetition_card
SET state = ?, due = ?, /* ... */
    version = version + 1
WHERE id = ? AND version = ?;  -- 这里的 version=? 是“我读到的旧版本”

3）优缺点与适用场景

• 优点：不会把并发请求都堵在锁上，吞吐和响应更好；通常也不会产生死锁。
• 缺点：在高冲突场景会产生大量更新失败与重试，反而浪费 CPU/数据库资源；并且需要业务层决定“失败后怎么办”。
• 适用场景：读多写少、冲突概率低，但又不能接受丢失更新（例如编辑资料、更新用户配置、间隔重复卡片状态更新等）。

// JPA 实体常见写法（示例）
@Entity
public class SpacedRepetitionCard {
    @Version
    private Long version;
}

-- 计数累加类：避免 read-modify-write
UPDATE t SET cnt = cnt + 1 WHERE id = ?;

24 MySQL 索引设计与优化

面试必答要点

• B+ Tree（B+ 树索引结构） 结构：InnoDB（MySQL 默认事务型存储引擎） 默认索引，叶子节点有序链表，支持范围查询。
• 聚簇索引 vs 二级索引：主键索引叶子存完整行数据；二级索引叶子存主键值（需回表）。
• 覆盖索引：查询列全在索引中，无需回表 → EXPLAIN（执行计划分析命令） 中 Using index（命中覆盖索引）。
• 最左前缀原则：联合索引 (user_id, state, due) → 能命中 WHERE user_id=?、WHERE user_id=? AND state=?，但不能只用 WHERE state=?。
• 项目实例：SpacedRepetitionCard 的 idx_user_state_due 就是按照最左前缀设计的，先按用户过滤（区分度高），再按状态分类，最后按到期时间排序。

flowchart LR
    subgraph BTree["B+ Tree 索引结构"]
        direction TB
        Root[Root]
        N1[Internal Node]
        N2[Internal Node]
        L1[Leaf 1]
        L2[Leaf 2]
        L3[Leaf 3]
        Root --> N1
        Root --> N2
        N1 --> L1
        N1 --> L2
        N2 --> L3
        L1 --- L2
        L2 --- L3
    end

    subgraph Clustered["聚簇索引 vs 二级索引"]
        direction TB
        PK[聚簇索引叶子：完整行数据]
        SK[二级索引叶子：主键值]
        SK --> 回表[按主键回表到聚簇索引]
        回表 --> PK
    end

    subgraph Prefix["联合索引 idx_user_state_due(user_id, state, due)"]
        direction TB
        IDX[user_id → state → due]
        Q1[WHERE user_id = ?] --> 命中1[命中]
        Q2[WHERE user_id = ? AND state = ?] --> 命中2[命中]
        Q3[WHERE user_id = ? AND state = ? AND due > ?] --> 命中3[命中]
        Q4[WHERE state = ?] --> 失效[不能只跳过最左列]
        IDX --> Q1
        IDX --> Q2
        IDX --> Q3
        IDX --> Q4
    end

25 软删除 (Logical Delete)

面试要点

• vs 物理删除：误操作可恢复、保留审计轨迹、关联数据不断裂。
• 查询影响：所有查询必须加 WHERE deleted = 0，容易遗漏 → 解决方案：@Where（默认追加查询过滤条件的注解）(clause="deleted=0") 或全局过滤器。
• 清理策略：项目定时任务定期物理删除超期软删除数据，防止表膨胀。

26 JPA AttributeConverter（自定义类型映射）

面试必答要点

• 使用场景：Java 属性类型与数据库列类型不一致且 JPA 默认无法处理时（如数组→JSON字符串、枚举→自定义编码、复杂对象→字符串），实现 AttributeConverter（自定义字段类型转换器）<JavaType, DbType>。
• 两个方法：convertToDatabaseColumn()（Java → DB 写入方向）和 convertToEntityAttribute()（DB → Java 读取方向），加 @Converter 注解注册到 JPA。
• autoApply=true vs 字段指定：@Converter(autoApply=true) 全局自动应用到所有匹配 Java 类型；@Convert(converter=X.class) 在字段上精确指定，避免误用。
• vs @Enumerated(EnumType.STRING)：标准枚举推荐用 @Enumerated(STRING)（简洁）；非标准映射（数组、复杂格式、第三方类型）用 Converter 更灵活。
• 注意：Converter 内的 ObjectMapper（JSON 对象转换器） 应为静态常量复用（线程安全）；转换异常需记录日志并决定返回 null 还是抛出异常（影响整行能否读取）。

27 JPA Auditing（@CreatedDate / @LastModifiedDate 自动审计）

面试要点

• 配置三步：① @EnableJpaAuditing 开启 → ② 实体类加 @EntityListeners(AuditingEntityListener.class)（其中 AuditingEntityListener（审计实体监听器）） → ③ 字段加 @CreatedDate/@LastModifiedDate。
• vs @PrePersist/@PreUpdate：生命周期回调需手动编写赋值逻辑，重复代码多易遗漏；Auditing 注解更声明式，统一管理，项目两种方式均有使用。
• 记录操作人（AuditorAware（审计人提供接口））：实现 AuditorAware<String> 接口，从 SecurityContextHolder（安全上下文持有器） 读取当前登录用户，配合 @CreatedBy/@LastModifiedBy 自动填充操作人字段（项目已预留接口未实装）。
• 字段类型：支持 LocalDateTime、ZonedDateTime 等 Java 8 时间类型，无需手动格式转换。

28 @Modifying 与一级缓存

面试要点

• 为什么需要？JPA 默认 @Query 只支持 SELECT；UPDATE/DELETE 必须加 @Modifying。
• clearAutomatically=true：执行完自动清空持久化上下文，防止一级缓存中的脏数据（旧数据）被后续查询读到。
• 必须配合 @Transactional（事务边界注解） 使用。

29 关联映射与懒加载 (N+1)

面试要点

• 全项目 LAZY：避免加载 User 时连带查出所有关联实体。
• N+1 触发场景：循环中访问懒加载属性 → 每次触发一个 SELECT。
• 解决：@EntityGraph（实体图抓取策略） / JOIN FETCH（关联预抓取查询） / @BatchSize（批量抓取大小配置）。

30 联合唯一约束 (Unique Constraint)

面试要点

• 防并发重入的最后一道防线：即使前端做了防抖拦截、后端 Service 做了先查再插（SELECT THEN INSERT（先查后插） INSERT），在分布式严苛的高并发下依然存在极短的竞态窗口。在数据库表上建立强约束，才是彻底堵死脏数据的兜底方案。
• 异常如何兜底转化：违反唯一约束时，Hibernate 会抛出 DataIntegrityViolationException（数据完整性冲突异常）。项目中的 GlobalExceptionHandler 会精确捕获该特定异常，并向前端返回友好的 400 业务提示（如："您已收藏过此题目"），避免前端暴雷 500 错误。
• 对性能的正面影响：建立联合唯一约束实际上也会在数据库底部隐式生成一个联合索引（Composite Index（Composite Index，联合索引）。不仅防重，在查询“某个用户有没有收藏某道题”时还会顺理成章走联合索引覆盖，加速查询。

31 数据库视图 (Database View) 与查询抽象

面试必答要点

• 极其优雅的架构化繁为简：排行榜通常包含及其繁琐的多表 JOIN、按时间的聚合 SUM 和复杂的 MySQL 8.0 窗口函数（如 ROW_NUMBER()（窗口函数里的行号函数））。如果写在 JPA 的 @Query 中不仅丑陋难懂且难以维护。在数据库中封装一层视图（View），不仅让这些超长计算黑盒化，Java 层更是可以直接当做查询单表一样极其清爽地直接调用。
• 业务只读属性边界（Read-Only（只读））：普通视图不保存实际数据（纯 SQL 语句映射），并且包含 GROUP BY/聚合 的复杂视图在底层数据库是不允许执行 UPDATE/INSERT 操作的。因此这非常契合这种仅供前端展示的统计看板业务。
• 与数据演进扩展相结合：如果后期数据量达到百万级单查视图非常慢怎么办？可以顺滑地把普通的 View 升级改为物化视图（或者定时跑批用独立的统计物理表代替），而这一改造过程对上层使用原生单表查询格式的 Java 代码毫无破坏！

32 数据库迁移脚本 (版本化 Schema 管理)

面试要点

• 什么是自动化版本化管理：在系统第一次启动时自动检测 schema_history 版本表，找出本地没执行过的新版本脚本，对库结构按照严格的顺向顺序去执行（例如，开发到测试环境，代码一打版启动它就自动建表，再不需要 DBA（数据库管理员） 去手工执行）。
• “只增不改”的铁律约束：如果 V1.1 表明已经在任何环境执行过，绝对不准再次去修改那份旧脚本去试图修 Bug。因为这会让版本工具发现历史文件的校验和（Checksum（校验摘要））对不上，直接启动报错。
• 修错怎么办：如果在 1.1 里面发现了字段拼写错误，只能老老实实地再创建一个 V1.3__fix_column.sql 写入 ALTER TABLE 打布丁。这叫做：架构的基建是“向前推演”的。项目深谙这种正规军级别的协同规范。

33 缓存穿透 / 击穿 / 雪崩

1. 缓存穿透 (Cache Penetration)

• 为什么会发生（根本原因）：业务查询了一个在数据库中压根不存在的数据。按照常规流程：先查缓存（没有）→ 再查数据库（也没有返回空）→ 因为没数据所以不会写入缓存。这导致恶意的并发请求（如故意查询 id=-1 的僵尸粉）每次都能顺利穿透缓存，把压力结结实实地全部砸在数据库上，容易被人利用发起 DDoS（Distributed Denial of Service，分布式拒绝服务攻击） 攻击。
• 解决方案：
  • 缓存空对象（项目级兜底）：即使数据库查不到，也将这个“空值”存入缓存（需设置一个较短的有效期如 5 分钟），这样接下来的恶意查询就能被缓存拦截。
  • 布隆过滤器（Bloom Filter（布隆过滤器））：在请求到达系统时，先用布隆过滤器判断请求的 Key 到底存不存在。不存在直接挡飞，存在才放行。

2. 缓存击穿 (Cache Breakdown)

• 为什么会发生（根本原因）：这往往是因为某一个极其热门的绝对中心词数据（比如微博热搜第一、秒杀商品）被设置了过期时间。在这个热点 Key 失效的“那短短一毫秒”，恰巧有成千上万的并发请求蜂拥而至；这些请求发现缓存没命中，就全都转头去找数据库“重建缓存”，瞬间的瞬时尖刺流量会把数据库的 CPU 和连接池瞬间打满甚至宕机。
• 解决方案：
  • 互斥锁（Mutex Lock（互斥锁））：也就是当缓存失效去查库重建时，必须先抢一把锁（例如基于 Redis 的 setnx（不存在才设置） 或本地锁）。只让抢到锁的绝对少数代表去查库并写入缓存，抢不到的稍微睡眠重试一下，那时候缓存早就被写好了。
  • 逻辑过期策略：把这种高危数据设为“无物理过期时间（永不淘汰）”，而在 JSON 格式的 Value 中加一个 expireTime 字段。查询时如发现超过逻辑过期时间，程序不阻塞立刻返回旧数据，然后丢弃给后台子线程去静默查库刷新。

3. 缓存雪崩 (Cache Avalanche)

• 为什么会发生（根本原因）：这不是极个别 Key 的问题，而是一场群体性灾难。出现于两类极端情况：第一类是代码在初始化写入数据时，为了偷懒把成千上万个 Key 全设置了相同的过期时间，导致在某一秒钟，大批量的缓存同时失效，海量平切的流量涌入底层；第二类则是 Redis 缓存节点物理宕机，这道屏障直接全盘碎裂。
• 解决方案：
  • 加噪打散：写入缓存设定 TTL 时，在这个时间基础上叠加一个随机值（例如：基础 10 分钟 + 随机的 0~5 分钟）。项目采用的是通过 CacheResolver 定义“分级 TTL”。
  • 熔断兜底与高可用：采用诸如 Cluster（Redis 集群模式）/Sentinel（Redis 哨兵模式） 的高可用架构部署 Redis，并在业务层（正如项目 CacheConfig.errorHandler() 做的）写好异常降级链路，发生集群雪崩时主动限流。

flowchart TB
    A[缓存异常类型] --> B[穿透]
    A --> C[击穿]
    A --> D[雪崩]

    B --> B1[查不存在的数据]
    B1 --> B2[缓存 miss]
    B2 --> B3[数据库也 miss]
    B3 --> B4[空值缓存 / 布隆过滤器]

    C --> C1[热点 key 过期]
    C1 --> C2[高并发同时回源]
    C2 --> C3[数据库瞬时被打满]
    C3 --> C4[互斥锁 / 逻辑过期]

    D --> D1[大量 key 同时过期 或 Redis 宕机]
    D1 --> D2[大面积回源]
    D2 --> D3[数据库与连接池承压]
    D3 --> D4[随机 TTL / 高可用 / 降级限流]

34 Spring Cache 声明式缓存

面试要点

• @Cacheable：命中直接返回；未命中执行方法并写入缓存，可用 key、condition、unless 控制缓存行为。
• @CachePut：总会执行方法，并将结果更新缓存，适合写后更新。
• @CacheEvict：删除缓存，支持 allEntries/beforeInvocation，适合写后删除与失败回滚策略。
• 异常降级：通过 CacheErrorHandler（缓存异常处理器） 兜底，缓存故障不影响主流程（读写异常降级为直连 DB）。

34A 缓存与数据库双写一致性（Cache-Aside / 延迟双删 / Binlog 驱动）

面试必答要点

• 先更新缓存还是先更新数据库？常见正确基线是 先写数据库，再删缓存。因为缓存是副本，数据库才是真相；直接“先改缓存再改库”更容易在失败时留下脏缓存。
• 为什么通常不推荐“写库后立刻更新缓存”？因为更新缓存也可能失败，而且如果缓存淘汰策略或并发读写叠加，仍可能被旧值覆盖。删除缓存通常更简单、更稳。
• 延迟双删：在“写库 → 删缓存”后，再延迟一小段时间补删一次，目的是处理并发窗口中“某个读请求恰好读到旧库值并把旧值重新写回缓存”的情况。
• Binlog（数据库变更日志） / CDC（Change Data Capture，变更数据捕获） 驱动：更工程化的方案是订阅数据库变更（如 Canal（订阅 MySQL Binlog 的 CDC 工具） / Debezium（通用 CDC 工具）），由变更事件统一驱动缓存失效或刷新，把“改库”和“删缓存”从业务代码里解耦出来。
• Canal 该怎么理解更准确？它本质是订阅 MySQL Binlog 的 CDC 工具：数据库一旦发生变更，就把事件统一投给缓存失效、索引同步或下游消费者。它适合做高并发场景下的最终一致性链路，而不是把缓存和数据库强行做成强一致。
• 真正的结论：双写一致性很难做到绝对强一致，目标通常是把不一致窗口缩到足够小，并通过 TTL（生存时间）、重试、幂等、补偿和监控把风险控制在可接受范围内。

sequenceDiagram
    actor Client as 写请求
    participant App as 应用服务
    participant DB as 数据库
    participant Cache as Redis缓存
    participant Reader as 并发读请求
    participant CDC as Binlog/CDC

    Client->>App: 提交写操作
    App->>DB: 先更新数据库
    DB-->>App: 更新成功
    App->>Cache: 删除对应缓存
    Cache-->>App: 删除完成

    par 并发窗口
        Reader->>Cache: 读取缓存
        Cache-->>Reader: miss
        Reader->>DB: 读数据库旧值/临界值
        Reader->>Cache: 可能把旧值回填缓存
    and 写侧补强
        App->>App: 延迟一小段时间
        App->>Cache: 第二次删除缓存
    end

    opt 更高一致性要求
        DB-->>CDC: 发送变更事件
        CDC->>Cache: 统一驱动失效/刷新
    end

35 @Transactional 事务管理

面试必答要点

• 传播行为：REQUIRED（有事务就加入，没有就新建）、REQUIRES_NEW（总是新建事务）、NESTED（嵌套事务）。
• 回滚规则：默认只对 RuntimeException/Error 回滚；受检异常默认不回滚，必要时用 rollbackFor/noRollbackFor 显式声明。
• 事务失效四大场景：① 方法非 public ② 同类内部调用（代理失效）③ 异常被 catch 吞掉 ④ 用了 @Async（不同线程不共享事务）。
• readOnly = true（只读事务提示）：给 ORM/数据库只读提示（常见效果是减少不必要的 flush/脏检查）；是否提升性能与数据库/驱动实现相关。
• 隔离级别：读未提交 → 读已提交 → 可重复读（MySQL InnoDB 默认）→ 串行化。

35A 事务之外的一致性：数据库 + 文件 + 补偿清理

先讲人话

• @Transactional 只能管数据库：它能回滚表里的数据，但不会自动帮你删除磁盘文件，也不会帮你回滚第三方接口调用。
• 典型事故：图片已经上传成功了，数据库却在后面报错回滚。结果就是“库里没记录，磁盘上留下了一堆孤儿文件”。

项目里是怎么兜住的

• 第一步：先记账。每成功上传一张图片，就把它记到追踪器里，知道“这次流程已经产生了哪些外部副作用”。
• 第二步：主流程失败就补偿。一旦解析或入库失败，程序会回头把这批已经上传、但还没真正落库成功的图片删掉。
• 第三步：finally（无论是否异常都会执行的收尾块） 一定清理。ThreadLocal 用完必须 remove()，否则线程池复用线程时，旧上下文可能串到下一次请求，甚至造成内存泄漏。
• 这属于什么思想？这不是分布式事务，而是更常见、更实用的补偿式一致性：数据库负责回滚，文件系统靠代码补偿。

35B 数据库死锁排查与解决

面试必答要点

• 死锁本质：事务 A 等 B 持有的锁，事务 B 又等 A 持有的锁，形成循环等待。数据库通常会主动选一个“牺牲者”回滚，另一个事务继续执行。
• 业务侧常见诱因：不同事务以不同顺序更新多条记录、范围更新没有命中索引导致锁范围扩大、长事务里夹杂远程调用/复杂计算、批量更新一次锁住太多行。
• 排查方法：先看应用侧超时/回滚日志，再结合数据库死锁日志（如 MySQL 常见的 SHOW ENGINE INNODB STATUS（查看 InnoDB 状态的命令） 或 performance_schema（性能与等待信息视图库） 相关视图）还原“谁在等谁”。
• 规避思路：统一更新顺序（例如始终按主键升序更新）、缩短事务时间、让查询命中索引、减少范围锁、把非数据库操作移出事务、把大批量任务拆小批处理。
• 失败后的正确姿势：死锁不是系统崩了，而是并发冲突的一种正常表现。对可重试事务，通常要做有限次数重试 + 退避，而不是看到异常就当 500 永久失败。

35C MVCC、Read View 与幻读防护（Gap Lock / Next-Key Lock）

先把几个第一次出现的词讲成人话

• MVCC（多版本并发控制：让读请求尽量不堵写请求，方法是给一行数据保留多个历史版本）：它不是“大家一起随便改”，而是让读操作优先去看自己能看到的那个版本，这样普通查询不必总和写操作抢锁。
• Undo Log（回滚日志：既能回滚事务，也能把旧版本串起来）：一行数据被更新前，旧值会先记到 Undo Log 里。后续如果事务回滚，要靠它恢复；如果其他事务做快照读，也会顺着它去找更早的版本。
• 版本链（Version Chain：一行记录历次修改形成的旧版本链表）：可以把它想成“这行数据的历史时间线”。最新版本在表里，旧版本沿着 Undo Log 往前串起来。
• Read View（一致性视图：事务在做快照读时，用来判断哪些事务提交了、哪些还没提交的可见性规则）：它不是数据副本，而更像一张“可见性名单”。数据库会拿这张名单去判断当前行版本能不能给你看。
• 快照读（Snapshot Read：普通 SELECT 读取某一时刻可见版本）：重点是“读历史上对我可见的版本”，通常不主动加锁。
• 当前读（Current Read：要读最新版本并准备加锁/修改的读取）：如 SELECT ... FOR UPDATE、SELECT ... FOR SHARE、UPDATE、DELETE。这类操作关心的是“现在最新的真实状态”，并且往往要加锁。
• 幻读：同一事务里按“某个范围条件”读了两次，第二次突然多出几行原来没有的记录，就像“凭空冒出来的幻影”。它强调的是范围结果集发生变化，不是某一行值变了。
• Gap Lock（间隙锁：锁住索引记录之间的空档，不让别人往这个空档插入新记录）：它锁的不是现有行，而是“行与行之间的位置”。
• Next-Key Lock（临键锁：记录锁 + 前间隙锁的组合，既管住已有索引记录，也管住它前面的插入空档）：单个临键锁锁的是“当前记录 + 前间隙”，而范围扫描时会形成连续区间保护，这是 InnoDB 在可重复读下做范围当前读时最常见的防幻读手段。

面试必答要点

• 先把一句话讲对：快照读主要靠 MVCC 保证一致性视图；到了 当前读 / 锁定读（如 SELECT ... FOR UPDATE、UPDATE、DELETE），尤其是范围型条件或索引范围扫描时，InnoDB 在可重复读下还会结合 Gap Lock / Next-Key Lock 防止区间内插入，从而避免幻读。
• MVCC 的底层骨架：InnoDB 通过 Undo Log + 版本链 + Read View 实现多版本并发控制。一个事务做快照读时，不一定读“最新值”，而是读对当前事务可见的那一版历史快照。
• Read View 到底看什么？它会关心“创建这个视图时，哪些事务已经提交、哪些事务还活着”。行记录里也带有隐藏事务版本信息（可以理解为“这行最后一次被谁改过”），数据库就用“行版本信息 + Read View”一起判断可见性。
• 可见性的大白话规则：如果某版本对应的事务在 Read View 创建前就已经提交，通常可见；如果是之后才开启/才提交，通常不可见；如果就是当前事务自己改出来的版本，对自己当然可见。遇到不可见版本，就继续顺着 Undo Log 往前找。
• 为什么说 MVCC 不是单独解决幻读？因为 MVCC 更擅长解决快照读的一致性问题；真正到了“要改数据、要锁范围”的场景，防幻读主要靠 Gap Lock / Next-Key Lock 把区间锁住，而不是单靠历史版本链。
• Gap Lock vs Next-Key Lock：Gap Lock 锁的是索引记录之间的“间隙”，防止新区间插入；Next-Key Lock = 记录锁 + 间隙锁，既锁已有记录，也锁它前面的 gap，是 InnoDB 在 RR（Repeatable Read，可重复读） 下的典型范围锁形态。
• 别把“幻读”和“不可重复读”混了：不可重复读更像“同一行被别人改了，前后两次值不一样”；幻读更像“本来满足条件的结果集突然多了/少了几行”。一个偏单行内容变化，一个偏范围结果集变化。
• 工程上的代价：锁范围扩大能减少幻读，但也更容易带来锁冲突、插入阻塞甚至死锁。因此索引命中、范围条件设计和事务时长控制都很关键。

flowchart LR
    Q[读取请求] --> S{属于哪种读?}

    S -->|快照读| MVCC[MVCC]
    MVCC --> RV[Read View]
    MVCC --> VC[版本链 / Undo Log]
    RV --> Visible[找到当前事务可见的历史版本]
    VC --> Visible

    S -->|当前读| CUR[读取最新版本]
    CUR --> LOCK[记录锁 / Gap Lock / Next-Key Lock]
    LOCK --> Protect[锁住记录或索引区间]
    Protect --> Phantom[防止范围插入 / 幻读]

    Visible --> Result1[返回历史快照]
    Phantom --> Result2[返回当前最新值并保持区间安全]

36 Redis 数据结构与应用场景

面试必答要点

• 五种基本数据结构：String（缓存/计数器）、Hash（对象存储）、List（消息队列）、Set（去重/交集）、ZSet（有序集合）（排行榜/延迟队列）。
• StringRedisTemplate vs RedisTemplate<String, Object>：前者只处理字符串；后者通过 Jackson（JSON 序列化工具库） 序列化支持复杂对象。
• 分级 TTL：首页统计 10 分钟（变化快）、用户成就 60 分钟（变化慢）、系统配置 24 小时（几乎不变）。
• 序列化安全：项目用 BasicPolymorphicTypeValidator（多态类型白名单校验器） 限制反序列化类型白名单，防攻击。

36A Redis 持久化机制：RDB vs AOF 与数据丢失容忍度

先把几个第一次出现的词讲成人话

• RDB（快照持久化：定时把某一时刻的整份内存数据拍成“存档照片”）：它保存的是“那个时刻的结果”，不是每一次写入过程。
• AOF（追加文件持久化：把写操作像流水账一样持续记下来）：Redis 重启后会按日志把数据重新“做一遍”，因此通常比单纯快照更耐丢数据。
• fsync（刷盘：把已经写到操作系统缓冲区的数据真正落到磁盘）：很多人以为“程序写文件了就等于落盘了”，其实中间还隔着操作系统缓存。
• appendfsync（AOF 刷盘策略：决定 AOF 多快真正落盘）：它主要影响 AOF 的落盘频率，因此会直接影响 Redis 异常退出时最近写入的大致丢失窗口。
• AOF rewrite（AOF 重写：把很长的旧日志压缩成一份能恢复当前状态的更短新日志）：它不是简单删日志，而是为了控制文件体积和恢复时间。
• BGREWRITEAOF（后台 AOF 重写：在尽量不阻塞主服务的前提下生成新 AOF 文件）：名字里有 BG，意思就是尽量放到后台做。
• 混合持久化（Hybrid Persistence：更严格地说，通常指 AOF 重写时在前半段使用 RDB 方式表达快照、后半段继续追加 AOF 增量）：它的目标是同时兼顾恢复速度和数据完整性。要注意，这和“同时启用 RDB 和 AOF”有关，但不是完全同一句话。
• 数据丢失容忍度：不是问“会不会丢”，而是问“最多能丢多久、丢了会出什么事”。这是 Redis 持久化选型的起点。

面试必答要点

• RDB：定时做快照（snapshot），优点是文件紧凑、恢复通常更快、非常适合备份；缺点是两次快照之间的数据可能整体丢失，适合“可以接受一段时间窗口丢失”的场景。
• AOF：把写命令追加记录，重启时通过回放恢复数据。优点是通常比单纯 RDB 更耐丢数据；缺点是文件更大、写放大更明显、恢复通常慢于纯 RDB。
• appendfsync 取舍：always 最安全但最慢；everysec 是常见折中，通常意味着宕机时最多丢最近约 1 秒数据；no 性能最好，但落盘时机更多交给操作系统，数据丢失窗口最不稳定。
• AOF rewrite 到底解决什么问题？AOF 一直追加会越写越大，恢复也会越来越慢，所以需要后台重写，把“历史过程”压缩成“恢复当前状态的较短内容”。
• RDB + AOF / 混合持久化怎么理解？生产里常见做法是同时启用 RDB 和 AOF：用 AOF 缩小数据丢失窗口，用 RDB 保留快照备份与较快恢复能力。更严格地说，Redis 所说的“混合持久化”通常还特指 AOF 重写时使用 RDB 前导段。另外，两者都启用时，如果 AOF 文件可用，Redis 重启默认会优先加载 AOF，因为它通常比单独的 RDB 快照包含更完整的最新写入。
• 持久化 ≠ 高可用：持久化解决的是“Redis 重启后数据还在不在”；主从复制、哨兵、集群解决的是“节点挂了服务还能不能继续”。这两类问题经常一起出现，但不是一回事。
• 先问业务容忍度：排行榜缓存丢 1 分钟通常问题不大；会话、限流、一次性验证码、锁状态、任务进度若丢失，就可能直接影响业务正确性和安全性。技术选型本质上是业务容忍度的映射。

36B Big Key / Hot Key：发现、打散与治理

面试要点

• Big Key：单个 Key 对应的 value 或集合元素过大，导致序列化/反序列化慢、网络传输慢、删除阻塞长，甚至造成主线程抖动。
• Hot Key：某个 Key 被极高频访问，即使它本身不大，也会把单点流量、单分片或单机 CPU 打满，形成热点瓶颈。
• 发现方式：常见手段包括 redis-cli --bigkeys、--hotkeys、监控单 Key QPS（每秒请求数） / 流量 / 延迟、用 MEMORY USAGE（查看 Key 内存占用的命令） 抽样分析、从应用日志中识别异常热点。
• 治理 Big Key：拆分结构（如一个超大 Hash 拆成多个分片 Key）、分页存储、只缓存热点窗口、异步删除（避免阻塞）、不要把超大 JSON 一把全塞进 Redis。
• 治理 Hot Key：本地缓存 + Redis 二级缓存、热点副本、Key 打散、只读降级、预热缓存、限流保护；本质是避免所有流量同时砸到同一个点。

37 分布式锁（Distributed Lock）

面试必答要点

• 为什么需要？多实例部署时 synchronized（Java 内置同步锁）/ReentrantLock（可重入显式锁） 只锁单个 JVM（Java 虚拟机进程）。
• 原理：SET key value NX EX timeout → NX（不存在才设置，原子操作）+ EX（过期防死锁）。
• Lua 脚本：解锁时"检查 value + 删除 key"必须原子，否则可能误删别人的锁。
• 锁续期（看门狗）：防止任务没完成锁就过期被别人抢走。

38 线程池（ThreadPoolExecutor）

概念定义

ThreadPoolExecutor（Java 原生线程池实现） 是 Java 并发包里最常用的线程池实现，本质上是用一组可复用的工作线程来执行提交的任务，而不是每来一个任务就直接新建一个线程。它通过核心线程数、最大线程数、阻塞队列、空闲存活时间和拒绝策略，统一控制任务是立即执行、排队等待还是在过载时拒绝，从而把线程创建开销、并发上限和资源使用都纳入可管理范围。

面试必答要点

• 七大参数：corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务阻塞队列）、threadFactory（线程创建工厂）、handler（拒绝策略处理器）、时间单位。
• 执行流程：提交 → 核心未满创建核心线程 → 核心满入队 → 队列满创建非核心 → 都满执行拒绝策略。
• 拒绝策略：AbortPolicy（直接拒绝并抛异常）、CallerRunsPolicy（由提交线程自己执行）、DiscardPolicy（直接丢弃任务）、DiscardOldestPolicy（丢弃最旧排队任务）。
• 线程池隔离（舱壁模式）：AI 长耗时调用独立线程池，防阻塞文件解析等任务。
• 大小公式：CPU 密集型 = N+1；IO 密集型 = 2N。
• 更稳的估算：线程数 ≈ Ncpu × (1 + 等待时间/计算时间)；配合队列容量、拒绝策略与压测结果一起定。

flowchart TD
提交任务[提交任务] --> 核心是否未满{核心线程未满?}
核心是否未满 -->|是| 创建核心[创建核心线程]
创建核心 --> 执行任务[立即执行任务]
核心是否未满 -->|否| 进入队列[任务进入阻塞队列]
进入队列 --> 队列是否已满{队列已满?}
队列是否已满 -->|否| 等待消费[等待空闲线程取走]
队列是否已满 -->|是| 最大线程是否未满{还能创建非核心线程?}
最大线程是否未满 -->|是| 创建非核心[创建非核心线程]
创建非核心 --> 执行任务
最大线程是否未满 -->|否| 拒绝策略[触发拒绝策略]

39 @Async 异步执行

面试必答要点

• 原理：Spring AOP（Aspect-Oriented Programming，面向切面编程） 代理 + 线程池。
• 致命坑：同类内部调用 @Async 方法不生效（不走代理）。
• 返回值：void / Future（异步结果占位对象）<T> / CompletableFuture（可编排的异步结果对象）<T>（推荐）。
• 异常处理：异常不会被调用方捕获（不同线程），需 AsyncUncaughtExceptionHandler（异步 void 方法异常处理器）。

40 Spring 事件驱动（ApplicationEvent / @TransactionalEventListener）

面试必答要点

• 核心角色：事件（POJO（Plain Old Java Object，普通 Java 对象） 或继承 ApplicationEvent（Spring 事件基类））、发布者（注入 ApplicationEventPublisher（事件发布器） 后调用 publishEvent()（发布事件方法））、监听者（@EventListener（事件监听注解） 方法）。
• @EventListener vs @TransactionalEventListener：@EventListener 在事件发布时立即触发（可能在事务内）；@TransactionalEventListener（事务阶段事件监听注解） 等到事务提交后才触发 —— 防止事务回滚后统计数据仍被错误更新（脏更新问题）。
• TransactionPhase（事务事件触发阶段） 阶段：AFTER_COMMIT（事务提交后）、BEFORE_COMMIT（事务提交前）、AFTER_ROLLBACK（事务回滚后）、AFTER_COMPLETION（事务结束后）。
• 配合 @Async：监听器加 @Async("statsUpdateExecutor") → 事件处理在独立线程池中执行，不阻塞主事务线程；异常只记录日志不上抛，定时任务定期兜底重算（双保险）。
• vs 消息队列（MQ（Message Queue，消息队列））对比：Spring 事件仅限单进程（零依赖、低延迟）；MQ 可跨服务（高可靠、可重试，但引入外部依赖+运维成本）。简单场景优先用事件总线，跨服务再引入 MQ。

sequenceDiagram
participant 主流程事务
participant 事件发布器
participant 事务后监听器
participant 统计线程
participant 定时兜底任务

主流程事务->>事件发布器: 发布答题完成事件
主流程事务->>主流程事务: 提交事务
主流程事务-->>事务后监听器: AFTER_COMMIT 后触发监听
主流程事务-->>主流程事务: 主流程直接返回成功
事务后监听器->>统计线程: 异步刷新统计
统计线程-->>事务后监听器: 成功则更新统计结果
统计线程-->>定时兜底任务: 失败仅记录日志
定时兜底任务->>统计线程: 下次巡检时兜底重算

41 @Scheduled 定时任务与 @EnableScheduling

面试必答要点

• 启用方式：配置类加 @EnableScheduling（启用定时调度），方法加 @Scheduled 即可，无需额外依赖。
• 三种触发方式对比：
  • cron（定时表达式）：Cron 表达式，精确控制"每天几点执行"，最灵活（如 "0 0 3 * * ?" 每天凌晨3点）。
  • fixedRate（按开始时间固定频率触发）：固定速率，以上次开始时间为基准，间隔固定时间触发。若任务超时则任务会并发。
  • fixedDelay（按完成时间固定延迟触发）：固定延迟，以上次完成时间为基准，上一次跑完再等待。适合严格串行的任务。
• 默认单线程陷阱：Spring 默认用单线程执行所有定时任务，若某个任务阻塞，其他所有任务都会延迟！解决方案：配置 ThreadPoolTaskScheduler（Spring 调度线程池） 作为调度线程池（至少核心线程数 = 定时任务数量）。
• @Scheduled 失效场景：① 未加 @EnableScheduling ② 方法有参数（必须是无参方法） ③ Bean 未被 Spring 管理 ④ 同类内部调用（代理失效）。
• 分布式陷阱：多实例部署时，每个实例都会独立触发定时任务，导致重复执行！解决方案：Redis 分布式锁抢占 + 只有抢到锁的实例执行，或引入 Quartz（Java 定时调度框架）/XXL-Job（分布式任务调度平台） 分布式调度框架。
• Cron 表达式：格式为 秒 分 时 日 月 周，? 表示不指定（日和周不能同时指定），* 表示任意，/N 表示每隔N。

42 CompletableFuture 异步编排

面试必答要点

• vs Future：JDK 5 的 Future（只能等待结果的异步占位） 只能阻塞 get() 等待，无法链式组合；CompletableFuture（可编排的异步结果对象）（JDK 8）是异步编程的革命——可以像 Promise（可链式处理的异步结果） 一样链式调用，无需阻塞等待。
• 核心 API：
  • supplyAsync（异步执行并返回结果）(supplier)：异步执行有返回值的任务。
  • thenApply（接上一步结果继续处理）(fn)：上一步完成后，同步处理结果，返回新的 CompletableFuture。
  • thenCompose（串接下一个异步任务）(fn)：上一步完成后，返回另一个 CompletableFuture（flatMap（拍平嵌套结果），避免嵌套）。
  • thenCombine（合并两个异步结果）(other, fn)：两个任务都完成后，合并两者结果。
  • allOf（等待全部完成）(futures...)：等待所有任务完成（项目用于并行收集多路指标）。
  • anyOf（任一完成即返回）(futures...)：任意一个完成即触发（适合"有一个结果就行"场景）。
  • exceptionally（异常兜底回调）(fn)：异常兜底，出错时返回默认值（项目超时降级的核心）。
  • orTimeout（超时即失败）(n, unit)：（JDK 9+）超过时间抛出 TimeoutException，配合 exceptionally 实现超时降级。
• 线程池说明：默认使用 ForkJoinPool.commonPool()（JDK 默认公共线程池）；生产中建议传入自定义线程池（supplyAsync(supplier, executor)），避免阻塞公共池。
• 异常传播：链式调用中任意环节抛异常，后续 thenApply 都会跳过，直到 exceptionally 或 handle 捕获。
• join() vs get()：两者都会阻塞等待，区别在于 get() 抛受检异常（需捕获），join() 抛非受检 CompletionException（异步包装异常）（更简洁）。

先举个直觉例子

比如一个用户主页接口，打开页面时通常要同时查这 4 类数据：

• 用户基本信息
• 订单信息
• 优惠券信息
• 推荐商品

这 4 件事彼此独立，所以非常适合用 CompletableFuture 做异步编排。

如果不编排，会怎样？

1. 先查用户信息
2. 再查订单
3. 再查优惠券
4. 再查推荐商品
5. 最后组装成页面数据返回

如果每一步大约都要 100ms，总耗时通常就是 400ms+。

如果用了异步编排，会怎样？

• 4 个任务同时发起，最后统一汇总结果。
• 总耗时接近最慢的那个任务，比如 4 路里最慢的是 120ms，整体就接近 120ms。
• 如果某一路失败，还可以返回默认值或空数据，不一定拖垮整页。

flowchart TD
指标请求[一份指标请求] --> 并发拆分[拆成四路并发采集]
并发拆分 --> 线程池指标[采集线程池指标]
并发拆分 --> 连接池指标[采集连接池指标]
并发拆分 --> Redis指标[采集 Redis 指标]
并发拆分 --> HTTP指标[采集 HTTP 指标]
线程池指标 --> 线程池结果[2 秒超时或异常则返回默认值]
连接池指标 --> 连接池结果[2 秒超时或异常则返回默认值]
Redis指标 --> Redis结果[2 秒超时或异常则返回默认值]
HTTP指标 --> HTTP结果[2 秒超时或异常则返回默认值]
线程池结果 --> 汇总结果[allOf 汇总全部结果]
连接池结果 --> 汇总结果
Redis结果 --> 汇总结果
HTTP结果 --> 汇总结果
汇总结果 --> 统一响应[返回一份完整响应]

43 企业级定时任务管理框架（自定义注解 + 注册中心 + 模板方法）

面试要点

• 为什么不直接用 @Scheduled？原生 @Scheduled 无法：① 动态查询任务列表 ② 手动触发某个任务 ③ 记录执行历史与成功率 ④ 统一管理参数和高风险确认。项目自建框架解决了以上所有问题，且保留 @Scheduled 作为触发引擎。
• 模板方法模式（Template Method（模板方法模式））：AbstractScheduledTask 定义执行骨架（校验→前置→doExecute→后置→日志），子类只需实现 doExecute()，通用逻辑写一次，无需在每个任务类中重复。
• 注解 + 反射元数据读取：@PostConstruct 中通过 this.getClass().getAnnotation(ScheduledTask.class) 读取注解元数据，实现"零配置"自动注册。
• 高风险任务设计：highRisk = true 的任务（如大范围数据删除）在管理端触发前需要二次确认，防止误操作。
• TaskLogCollector（任务日志收集器）：每次执行创建独立日志收集器，执行过程中随时追加日志，最终持久化到数据库，便于事后排查任务执行细节。
• 与 Quartz / XXL-Job 对比：自研框架零外部依赖、与 Spring 深度集成，适合中小规模单体项目；Quartz 支持持久化调度、集群；XXL-Job 提供可视化控制台与分布式调度，适合大规模微服务。

flowchart TD
taskClass[具体任务类] --> taskMeta[ScheduledTask 注解元数据]
taskMeta --> registry[ScheduledTaskRegistry 注册中心]
manualTrigger[管理端或 API 手动触发] --> registry
scheduledTrigger[Scheduled 定时触发] --> registry
registry --> taskInstance[定位具体任务实例]
taskInstance --> templateFlow[AbstractScheduledTask 模板流程]
templateFlow --> preProcess[参数校验与前置处理]
preProcess --> executeCore[执行具体任务逻辑]
executeCore --> logCollector[TaskLogCollector 收集日志]
logCollector --> auditStore[执行历史与审计持久化]

43A 消息队列（MQ）

最准确的结论是：MQ 不是“更高级的异步”，而是“带缓冲和治理能力的异步通信通道”

你可以先把消息队列理解成一个任务暂存区 + 交接带：生产者只负责把消息投进去，消费者按自己的节奏取出来处理。它解决的不是“代码怎么异步调用”这么小的问题，而是系统之间不必同时在线、同时处理、同时成功的问题。

• 如果只有线程池 / @Async：更像是“我自己开个后台线程继续干活”，本质仍然偏单机内、单服务内的异步。
• 如果引入 MQ：就变成“先把任务正式交给一个中间站”，后续由 Broker（消息中间站） 负责暂存、排队、投递，消费者再异步处理。
• 一句人话：@Async 解决的是‘先别堵住当前请求线程’，MQ 解决的是‘任务如何被可靠地交出去、排起来、稍后再处理’。

它通常由哪几部分组成？

• Producer（消息生产者）：负责发消息的人 / 服务，例如“上传文件后创建 AI 解析任务”的入口接口。
• Broker / MQ Server：负责接收、保存、路由、分发消息的中间站。
• Queue（工作队列） / Topic（主题通道）：消息暂存的位置。Queue 更像工作队列；Topic 更像事件广播入口。
• Consumer（消息消费者）：真正取消息并执行的人 / 服务，例如解析 Worker（后台消费进程）、通知 Worker、导出 Worker。
• Ack（消费确认） / Retry（失败重试） / DLQ（Dead Letter Queue，死信队列）：分别对应“处理完成确认”“失败后是否重试”“多次失败后进入死信队列”，它们决定了 MQ 是否真的可靠。

项目为什么会需要它？

• 解耦：上传请求只负责受理和生成任务，不必同步等待 AI 解析、消息通知、统计刷新都完成。
• 异步：把长耗时任务从请求线程彻底摘出去，让用户先拿到 taskId 或受理结果。
• 削峰填谷：高峰时先把任务放进队列，后台 Worker 按可控速率消费，避免线程池、数据库或外部 AI API 被瞬时打满。
• 可靠治理：失败可重试、坏消息可进死信、积压可监控、延迟可告警，异步任务从“能跑”升级为“可治理”。

什么时候它最有价值，什么时候反而没必要？

• 适合：导出、大文件解析、批量导入、通知投递、支付结果回传、跨系统事件传播，这些都不要求用户在当前请求里立刻拿到最终结果。
• 不适合：库存扣减是否成功、支付是否完成、转账是否落账，这类核心流程通常必须同步知道结果，不能一句“我先发个消息”就交代过去。
• 一个判断句：如果业务真正需要的是“稍后完成，但必须能追踪、补偿和重试”，MQ 往往有价值；如果业务需要的是“现在立刻知道最终结果”，那优先考虑同步调用或本地事务链路。

43B 消息队列（MQ）选型：RabbitMQ vs Kafka

进入选型前，先明确 RabbitMQ 和 Kafka 各自代表什么

• 严格来说：Kafka（分布式事件流平台） 也是消息中间件，但它更准确的定位是分布式事件流平台；而大家口语里说“上 MQ”，通常是指 RabbitMQ（任务型消息队列） 这类传统消息队列 / Broker。
• RabbitMQ 的核心模型：Producer（消息生产者） 把消息投递给 Exchange（RabbitMQ 路由交换器），Exchange 按 routing key（消息路由键） 路由到 Queue，Consumer 从队列中取消息处理。
• Kafka 的核心模型：Producer 把事件写入 Topic 的分区日志；Consumer Group（消费者组） 自己维护 offset（消费位点），从日志中顺序消费、可重复回放。
• 一句话区分：RabbitMQ 更像“任务分发中心”，强调路由、确认、工作队列；Kafka 更像“可回放事件总线”，强调吞吐、分区、消费者组、事件留存。

为什么系统走到这一步会想引入 MQ？

• 把长耗时任务从请求线程里彻底摘出去：例如 AI 解析、文档导出、批量导入、通知发送，本质上都不适合阻塞 HTTP 请求。
• 削峰填谷：流量高峰时先把任务写入队列，由后台 Worker 按可控速率消费，避免瞬时把线程池、下游 AI API、数据库压垮。
• 提高故障隔离能力：生产者只负责“投递成功”，消费者失败时可单独重试 / DLQ / 补偿，不把失败直接传回用户入口。
• 让异步任务变得可治理：任务状态、重试次数、死信、积压量、平均处理时长、失败原因，都可以作为统一治理对象。

行业最佳实践（无论选 RabbitMQ 还是 Kafka，基本都适用）

• 消费者必须幂等：消息系统通常只能保证至少一次（at-least-once（至少一次投递语义）），不能假设“绝不会重复投递”。常见做法是业务主键去重、幂等表、唯一约束、状态机防重入。
• 重试要分“瞬时失败”和“永久失败”：网络抖动、超时、下游 503 可以指数退避重试；参数错误、脏数据、协议不兼容应直接进入死信，不要无限重试。
• 必须有 DLQ / DLT（Dead Letter Topic，死信主题）：坏消息不能既不处理也不落地。RabbitMQ 通常用 DLX（Dead Letter Exchange，死信交换器） + DLQ；Kafka 通常用 Retry Topic + DLT。
• 消息体尽量小、语义尽量稳：推荐传 taskId / entityId / 事件摘要，而不是把超大业务对象直接塞进消息体。
• 要有可观测性：至少要监控队列深度、消费速率、失败率、重试率、死信量、消费者延迟、平均处理时长、积压年龄。
• 不要把 Broker 当数据库：队列只负责搬运与缓冲，不是业务状态真相。业务状态仍应以数据库 / Outbox（本地事务出站表） / 任务表为准。
• 跨数据库事务要靠 Outbox，而不是靠运气：如果业务数据落库和消息发布都必须成功，业界常见解法是Transactional Outbox，而不是“先写库再发消息”硬赌中间不出错。

RabbitMQ（传统 MQ）适合什么？

• 典型场景：工作队列、异步后台任务、通知投递、延迟任务、流程编排、命令分发、按路由规则把消息送到不同消费者。
• 工程优势：路由灵活（direct/topic/fanout）、低延迟、对“任务处理”语义天然友好，Spring AMQP（Spring 的 RabbitMQ 抽象） 接入成本低。
• 失败处理成熟：Manual Ack（手动确认）、Nack（拒绝确认）、DLX、TTL（消息存活时间）、延迟重试、Prefetch（消费者预取上限）、并发消费者这些概念非常适合“导出/解析/通知”类任务系统。
• 官方实践点：RabbitMQ 官方建议优先用policy（Broker 侧策略配置） 配置 DLX，而不是把 x-dead-letter-exchange 硬编码在队列声明里；这样后续可在线调整策略，不必删队列重建。
• 消费治理：RabbitMQ 的 prefetch 是核心参数之一，本质是“限制消费者手里未 ack 的消息数量”，用于平衡吞吐与内存占用。慢消费者 prefetch 要小，快消费者可以适当放大。

Kafka 适合什么？

• 典型场景：事件总线、行为日志、审计流、埋点采集、实时分析、CDC（Change Data Capture，变更数据捕获）、事件溯源、跨多个系统长期订阅同一事件流。
• 核心优势：超高吞吐、水平扩展强、消息可保留且可重放、消费者组天然支持“一份数据给多类消费者重复利用”。
• 工程特征：需要考虑 topic / partition（分区） / consumer group / offset / rebalance（消费者重平衡） / lag（消费积压量） / key 分区策略；它不是“拿来就能当工作队列”的轻型组件。
• Spring Kafka 常见实践：关闭自动提交、使用明确的错误处理器、用 Retry Topic / DLT 管控失败、消费者保持幂等、对顺序敏感场景设计好 partition key。
• 什么时候会过度设计？如果系统只是想做“后台解析任务排队 + 成功失败通知 + 少量重试”，Kafka 往往会因为引入了过多流式概念而显得过重。

RabbitMQ vs Kafka：核心对比

回到本项目：到底哪种更适合？

• 第一判断：当前项目更像“任务系统”，不是“事件平台”。现有最强诉求是把 AI 解析、导出、通知类长任务从线程池升级到更稳的后台作业体系，而不是建设一个高吞吐、可重放、被多个系统订阅的事件总线。
• 第二判断：项目里最接近 MQ 的模块已经出现了。QuestionUploadController 负责接收上传请求，先生成 taskId 再异步执行；ParseTaskStatusServiceImpl 还写明“当前用内存存储任务状态，如需持久化可改为 Redis 实现”。这说明它现在缺的不是“再来一个线程池”，而是更可靠的任务投递和消费模型。
• 第三判断：AI 解析链更偏“后台任务队列”。它有专用线程池、任务状态、用户并发控制、进度回调、长超时、重试退避、临时文件清理，这些都更贴近 RabbitMQ 的 Work Queue（工作队列模型） 模型，而不是 Kafka 的事件流模型。
• 第四判断：Kafka 不是不能用，而是现在没必要先上。只有当项目未来出现“学习行为日志全量采集、审计流长期保存、多服务订阅同一领域事件、实时推荐/实时风控/实时分析”等需求时，Kafka 的价值才会明显放大。

如果落地到这个项目，最佳引入姿势是什么？

1. 第一阶段：先上 RabbitMQ 承接 AI 解析任务。Controller 只负责参数校验、生成任务记录、投递消息；Consumer Worker 真正执行解析。
2. 第二阶段：补齐任务表 + Outbox。数据库保存任务主状态，消息只做驱动；避免“消息发出去了但数据库没写成功”或反过来的双写问题。
3. 第三阶段：完善失败治理。按异常类型决定立即失败、指数退避重试还是进入 DLQ；DLQ 消息要带 taskId、userId、失败原因、原始参数摘要。整个状态收口逻辑最好统一落回 任务表真相源。
4. 第四阶段：统一通知出口。任务完成后继续通过现有 WebSocket / SSE / 状态查询接口向前端反馈，前端交互模型几乎不用推倒重来。
5. 第五阶段：未来再评估 Kafka。如果后面真要做学习行为埋点、审计流、多系统事件订阅、实时推荐，再把“任务 MQ”和“事件流 Kafka”分层建设，而不是一开始就让 Kafka 同时承担所有责任。

43D 任务状态真相源：任务表 + Outbox + 最终一致性桥

先把结论说透：MQ、WebSocket、workflow 都不是业务真相，任务表 / 数据库才是主状态锚点

一个后台任务从创建到完成，往往会经过接口受理、数据库写入、消息投递、异步执行、通知前端、人工补偿等多个环节。如果没有一个统一的“状态真相源”，系统很快就会出现这种混乱：消息说成功了，数据库还没落；前端收到了完成通知，任务表却还是处理中；workflow 执行记录显示失败，但业务其实已经成功。

• 任务表：负责保存任务主状态，例如 PENDING / RUNNING / SUCCESS / FAILED / RETRYING（任务状态枚举），以及失败原因、重试次数、创建人、资源关联、结果摘要。
• MQ：负责驱动异步执行与削峰，不负责定义“任务最终是否成功”。
• WebSocket / SSE：负责把状态变化通知给前端，不负责成为唯一状态来源。
• workflow 平台：负责编排与可视化执行，不该替代领域系统里的核心业务真相。

为什么这里会自然走到 Outbox？

• 典型双写问题：数据库把任务记成“已创建”，但消息没发出去；或者消息发出去了，但数据库事务回滚了。两边一旦不同步，后面所有补偿和重试都会变得混乱。
• Outbox（本地事务出站表） 的意义：把“业务数据写入”和“待发送事件记录”放进同一个本地事务里，先保证这两件事同生共死，再由后台 Relay（出站投递进程） / CDC（Change Data Capture，变更数据捕获） 把事件安全发出去。
• 最终一致性的真正落点：不是允许系统长期错乱，而是允许短暂不一致，但必须通过重试、补偿、告警和人工介入，把状态收回到可恢复范围。

一个最容易讲清楚的项目例子

• 上传文件后创建 AI 解析任务：接口先写入任务表，状态是 PENDING，同时写一条 Outbox 事件。
• Relay / CDC 负责投消息：消费者开始处理后，把任务改成 RUNNING。
• 处理完成后：先更新任务表到 SUCCESS / FAILED，再通过 WebSocket 或状态查询接口把结果返回给前端。
• 所以用户最终应该信谁？前端通知只是快照，真正要以任务表 / 数据库里的主状态为准。

43C n8n 自动化工作流（Workflow Automation）

面试必答要点

• 它是什么？n8n 本质上是一个工作流自动化 / 编排平台：用节点（Nodes（流程节点））把触发器、业务逻辑、外部系统和数据转换步骤串成一条执行链，而不是每个自动化场景都从零写一套胶水代码。
• 核心构成：通常由 Trigger（触发节点）（如 Webhook、定时触发、第三方事件）、Action / Logic Nodes（动作 / 逻辑节点）（调用 API、判断、分支、循环、转换数据）、Credentials（外部系统凭证）（管理外部系统密钥）和 Executions（执行记录）（执行记录 / 调试 / 重跑）组成。
• 为什么它值得单独学？因为很多真实后端需求不是“写一个接口”就结束，而是跨多个系统、多步串联、由事件驱动的业务流程。例如表单提交后同步 CRM（客户关系管理系统）、发邮件、写数据库、推 IM（即时通讯） 通知、再落审计日志，这种链路用工作流编排比散落在多个定时任务和脚本里更容易治理。
• 它和纯 Agent（智能代理） 的区别：当步骤固定、边界清晰、审批节点明确时，显式工作流往往比“让模型自由决策每一步”更稳。Agent 更适合开放式任务决策；n8n 这类 workflow 更适合已知步骤的自动化编排。
• 典型场景：Webhook 事件编排、定时数据同步、ETL（Extract Transform Load，抽取转换加载） / 数据清洗、审批流 / Human-in-the-loop（人工介入环节）、AI 工作流（检索 → 调模型 → 调工具 → 写回系统）。
• 工程边界：n8n 解决的是“流程编排与集成效率”问题，不会自动替你解决所有生产级难题。幂等、重试、鉴权、审计、限流、数据一致性、死信与补偿，依然要按后端工程标准设计。

44 动态上下文注入（ChatContextBuilder）

解决方案与面试要点

• 意图识别：正则从用户文本中抽取题号引用（如 第(\d+)题），再按题库序号查询完整题目数据。
• Prompt 组装：系统自动将题干、选项、答案、解析注入到 System Prompt（模型最高优先级指令） 中，AI 获得"上帝视角"。
• 提示词模板：按用户状态过滤可用模板，按 sortOrder（排序字段） 排序选择；支持“系统模板 + 分类模板”叠加，做到场景化输出格式（如解析、总结、追问）。
• 模板治理：模板版本化与灰度发布；关键模板绑定评估集，防止小改动引发输出格式回归。
• 注入优先级：题目引用 → 学情进度 → 错题分析 → 联网搜索结果。
• 上下文截断：按 Token 预算从最新消息向前回填，优先保留 System Prompt，保证不超模型上限。
• 上下文压缩：上下文接近上限时，将早期对话摘要为一条 is_summary=true（摘要消息标记） 消息，保留最近几轮细节。

45 多模型适配引擎（配置 + 主动探测）

解决方案与面试要点

• 全量配置矩阵：支持 Temperature、Top-P（概率截断参数）、Top-K（候选截断参数）、Max Tokens、Thinking Budget（思考预算参数） 等 6+ 维度参数。
• 主动式能力探测（AiConfigTestService（AI 配置探测服务））：保存配置后，系统逐项向模型发请求测试哪些参数支持/不支持，生成"兼容性支持矩阵"。
• Fail-Open（局部失败先放行） 策略：某参数不支持时标记为不可用而非整体报错，最大化兼容性。
• 会话级绑定：ChatSession.aiConfigId（会话绑定的 AI 配置 ID） 支持“每个对话独立选模型/参数”，同一用户可同时开多个会话：一个低成本解析、一个高质量答疑。
• 默认配置回退：请求指定配置 → 用户默认配置 → 系统内置配置，零门槛上手。
• 场景化路由：题库解析绑轻量模型（低成本），深度答疑绑旗舰模型（高智力）。

46 Token 动态校准与流式测速

面试要点

• 校准流程：发送标准中英文语料 → 从 API 响应提取真实 usage.prompt_tokens（输入 Token 统计字段） → 计算 Chars/Token（字符与 Token 比率） 比率存入数据库。
• 流式测速原理：利用 SSE（Server-Sent Events，服务器推送事件流） 流的可观测性，精准剥离排队时间：生成速度 = Token数 / (T_last - T_first)。非流式（黑盒）无法区分。
• 智能超时决策：利用校准数据预估耗时，快模型短超时（快速失败），慢模型宽超时（避免误杀），公式：推荐超时 = 预估值 × 1.5 + 60s。

46A 大模型请求容错、限流与 Token 治理

面试必答要点

• 先治理预算，再治理效果：模型调用不仅是“能不能答出来”，还是“每次要消耗多少 Token、花多少钱、能承受多少并发”。这本质上是容量治理问题。
• 限流维度：不仅要看供应商的 RPM/TPM，还要做本地的用户级、租户级、模型级、场景级配额，避免一个重度用户或某个高成本模型拖垮整体服务。
• 上下文治理：超长上下文要优先做裁剪、摘要、分块、分阶段提问，而不是把所有历史对话和文档一股脑塞进去导致截断、超时或费用飙升。
• 容错策略：对 429、瞬时超时、上游 5xx 做指数退避重试；对“上下文超长”“参数非法”“余额不足”这类确定性错误要快速失败，不要盲重试。
• 削峰思路：高成本 AI 任务可先入本地队列 / MQ，按可控速率出队；必要时对低优先级请求做延迟、降级到轻量模型、或提示稍后重试，避免把第三方配额当无底洞。

47 Tavily 联网搜索增强（RAG 思想）

面试要点

• 为什么选 Tavily（面向 AI 的搜索服务）？专为 AI Agent（AI 智能代理） 设计 —— 自动过滤广告/噪声，返回清洗后结构化摘要，减少 Token 消耗。传统搜索 API 只返回 URL 链接需二次爬取。
• 智能触发：正则意图识别按需触发 —— 显式（"帮我搜"）、隐式（"最新版本"）、实时（"今天天气"）。
• 注入方式：搜索结果封装为上下文块注入 System Prompt 末端，确保权重高于训练数据（事实锚点，Anti-Hallucination（抑制模型幻觉））。

48 Prompt Engineering（提示词工程）

面试要点

• 三段式结构：System（角色/边界/禁令）+ Context（题干/选项/知识点/检索结果）+ Output（严格 JSON/Markdown（轻量标记格式） 模板）。
• 核心禁令：禁止编造缺失字段、禁止修改原文、字段缺失时显式标记为 unknown/empty 并给出原因。
• 可观测性：记录 Prompt 版本号、模型、温度、输入摘要与输出校验结果，便于回放与回归测试。
• 评估闭环：用“示例集 + 评分规则”做离线回归，Prompt/模型切换必须跑评估集。

49 双引擎互补架构（规则 + AI）

两条链路对比

50 有限状态机 FSM（规则引擎核心）

面试要点

• 原理：维护当前状态（UNKNOWN/STEM/OPTIONS/ANSWER/DIFFICULTY/EXPLANATION（解析阶段状态枚举）），根据每行内容决定转移。
• 关键设计 allowsNewQuestionDetection()（是否允许识别新题号的方法）：只在 UNKNOWN/EXPLANATION/DIFFICULTY 状态才允许识别新题号 → 防止解析/选项中的"1."被误判。
• 编号宽松匹配：支持 1.、(1)、一、、纯数字等多种格式。
• 面试话术："用状态机解决非结构化数据解析，因为解析器需要'记住'自己当前在解析什么（题干？选项？解析？），这正是状态机的核心优势 —— 有限的状态 + 确定性的转移规则。"

51 AI 语义归一化与保真策略

面试要点

• 语义归一化：LLM（Large Language Model，大语言模型） 自动将 (√)/(×) 规范为标准判断题选项 A/B；将缺失的题型根据内容推断补全。
• 保真策略（防幻觉）：Prompt 中植入核心禁令 —— 严禁自动生成缺失的选项或答案、严禁修改原始内容。缺少必要字段时标记 isComplete: false（结果不完整标记）。
• 后端双重保障：① AI 标记 isComplete=false 时直接拦截不入库 ② 自动剥离题干中的答案痕迹（如行尾 (√)）③ 符号判断题用结构特征识别（非死板关键词匹配）。

52 图片分配算法（区间列表 + 重力吸附）

面试要点

• DOCX 底层结构：实际是 ZIP 包，包含 document.xml（Word 正文 XML 文件） + media/（图片资源目录） + _rels/（引用关系目录）。图片通过 rId（文档内部引用 ID） 引用，无语义位置信息。
• 区间列表：为每道题的每个部分（题干/选项/解析）建立行号区间 [startLine, endLine]。
• 重力吸附（Gravity Fallback（向上吸附兜底策略））：图片位于两个区间之间时，"向上寻找"最近的有效组件（题干/选项/解析）—— 像地心引力一样，保证图片不会无声丢失，而是有合理归属。
• 逻辑行号 vs 物理行号：解析时维护逻辑行号统一文本和图片的坐标空间。

53 Apache POI（文件读写）

面试要点

• 解析要点：区分结构化段落/表格/图片等元素，保持顺序与定位信息，避免内容错位。
• 性能与内存：大文件优先使用流式处理或分批读取，避免一次性加载导致 OOM（Out Of Memory，内存溢出）。
• 安全：配合上传校验与大小限制，防止压缩炸弹与恶意文件占用资源。

54 FSRS-5 遗忘曲线与调度

面试要点

• 遗忘曲线公式：R(t) = (1 + FACTOR × t / S)^DECAY —— R 是记忆保留率，t 是时间，S 是稳定度（记忆强度）。
• 间隔公式：I = S × 9 × (R^(-2) - 1)，并做上下界裁剪（最短 1 天、最长 36500 天）。
• vs SM-2（早期间隔重复算法）：SM-2 主要用“易度因子 + 规则表”做启发式间隔；FSRS 用稳定度/难度建模并拟合个体数据，直接预测保留率，更个性化也更易解释“为什么这个间隔是 N 天”。
• 卡片状态机：NEW → LEARNING → REVIEW ↔ RELEARNING（卡片学习状态流转），四种评分（Again / Hard / Good / Easy（四级复习评分））驱动转移。
• 关键参数：Stability（记忆稳定度）（稳定度，越高间隔越长）、Difficulty（记忆难度）（难度，影响学习速率）、Reps（复习次数）、Lapses（遗忘次数）。
• Leech（反复遗忘卡） 机制：连续遗忘超过 8 次自动暂停该卡片（"水蛭卡"= 怎么学都记不住的卡）。

55 FSRS 服务分层 — 门面模式（Facade）

面试要点

• 门面模式：Controller 只和 Facade Service（统一对外编排入口） 交互，Facade 编排调用多个子 Service → 降低 Controller 复杂度、提高子服务的复用性和独立测试性。
• 统计与主流程解耦：统计更新失败不影响复习提交主流程（try-catch 隔离，记录日志）。
• SQL 迁移管理：使用版本化 SQL 脚本（V1.1.0__add_spaced_repetition.sql）确保数据库结构可追溯。

122 第三方大模型 API 限流、削峰、降级与补偿

面试必答要点

• 限流不是只看供应商配额：除了上游的 RPM/TPM/RPD（其中 RPD（每日请求数）），本地还要做用户级、租户级、模型级、场景级限额，否则一个高成本场景就能拖垮所有请求。
• 429 的正确处理：对速率型错误做指数退避 + 抖动重试；但要设置最大重试次数，避免把瞬时限流放大成全站重试风暴。
• 削峰策略：把非实时任务放入本地队列或 MQ（Message Queue，消息队列） 排队，按可控速率出队；高峰期可对低优先级请求延迟、排队、返回稍后重试。
• 降级策略：旗舰模型不可用时，按场景降级到轻量模型、缩短上下文、关闭深度思考、退回缓存答案或直接走规则链路。
• 补偿意识：调用失败后不只是“报错给前端”，还要记录任务状态、失败原因、重试次数、traceId（请求追踪 ID），便于后续人工重放和自动补偿。

123 Token 动态校准、SSE 流式测速与超时治理

面试要点

• 为什么要做 Token 动态校准？不同模型的 tokenizer（分词器） 差异很大，同样 1 万字符在不同模型上消耗的 Token 可能差很多，不校准就无法准确估算成本、上下文容量和超时预算。
• 流式测速价值：流式 SSE（Server-Sent Events，服务器推送事件流） 可以测出 首 Token 延迟、生成速率、尾部完成时间，比非流式黑盒调用更适合做精细化容量治理。
• 非流式超时：更关注总调用时长，通常用 connectTimeout（建连超时） + readTimeout（读响应超时） + callTimeout（整次调用总超时） 控制“最晚多久必须返回完整答案”。
• 流式超时：除了总时长，还要关注 首包超时、空闲超时 和 心跳保活。长推理模型可能几十秒才吐首字，如果没有心跳和 idle timeout（空闲超时） 策略，网关与客户端会误判为死连接。
• 落地做法：把模型、提示词长度、历史 Token、预估输出长度、是否开启 thinking（深度思考模式） 一起纳入超时预算，不同模型使用不同超时模板。

124 Java 服务调用大模型：同步阻塞、异步编排与线程池隔离

面试必答要点

• 同步阻塞模式：实现最简单，但一个慢模型请求会长时间占住 Servlet 线程，适合后台小流量管理场景，不适合高并发对话入口。
• 异步编排模式：可用 CompletableFuture（可编排的异步结果对象）、专用线程池、回调或 MQ，把长耗时 AI 请求从请求线程摘出去，只让入口线程负责受理、鉴权、落任务和返回状态。
• 流式交互模式：如果要做打字机体验，优先用 SSE + WebFlux（其中 WebFlux（Spring 响应式 Web 框架））或异步响应模型，让连接由非阻塞 I/O 承接，而不是让 Tomcat 工作线程傻等几十秒。
• 线程池隔离：AI 调用、文件解析、通知推送不要共用一个公共线程池；要按下游特征拆分，独立设置队列长度、并发上限、拒绝策略和监控指标。
• 防慢轮询：不要让前端高频轮询“结果好了没”，应结合 WebSocket / SSE / 状态接口兜底，减少无意义请求把网关和线程池拖死。

125 Java AI 技术选型：原生 HTTP / OkHttp vs Spring AI vs LangChain4j

选型比较

• Spring AI 更像“Spring 风格统一抽象层”：适合想把模型、向量库、工具调用、观测统一纳入 Spring 工程治理的人。
• LangChain4j 更像“Java 版 AI 工作流框架”：在 AI Service、Tool、Memory、RAG、Agent 风格开发上更顺手。
• 实际建议：底层链路一定要保留一层原生 HTTP 能力，用来兜住厂商特性差异、调试原始请求和紧急热修；不要把所有可观测性都交给框架黑盒。

126 RAG vs 微调（Fine-tuning）：分别解决什么问题？

面试必答要点

• RAG（Retrieval-Augmented Generation，检索增强生成） 解决的是“知识新鲜度与可引用性”：把私有文档、最新制度、外部资料检索出来，再注入上下文，让模型基于事实回答。
• 微调解决的是“行为习惯与输出风格”：例如固定 JSON 格式、品牌口吻、垂直任务习惯、某类分类或抽取能力，而不是拿来补最新知识库。
• 为什么很多业务系统不先微调？因为业务文档天天变，微调更新慢、成本高、可追溯性弱；而 RAG 可以按文档版本随时更新，且更容易做 citation（引用溯源）。
• 组合策略：底层模型可轻微微调以提升某类输出稳定性，上层再叠 RAG 提供最新事实与私有知识，两者不是绝对对立关系。

126A Embedding / 向量相似度基础

最准确的结论是：Embedding 不是“把文本加密一下”，而是把语义压成可计算距离的数字坐标

模型先把一句话、一个段落或一个 Chunk（检索切片） 映射成一串高维数字向量。这样系统就能在数学空间里比较“这段文本和用户问题是不是语义接近”，而不只靠关键词是否一字不差地命中。

• 为什么要向量化？因为用户提问和文档原文常常不是同一句话，但语义可能很接近。Embedding（文本语义向量） 解决的是“换种说法还能不能找到同一类内容”。
• 向量相似度在干什么？本质是在比较两个向量之间的距离或夹角，越接近，通常代表语义越相似。
• 一句人话：关键词检索更像找字面匹配，Embedding 检索更像找语义邻居。

为什么只靠 Embedding 还不够？

• 它擅长语义接近，不擅长硬过滤：租户范围、权限范围、时间条件、标签条件，仍然需要元数据过滤或关键词检索配合。
• 它不是天然精确：召回到“差不多相关”的内容后，往往还需要 Rerank（二次重排） 再排一遍，把真正最相关的 Chunk 顶到前面。
• 它高度依赖切片质量：Chunk 切太碎、切太脏、结构被破坏，再好的向量模型也会把错误语义编码进去。

一个最容易讲清楚的例子

• 用户问：“怎么防止同一个支付回调被处理两次？”
• 文档里可能写的是：“第三方回调必须做事件 ID 去重和幂等控制”。
• 关键词不一定完全重合：但 Embedding 仍可能把这两句话映射到相近区域，所以检索能命中相关文档。

127 RAG 主链路：问题改写 → 检索召回 → Rerank → Prompt 注入（外加 Citation 出链）

面试必答要点

1. 问题改写：把用户口语问题改写成更适合检索的查询，补齐省略信息、实体名、时间范围和业务上下文。
2. 检索召回：Embedding（文本语义向量） 相似度检索只是第一层，可与关键词检索、标签过滤、租户过滤、时间范围过滤组合成 Hybrid Search（混合检索）。若这一步的底层直觉还不稳，先回看 126A。
3. Rerank（重排）：先多召回，再用重排模型或交叉编码器做二次排序，把最相关的 chunk（检索切片） 挤到前面，减少“召回了但排位靠后没被注入”的问题。
4. Prompt 注入：把最终上下文以有边界的方式注入模型，明确“只能基于给定资料作答、资料不足就承认不知道”。
5. Citation（引用溯源） 出链：答案中同时返回引用片段、来源文档、chunk 编号和定位信息，让用户知道“这句结论来自哪里”。

128 Citation 溯源设计：唯一文档 ID、Chunk 元数据与防串库

面试要点

• 引用主键不能只用文件名：必须有 documentId（文档唯一标识）、version（版本号）、chunkId（切片 ID）、tenantId（租户标识）、sourceUri（来源地址标识） 等稳定标识。
• 元数据设计：至少要能记录上传人、知识库、文档版本、切片顺序、页码/段落号、权限范围、入库时间和解析状态。
• 多租户与 ACL（Access Control List，访问控制列表） 不只是 tenantId：真实 SaaS（Software as a Service，软件即服务） 场景里，同租户下还会区分角色、群组、部门、知识库共享范围和文档可见级别；这些授权元数据要在写入时就固化到 chunk 或索引记录里。
• 防串库的关键：检索时不仅做向量相似度，还要先做租户、知识库、ACL、权限和版本范围过滤，否则最相近的 chunk 可能来自错误的数据域。
• 答案返回值：除了最终文本，还应返回 citations[]（引用结果列表），里面带来源标题、chunk 摘要、定位信息、sourceId；高敏资料在前端展示引用前也应做二次授权确认。

129 向量库选型：Milvus / Redis Vector / Elasticsearch / pgvector vs MySQL

面试要点

• MySQL 能不能做？能存向量，但不擅长大规模高维近邻搜索。小规模 PoC（Proof of Concept，概念验证） 可以硬做，生产检索延迟、召回效果和扩展性通常不理想。
• Milvus（向量数据库）：更像专业向量数据库，适合高维检索、规模大、召回要求高的知识库型场景。
• Redis Vector（Redis 向量检索能力）：接入轻、延迟低，适合已有 Redis 基础设施、对在线查询延迟敏感的场景，但要关注成本和内存模型。
• Elasticsearch（分布式搜索引擎）：适合把关键词检索、过滤、聚合和向量检索放在一个搜索体系里，做 Hybrid Search 很自然。
• pgvector（PostgreSQL 向量扩展）：如果团队 PostgreSQL 基础强、数据规模中等、希望“先从数据库内扩展”开始，是一个常见折中方案。

130 Chunk 切片策略：切太大、切太小都会出问题

面试必答要点

• 切太大：一个 Chunk（检索切片） 混入太多无关信息，向量语义被稀释，召回后还会白白浪费上下文窗口和 Token 成本。
• 切太小：上下文断裂，检索到一句话却缺失前后定义，模型容易误解语境、胡乱补全。
• 优先按语义结构切：标题、章节、段落、表格、代码块、问答对、题目解析等天然边界优先，不要机械按固定字数生砍。
• 常见优化：设置适度 overlap（切片重叠区），保住跨段衔接；对表格、代码、流程图、FAQ（常见问题列表） 采用专门切法，而不是一套参数打天下。
• 最终目标：既让检索命中足够精准，又让注入到 Prompt 的上下文足够完整、可引用、不过度冗余。

131 Agent 架构认知：模型不等于 Agent

面试必答要点

• 模型（LLM（Large Language Model，大语言模型））是推理核心，不是完整系统：它负责理解与生成；但没有工具、记忆、规划与状态循环时，只是一次性的语言函数。
• Agent 的四大核心组件：感知（接收用户输入、环境信号、多模态内容）、规划（拆解目标与步骤）、记忆（短期上下文与长期状态）、工具（调用外部 API / 数据源 / 系统能力）。
• 关键差异：普通问答是“一问一答”，Agent 更像“有状态的任务执行循环”——会观察、决策、调用、反思，再继续下一步。
• 工程边界：不是所有场景都该上 Agent。只要工作流稳定、步骤固定、工具有限，很多时候显式编排比“让模型自由决策”更稳更便宜。

132 Function Calling / Tool Calling：模型如何与后端系统握手

面试必答要点

• 基本握手流程：后端向模型注册工具 Schema（参数结构定义） → 模型生成 tool call（工具调用请求） → 后端校验参数、权限、幂等与风控 → 执行工具 → 把结果作为 tool message（工具执行结果消息） 再喂回模型生成最终答案。
• 和 ReAct（推理-行动-观察范式） 的关系：ReAct 更强调“思考 + 行动 + 观察”的推理模式；Function Calling（模型提出函数调用请求） 是更结构化、更适合生产系统的工具调用接口。
• 安全边界：工具不能让模型任意越权。必须做参数校验、资源授权、审计日志、超时、熔断和幂等，不能把数据库写接口直接裸露给模型。
• 可靠性设计：工具执行失败时，要把失败原因结构化返回给模型，而不是简单抛异常；必要时允许模型改用其他工具或给用户解释失败原因。

133 会话记忆与裁剪：滑动窗口、摘要压缩与长期记忆

面试要点

• 短期记忆：保留最近 N 轮对话，适合连续追问和局部上下文理解。
• 摘要压缩：把更早历史压成一条 summary message（历史摘要消息），只保留当前还需要的事实、结论、用户偏好与未完成任务。
• 长期记忆：对稳定偏好、历史任务、知识点画像、用户画像等内容，不应一直塞在 prompt 里，而应像 RAG 一样按需检索。
• 裁剪原则：优先保留 System Prompt（模型最高优先级指令）、当前任务上下文、最近几轮强相关对话；把寒暄、重复问答、低价值噪声先裁掉。
• 观测指标：要能看到每轮输入/输出 Token、摘要触发率、上下文命中率、裁剪后答非所问比例，否则无法优化 memory 策略。

134 多模态链路可靠性：上传文件 → 存储 → 解析 → 数据状态最终一致

面试必答要点

• 不要把“文件已上传”与“业务已成功”混为一谈：文件落存储成功，只代表素材可用，不代表题目已经解析成功入库。
• 状态机建模：可把任务拆成 PENDING_UPLOAD → UPLOADED → PARSING → PARSED / FAILED（多模态处理状态流转），每一步都落状态，便于补偿与重放。
• 补偿机制：模型解析失败或写库失败时，要么重试任务，要么清理孤儿文件，要么标记人工介入，不能让 OSS（Object Storage Service，对象存储服务） 里躺一堆垃圾文件、数据库里却没有对应记录。
• 幂等与去重：上传重试、回调重放、前端重复点击都可能发生；需要用文件哈希、任务号、业务幂等键控制“同一素材不要被重复处理多次”。
• 一句话理解：多模态链路的难点不只是“让模型看图”，而是把文件系统、对象存储、任务系统和数据库状态收敛到一致的最终结果。

135 AI Gateway、统一流量治理与语义缓存

面试必答要点

• AI Gateway（AI 网关） 的定位：它是应用和模型供应商之间的控制平面，负责统一鉴权、供应商路由、模型路由、速率限制、预算控制、审计日志和故障切换。
• 为什么不能把逻辑散在各服务里？一旦供应商限流、模型下线、成本超标、区域合规或埋点字段变化，分散接入的治理成本会指数级上升。
• 语义缓存（Semantic Cache（语义缓存））：不是只缓存“完全相同的 prompt”，而是对语义接近的问题复用结果，减少重复调用、降低 Token 成本，并在上游限流时充当缓冲层。
• 缓存治理：语义缓存必须带 tenantId（租户标识）、场景标签、Prompt 版本、模型版本、TTL（生存时间） 和相似度阈值；否则极容易出现跨租户串答、旧答案污染或误命中。
• 请求去重：对短时间内完全相同或高度相似的请求做合并/去重，可以显著减少“同一热点问题被并发问 100 次”的重复耗费。

136 AI 可观测性、评测体系与 Prompt / 模型版本治理

面试必答要点

• 至少要监控哪些指标？延迟、输入/输出 Token、总成本、缓存命中率、首 Token 时间、RAG 检索命中率、Citation 覆盖率、Tool 成功率、用户负反馈率。
• Tracing（链路追踪） 要下钻到 AI 细节：不只追 HTTP span（链路中的单个步骤），还要拆出 LLM 调用、检索、Rerank、工具调用、评测与缓存命中，让一次回答的全过程可以复盘。
• Prompt / 模型 / 策略版本治理：每次请求都应带上 provider（模型供应商标识）、model、modelVersion（模型版本标识）、promptVersion（提示词版本标识）、policyVersion（策略版本标识）、experimentVariant（实验分组标识） 等元数据，否则出问题时很难回放和回滚。
• 评测闭环：新 Prompt、新模型、新 RAG 策略上线前要跑黄金数据集（golden dataset（黄金评测集）），从正确性、忠实度、拒答质量、工具轨迹、成本与延迟等维度做回归评测。
• 生产反馈回流：最有价值的评测样本往往不是人工臆造的，而是来自真实线上失败案例、低评分会话、错误 Citation 和异常工具轨迹。

137 RAG 入库链路、增量索引与知识新鲜度治理

面试必答要点

• 入库链路要和查询链路分开：生产级 RAG 至少有两条路径——离线/异步的 ingestion pipeline（入库处理流水线） 和在线的 query pipeline（在线查询流水线），不能让文档处理阻塞用户查询。
• 完整入库步骤：解析原文 → 清洗噪声 → 语义切片 → 元数据增强 → 生成 embedding（文本语义向量） → 写入向量库 / 倒排索引 → 更新检索目录。
• 增量索引：文档更新时不能每次全量重跑整库；要基于 documentId、版本号、文件哈希、更新时间或 CDC（Change Data Capture，变更数据捕获） 事件只处理变更部分。
• 知识新鲜度：用户问到过期内容时，问题往往不在大模型，而在索引还停留在旧版本。要能回答“新文档多久可检索到”“旧 chunk 何时失效”“重建期间如何避免读到脏索引”。
• 幂等性：重复上传、重复同步、失败重试都不应产生重复 chunk 或重复 embedding；入库任务必须可重跑、可补偿、可追踪。

138 Prompt Injection、Guardrails 与 AI 安全边界

面试必答要点

• 直接注入 vs 间接注入：直接注入来自用户 prompt；间接注入藏在网页、邮件、PDF、知识库文档或第三方返回内容里，模型一旦把这些内容当“指令”而不是“数据”读取，就可能被带偏。
• 危险升级点：在有 Tool / Agent 能力时，Prompt Injection 不只是“让模型胡说”，而可能变成“诱导模型执行不该执行的工具、访问不该访问的数据、泄漏不该泄漏的信息”。
• Guardrails（安全护栏机制） 不是单一过滤器：真正有效的是分层防护：输入检查、Prompt 结构化、RAG 数据净化、最小权限工具、输出过滤、DLP（Data Loss Prevention，数据泄露防护）/PII（Personally Identifiable Information，个人敏感信息） 脱敏、日志审计与人工审批。
• 结构化输出也属于 guardrails：如果系统要求返回 JSON / schema（结构约束定义），后端必须做输出校验，不合法时可触发重试、降级或拒绝返回，避免模型把脏结构直接送进业务代码。
• 权限边界：永远不要因为“模型说它需要”就给它高权限。工具、模型、知识库和租户数据都要做显式 RBAC（Role-Based Access Control，基于角色的访问控制）/ABAC（Attribute-Based Access Control，基于属性的访问控制） 与最小权限控制。
• 关键意识：模型不是可信执行环境。所有高风险动作（转账、删库、发通知、调用内部写接口）都应通过后端二次校验，必要时加 human-in-the-loop（人工介入审批）。

56 并发三性 / JMM / happens-before

很多并发 bug 不是代码“完全没写对”，而是主线程和工作线程对同一份数据的理解不一致。你以为已经改了，另一个线程却还没看到；你以为这几步会按顺序发生，运行时却可能重排。这个概念的价值，就是给你一套判断标准，帮你区分“看起来能跑”和“真的线程安全”。

先把并发三性分开

• 原子性：一个操作要么整体完成，要么整体不完成，中间不会被别人插进来。最常见的反例就是 count++，它其实不是一步，而是“读旧值 → 加一 → 写回新值”。
• 可见性：一个线程改了共享变量，别的线程什么时候能看到。比如线程 A 把 stop = true，线程 B 如果一直看不到这个新值，就可能还在死循环里跑。
• 有序性：程序写出来的顺序，不等于其他线程最终观察到的顺序。单线程里通常没感觉，但一旦跨线程共享数据，就要关心哪些顺序必须被约束住。

JMM 到底在管什么

JMM（Java Memory Model，Java 内存模型）不是让你背一串并发 API，它更像 JVM 给多线程规定的一套“传话规则”：线程 A 写过的数据，在线程 B 看来什么时候应该可见；哪些读写顺序可以优化，哪些顺序必须保住。面试里说 JMM，重点不是列类名，而是说明它解决的是跨线程的可见性和有序性问题。

happens-before 为什么是推理核心

• 判断思路：不要先问“我用了哪个关键字”，先问“这次写和那次读之间，有没有 happens-before（先行发生关系）”。
• 有 HB：前面的写入对后面的读取可见，而且顺序上也成立，你就有理由说“这个线程能看到那个线程的结果”。
• 没 HB：就别指望“多等一会儿应该就好了”，那只是碰运气，不是正确性保证。
• volatile 不是万能锁：假设 volatile int count = 0;，线程 T1 和 T2 同时执行 count++，两边都可能先读到 0，再各自写回 1，最后结果仍然是 1。这里失败的不是可见性，而是 count++ 这三个步骤合起来不具备原子性。

面试必答要点

• 并发三性：原子性（操作不可分割）、可见性（写入对其他线程可见）、有序性（重排序限制）。
• happens-before：HB 关系成立 ⇒ 前者对后者可见且有序（这是“线程安全推理”的底层规则）。
• HB 常用规则：对同一个volatile 变量的写 HB 于后续对这个变量的读；退出 synchronized HB 进入同一锁；start() HB 新线程动作；线程动作 HB join() 返回。
• volatile 边界：保证可见性，并禁止会破坏它语义的那部分重排序；不是加了 volatile 就所有代码都绝对不重排，也不保证 count++ 这类复合操作原子性。
• 别踩坑：sleep/yield 不提供同步语义，不能拿来“等一等就可见”。

flowchart TD
    A[线程 T1: volatile write x = 1] -->|HB 规则| B[线程 T2: volatile read x]
    B -->|保证| C[T2 能看到这次 volatile 写的结果]
    C -->|保证| D[T1 在这次写之前的普通写
对 T2 也可见]

    E[线程 T1: 退出 synchronized] -->|HB 规则| F[线程 T2: 进入同一 synchronized]
    F -->|保证| G[T2 看到 T1 释放锁前的所有写操作]

    H[线程 T1: thread.start] -->|HB 规则| I[新线程 T2 的任何动作]
    I -->|保证| J[T2 能看到 T1 在 start 前的所有写操作]

    K[线程 T2: 任何动作] -->|HB 规则| L[线程 T1: thread.join 返回]
    L -->|保证| M[T1 能看到 T2 在 join 前的所有写操作]

    N[volatile 保证可见性 + 有序性] -.不保证.-> O[count++ 是复合操作
读-改-写三步]
    O -->|结论| P[多线程 count++ 仍不安全
需要原子类或 synchronized]

    style A fill:#f0fdf4,stroke:#16a34a
    style E fill:#f0fdf4,stroke:#16a34a
    style H fill:#f0fdf4,stroke:#16a34a
    style K fill:#f0fdf4,stroke:#16a34a
    style C fill:#e0f2fe,stroke:#0284c7
    style D fill:#e0f2fe,stroke:#0284c7
    style G fill:#e0f2fe,stroke:#0284c7
    style J fill:#e0f2fe,stroke:#0284c7
    style M fill:#e0f2fe,stroke:#0284c7
    style O fill:#fef3c7,stroke:#d97706
    style P fill:#fef3c7,stroke:#d97706

57 线程状态与中断（Interrupt）

线上系统里最常见的并发诉求不是“把线程开起来”，而是“线程卡住时怎么判断它在等什么、超时或停机时怎么让它体面退出”。所以这题一半在讲线程生命周期，一半在讲取消机制：线程当前处于什么状态，决定了它会不会响应中断，以及应该怎么收尾退出。

先把 6 种状态分开

• NEW：线程对象刚创建，还没调用 start()。
• RUNNABLE：Java 视角下的“可运行”；既可能正在占用 CPU，也可能已经就绪、等待调度。
• BLOCKED：通常是进入 synchronized 时抢不到监视器锁，被卡在锁竞争上。
• WAITING：线程主动进入无限等待，典型来自 wait() / join() / park()。
• TIMED_WAITING：带超时的等待，典型来自 sleep() / wait(timeout) / join(timeout)。
• TERMINATED：run() 执行结束或异常退出，线程生命周期完成。

BLOCKED、WAITING、TIMED_WAITING 怎么区分

• BLOCKED：我想继续往下跑，但临界区门口有人占着锁，所以我只能被动等。
• WAITING：我主动停下来，等别人明确通知我继续，比如 notify / unpark / 目标线程结束。
• TIMED_WAITING：我主动停一段时间；即使没人通知，到点也能自己回来。

中断为什么不是“强杀线程”

• 中断本质：interrupt() 发的是“请尽快停”的协作信号，不会像杀进程那样把线程粗暴打死。
• 运行中线程：多数情况下只是把中断标记设为 true；线程需要自己检查并决定何时退出。
• 阻塞中线程：如果正卡在 sleep / wait / join，通常会收到 InterruptedException；如果是 park，常见表现是返回后由代码自己处理中断。
• 工程价值：这样线程可以先释放锁、连接、文件句柄，再优雅退出，避免共享状态停在半更新状态。

面试必答要点

• 6 状态：NEW/RUNNABLE/BLOCKED/WAITING/TIMED_WAITING/TERMINATED；其中 RUNNABLE 不等于“此刻一定在执行”。
• BLOCKED vs WAITING：BLOCKED 多为锁竞争；WAITING/TIMED_WAITING 多为 park/wait/join/sleep 这类主动等待。
• 中断语义：中断是“请求停止”的标记；线程需自行检查并尽快退出，或把中断语义继续往上传递。
• 中断 API：isInterrupted() 读取中断标记但不清除；Thread.interrupted() 读取当前线程并顺手清除标记。
• 最佳实践：catch 到 InterruptedException 后要么向上抛出，要么执行 Thread.currentThread().interrupt() 恢复中断状态。
• 锁获取差异：等待 synchronized 锁时不能靠中断立即打断；显式锁可用 lockInterruptibly() 支持可中断获取锁。
• 线程池取消：Future.cancel(true) 与 shutdownNow() 本质都是“尝试中断”；任务能不能停下来，取决于代码是否正确响应中断。

flowchart TD
    A[NEW] -->|调用 start| B[RUNNABLE]
    B -->|抢锁失败| C[BLOCKED]
    C -->|拿到锁| B

    B -->|主动等待| D[WAITING]
    B -->|超时等待| E[TIMED_WAITING]
    D -->|被通知后继续| B
    E -->|超时或被唤醒| B

    D -. interrupt .-> F[抛 InterruptedException
或返回后处理中断]
    E -. interrupt .-> F
    B -. interrupt .-> G[只设置中断标记
需要主动检查]
    F --> H[清理资源并退出]
    G --> H
    B -->|正常结束| I[TERMINATED]
    H --> I

    style A fill:#f0fdf4,stroke:#16a34a
    style B fill:#e0f2fe,stroke:#0284c7
    style C fill:#fde68a,stroke:#d97706
    style D fill:#e0f2fe,stroke:#0284c7
    style E fill:#e0f2fe,stroke:#0284c7
    style F fill:#fee2e2,stroke:#dc2626
    style G fill:#fee2e2,stroke:#dc2626
    style H fill:#fef3c7,stroke:#d97706
    style I fill:#dcfce7,stroke:#16a34a

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    return;
}

while (!Thread.currentThread().isInterrupted()) {
    doWork();
}

58 synchronized 与线程协作（wait/notify/Condition）

很多人学到这里会把所有词都混成“线程同步”。但其实它们在解决两类不同问题：synchronized 负责防止多个线程同时把共享数据改乱；线程协作机制负责让线程在条件不满足时先等着，条件满足后再继续。所以这题真正要分清的是：哪些问题靠“加锁”解决，哪些问题靠“等待与通知”解决。

先把两个概念的核心定义立住

• synchronized：Java 内置的监视器锁机制，用来保护临界区。它的核心作用有两层：一是互斥，同一时刻只允许一个线程进入受保护代码；二是内存语义，线程退出同步块前的写入，对之后进入同一把锁的线程可见。
• 线程协作：多个线程围绕“某个条件是否成立”来协调执行时机，不是谁都一直抢着跑，而是该等就等、条件满足再被唤醒继续执行。它解决的是“什么时候轮到谁执行”，常见手段就是 wait/notify/notifyAll 或 Condition（条件变量 / 条件队列） 的 await/signal。

一句话区分：synchronized 主要解决“能不能同时进”；线程协作主要解决“什么时候该等、什么时候该醒”。

为什么单纯加锁还不够

如果只是多个线程抢同一份数据，互斥通常就够了；但如果线程之间存在“前置条件”，光加锁不够表达业务语义。比如生产者必须等“队列未满”才能放数据，消费者必须等“队列非空”才能取数据，这时候不能让线程一直空转重试，而应该在条件不满足时释放锁、进入等待，等条件变化后再被唤醒继续检查。

wait/notify 到底在做什么

• wait()：当前线程在持有锁时发现条件不满足，于是释放这把监视器锁并进入等待集，暂停执行。
• notify()：随机唤醒同一个对象等待集中的一个线程；它只是“通知有机会了”，不保证被唤醒线程立刻执行。
• notifyAll()：唤醒同一个对象等待集中的全部线程；它们会重新竞争锁，谁拿到锁谁先继续检查条件。
• 关键区别：wait() 会释放当前监视器锁，而 sleep() 只暂停当前线程，不会释放已经持有的锁。

面试必答要点

• synchronized：互斥 + 内存语义（退出/进入建立 happens-before）。
• wait/notify：必须在持有锁时调用；wait 会释放锁并进入等待集；必须while(条件不满足) wait() 防虚假唤醒。
• notify vs notifyAll：优先考虑 notifyAll，避免唤醒“错误类型等待者”导致系统长期不前进。
• Condition：一个锁对应多个条件队列（比 Object.wait 更可控）。

class Buffer {
    private final LinkedList<Integer> list = new LinkedList<>();
    private final int capacity = 5;

    public synchronized void put(int value) throws InterruptedException {
        while (list.size() == capacity) {
            wait();
        }
        list.add(value);
        notifyAll();
    }

    public synchronized int take() throws InterruptedException {
        while (list.isEmpty()) {
            wait();
        }
        int value = list.removeFirst();
        notifyAll();
        return value;
    }
}

Lock lock = new ReentrantLock();
Condition notFull = lock.newCondition();
Condition notEmpty = lock.newCondition();

59 Lock / AQS / CAS / 原子类（Atomic）

这一节最容易学散，因为它表面上是在讲 4 个名词，实际上讲的是一条并发工具栈：Lock 是上层显式锁工具，AQS（AbstractQueuedSynchronizer，抽象队列同步器）是很多同步器共用的排队骨架，CAS（Compare-And-Set，比较并设置）是乐观并发里的原子更新手段，Atomic（原子类） / LongAdder（长整型累加器）则是把这些能力包装成业务代码更容易直接调用的 API。

先把总纲立住：这 4 层不是并列词，而是一条工具栈

• 从 58 节接过来：synchronized 解决的是“先把互斥和线程协作建立起来”，59 节开始补“显式锁”和“无锁原子更新”这两条更细的路线。
• Lock：你在业务代码里直接选用的显式锁工具，比如 ReentrantLock、ReadWriteLock、StampedLock。
• AQS：不是锁本身，而是很多同步器共用的底座，核心是 state + FIFO（First In, First Out，先进先出）等待队列，负责“抢不到资源时怎么排队、阻塞、唤醒”；但等待队列按 FIFO 组织，不等于一定严格按 FIFO 拿到资源，还要看公平策略和具体实现。
• CAS：不是“锁的替代品”这 5 个字就能讲清的，它更准确是“先比较旧值，再决定是否原子更新”的乐观竞争手段。
• Atomic / LongAdder：Atomic* 适合单变量原子更新；LongAdder 适合高并发热点计数，但不是所有原子类的默认升级版。

遇到什么场景，就该先想到谁

• 需要超时、可中断、公平锁、多条件队列：先想到 ReentrantLock，因为这类题通常已经超出 synchronized 的舒适区。
• 读远多于写：先想到 ReadWriteLock，目的是让读线程并发通过，而不是所有访问都串行排队。
• 想先乐观读，再视情况尝试转换为写锁：先想到 StampedLock，但要记住它不支持重入，而且乐观读必须做校验。
• 只是一个计数器、状态位、引用值要做原子更新：先想到 AtomicInteger / AtomicLong / AtomicReference 这类原子类。
• 高并发下很多线程都在猛加同一个计数：先想到 LongAdder，因为它会把热点写入分散到多个槽位，降低单点 CAS 竞争。
• 多步复合操作、多个变量必须一起保持一致：这类题别死扛 CAS，通常还是锁或更高层同步器更稳。

AQS / CAS / Atomic 到底怎么串起来

1. AQS 的思路：线程先尝试改 state；成功就继续执行，失败才进入等待队列，不是所有线程都一上来就睡死。
2. CAS 的思路：线程不先上锁，而是先看“当前值是不是我刚刚读到的旧值”，只有一致时才交换成新值。
3. Atomic* 的角色：把 CAS 包装成更直接的 API，让你不需要自己手写底层原子更新逻辑。
4. 真实世界不是二选一：很多 AQS 同步器本身也会先用 CAS 抢占状态，抢不到才进入排队阻塞路径，所以它们常常是“CAS 快路径 + 队列阻塞慢路径”的组合。
5. 真正该记住的是线程下一步干什么：锁/AQS 路线是“抢不到就排队等”；CAS/Atomic 路线是“抢不到就失败或重试”；LongAdder 路线是“热点太高就把写入拆散再汇总”。

面试必答要点

• ReentrantLock / ReadWriteLock / StampedLock vs synchronized：显式锁不是“更高级”，而是当你需要 tryLock(timeout)、可中断获取、公平策略或多个 Condition 时，它才真正体现价值。
• AQS：它是同步器基础设施，不是你在业务里直接“new 一个来用”的工具；很多锁、门闩、信号量都只是用不同方式解释它的 state。
• CAS：适合单变量乐观更新，但在高冲突场景会反复失败、自旋重试，未必就比加锁更省。
• ABA 问题：CAS 只能确认“当前值还是不是原来的值”，不能确认“中间有没有被改过又改回来”，这时要想到版本戳或标记位。
• Atomic vs LongAdder：低冲突、需要单点精确原子值时用 Atomic；高并发热点统计用 LongAdder；它的 sum() 更适合统计口径，不适合拿来做精确业务真值控制。
• 常见同步器（按问题触发）：CountDownLatch 适合“等 N 个任务完成再继续”；CyclicBarrier 适合“一组线程到齐后再一起推进”；Semaphore 适合“限制同时进入的线程数”；Phaser 适合“分阶段协作且参与方可能变化”的题。

flowchart LR
    A[并发问题来了] --> B{要不要把临界区串起来?}
    B -->|要| C[锁路线]
    B -->|不要 先试原子更新| D[CAS 路线]

    C --> E[ReentrantLock / ReentrantReadWriteLock]
    E --> F[AQS 管 state + 排队 + 阻塞唤醒]
    C --> K[StampedLock]
    K --> L[乐观读需校验 且不支持重入]

    D --> G[AtomicInteger / AtomicLong / AtomicReference]
    G --> H{是否热点计数?}
    H -->|是| I[LongAdder 分散竞争再汇总]
    H -->|否| J[CAS 失败则重试或回退]

    style C fill:#e0f2fe,stroke:#0284c7
    style D fill:#fef3c7,stroke:#d97706
    style F fill:#f0fdf4,stroke:#16a34a
    style I fill:#f0fdf4,stroke:#16a34a
    style J fill:#fef2f2,stroke:#dc2626
    style L fill:#fef3c7,stroke:#d97706

60 线程池治理：背压、拒绝、优雅停机与监控

线程池治理不是“我会配几个参数”，而是要回答：任务高峰来了以后，线程、队列、拒绝、停机和监控怎样一起工作，既把吞吐撑起来，又不把系统自己拖垮。所以这题真正要讲的不是单个 API，而是一套过载控制链：任务来了，先怎么接；接不住时怎么退；服务要下线时怎么收；运行中又靠什么发现它快出问题了。

先把 6 个核心概念讲清

• 线程池治理是什么：ExecutorService 负责任务生命周期，ThreadPoolExecutor 是最常用实现；而“治理”讲的是把核心线程数、最大线程数、队列、拒绝策略、停机流程和监控指标一起纳入控制，让线程池在高峰期不是一味硬扛，而是按规则运行、退化和收尾。
• 参数联动为什么是主线：corePoolSize、maximumPoolSize、workQueue、keepAliveTime、threadFactory、handler 不是独立记忆点，而是在共同决定“任务来了以后，先开线程、先入队，还是直接拒绝”。只要这条路径讲清楚，后面的背压、扩容、拒绝和停机才有骨架。
• 背压是什么：当下游处理不过来时，系统必须让上游变慢、进入排队、触发拒绝或降级，而不是无限接单、把内存当缓冲区。换句话说，背压不是单独一个 API，而是系统在高压下把压力显式暴露出来的能力。
• 队列边界为什么关键：BlockingQueue（阻塞队列）决定任务是“先缓冲”还是“更早暴露压力”。无界队列看起来不容易拒绝，但任务会一直堆，最后把延迟和内存一起拖爆；有界队列虽然更早触发扩容或拒绝，却能让系统在高压下可控退化。
• 拒绝策略为什么不是小细节：饱和时由 RejectedExecutionHandler（拒绝执行处理器） 决定如何处理；CallerRunsPolicy 让上游变慢，形成天然限速；AbortPolicy 快速失败，让调用方立刻感知。它本质上不是“线程池行为”，而是业务在过载下怎样降级的入口。
• 优雅停机是什么：shutdown() + awaitTermination 的核心目标不是“把线程池关掉”，而是先停止接收新任务，再给在途任务一个排空窗口；只有确实收不住时，才会考虑 shutdownNow()，并配合中断协议让任务尽快退出。
• 监控闭环怎么看：线程池不能只看当前线程数，还要一起看 active、poolSize、queueSize、completedTask、rejectCount、任务等待时间和 P99（99 分位延迟）。只有这些指标和队列边界、拒绝策略、停机流程一起看，线程池才不是一个会跑的黑盒。

flowchart TD
    A[新任务提交] --> B{当前线程数
< corePoolSize?}
    B -->|是| C[创建新核心线程执行]
    B -->|否| D{队列已满?}
    D -->|否| E[任务入队等待]
    D -->|是| F{当前线程数
< maximumPoolSize?}
    F -->|是| G[创建非核心线程执行]
    F -->|否| H[触发拒绝策略]

    H --> I{RejectedExecutionHandler}
    I -->|AbortPolicy| J[抛异常：快速失败]
    I -->|CallerRunsPolicy| K[调用者线程执行：天然限速]
    I -->|DiscardPolicy| L[静默丢弃]
    I -->|DiscardOldestPolicy| M[丢弃队列最老任务后重试]

    E -.注意.-> N[无界队列风险：
延迟飙升 + OOM（Out Of Memory，内存溢出）]
    H -.注意.-> O[有界队列 + 拒绝 = 背压
让系统可控退化]

    style A fill:#f0fdf4,stroke:#16a34a
    style C fill:#e0f2fe,stroke:#0284c7
    style E fill:#e0f2fe,stroke:#0284c7
    style G fill:#e0f2fe,stroke:#0284c7
    style H fill:#fef3c7,stroke:#d97706
    style J fill:#fef2f2,stroke:#dc2626
    style K fill:#fef3c7,stroke:#d97706
    style L fill:#fef2f2,stroke:#dc2626
    style M fill:#fef3c7,stroke:#d97706
    style N fill:#fef2f2,stroke:#dc2626
    style O fill:#f0fdf4,stroke:#16a34a

61 CompletableFuture：编排 + 超时/取消/异常传播

CompletableFuture 可以先把它理解成“可编排的异步结果容器”：不仅能表示“结果将来才会回来”，还允许你把多个异步步骤串起来、并起来、超时收口、异常兜底。

先举个直觉例子

比如一个用户学习首页接口，打开页面时通常要同时查这几类数据：

• 用户基本信息
• 最近练习记录
• 错题统计
• 推荐题单

这几件事彼此独立，如果你一条一条顺序查，接口总耗时通常就是它们的总和；如果你把它们并发发起，再在最后统一汇总，整体耗时更接近最慢的那一路。这就是 CompletableFuture 最适合初学者先建立的直觉：不是“写异步 API”，而是“把可独立的慢步骤拆开并发，再在最后收回来”。

面试必答要点

• 先分清它解决什么问题：@Async 更像“把任务扔出去”，而 CompletableFuture 更像“把扔出去的多个异步结果再编排回来”。它最有价值的地方不是单步异步，而是串接、并发、汇总、超时和异常收口。
• 方法要按依赖形状理解：上一步结果决定下一步，用 thenCompose；两个任务彼此独立、最后合并，用 thenCombine；很多个一起发起、最后统一等待，用 allOf；谁先完成用谁，可以想到 anyOf / applyToEither。对初学者来说，这比死背方法名更重要。
• 默认执行器：不传 Executor 的异步阶段通常用 ForkJoinPool（Fork/Join 线程池）.commonPool()，阻塞 IO 混入会导致饥饿。
• 异常处理不要只记“传播”两个字：whenComplete 更像“看结果并记日志”，handle 更像“无论成功失败都接住并产出新值”，exceptionally 则是“只在失败时给兜底值”。这三者的角色不同，别混成一个异常回调。
• 超时与取消要分开讲：超时是 SLA（Service Level Agreement，服务等级协议）语义，避免请求无穷等待；取消是资源语义，表示停止继续浪费线程和计算资源。像 orTimeout 是“超时就异常完成”，completeOnTimeout 是“超时就给默认值”，两者不要混着讲。
• 线程池隔离：IO 密集与 CPU 密集分离；避免把所有异步都丢到同一个池。

flowchart TD
    请求[一份页面请求] --> 拆分[拆成多路独立异步任务]
    拆分 --> 用户信息[查用户信息]
    拆分 --> 练习记录[查最近练习]
    拆分 --> 错题统计[查错题统计]
    拆分 --> 推荐题单[查推荐题单]

    用户信息 --> 汇总[统一汇总结果]
    练习记录 --> 汇总
    错题统计 --> 汇总
    推荐题单 --> 汇总

    错题统计 -. 超时/异常 .-> 降级[给默认值或空数据]
    降级 --> 汇总
    汇总 --> 返回[返回一份完整响应]

61A CompletableFuture 高级编排：thenCombine / allOf / 依赖聚合

如果说 61 解决的是“先把 CompletableFuture 看懂、知道为什么要用”，那这一小节就是继续往前走：当你已经能区分“串起来”“并起来”“最后收回来”之后，才需要进一步分清 thenCompose、thenCombine、allOf 这些方法各自适合哪种依赖关系。

面试必答要点

• thenCombine：适合“两条独立异步链都完成后再合并结果”的场景，例如“同时查成绩统计 + 卡片状态，再生成用户学习面板”。
• allOf：适合并行等待多路任务全部完成后统一收口，但它本身不聚合返回值；实际项目里通常要配合 join() / 收集列表再做结果拼装。
• 避免嵌套 Future：上一步结果决定下一步还要发起异步调用时，用 thenCompose 而不是 thenApply 返回另一个 Future，否则会出现 CompletableFuture<CompletableFuture<T>> 的嵌套地狱。
• 不要滥用串行 join：很多人表面上写了异步，最后却 a.join(); b.join(); c.join(); 串行等待，真正的价值就打折了。正确思路是先并发启动，再统一收口。
• 线程池容量必须受控：高并发下如果把海量 CompletableFuture 任务丢进默认执行器，或挂到基于无界 LinkedBlockingQueue 的线程池，本质上是在把内存当缓冲区；线上更稳的做法是显式传入有界队列 + 拒绝策略的自定义线程池。
• 项目视角：交卷后并发计算统计、更新卡片、发送站内信、生成错题解析摘要，这类“多任务并行 + 部分依赖聚合”的场景，正是 thenCombine + allOf + exceptionally 的典型用法。

62 上下文传递：ThreadLocal / MDC / SecurityContext / Reactor Context（Reactor 上下文）

这组概念最容易让初学者困惑的地方在于：主线程里明明能拿到的值，为什么到了异步线程、线程池或 WebFlux 链路里就没了，甚至还会串到别人请求上。它们本质上都在回答同一个问题：请求级上下文（traceId、登录用户、认证信息、请求标签）到底跟着什么走，是跟着线程走，还是跟着异步链路走。

先举个直觉例子

比如一个请求进来后，你在入口线程里拿到了：

• traceId：用于串联日志
• 当前登录用户：用于权限判断
• 请求级标签：用于灰度或审计

如果后面只是同步调用，这些值通常都还能拿到；但一旦切到 @Async、线程池、CompletableFuture 或 WebFlux，线程边界就变了。此时最关键的判断不是“我能不能继续 get 值”，而是：这类上下文默认会不会自动跟过去，如果不会，应该靠什么传播，结束时又该怎么清理。

面试必答要点

• ThreadLocal（线程本地变量）的两面性：方便但危险：线程池复用会导致“脏上下文”泄漏到下一次任务。
• MDC（Mapped Diagnostic Context，映射诊断上下文）/traceId：默认依赖 ThreadLocal，跨线程会丢；应在任务提交/执行阶段捕获与恢复，并在 finally 清理。
• SecurityContext（安全上下文）：默认 ThreadLocal；异步线程需要包装 Executor（DelegatingSecurityContext*）才能拿到认证信息。
• WebFlux：线程会切换，ThreadLocal 不可靠；用 Reactor Context（Reactor 上下文） Context（contextWrite/deferContextual）传播。
• event-loop（事件循环线程）禁忌：严禁在非阻塞线程上 block()；必要阻塞调用应迁移到 boundedElastic（有界弹性调度器）。
• Spring 落地：用线程池的 TaskDecorator（例如 ContextPropagatingTaskDecorator）做 MDC/Tracing 上下文捕获与恢复，避免链路断裂。

62A ThreadLocal 内存泄漏陷阱：为什么必须 finally remove()

这题真正要理解的不是一句“记得 remove()”，而是：为什么 ThreadLocal 在线程池里会从“方便”变成“危险”。只要你把“线程不会跟着请求一起销毁，而是会被线程池反复复用”这件事想明白，后面的串台、脏上下文、内存占用都能顺着推出来。

面试必答要点

• 根因：线程池里的线程不会随着一次请求结束而销毁，下一次任务可能复用同一线程。如果上一次放进 ThreadLocal 的值没清掉，下一次任务就可能读到别人的上下文。
• 为什么会像“内存泄漏”？ThreadLocalMap 里的值跟线程生命周期绑定。在线程长期存活的线程池里，这些对象可能长时间不释放，尤其当值对象本身又引用了大对象时，问题更明显。
• 标准姿势：set() 之后必须在 finally 里 remove()，而不是指望方法正常返回时自然释放。异常、超时、中断场景都必须能清理。
• 不要误会 InheritableThreadLocal（可继承线程本地变量）：它解决的是“子线程继承初始值”，不是线程池上下文隔离；线程池复用线程时，它反而更容易带来诡异串值。
• 工程化落地：优先用 TaskDecorator、DelegatingSecurityContext、MDC 包装器、Reactor Context 这类“可控传播 + 自动清理”的方式，而不是到处手写裸 ThreadLocal。

flowchart TD
    请求A[请求 A 进入] --> 线程1[线程池复用线程 T1]
    线程1 --> setA[ThreadLocal set 用户A / traceId-A]
    setA --> 执行A[执行任务 A]
    执行A --> 忘清理[忘记 remove]

    忘清理 --> 请求B[请求 B 进入]
    请求B --> 仍用线程1[再次复用线程 T1]
    仍用线程1 --> 读旧值[读到上一次残留值]
    读旧值 --> 串台[日志串号 / 用户上下文串台]

    忘清理 -. 长期持有大对象 .-> 占用[对象迟迟不释放]
    占用 --> 风险[长期内存占用风险]

63 死锁/活锁/饥饿与排障（Thread Dump，线程转储）

这一题对初学者最难的地方，不是背出“死锁 / 活锁 / 饥饿”三个词，而是看到系统卡住时，到底先看哪里，怎么从 Thread Dump 一步步判断出是锁竞争、主动等待，还是线程根本没有在真正工作。所以这张卡最该补的不是更多名词，而是一条排障顺序。

先举个直觉例子

比如线上某个接口突然变慢，CPU 不一定很高，但请求大量超时。你抓了一份 Thread Dump（线程转储：把当前 JVM 里所有线程状态打印出来用于排查），这时最容易懵的是：这么多线程名、这么多栈，到底先看什么？初学者最稳的顺序通常是：

1. 先看是不是有大量线程卡在同一种状态
2. 再看这些线程是在等锁、等通知，还是等下游返回
3. 最后结合线程池队列长度、拒绝数、P99 去判断“是卡死了，还是只是慢得厉害”

面试必答要点

• 死锁：循环等待；预防靠锁顺序、分层锁、tryLock(timeout)、缩小锁粒度。
• 饥饿/活锁：线程一直抢不到资源或忙于互相让步；关注公平性与退避策略。
• Thread Dump 读法：BLOCKED 看锁竞争；WAITING 看 park/wait/join；结合“线程池队列长度/拒绝数/P99（99 分位延迟）”定位瓶颈（线上排障常用关键字：thread dump）。