2026后端面试全景图:100道大厂真题,吃透这6大模块直接拿Offer

阿里 · 字节 · 腾讯 · 美团 · 京东 · 百度

整理了 100篇大厂真实面试精华（覆盖阿里/字节/腾讯/美团/京东/百度/拼多多/支付宝），按技术领域拆分为 6大核心模块。每道题都标注了来源公司和考察意图——不是背八股文，而是理解面试官真正想听什么。建议收藏反复刷，面试前一周过一遍。

01 Java 基础 & JVM

面试频率 ⭐⭐⭐⭐⭐

Q1 String s = new String("abc") 创建了几个对象？

标签： 🔴 阿里一面

标准答案：2个对象（JDK8及以下）。

① 字符串常量池中的 "abc"（如果常量池不存在则创建）； ② 堆上的 new 出来的 String 对象。

进阶追问：JDK8 的字符串常量池在堆中（和 PermGen 分离后），JDK21 中进一步优化为 G1 的专用 region。

💡 面试官想确认你懂常量池位置变化 + 字符串 intern 机制。

Q2 synchronized 锁升级过程？轻量级锁会自旋吗？偏向锁有对象头吗？

标签： 🔴 阿里锁体系追问

升级链路：无锁 → 偏向锁 → 轻量级锁 → 重量级锁

关键坑点：

• ❌ 轻量级锁不会自旋！ 自旋是 JDK6 引入的自适应自旋锁（在重量级锁阶段尝试避免阻塞）。
• ❌ 匿名偏向！ 匿名偏向（Anonymous Biased）的对象没有线程ID偏向，第一个获取锁的线程会"窃取"这个偏向状态。
• 对象头 Mark Word 在各阶段的位图完全不同，64位JVM中：偏向存线程ID + epoch，轻量存栈帧指针（Displaced Mark Word），重量存 Monitor 指针。

Q3 ThreadLocal 内存泄漏原因？弱引用怎么解决？

标签： 🔴 阿里ThreadLocal连环炮

根因： ThreadLocalMap 的 key 是 ThreadLocal 对象的弱引用，但 value 是强引用。

当外部 ThreadLocal 引用被置 null 后，key 会被 GC 回收（弱引用），但 value 无法回收 → Entry 变成 key=null 的"僵尸条目"。如果线程是线程池中的长期存活线程，value 会一直泄漏。

解决方案：每次用完手动 remove()；或用 try-finally 包裹确保清理。线程池场景下尤其危险——任务复用线程 = 复用 ThreadLocalMap。

Q4 OOM 后 JVM 一定会退出吗？

标签： 🔴 阿里一面必问

❌ 不一定！ 这是90%的人答错的题。

关键区分： OOM 是 Throwable（不是 Error 才退出），可以被 catch 捕获。只有当 所有非守护线程都结束时，JVM 才会退出。

场景举例：某个线程 OOM 被 catch 住后打印日志继续跑，主线程正常执行 → JVM 不退出。但如果 OOM 发生在主线程且未捕获 → 主线程异常终止 → 若无非守护线程存活 → JVM 退出。

💡 面试官考的是：异常体系理解 + 线程生命周期独立性。

Q5 线程池参数怎么设？1万QPS+500ms接口，核心数多少？

标签： 🔴 阿里面试高频

别再背口诀了！ "CPU密集N+1、IO密集2N" 只是入门参考。

实际计算公式：核心数 = QPS × RT(秒)

本题：10000 × 0.5 = 5000 个并发线程需求。单机扛不住就拆多机。

实战配置原则：

① 核心线程数 = 期望吞吐 / 单请求耗时 ② 最大线程 = 核心 × 1.5~2 （应对突发） ③ 队列容量 = (最大-核心) × 单请求耗时（缓冲突刺） ④ ❌ 禁止用 Executors 创建！ 必须用 ThreadPoolExecutor 手动配。

🎯 Java基础 面试核心记忆点

• synchronized 升级链路 + 各阶段 Mark Word 位图必须画出来讲
• ThreadLocal 弱引用 key + 强引用 value = 泄漏根因，线程池场景必问
• JVM OOM 可被 catch，不等于进程退出；ZGC 把 STW 控制在 10ms 内的原理要能说
• 线程池拒绝策略选型：CallerRuns 不是万能药，要根据业务丢任务 vs 重试 vs 降级来定

