1.自我介绍

2.项目拷打穿插八股：

a.你在哪些功能中引入了新的组件?

b.ES相比于MySQL好在哪？

c.什么场景下用MySQL查找,什么场景下用ES？

d.大数据量用ES就一定更好吗？

e.你知道在分布式部署下ES可能出现哪些问题吗？

f.讲讲RocketMQ在你的项目中的使用逻辑？

g.你认为在你的理解中RocketMQ最重要的特性是什么?（顺序性，不丢失，不重复，幂等性，可用性）

h.那你知道RocketMQ是怎么实现这些特性的吗?

i.Kafka是怎么实现集群高可用，在Leader宕机情况下不会有消息丢失的？

j.你平时是怎么学习技术的？

k.你这边建立了二级缓存，那请问你是怎么保证二级缓存中数据一致性的？

l.那你采用事务可能会带来一些什么问题？

m.除了Caffeine还了解哪些本地缓存结构吗？

n.知道Caffeine的内部结构吗？

3.来讲讲Java中的Error是怎么出现的？会带来什么后果？

4.你提到了OOM，请问什么情况下会出现OOM呢？

5.那异常呢？Java中有哪些异常类型？

6.你认为编译时异常和运行时异常该怎么去处理？什么时候要注意处理这些异常？

7.来讲讲锁，对Synchronized了解吗？

8.Synchronized是可重入锁吗？是公平锁吗？

9.还了解哪些锁呢？

10.假如你自己设计了一个并发包，我们可以丢弃Synchronized只用ReentrantLock吗？

手撕：实现一个单链表首尾交叉相连，要求必须在原链表上操作

例子：1-2-3-4-5-6-7

输出：1-7-2-6-3-5-4

作者：约个OFFER吧

链接：

https://www.nowcoder.com/feed/main/detail/ee2a93c1acb242bc84de65cda49f85b0?sourceSSR=search

来源：牛客网

1. 自我介绍

考察知识点：自我认知、技术栈与岗位匹配度、项目价值提炼。参考回答：我叫 XX，2 年 Java 后端 + 大数据开发经验，核心技术栈覆盖 Spring Cloud、MySQL、ES、RocketMQ、Spark，擅长高并发场景下的缓存设计和数据链路优化。之前在电商项目中，主导过 “商品搜索性能优化” 和 “订单异步流转” 两个核心模块：前者用 ES 替代 MySQL 模糊查询，把搜索响应从 3 秒压到 80ms；后者用 RocketMQ 解耦库存、物流系统，订单处理成功率从 91% 提到 99.8%。平时喜欢钻研源码，比如深入看过 Caffeine 缓存的淘汰算法和 RocketMQ 的消息持久化逻辑，希望能把这些实践经验用到贵公司的分布式业务中。

回答注意要点：

1. 必含 “核心技术栈”（对应岗位要求，比如岗位要 ES 就重点提）；
2. 项目选 1-2 个有量化成果的（用 “时间 / 成功率 / 性能” 等数据说话，避免空泛）；
3. 结尾关联 “岗位需求”（体现求职动机，不是单纯念简历）。

2. 项目拷打穿插八股

a. 你在哪些功能中引入了新的组件？

考察知识点：技术选型逻辑、组件解决的业务痛点。参考回答：主要在两个功能中引入新组件：

1. 商品搜索功能：原用 MySQL 的like查询，千万级数据下响应超 3 秒，引入 ES 后，靠分词和倒排索引，查询耗时降到 100ms 内，还支持 “价格区间筛选”“品牌聚合” 等新需求；
2. 订单状态同步：原用同步 HTTP 调用，库存系统超时会导致订单阻塞，引入 RocketMQ 做异步通知，订单创建后只发消息，库存、物流系统各自消费，处理成功率从 92% 升到 99.9%，还支持失败重试。

回答注意要点：

1. 每个组件必说 “引入前的问题”（痛点）+“引入后的效果”（对比）；
2. 关联业务价值（比如 “支持新需求”“提升成功率”，不是单纯说技术）。

b. ES 相比于 MySQL 好在哪？

考察知识点：ES 与 MySQL 的核心差异（检索能力、性能、架构）。参考回答：最核心的优势在 “全文检索” 和 “大数据量复杂查询”：

1. 检索能力：ES 支持分词（比如 “无线耳机” 能匹配 “耳机无线”）、模糊匹配（容错拼写错误），MySQL 的like %xxx%只能全表扫描，还不支持分词；
2. 查询性能：千万级数据下，ES 的倒排索引查多条件过滤 + 排序（如 “价格 < 5000 且评分> 4.5”）只要毫秒级，MySQL 得建复杂联合索引，还容易失效；
3. 分布式扩展：ES 天生支持分布式，加节点就能扩容，MySQL 分库分表要靠 Sharding-JDBC，复杂度高很多。

回答注意要点：

1. 别只说 “ES 快”，要拆解 “为什么快”（倒排索引、分布式）；
2. 对比维度要具体（检索、性能、扩展），避免笼统说 “ES 更适合大数据”。

c. 什么场景下用 MySQL 查找，什么场景下用 ES？

考察知识点：数据库与搜索引擎的场景匹配逻辑。参考回答：核心看 “业务需求是否需要事务 / 精确查询” 还是 “全文检索 / 复杂聚合”：

• 用 MySQL：需要事务（如订单创建、支付）、按主键 / 唯一键精确查（如 “按用户 ID 查信息”）、多表 join（如 “查订单 + 用户 + 商品详情”），比如 “用户登录验证”“订单支付扣减余额”，MySQL 的 ACID 和 B + 树索引更稳；
• 用 ES：需要全文检索（如 “商品搜索‘轻薄笔记本’”）、大数据量过滤排序（如 “电商筛选页多条件过滤”）、聚合统计（如 “按品牌统计商品销量占比”），比如 “商品搜索页”“日志检索系统”，ES 的分词和分布式查询更高效。

回答注意要点：

1. 每个场景必带 “具体业务例子”（比如不说 “事务场景”，说 “订单支付”）；
2. 隐含 “配合使用逻辑”（如 MySQL 存核心数据，ES 同步做检索），体现实践经验。

d. 大数据量用 ES 就一定更好吗？

考察知识点：ES 的局限性、技术选型的辩证思维。参考回答：不一定，得看具体场景，ES 有明显短板：

1. 写入高频场景：比如每秒 10 万条日志写入，ES 要频繁刷新倒排索引，性能会掉得厉害，MySQL 用 InnoDB 的 buffer pool+redo log，写入更稳定；
2. 强事务需求：ES 不支持事务，比如 “修改商品库存 + 记录日志” 要原子性，ES 做不到，还得靠 MySQL；
3. 存储成本：ES 的索引文件比 MySQL 大 3-5 倍，PB 级数据存 ES 成本太高；
4. 简单查询：比如 “按 ID 查单条商品”，MySQL 的 B + 树直接定位，比 ES 快，没必要用 ES。

回答注意要点：