有赞 Java 一面面经

有赞 · Java 后端工程师 · 一面 · 2026-03

Java MySQL Redis 线程池消息队列分布式事务

面试题目

基础自我介绍

自我介绍

Java 并发

线程池的原理、使用，参数如何设置？
线程池上下文传递（如何在线程池中传递 ThreadLocal 上下文）？

MySQL

MySQL 索引覆盖是什么？
分库分表策略？什么时候需要分库（多少数据量）？
MySQL 主从同步如何实现的？

Redis

Redis 的用途？缓存击穿和缓存穿透是什么？怎么解决？
热点 Key 问题如何处理？

消息队列

消息队列如何保证消息的可靠性？如何保证消息不被重复消费？

分布式

分布式事务有用过吗？怎么用的？

实习项目拷打

RAG 如何优化的？如果文档中存在图片该怎么办？文档有没有做分类？有没有了解过 Agent 集群？

参考解析

线程池原理与参数设置

核心参数：corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务队列）、RejectedExecutionHandler（拒绝策略）。
执行流程：任务提交 → 核心线程未满则新建 → 核心线程满则入队 → 队列满则扩展到最大线程 → 最大线程也满则触发拒绝策略。
IO 密集型建议 corePoolSize = 2 * CPU核数，CPU 密集型建议 CPU核数 + 1。
队列建议使用有界队列（如 ArrayBlockingQueue），避免 OOM。

线程池上下文传递

ThreadLocal 数据不会随任务自动传递到子线程，需手动处理。
常用方案：使用阿里开源的 TransmittableThreadLocal（TTL），配合 TtlRunnable / TtlCallable 包装任务，可自动在提交时快照并在执行时还原上下文。
也可在任务提交前手动 get() 值，在任务内 set() 并在 finally 中 remove()。

MySQL 索引覆盖

查询所需的所有字段都包含在所使用的索引中，无需回表查询主键索引，称为覆盖索引。
EXPLAIN 输出 Extra: Using index 即表示命中覆盖索引。
设计时可将高频查询的 SELECT 字段加入联合索引，减少回表开销。

分库分表

分表时机：单表数据量超过 500万~1000万行，或单表数据文件超过 2GB，查询性能明显下降时考虑分表。
分库时机：数据库连接数或写入 QPS 成为瓶颈，单机磁盘/内存不足时考虑分库。
常见策略：范围分片（按时间/ID范围，易产生热点）、Hash 取模（数据均匀，扩容难）、一致性 Hash（扩容友好）。
分库分表后需解决：跨库事务、分页排序、全局唯一 ID（Snowflake）等问题。

MySQL 主从同步

主库将所有写操作记录到 Binlog；从库的 IO 线程连接主库拉取 Binlog，写入本地 Relay Log；从库的 SQL 线程重放 Relay Log 实现数据同步。
同步模式：异步复制（默认，性能高但可能丢数据）、半同步复制（至少一个从库确认后才返回）、全同步/组复制。
主从延迟排查：SHOW SLAVE STATUS 中的 Seconds_Behind_Master 字段。

Redis 缓存击穿与缓存穿透

缓存穿透：查询不存在的 Key，每次都打到 DB。解决：布隆过滤器拦截非法 Key，或对空结果缓存短时间的空值。
缓存击穿：热点 Key 过期瞬间大量请求打到 DB。解决：互斥锁（只允许一个请求重建缓存）或逻辑过期（不设物理过期时间，异步更新）。
缓存雪崩：大量 Key 同时过期。解决：过期时间加随机抖动，或使用 Redis 集群保证高可用。

热点 Key 问题

热点 Key 会导致单个 Redis 节点 CPU/网络打满。
解决方案：本地缓存（Caffeine/Guava）+ Redis 二级缓存；Key 分片（热点 Key 加随机后缀拆分到多个 Key，读取时随机选取）；读写分离扩展读能力。

消息队列可靠性与幂等性

可靠性：生产者开启 Confirm/ACK 机制确认消息投递成功；Broker 持久化消息（Kafka 的 ISR 机制、RocketMQ 的同步刷盘）；消费者手动 ACK，处理完再确认。
幂等消费：消费者端通过唯一消息 ID 结合 Redis/DB 去重；或业务操作本身设计为幂等（如 DB 唯一索引、乐观锁版本号）。

分布式事务

常见方案：2PC（强一致，性能差，有单点问题）；TCC（Try-Confirm-Cancel，业务入侵强）；Saga（长事务补偿）；本地消息表 + 消息队列（最终一致性）。
实际项目中常用 Seata 框架（AT 模式自动生成 undo log，对业务侵入小）或基于 RocketMQ 的事务消息实现最终一致性。

RAG 优化

分块策略：按语义分块（而非固定字符数），保留上下文重叠窗口，减少信息截断。
检索优化：混合检索（向量相似度 + BM25 关键词），结合 Rerank 模型对召回结果重排序。
图片处理：使用多模态模型（如 GPT-4V）对图片生成文字描述后存入向量库，或提取图片中的表格/文字（OCR）。
文档分类：对文档打标签/分类后建立分类索引，检索时先路由到对应分类，缩小召回范围，提升精度。
Agent 集群：多个专用 Agent 各司其职（检索 Agent、推理 Agent、工具调用 Agent），通过 Orchestrator 协调，适合复杂多跳推理场景。