阿里 · 字节 · 腾讯 · 美团 · 京东 · 百度
整理了 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三坑
| | |
|---|
| 缓存穿透 | | 布隆过滤器 |
| 缓存击穿 | | 互斥锁（重建时只一个线程查DB）+ 逻辑过期（永不物理过期） |
| 缓存雪崩 | | 随机TTL（打散过期时间）+ 多级缓存 + 限流降级 + 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
抖音关注系统核心难点：
- 亿粉大博主的粉丝列表不能全量拉取 → 按时间分片或只返回最近活跃粉丝
- 关注后的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篇大厂面经提炼的核心考点分布：
| |
|---|
| Java/JVM | |
| MySQL | |
| Redis | |
| 高并发 | |
| 系统设计 | |
| 微服务 | |
💡 建议： 每个模块挑3道题手写过一遍代码，面试时能画出架构图就能赢80%候选人
📖 本文整理自「面试精华题库」100篇大厂真实面经 覆盖阿里 / 字节 / 腾讯 / 美团 / 京东 / 百度 / 拼多多 / 支付宝
