工作知识库

Appearance

AI+Java中级开发面试题库 ​

生成时间：2026-05-24 21:02

【面试题】1. 什么是注意力机制？为什么Transformer架构中的Self-Attention比RNN更适合处理长序列？ ​

【标准答案】注意力机制本质上是一种权重分配策略，让模型在处理每个位置时能动态关注到输入中最相关的部分。

Transformer的Self-Attention相比RNN有几个关键优势：

  • 并行计算：RNN必须序列处理，Transformer所有位置同时计算，训练效率高出数量级
  • 长距离依赖：RNN的长距离信息会衰减，Self-Attention任意两个位置直接相连，距离为1，不存在梯度消失问题
  • 全局视野：每个token都能直接看到整个序列，不存在信息瓶颈

实际项目中，我用BERT处理长文档分类，RNN这类任务根本跑不通。这就是为什么现在大模型基本都用Transformer架构。

【面试题】2. Spring Boot的自动装配原理是什么？如何自定义Starter？ ​

【标准答案】Spring Boot自动装配核心是@EnableAutoConfiguration注解，它通过@Import导入AutoConfigurationImportSelector，这个类会扫描所有jar包下的META-INF/spring.factories文件，把里面配置的自动配置类加载到IOC容器。

但不是所有配置类都会生效，每个配置类上有条件注解，比如@ConditionalOnClass、@ConditionalOnMissingBean，只有满足条件才装配。

自定义Starter的步骤：

  1. 创建一个模块，命名规范是xxx-spring-boot-starter
  2. 写一个配置类，用@Configuration标注
  3. 在resources/META-INF/spring.factories里配置EnableAutoConfiguration=你的配置类
  4. 如果需要配置属性，创建一个@ConfigurationProperties类

我们项目里自定义过Redis分布式锁的Starter，业务方引入依赖就能直接用@DistributedLock注解。

【面试题】3. RAG中的Chunking策略有哪些？如何选择合适的分块大小？ ​

【标准答案】RAG分块策略主要有几种：

按固定长度切分：简单粗暴，比如每500字符一块，但容易切断语义。

按段落/句子切分：保持语义完整性，比如用换行符或句号分割，但块大小不均匀。

滑动窗口切分：有重叠区域，比如每块500字符，重叠100字符，保证上下文连贯性。

语义切分：用embedding计算句子相似度，语义相近的放一起，效果最好但计算成本高。

递归切分：先按大单位（章节）切，太大再按小单位（段落）切，逐级细化。

选择策略的原则：

  • 文档结构规整的，用段落切分
  • 问答场景，块可以小一点（200-500字符）
  • 需要完整上下文的（法律文档），块要大（1000-2000字符）
  • 预算允许，用语义切分效果最好

我们项目用的滑动窗口+语义切分的混合方案，召回率提升了15%。

【面试题】4. ConcurrentHashMap在JDK 1.8相比1.7有什么重大改进？为什么性能更好？ ​

【标准答案】JDK 1.7的ConcurrentHashMap用分段锁（Segment），每个Segment继承ReentrantLock，相当于把大锁拆成多个小锁。默认16个Segment，并发度上限就是16。

JDK 1.8做了重大改进：

  • 取消Segment，改用CAS+synchronized锁单个Node：并发度理论上是Node的数量，大幅提升
  • 数据结构改用数组+链表+红黑树：链表超过8转红黑树，查询从O(n)变成O(log n)
  • 锁粒度更细：只锁头节点，不影响其他位置的读写

性能更好的原因：

  1. 并发度不再受Segment数量限制
  2. CAS无锁操作替代部分加锁场景
  3. 红黑树解决长链表性能问题
  4. synchronized在JDK 1.6后有大量优化，比ReentrantLock轻量

实际压测中，高并发写入场景，1.8比1.7性能提升30%以上。

【面试题】5. 如何设计一个高可用的AI Agent架构？关键组件有哪些？ ​

【标准答案】一个生产级的AI Agent架构，核心组件包括：

规划模块：负责任务分解和执行顺序规划，可以用ReAct或Plan-and-Execute模式。

记忆模块：短期记忆放对话上下文，长期记忆用向量数据库存储，需要检索时做RAG。

工具层：封装各种外部能力，API调用、数据库操作、代码执行等，要有统一的工具注册和调用机制。

执行引擎：协调规划、记忆、工具的交互流程，处理重试、回退、异常。

监控与反馈：记录每一步决策和结果，方便调试优化，也支持人类反馈介入（Human-in-the-loop）。

高可用设计要点：

  • 每个组件都支持降级，比如LLM调用失败有缓存兜底
  • 关键操作幂等设计，支持重试
  • 状态持久化，支持断点续跑
  • 工具调用加超时和熔断

我们项目用LangChain搭建Agent，遇到过LLM响应超时导致任务hang住，后来给每步加了超时熔断机制。

【面试题】6. MySQL的索引下推（ICP）是什么？什么场景下能提升性能？ ​

【标准答案】索引下推（Index Condition Pushdown）是MySQL 5.6引入的优化。简单说，就是把WHERE条件的过滤下推到存储引擎层，而不是在Server层过滤。

举个例子，有索引idx_name_age(name, age)，执行SELECT * FROM user WHERE name LIKE '张%' AND age = 30：

没有ICP：存储引擎用索引找到所有name LIKE '张%'的记录，返回Server层，Server层再过滤age = 30。

有ICP：存储引擎在索引遍历时就同时检查age = 30，不满足的记录根本不返回Server层。

