AI+Java中级开发面试题库
生成时间：2026-05-20 22:42 轮次标记：cron-7ea7589e 第N轮
【面试题】1. RAG系统中检索召回率低怎么优化？请从多维度给出方案。
【标准答案】 RAG召回率低，我一般从三个层面优化：第一，分块策略——不要无脑按固定token切，用语义分块（按段落/标题切）或递归分块，保证上下文完整；第二，检索策略——单路向量检索容易漏，换成混合检索（向量+BM25关键词），两者互补，向量抓语义相似、BM25抓精确匹配，再RRF融合排序；第三，Query改写——用户问题往往模糊或太短，用LLM做Query Expansion或HyDE（让模型先假装生成一个答案，拿这个答案去检索），能显著提升召回。如果还不够，考虑加一层重排序（Reranker），用交叉编码器对粗筛结果精排。实际项目里，混合检索+Rerank是最性价比高的组合。
【面试题】2. Java中synchronized和ReentrantLock本质区别是什么？什么场景用哪个？
【标准答案】 本质区别在三个维度：实现层面，synchronized是JVM层面的关键字，通过monitorenter/monitorexit字节码指令实现；ReentrantLock是JDK层面的API，基于AQS（AbstractQueuedSynchronizer）实现。功能层面，ReentrantLock支持公平锁、可中断锁、多条件变量（Condition）、超时获取锁（tryLock with timeout），synchronized都不支持。使用层面，synchronized自动释放锁（退出同步块即可），ReentrantLock必须手动unlock且要放finally里。选型建议：简单同步用synchronized，够用就别加复杂度，JDK6之后synchronized做了锁升级优化（偏向锁→轻量级锁→重量级锁），性能不差；需要高级特性时用ReentrantLock——比如要公平锁、要tryLock避免死锁、要多个Condition做精确唤醒。一句话：能用synchronized就synchronized，满足不了需求再上ReentrantLock。
【面试题】3. Spring AI和LangChain各自的定位和适用场景是什么？
【标准答案】 LangChain是Python生态的AI应用开发框架，核心是链式调用（Chain）和丰富的工具生态（Tool/Agent/Memory），适合快速原型验证和AI-native项目，Python生态的模型支持最全。Spring AI是Java/Spring生态的AI框架，核心设计理念是对齐Spring的编程模型——用Bean注入模型、用自动配置屏蔽细节、用统一的Model API（ChatModel/EmbeddingModel）抽象不同厂商，让Java开发者像用Spring MVC一样用AI。选型逻辑：团队以Java为主、已有Spring Boot项目 → Spring AI，无缝集成，不用跨语言；团队AI研究属性强、需要最新模型和工具链 → LangChain，生态更丰富。实际中也可以混合：Java业务层用Spring AI，数据处理/模型实验用Python+LangChain，通过API对接。
【面试题】4. JVM垃圾回收中，CMS和G1的核心差异是什么？生产环境怎么选？
【标准答案】** 核心差异：目标不同，CMS追求最低停顿，G1追求停顿时间可预测且可控。算法不同，CMS用标记-清除，老年代会产生内存碎片，达到一定条件要做Full GC（整理碎片），那次停顿很长；G1把堆分成固定大小Region，用标记-复制，回收时选择价值最高的Region集合（Mixed GC），天然避免碎片。适用堆大小不同，CMS适合6G以下，G1适合6G以上大堆。调优难度不同，CMS调优参数多且容易踩坑（浮动垃圾、concurrent mode failure），G1只需设-XX:MaxGCPauseMillis=200基本够用。生产环境选型：JDK8默认CMS，JDK9开始默认G1。现在新项目直接G1，6G以上堆必选G1。如果停顿要求极致（几十毫秒），上ZGC（JDK15+生产可用）。
【面试题】5. AI Agent中ReAct模式和Function Calling模式各自的原理和适用场景？
【标准答案】** ReAct（Reasoning+Acting）模式：LLM先推理（Thought），再决定执行动作（Action），观察结果（Observation），循环直到得出最终答案。核心是模型自主规划多步骤，像人一样思考-行动-观察。优点是灵活、能处理复杂多步任务；缺点是token消耗大、延迟高、可能循环不终止。Function Calling模式：预定义一组函数描述（名称、参数、返回值），LLM一次调用决定调用哪个函数+参数，由宿主代码执行后返回结果，LLM再生成最终回答。核心是单轮决策，快速高效。适用场景：简单查询、单步工具调用 → Function Calling，快且省token；复杂推理、多步规划、需要动态决定下一步 → ReAct。实际项目中最常见的做法是Function Calling作为ReAct的执行层——ReAct负责规划，每步的Action通过Function Calling执行，两者结合。
【面试题】6. MySQL中联合索引的最左前缀原则是什么？常见踩坑有哪些？
【标准答案】** 最左前缀原则：联合索引(a,b,c)，查询条件必须从左到右依次使用才能走索引。等值查询时可以跳跃中间列（但跳过的列之后的列用不上索引），范围查询之后的列全部失效。常见踩坑：第一，WHERE b=1 AND c=2 走不到索引——缺了最左列a；第二，WHERE a=1 AND c=2 只能用到a列索引，b列断了后面全废；第三，WHERE a>1 AND b=2，a的范围查询导致b用不上索引；第四，索引列上做函数操作，如WHERE YEAR(create_time)=2024，索引失效，要改写为WHERE create_time>='2024-01-01' AND create_time<'2025-01-01'；第五，隐式类型转换，如a是varchar但查WHERE a=123，MySQL会把a转数字，索引失效。面试中重点讲清范围查询截断和函数/类型转换这两个坑就够了。
【面试题】7. 向量数据库（如Milvus/Pinecone）的核心索引类型有哪些？各适合什么场景？
【标准答案】** 核心索引三大类：第一，FLAT（暴力扫描）——精确但慢，适合数据量小（百万以内）或要求100%召回率的场景。第二，IVF（倒排索引）——先对向量聚类（如K-Means），查询时只搜索最近的n个簇，速度和召回率的平衡，适合千万级数据，需要调nprobe参数。IVF又有变体：IVF_FLAT（簇内暴力）、IVF_PQ（簇内做乘积量化压缩，省内存但精度降）。第三，HNSW（层次可导航小世界图）——基于图的近似最近邻，查询速度极快、召回率高，但内存占用大、构建慢，适合实时性要求高且内存充裕的场景。选型建议：百万级+要求精度 → FLAT或IVF_FLAT；千万级+内存敏感 → IVF_PQ；千万级+低延迟要求 → HNSW。Milvus还支持DISKANN（磁盘索引），适合超大规模数据内存装不下的场景。
【面试题】8. Redis分布式锁用SETNX实现有什么问题？Redlock方案解决了什么、又引入了什么争议？
【标准答案】** SETNX简单实现的问题：第一，锁过期但业务未完成——客户端A拿锁后执行慢，锁自动过期，B拿到锁，A执行完误删B的锁。解决：value设唯一标识（UUID），删锁时Lua脚本校验是不是自己的锁再删。第二，非重入——同一线程拿两次锁会死锁。第三，单点故障——Redis主节点挂了，锁状态丢失。Redlock方案：向N个独立Redis实例同时加锁，超过半数成功且总耗时小于锁过期时间才算成功，解决单点问题。但争议很大：Martin Kleppmann批评说Redlock依赖系统时钟，时钟跳变会导致锁安全性被破坏，且网络分区场景下仍可能出问题，他建议用fencing token（单调递增token）做资源访问控制。Antirez反驳说实际场景中时钟漂移很小、fencing token也需要资源端配合。实际建议：单Redis实例+合理过期时间+Lua释放覆盖90%场景；强一致性要求用ZooKeeper/etcd；Redlock在中间地带，但要理解其局限。
【面试题】9. 大模型微调中LoRA和全量微调的区别和选择策略？
【标准答案】** 全量微调（Full Fine-tuning）：更新模型所有参数，效果好但成本高——7B模型全量微调需要约28GB显存（FP16），还得存优化器状态，实际需要多卡。LoRA（Low-Rank Adaptation）：冻结原始权重，在每层旁路加低秩矩阵A×B（如768×8×768），只训练这些小矩阵，参数量通常是原模型的0.1%~1%，7B模型单卡24G就能跑。效果对比：大部分场景LoRA达到全量微调90%+的效果，特别是指令跟随、风格适配等场景差距很小；但领域知识密集型任务（如医学、法律从零学），全量微调仍有优势。选择策略：资源有限/快速迭代/多任务适配 → LoRA；数据量极大/领域知识缺口大/效果优先 → 全量微调。实操建议：先LoRA跑一版看效果，不够再考虑全量；LoRA的r值（秩）一般8~64，数据少用小r，数据多用大r；学习率LoRA通常比全量微调大5~10倍。还有QLoRA（4bit量化+LoRA），进一步降显存，16G卡跑65B模型不是梦。
【面试题】10. 分布式系统中CAP定理和BASE理论如何指导架构设计？举个实际例子。
【标准答案】** CAP定理：分布式系统无法同时满足一致性（C）、可用性（A）、分区容错性（P），网络分区必然存在所以P必选，只能在C和A之间二选一。BASE理论是对CAP中AP方向的实践指导：Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）。架构指导：不是整个系统一刀切选C或A，而是按业务场景分区决策。举例——电商系统：订单创建必须强一致（CP），库存扣减和订单创建要在同一个事务里，宁可让用户等也不能超卖；商品搜索可以最终一致（AP），商品信息更新后搜索索引延迟几秒生效没关系，但搜索服务不能挂；购物车用最终一致（AP），Redis做主存异步同步到DB，偶尔丢个更新用户能接受。实际落地的关键模式：CP场景用分布式事务（Seata AT模式/TCC）；AP场景用消息队列做异步最终一致（本地消息表+MQ投递）；混合场景用CQRS——写走强一致，读走最终一致。