02 MySQL 高阶 & 分库分表

面试频率 ⭐⭐⭐⭐⭐

Q1 MySQL 索引失效的10条规则，为什么加了索引还慢？

标签： 🔴 阿里一面破防题

经典10条失效场景：

① 最左前缀不满足 ② 范围查询右边列失效 ③ %开头的LIKE ④ 函数/计算操作列 ⑤ 隐式类型转换 ⑥ OR 连接条件部分无索引 ⑦ != / NOT IN ⑧ IS NULL / IS NOT NULL ⑨ 字符集不一致 ⑩ 优化器选择全表扫描（数据量倾斜时）

⚠️ 面试官致命追问： "我有一个查询用了索引，EXPLAIN 显示走了索引，但还是3秒！"

→ 这时你要答：回表太多！ 用覆盖索引避免回表、用 ICP（Index Condition Pushdown）减少回表行数、考虑延迟关联（deferred join）。

MySQL 查询优化手段对比：

Q2 MVCC 怎么实现的？ReadView 怎么判断可见性？

标签： 🔴 阿里面试官追问MVCC

MVCC（多版本并发控制）核心三要素：

① 隐藏字段：DB_TRX_ID（最后修改事务ID）、DB_ROLL_PTR（回滚指针） ② Undo Log：记录修改前的版本快照，形成版本链 ③ ReadView：快照读时生成的一致性视图

RC vs RR 的区别就在 ReadView 生成时机不同：

• RC：每条 SQL 都生成新 ReadView → 能读到其他已提交事务的最新修改
• RR：事务首次 SELECT 时生成 ReadView → 之后都用同一个 → 不可重复读被解决

可见性判断算法： 依次比较 DB_TRX_ID 与 ReadView 中的 m_ids/min_id/max_id/creator_trx_id 四个条件。

Q3 订单过亿怎么分库分表？只答哈希取模直接凉

标签： 🔴 阿里面试官灵魂拷问

哈希取模只是起点，面试官想听的是完整方案：

① 分片键选择：用户ID（用户维查询友好）vs 订单时间（时间范围查询）→ 基因法把 user_id 注入 order_id，两边的查询都能命中

② 分片策略：一致性哈希（扩容平滑）vs 范围分片（时间序列好）vs 哈希（分布均匀）→ 实际常用复合策略

③ 跨片问题：跨库 JOIN（禁止/应用层合并）、全局唯一 ID（雪花算法/号段）、分布式事务（Seata/TCC）

④ 零停服扩容：双写 + 数据校验 + 切流（阿里P8方案）

Q4 只背ACID不够！4个实战场景说明为什么要用事务

标签： 🔴 阿里一面：你没做过项目？

别背定义！用业务场景回答：

① 转账：A扣款+B加钱，原子性保证不丢钱 ② 下单减库存：库存-1 + 订单+1，一致性保证超卖/少卖 ③ 红包发放：总额不变前提下多人分配，隔离性防止重复领 ④ 日志审计：操作记录与业务同事务提交，持久性保证可追溯

💡 能说出"我在项目中XX场景用了事务解决YY问题"，比背诵ACID四个字母的定义强100倍。

🎯 MySQL 面试核心记忆点

• 索引失效10条规则要熟，但更要会分析 Explain + 慢查询日志定位根因
• MVCC 的 ReadView 可见性判断算法要能手推一遍，RR 和 RC 区别在生成时机
• 分库分表不只是哈希取模，还要答分片键选择、跨片JOIN处理、唯一ID生成、零停服扩容
• 千万级大表优化四层法：SQL优化 → 索引优化 → 表结构优化 → 架构优化（分库分表/读写分离）

03 Redis 缓存 & 高并发

面试频率 ⭐⭐⭐⭐⭐

Q1 缓存穿透、缓存击穿、缓存雪崩的区别和解决方案

标签： 🔴 阿里必问·Redis三坑

⚠️ 京东面试加分项： "10亿非法Key攻击如何防御缓存穿透？" → 布隆过滤器 + 多级防护 + 限流熔断的全链路方案。

Q2 Redis 与 MySQL 数据一致性的4种策略

标签： 🔴 阿里高频题

Redis 与 MySQL 一致性策略演进：

