面试官资深架构师“坤哥欢迎参加本次高阶 Java 面试。我们直接进入正题。首先你在简历里提到了 Spring AI 在企业级私有知识库助手中的应用能聊聊你是怎么落地的吗”坤哥“好的我们项目是一个基于 RAG检索增强生成架构的私有知识库助手核心链路是用户提问 → 向量数据库检索 → LLM 生成答案。我们用 Spring AI 封装了 OpenAI 和本地模型的调用通过Document注解做文档切分再用VectorStore对接 Milvus 实现相似度搜索。”面试官点头“听起来流程清晰。那你们怎么处理 Prompt 调优有没有遇到过 Context Window 超限的问题”坤哥笑了笑“当然遇到过。我们一开始直接用原始问题 全部检索结果拼 Prompt结果经常超 4K token。后来我们做了两件事一是对检索结果做摘要压缩二是引入动态窗口策略——根据问题复杂度自动调整上下文长度。比如简单问题只保留 top-1 文档片段复杂问题才加载 top-3。”面试官追问“动态窗口策略听起来不错但怎么保证摘要质量有没有评估指标”坤哥稍作停顿“我们用了 ROUGE 和人工评分双轨制。ROUGE 看关键词覆盖人工评分看语义完整性。另外我们还加了一个 fallback 机制如果摘要后答案准确率下降超过 5%就切回原始片段。”面试官“有考虑过 Agentic 工作流吗比如让 LLM 自主决定是否需要多次检索或调用工具”坤哥眼睛一亮“这个我们 MVP 阶段试过用 ReAct 模式让模型自己规划步骤。但发现两个问题一是响应延迟增加 300ms 以上二是模型容易‘幻觉’执行路径。最后我们折中了一下改成‘半自主’模式——系统预定义几种常见任务模板模型只选择模板不生成执行逻辑。”面试官露出赞许神色“务实的选择。那接下来我们换个方向聊聊分布式事务。你们知识库涉及多数据源同步比如 MySQL 存元数据Elasticsearch 存索引怎么保证一致性”坤哥“我们用的是 Seata 的 AT 模式。MySQL 作为主库ES 通过监听 binlog 异步更新。关键是在GlobalTransactional注解下把 ES 操作也纳入事务上下文失败时触发反向补偿。”面试官立刻追问“AT 模式依赖 undo_log你们有没有遇到过 undo_log 表膨胀的问题线上怎么监控”坤哥愣了一下“呃……这个我们确实没深入监控。目前是每天凌晨 truncate 一次 undo_log 表。”面试官皱眉“truncate 是高危操作如果 truncate 时还有未提交事务会导致数据不一致。更稳妥的做法是用定时任务分批 delete并且要配合全局锁避免并发问题。”坤哥点头“您说得对我们后续会加上 delete 策略和监控告警。”面试官继续深入“那如果 Seata Server 宕机你们的业务会怎样有没有降级方案”坤哥“Seata Server 挂了AT 模式会自动降级为本地事务。但跨库操作就会丢一致性。所以我们加了本地消息表 定时任务补偿确保最终一致性。”面试官“消息表怎么设计幂等怎么处理”坤哥“消息表有 status、retry_count、next_retry_time 字段。消费者用唯一业务 ID 做幂等键配合 Redis 分布式锁防止重复消费。重试策略是指数退避最多重试 5 次。”面试官“Redis 锁过期时间怎么设有没有考虑时钟漂移”坤哥“我们设了 30 秒但确实没考虑时钟漂移……通常认为影响不大。”面试官摇头“在高并发场景下时钟漂移可能导致锁提前释放引发重复消费。建议用 Redlock 或改用数据库乐观锁。”坤哥擦了擦汗“明白了这块我们确实疏忽了。”面试官话锋一转“回到 Spring 本身。你们用 Spring Boot 自动装配了很多组件能说说EnableAutoConfiguration的原理吗”坤哥“它通过SpringFactoriesLoader加载META-INF/spring.factories里的配置类再根据Conditional注解判断是否注入 Bean。比如DataSourceAutoConfiguration会在 classpath 有 HikariCP 且未手动配置 DataSource 时生效。”面试官“那如果我想禁用某个自动配置除了 exclude 属性还有别的方法吗”坤哥“可以在 application.yml 里设置spring.autoconfigure.exclude或者用ConditionalOnMissingBean自己定义同名 Bean 覆盖。”面试官“如果多个自动配置类都满足条件加载顺序怎么定”坤哥卡壳了“这个……应该是按字母顺序或者依赖Order注解”面试官“错。Spring Boot 用AutoConfigureOrder和AutoConfigureAfter/Before控制顺序不是字母序也不是Order。Order只影响 Bean 初始化顺序不影响自动配置类加载。”坤哥苦笑“这块确实没源码级理解。”面试官继续施压“那说说循环依赖。你们项目里有没有遇到Spring 怎么解决的”坤哥“遇到过。比如 A 依赖 BB 依赖 A。Spring 用三级缓存解决singletonObjects、earlySingletonObjects、singletonFactories。在 Bean 创建早期就把 ObjectFactory 放进三级缓存其他 Bean 需要时提前暴露引用。”面试官“那为什么需要三级两级不行吗”坤哥思考片刻“因为 AOP。如果只用两级提前暴露的是原始对象但后续可能被代理包装。三级缓存的 ObjectFactory 可以保证每次 getObject() 都返回最新代理对象。”面试官点头“正确。那如果 Bean 是 prototype scopeSpring 还会解决循环依赖吗”坤哥“不会。prototype 每次都是新实例无法提前暴露所以 Spring 直接抛异常。”面试官“很好。最后问个 JVM 问题。你们线上 Full GC 频繁怎么排查”坤哥“先用jstat -gcutil看 GC 频率和内存分布再用jmap -dump:formatb,fileheap.hprof导出堆转储用 MAT 分析大对象。常见原因是内存泄漏比如静态集合没清理或者线程池未关闭导致线程堆积。”面试官“那如果 dump 文件太大服务器磁盘不够怎么办”坤哥“可以用jmap -histo:live在线分析对象数量或者用 Arthas 的heapdump命令指定只 dump 存活对象。”面试官“Arthas 的 heapdump 底层也是调用 jmap只是做了封装。不过思路是对的。”面试官看了看时间“时间差不多了。坤哥你整体基础扎实尤其在业务落地层面有思考但在一些底层机制和极端场景处理上还有提升空间。比如 Seata 的 undo_log 管理、自动配置加载顺序、时钟漂移对分布式锁的影响这些都需要再深挖。”坤哥起身“谢谢您的指导我回去一定补上这些盲点。”面试官微笑“回去等通知吧。”技术补丁包1. Spring AI 与 RAG 架构落地要点Prompt 调优避免直接拼接原始检索结果采用摘要压缩 动态上下文窗口策略。Context Window 管理根据问题复杂度动态调整输入长度设置 fallback 机制保障准确率。Agentic 工作流取舍ReAct 模式虽灵活但延迟高、易幻觉企业级场景建议采用“半自主”模板化方案。风险提示LLM 输出不可控务必加入内容安全过滤和人工审核兜底。2. 分布式事务与 Seata AT 模式深度解析undo_log 管理禁止直接 truncate应使用分批 delete 全局锁避免未提交事务被误清。Seata Server 容灾AT 模式降级为本地事务需配套本地消息表 定时补偿实现最终一致性。消息幂等设计唯一业务 ID Redis 分布式锁注意设置合理过期时间防范时钟漂移或改用数据库乐观锁。重试策略指数退避 最大重试次数限制避免雪崩。3. Spring Boot 自动装配原理与循环依赖自动配置加载顺序由AutoConfigureOrder和AutoConfigureAfter/Before控制非字母序或Order。循环依赖解决方案三级缓存singletonObjects、earlySingletonObjects、singletonFactories支持 AOP 代理对象提前暴露。prototype 作用域限制不支持循环依赖因无法提前暴露实例。源码关键类DefaultListableBeanFactory、AbstractAutowireCapableBeanFactory、DefaultSingletonBeanRegistry。4. JVM 线上排查实战技巧GC 监控命令jstat -gcutil pid 1000实时查看 GC 情况。堆转储优化磁盘不足时用jmap -histo:live在线分析或 Arthas 的heapdump --live减少 dump 体积。常见内存泄漏点静态集合、未关闭线程池、ThreadLocal 未 remove、缓存无过期策略。工具链推荐MATMemory Analyzer Tool、VisualVM、Arthas、GCViewer。5. 分布式锁的时钟漂移问题问题本质Redis 锁依赖系统时间若客户端时钟快于服务器可能导致锁提前失效。解决方案使用 Redlock 算法需多节点部署改用数据库乐观锁version 字段锁过期时间设置冗余如业务最大执行时间 × 2避免依赖系统时间做关键逻辑判断。本次面试虽以“回去等通知”收尾但技术交锋中暴露的盲点正是进阶架构师的必经之路。夯实底层、敬畏生产方能在高并发、高可用的复杂系统中游刃有余。