本轮 AI+Java中级开发面试题库（带答案）
【面试题】1. 请解释Transformer架构中的自注意力机制（Self-Attention）原理，以及在BERT和GPT模型中的区别是什么？
【标准答案】自注意力机制的核心是计算序列中每个token与其他所有token的相关性。具体来说，通过Q（Query）、K（Key）、V（Value）三个矩阵，计算注意力分数：Attention(Q,K,V) = softmax(QK^T/√d_k)V。这样做的好处是能够捕获长距离依赖关系，不管两个词在句子中距离多远，都能建立直接联系。
BERT用的是双向自注意力，模型可以同时看到左边和右边的上下文，适合理解类任务如文本分类、命名实体识别。GPT用的是单向自注意力（也叫masked self-attention），只能看到当前token左边的上下文，适合生成类任务，因为生成时不能提前看到后面的内容。简单说，BERT是"看全局"，GPT是"看历史"。
【面试题】2. Java中ConcurrentHashMap在JDK 1.7和JDK 1.8有什么区别？为什么这么改？
【标准答案】JDK 1.7采用分段锁（Segment）机制，把数据分成多个段，每个段有一把独立的ReentrantLock，并发操作时只锁住对应的段。但问题是并发度受段数限制，而且Segment继承ReentrantLock比较重。
JDK 1.8放弃了分段锁，改用CAS + synchronized锁单个Node的方式。当hash冲突时，用CAS尝试插入；冲突严重形成链表或红黑树时，用synchronized锁住头节点。这样做的优势：一是锁粒度更细，并发度更高；二是synchronized在JDK 1.6后做了大量优化，性能不输ReentrantLock；三是内存占用更小，不需要维护Segment数组。同时，当链表长度超过8时转红黑树，查询从O(n)变成O(log n)，进一步优化性能。
【面试题】3. 在RAG系统中，向量检索的召回率不高怎么办？有哪些优化策略？
【标准答案】这是实际项目中很常见的问题。我通常会从几个维度优化：
第一，embedding模型的选择和微调。通用模型在垂直领域效果不好，可以用领域数据微调embedding模型，或者换用更适合中文的模型如BGE、M3E。
第二，检索策略优化。单路检索不够就上多路召回，比如关键词检索（BM25）+ 向量检索 + 稀疏检索混合，最后做RRF融合排序。还可以做Query改写，用户原始query可能表述不清，用LLM重写或扩展成多个相关query并行检索。
第三，索引层面优化。调小向量维度（用PCA降维），或者用分层索引先粗筛再精排。分块策略也很关键，chunk size太大检索精度低，太小上下文不足，可以试试滑动窗口或语义分块。
第四，后处理优化。加一层重排序模型（re-ranker）对召回结果精排，或者用LLM判断文档相关性，过滤掉不相关的chunk。
【面试题】4. Spring Boot中@Async注解失效的常见原因有哪些？如何正确使用异步调用？
【标准答案】@Async失效主要有几个坑：
第一，没有开启异步支持。需要在配置类上加@EnableAsync注解，否则@Async就是摆设。
第二，同类内部调用。Spring AOP基于代理，同一个类中方法A调用方法B，绕过了代理，@Async不会生效。解决办法是把异步方法抽到另一个Bean，或者自己注入自己调用。
第三，方法不是public。代理只能拦截public方法，private/protected方法上的@Async直接失效。
第四，返回值问题。异步方法要么返回void，要么返回Future或CompletableFuture。如果直接返回业务对象，调用方拿不到结果，异步也失去了意义。
正确用法：配置线程池（不配置会用默认SimpleAsyncTaskExecutor，每次新建线程很危险），设置合理的拒绝策略和异常处理。推荐自定义ThreadPoolTaskExecutor，通过@Async("myExecutor")指定线程池。
【面试题】5. 请解释LangChain中Chain和Agent的区别，什么时候用哪个？
【标准答案】Chain是固定流程的执行链，每一步都预先定义好，输入→处理1→处理2→输出，适合任务流程明确的场景。比如文档问答：加载文档→切分→向量化→检索→生成答案，这个流程固定，用Chain实现最合适。
Agent是有决策能力的执行单元，它会根据输入自主选择工具、决定下一步做什么。Agent内部有个循环：思考→选工具→执行→观察结果→再思考，直到得到最终答案。适合任务流程不确定、需要动态规划的场景。比如一个智能客服，用户可能问天气、订票、查订单，Agent要根据问题类型选择不同的工具。
简单说，流程固定用Chain，流程不确定需要决策用Agent。实际项目中，很多场景是Chain和Agent组合使用，比如用Chain做预处理和后处理，核心决策部分用Agent。
【面试题】6. Redis实现分布式锁有哪些方案？各自的优缺点是什么？
【标准答案】最常用的是setnx + 过期时间，一条命令完成：SET key value NX PX 30000。优点是简单可靠，Redis单线程保证原子性。但有问题：如果业务执行时间超过锁过期时间，锁会自动释放，其他线程获得锁，导致并发安全问题。
第二是Redlock算法，Redis官方推荐的多节点方案。在多个Redis实例上同时加锁，超过半数成功才算加锁成功。优点是解决了单点故障问题，缺点是实现复杂，网络分区时仍有争议。
第三是Redisson框架，封装了看门狗机制（自动续期），业务没执行完锁不会过期。还支持可重入锁、读写锁、红锁等高级特性。生产环境推荐用Redisson，但要注意加锁解锁的原子性，用lua脚本保证。
实际选型：单机或主从架构用Redisson即可；对可靠性要求极高用Redlock；简单场景setnx够用，但要处理好续期和异常释放的问题。
【面试题】7. 什么是Prompt Engineering中的Few-shot和CoT？在实际项目中如何应用？
【标准答案】Few-shot就是在提示词里给几个示例，让模型理解你要什么样的输出。比如情感分类任务，给三个标注好的例子："好评:这款产品很棒→正面"，模型就能按照这个格式输出。好处是不用微调模型，几条示例就能显著提升效果，特别适合数据量少、需要快速迭代的场景。
CoT是思维链，让模型"一步一步思考"。比如数学推理题，不要直接问答案，而是问"请一步步分析这道题"，模型会把推理过程写出来，准确率大幅提升。OpenAI的论文显示，CoT能让GSM8K数据集准确率从17%提升到58%。
实际项目中两者经常组合使用：Few-shot提供格式示例，CoT引导推理过程。比如我之前做的合同审查系统，给了5个审查案例（Few-shot），然后让模型"逐条分析合同条款的风险点"（CoT），召回率提升了30%多。关键技巧是示例要典型、覆盖边界情况，思维链要引导模型关注关键要素。
【面试题】8. MySQL索引什么情况下会失效？如何避免？
【标准答案】索引失效的常见情况：
第一，最左前缀原则违反。复合索引(a,b,c)，查询条件只有b或c，索引用不上。必须从最左列开始，可以部分匹配但不能跳过。
第二，对索引列做函数操作。WHERE YEAR(create_time) = 2024，函数作用在索引列上，索引失效。改成范围查询：WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31'。
第三，隐式类型转换。字段是varchar，查询用数字：WHERE phone = 13800138000，MySQL会做类型转换，索引失效。要保证类型一致，加引号。
第四，LIKE以通配符开头。WHERE name LIKE '%张%'，前面有%索引失效。如果是'张%'可以用索引。可以用全文索引或搜索引擎解决。
第五，OR条件中有一个字段没索引。WHERE a = 1 OR b = 2，如果b没索引，整个索引都失效。可以拆成UNION或给b加索引。
第六，IS NULL或IS NOT NULL在某些情况下不使用索引，取决于数据分布。如果null值太多，优化器会判断全表扫描更快。
避免方法：用EXPLAIN分析执行计划，看key字段是否命中索引；设计索引时考虑查询模式；避免在索引列上做计算。
【面试题】9. 如何评估一个大模型在特定业务场景下的效果？有哪些关键指标？
【标准答案】评估大模型效果分几个维度：
首先是任务相关的核心指标。生成任务用BLEU、ROUGE、困惑度（PPL）；分类任务用准确率、F1分数；问答任务用EM（精确匹配）、F1；对话任务可以用人类评估或多轮一致性。
其次是业务指标。如果是RAG系统，关注检索召回率、答案准确率、引用命中率；如果是Agent，关注任务完成率、工具调用准确率、平均交互轮数。这些比学术指标更重要。
然后是成本和性能指标。延迟（首token时间、总生成时间）、吞吐量（QPS）、成本（token消耗）、错误率。这些决定了能不能上线。
最后是安全性和稳定性。幻觉率（生成错误信息的比例）、有害内容生成率、对抗攻击鲁棒性。
实际做法：先在小规模测试集上评估核心指标，人工review100-200条样本；然后用AB测试对比线上效果；最后持续监控生产环境指标。评估集要定期更新，避免模型过拟合测试集。
【面试题】10. Spring Cloud中服务雪崩是什么？有哪些防护机制？
【标准答案】服务雪崩是微服务架构中典型的级联故障：一个服务挂了，调用方请求堆积超时，线程池耗尽，导致调用方也挂了，像多米诺骨牌一样向上下游蔓延。
防护机制有几个层面：
第一，熔断器（Circuit Breaker）。当错误率达到阈值，直接熔断返回fallback，不再调用下游。用Resilience4j或Sentinel实现，有三种状态：关闭（正常调用）→打开（直接拒绝）→半开（试探性恢复）。
第二，降级策略。服务不可用时返回兜底数据，比如推荐服务挂了，返回热门商品列表。降级可以是自动的（熔断后触发），也可以是手动的（大促前主动关闭非核心功能）。
第三，限流。限制QPS，防止突发流量打垮服务。可以用令牌桶、漏桶算法，或者Sentinel的QPS限流。注意区分服务总限流和对每个调用方的限流。
第四，超时控制。设置合理的连接超时和读超时，避免线程长时间阻塞。一般连接超时短一点（100ms），读超时根据业务RT设置，建议是P99的2-3倍。
第五，隔离策略。线程池隔离或信号量隔离，一个服务的故障不会耗尽整个应用的线程资源。Hystrix默认线程池隔离，Sentinel支持两种。
实际项目中，这些机制组合使用：限流防突发→熔断防级联→降级保可用→超时防阻塞→隔离防资源耗尽。还要做好监控告警，提前发现问题。