Cache Aside（旁路缓存）    ↓Write Through（同步写）    ↓Write Behind（异步写回）    ↓Write Behind + MQ（最终一致）

实际推荐： 大多数业务用 Cache Aside + 延迟双删 + 消息队列重试 达到最终一致性。强一致性场景用 ReadWriteLock + 分布式锁 保证串行化读写。

💡 双十一抗崩方案：先更新DB → 删缓存 → 发MQ延迟再次删（补偿可能删除失败的缓存）

Q3 Redis 1亿个 Key 中找10万固定前缀的 Key？3种解法藏着大厂思维

标签： 🔴 阿里面试必问

方案对比：

① KEYS prefix* → 🔴 O(N) 阻塞Redis，生产禁用 ② SCAN cursor MATCH prefix* COUNT 1000 → 🟢 渐进式遍历，不阻塞，生产首选 ③ Cluster 场景：SCAN 只能在单个节点上扫 → 需要并行对所有节点执行 SCAN 再汇总

大厂思维延伸： 如果这10万个 Key 需要做批量操作？→ 用 Pipeline（非原子）或 Lua脚本（原子）。但秒杀场景慎用 Pipeline——网络抖动导致部分命令丢失无法回滚！

Q4 Redis CPU 飙到90%？排查思路是什么？

标签： 🟠 京东一面必考

排查三板斧：

① redis-cli --stat 看 hits/misses → miss率过高说明缓存没起作用 ② SLOWLOG GET 10 看慢查询 → 是否有大Key操作或复杂命令 ③ redis-cli --bigkeys 或 --memkeys → 是否有超大Key占用CPU

常见元凶： Keys命令 / HGETALL 大Hash / FLUSHALL / Lua死循环 / 持久化fork导致Copy-on-Write内存翻倍

04 高并发架构 & 秒杀系统

面试频率 ⭐⭐⭐⭐⭐

Q1 设计一套10万QPS的秒杀系统？杜绝对超卖

标签： 🔴 阿里最狠压力面

7层防御架构（由外到内）：

① CDN静态资源    ↓② Nginx限流    ↓③ 网关层令牌桶    ↓④ Redis预减库存  ← 关键层    ↓⑤ MQ异步下单    ↓⑥ DB扣库存(CAS)  ← 最终兜底    ↓⑦ 回调通知

防超卖核心：

• Redis 预减库存用 DECR 原子操作（Lua脚本保证原子）
• MySQL 扣库存用 CAS乐观锁：UPDATE stock SET num=num-1 WHERE id=? AND num>0
• 超卖=0：两层兜底 + 幂等校验（订单表建唯一索引防重复）

Q2 10万QPS防重复下单？只答分布式锁直接凉

标签： 🔴 阿里电商岗必问

全链路5层防护：

① 前端：按钮置灰 + 倒计时（防连击） ② 网关层：基于用户ID + 接口路径的限流（同一用户1秒内只能调一次） ③ 业务层-Token机制：进入页面下发Token，提交时校验并删除（一次性Token） ④ 分布式锁：Redis SETNX + 过期时间（防机器宕机死锁） ⑤ 数据库兜底：唯一约束索引（user_id + biz_no）

💡 面试官想听的不是某一个技术，而是"前端到数据库的多层防御思维"。

Q3 分布式锁设计：如何扛住10万QPS？告别30%生产事故

标签： 🔴 阿里灵魂拷问

Redis 分布式锁演进路线：

• V1: SETNX + EXPIRE（非原子，可能设了锁没过期时间 → 死锁风险）
• V2: SET key value NX EX ttl（原子操作 ✅）
• V3: 看门狗自动续期（Redisson 实现，业务未完自动延期）
• V4: RedLock 多节点（防Redis主从切换导致锁丢失）

ZooKeeper vs Redis 锁： ZK 的 CP 特性适合强一致性场景，Redis 的 AP 特性适合高性能容忍少量失败的场景。

Q4 MQ 三巨头怎么选？RocketMQ / Kafka / RabbitMQ

标签： 🔴 阿里面试死磕

05 系统设计 & 大数据算法

面试频率 ⭐⭐⭐⭐

Q1 1亿条 URL 去重？40亿QQ号去重？1G内存搞定