性能提升的关键是减少了存储引擎和Server层之间的数据传输。

适用场景：

  • 联合索引，但WHERE条件包含索引的前缀和后缀列
  • LIKE前缀匹配配合其他索引列条件
  • 不是所有条件都能下推，比如条件涉及非索引列

我们有个查询从800ms优化到50ms，就是利用了ICP特性，关键是联合索引的列顺序要设计好。

【面试题】7. 向量数据库的HNSW索引原理是什么？为什么适合高维向量检索？ ​

【标准答案】HNSW全称Hierarchical Navigable Small World，是一种基于图的近似最近邻搜索算法。

核心思想是构建多层图结构：

  • 顶层稀疏：节点少，连接远距离节点，快速跳跃
  • 底层稠密：节点多，连接近距离节点，精确定位
  • 搜索过程：从顶层入口开始，逐层向下逼近，最后在底层找到最近邻

为什么比传统方法好：

  • 高维效率：暴力搜索O(n)，树结构在高维会退化，HNSW能保持O(log n)
  • 召回率高：相比IVF这类聚类方法，HNSW召回率更高，95%以上召回率下性能仍优异
  • 支持增量更新：Milvus这类向量库支持实时写入

实际选型时：

  • 数据量小（<100万）用FLAT暴力搜索，精度最高
  • 数据量中等用IVF，平衡性能和精度
  • 数据量大、实时性要求高用HNSW

我们项目中2亿向量检索，用HNSW 10ms内返回Top10，召回率92%。

【面试题】8. Spring Cloud Gateway的过滤器链是如何工作的？如何实现限流？ ​

【标准答案】Spring Cloud Gateway基于WebFlux，核心是Filter Chain模式。请求进来会依次经过：

  1. GlobalFilter（全局过滤器）
  2. GatewayFilter（路由级过滤器）
  3. 最后转发到下游服务

过滤器有pre和post两个阶段：pre在请求转发前执行，post在响应返回后执行。

实现限流的几种方式：

内置RequestRateLimiter：

yaml
spring:
  cloud:
    gateway:
      routes:
        - id: myroute
          uri: lb://myservice
          predicates:
            - Path=/api/**
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 10
                redis-rate-limiter.burstCapacity: 20
                key-resolver: "#{@userKeyResolver}"

基于Redis令牌桶，支持分布式。

自定义过滤器限流：实现GatewayFilterFactory，在pre阶段检查计数器，超过阈值返回429。

结合Sentinel：Spring Cloud Alibaba整合，支持QPS限流、线程池限流、熔断降级。

我们项目用Redis+Lua脚本实现滑动窗口限流，QPS精确控制，网关层统一拦截。

【面试题】9. Prompt Engineering中，什么是Few-shot提示？和Zero-shot、CoT的区别是什么？ ​

【标准答案】三种提示策略各有适用场景：

Zero-shot（零样本）：直接给任务描述，不给示例。

将以下句子翻译成英文：
今天天气很好

优点是简单，但对复杂任务效果不稳定。

Few-shot（少样本）：给几个示例再让模型完成任务。

将以下句子翻译成英文：
示例1：你好 → Hello
示例2：谢谢 → Thank you
今天天气很好

通过示例教会模型任务模式，效果提升明显，是实际项目中最常用的策略。

CoT（Chain of Thought，思维链）：让模型一步步推理。

问题：小明有5个苹果，吃了2个，又买了3个，还剩几个？
请一步步思考：

模型会输出推理过程，适合数学推理、逻辑判断。

实际选择：

  • 简单任务用Zero-shot
  • 有明确模式用Few-shot，2-5个示例性价比最高
  • 复杂推理用CoT，或Few-shot+CoT组合
  • 示例质量比数量重要，覆盖边界情况效果更好

我们项目做意图识别，Zero-shot准确率70%，加了Few-shot提升到92%，关键是示例要覆盖典型case。

【面试题】10. 如何处理分布式事务？Seata的AT模式原理是什么？ ​

【标准答案】分布式事务的解决方案主要有：

2PC/XA：强一致性，两阶段提交，但同步阻塞、性能差，适合数据库层面。

TCC：Try-Confirm-Cancel，业务层面实现，性能好但开发成本高。

Saga：长事务拆成多个本地事务，每个有补偿动作，适合业务流程长的场景。

本地消息表/事务消息：最终一致性，通过消息队列解耦，适合高并发场景。

Seata的AT模式是最常用的，原理是：

  1. 一阶段提交：本地事务直接提交，记录undolog（回滚日志）
  2. 二阶段提交/回滚：
    • 提交：异步删除undolog
    • 回滚：根据undolog反向生成SQL恢复数据

核心优势：

  • 无侵入：业务代码不需要改，只需加@GlobalTransactional注解
  • 性能好：一阶段直接提交，不阻塞
  • 支持多数据源：MySQL、PostgreSQL等都支持

注意事项：

  • 要加全局锁，防止脏写，性能有损耗
  • 只支持ACID数据库
  • undolog表要定期清理

我们项目跨库下单场景，用Seata AT模式，TPS从单库的2000降到跨库的800，但一致性有保障。

本轮题库统计：

  • AI方向：5题（大模型原理、RAG、向量数据库、Agent架构、Prompt Engineering）
  • Java方向：5题（Spring Boot、ConcurrentHashMap、MySQL索引、Spring Cloud Gateway、分布式事务）
  • 涵盖：技术基础、架构设计、场景实操、性能优化