标签： 🔴 阿里封神题 / 🔵 腾讯高频

海量去重的4套武器（按精度递增）：

40亿QQ号去重实战： 40亿 ≈ 2^32，用 Bitmap 仅需 2^32 bit = 512MB。若限制1G内存，可用 Roaring Bitmap（稀疏压缩，通常压缩到原始1/10~1/30）或 分片Bitmap（拆成多个小Bitmap分散到多台机器）。

Q2 抖音关注系统设计？7亿王者荣耀在线用户统计？

标签： 🟠 字节跳动 / 🔵 腾讯封神题

7亿用户在线统计（83MB内存方案）：

用 Bitmap！7亿用户 → 需要 7亿 bit = 700M / 8 ≈ 87.5MB。

但实际更优：Roaring Bitmap 压缩后仅需 几十MB。

Redis 天然支持 BitMap 操作：SETBIT online:20260604 userId 1 / BITCOUNT online:20260604

抖音关注系统核心难点：

• 小博主（粉丝<1万）：普通 List 存粉丝列表
• 亿粉大博主的粉丝列表不能全量拉取 → 按时间分片或只返回最近活跃粉丝
• 关注后的Feed推送：发消息到粉丝的收件箱（推模式）/ 从关注列表拉取（拉模式）→ 大V用推模式，长尾用户用拉模式

Q3 扫码登录PC端的完整原理？不只"扫码点确认"

标签： 🔵 腾讯一面挂了

完整流程：

① PC端请求UUID    ↓② 生成带UUID二维码    ↓③ 手机扫码 → 携token+UUID确认  ← 关键步骤    ↓④ PC轮询/长连接收到确认    ↓⑤ PC获得登录态Token

面试官追问方向： 二维码过期策略？手机确认后PC怎么知道（轮询 vs WebSocket vs 长连接）？同一账号多设备登录怎么处理（踢人策略）？

💡 关键不是流程描述，而是安全考量（二维码伪造、中间人攻击）+ 技术选型理由（轮询简单但浪费资源，WebSocket实时但复杂度高）。

06 微服务 & 分布式

面试频率 ⭐⭐⭐⭐

Q1 Eureka / Nacos / ZooKeeper 注册中心怎么选？

标签： 🔴 阿里面试必问

结论： 新项目首选 Nacos（功能最全 + 国内生态最好）；老项目用 Eureka 可迁移至 Nacos；需要强一致性选 ZK（如分布式锁协调）。

Q2 设计10微服务的SSO单点登录系统？只答JWT当场尬住

标签： 🔵 腾讯面试

JWT ≠ SSO 全部！ JWT 只是 Token 格式的一种实现。

完整SSO需要考虑：

① 统一认证中心：负责登录、颁发/校验 Token ② Session 共享：JWT 无状态（自带用户信息）or Session 集中存储（Redis） ③ 单点登出：JWT 天然不支持主动失效 → 需要黑名单机制（Redis 记录已注销 Token） ④ 跨域：CORS 配置 + Cookie 的 SameSite 属性 ⑤ 安全性：Token 劫持/重放攻击 → 签名验证 + 过期时间 + Refresh Token 轮转

💡 日活100万的SSO → JWT + 黑名单Redis + 网关层统一鉴权 + OAuth2.0协议

Q3 支付系统幂等性设计？付1单扣4次钱怎么办

标签： 🟢 支付宝惊魂一刻

「付138元被扣4次」—— 这就是缺乏幂等性的后果。

幂等性三层保障：

① 数据库唯一约束：订单号做 UK，INSERT 重复直接报错（最强兜底） ② 分布式锁：同一订单号的支付请求串行执行（Redis SETNX） ③ Token 机制：支付接口要求客户端携带一次性 Token（前置接口下发）

支付回调幂等： 第三方支付平台可能多次推送回调 → 服务端用 流水号做幂等校验，已处理的直接返回成功，不要重复扣款。

📋 2026 后端面试 · 备战清单

基于100篇大厂面经提炼的核心考点分布：

💡 建议： 每个模块挑3道题手写过一遍代码，面试时能画出架构图就能赢80%候选人

📖 本文整理自「面试精华题库」100篇大厂真实面经 覆盖阿里 / 字节 / 腾讯 / 美团 / 京东 / 百度 / 拼多多 / 支付宝