Java大厂面试实录电商秒杀支付场景下Redis缓存、Kafka削峰、分布式事务与微服务安全连环问故事背景某互联网大厂会议室。一位面无表情的资深面试官推了推眼镜对面坐着一位头发略油、自称三年Java经验的程序员——谢飞机。今天面的岗位是电商中台后端开发业务覆盖秒杀、订单、支付三大块。面试官谢先生我们直接进入正题一共三轮。第一轮 · Java基础与JVM热身局面试官先说说你平时用的 JDK 版本8、11、17 有什么区别谢飞机8 最熟11 和 17 也了解。JDK 11 是 LTS加了var局部变量推断、ZGC 垃圾收集器、新的 HttpClient还有 String 的isBlank、repeat、lines这些方法。JDK 17 也是 LTS主要是废弃一些旧 API、封禁内部 API加了密封类 sealed class。面试官嗯答得挺顺看来是真用过。那HashMap 在并发下有什么问题为什么推荐 ConcurrentHashMap谢飞机HashMap 线程不安全并发 put 会数据覆盖。JDK7 扩容时头插法可能形成环形链表get 死循环JDK8 改成尾插法解决了死循环但并发丢数据还是存在。ConcurrentHashMap 是 CAS synchronized 锁桶读操作不加锁写操作锁住单个桶并发性能好。面试官微微点头底子可以。那Spring 的 IoC 和 AOP 核心思想说说。谢飞机IoC 就是把对象的创建和依赖管理反转给 Spring 容器降低耦合AOP 是面向切面编程把日志、事务、权限这些横切逻辑从业务里抽出来靠动态代理JDK 动态代理 / CGLIB实现。面试官热身过了我们来点真实的。第二轮 · 电商秒杀场景上强度面试官假设我们做双十一秒杀流量瞬间几百万 QPS 的读、几十万 QPS 的写Redis 怎么设计库存扣减谢飞机秒杀要提前把库存预热到 Redis用 Lua 脚本保证判断库存 扣减的原子性防止超卖。接口层面可以加限流、防重复提交。面试官好Lua 这块答得可以。那缓存穿透、击穿、雪崩分别怎么解决谢飞机穿透就是查不存在的 key请求全打 DB用布隆过滤器 空值缓存击穿是热点 key 过期瞬间大量请求打 DB用互斥锁或者逻辑过期雪崩是大量 key 同时过期用随机过期时间 多级缓存 熔断降级。面试官不错。那缓存和数据库的一致性怎么保证先删缓存还是先更新 DB谢飞机呃…这个一般先更新数据库再删缓存加上延迟双删……但极端情况下还是会不一致得靠 binlog 订阅或者 TTL 兜底……越说越小声面试官含糊了。那我们聊消息队列——秒杀下单怎么用 Kafka 削峰怎么保证不丢消息谢飞机订单请求先写 Kafka消费者慢慢消费落库。不丢消息的话……生产者要 ackall消费者手动提交 offset还要幂等……呃还有那个事务消息眼神开始飘忽面试官行这块我们记下了。第三轮 · 支付与微服务压轴局面试官秒杀只是入口钱才是大事。假设我们做支付系统订单、账户、积分、优惠券多个系统一起改怎么保证分布式事务的一致性谢飞机嗯…分布式事务有 2PC、TCC、SAGA还有那个 Seata……大概就是要么都成功要么都回滚但本地消息表 MQ 最终一致性我比较熟……支支吾吾面试官最终一致性那你讲讲对账怎么发现少钱多钱谢飞机对账就是……拉微信、支付宝的账单和本地流水比对有差异就生成差错单人工处理……但具体的对账引擎设计我没做过我都是看别人配的……越说越没底面试官那换个轻松的。Spring Cloud 微服务里服务发现、熔断降级怎么做谢飞机服务发现用 Nacos 或 EurekaOpenFeign 做远程调用熔断用 Resilience4j 或者 Sentinel配置中心用 Apollo……这块我搭过 Demo生产环境还是大佬带的。挠头面试官JWT 和 OAuth2 区别支付接口怎么防篡改防重放谢飞机JWT 是无状态 tokenOAuth2 是授权协议可以签发 JWT……防篡改用签名验签防重放要加 nonce 和 timestamp……声音越来越虚面试官最后问一个。线上突然 OOM 或者 CPU 飙高你怎么排查谢飞机OOM 先看堆转储jmap 导 dump 用 MAT 分析……CPU 飙高用 jstack 看线程栈找 top 线程……不过一般我都是重启一下先恢复业务再查……尴尬地笑面试官合上电脑面无表情行谢先生你的基础面还是可以的底层原理和常用组件都能说上来。但是分布式事务、对账、性能排查这些核心的深度还不够我们中台这块要求比较高。这样吧你先回去等通知我们下周还有几位候选人要面有结果 HR 会联系你。谢飞机好的好的谢谢面试官我回去一定好好补课走出会议室掏出手机赶紧买个《分布式事务从入门到放弃》答案解析小白学习版下面把每一问的业务场景 技术点展开讲透面试前可以直接背。第一轮Java基础与JVMQ1JDK 8 / 11 / 17 有什么区别JDK 8LTS企业线上绝对主力。核心特性Lambda 表达式、Stream 流式 API、Optional、CompletableFuture 异步编程、新的日期时间 APILocalDateTime、接口默认方法与静态方法、Metaspace 替代永久代。JDK 11LTSvar局部变量类型推断注意只能用于局部变量不能用于成员变量String 新增isBlank/repeat/lines/strip全新的 HttpClient替代 HttpURLConnectionZGC 试验性引入移除 Java EE 模块JAXB、JTA 等。JDK 17LTS密封类 sealed class 正式化强封装 JDK 内部 API要使用需加--add-opens默认禁用 finalize移除部分实验性 AOT 编译等。面试加分点能说出每个版本的 LTS 定位、线上用的哪个、升级的顾虑如依赖兼容、GC 选择。Q2HashMap 并发问题 为什么用 ConcurrentHashMapHashMap 线程不安全并发 put 时两个线程同时往同一个桶写可能互相覆盖数据。JDK7 死循环问题数组 链表扩容用头插法。多线程并发扩容时链表被倒序重排可能形成环形链表get 时无限循环 → CPU 飙高甚至宕机。JDK8 改进改成尾插法死循环问题解决但并发数据覆盖问题依旧存在putVal里tab[i]赋值被后写的线程覆盖。ConcurrentHashMapJDK8放弃分段锁改为CAS synchronized 锁单个桶bin锁粒度从整张表降到单个哈希桶读操作完全无锁扩容时多线程协助搬运size()用 CounterCell 数组累加。Q3Spring 的 IoC 与 AOPIoC控制反转把对象的创建、依赖关系交给 Spring 容器管理开发者只需声明依赖构造器注入、Setter、Autowired实现高内聚低耦合。AOP面向切面编程把事务Transactional、日志、权限校验、性能监控等横切逻辑从业务中抽离。实现基于动态代理目标类有接口 → JDK 动态代理无接口 → CGLIB 字节码增强。第二轮电商秒杀场景Q1Redis 如何设计库存扣减预热活动开始前把库存批量写入 Redis避免活动瞬间冷启动打爆 DB。Lua 脚本保证原子性把判断库存 0 扣减合并成一个 Lua 脚本整体执行Redis 单线程保证脚本内操作原子从根本上防超卖if tonumber(redis.call(get, KEYS[1])) 0 then return redis.call(decr, KEYS[1]) end return -1限流Sentinel / Guava RateLimiter / 令牌桶限制单位时间放行量用户维度做防重复提交Redis SETNX 幂等标记。异步落库Redis 预扣成功 → 发 MQ → 下游真正扣库存落库 → 超时未支付则释放库存。Q2缓存穿透 / 击穿 / 雪崩| 问题 | 现象 | 解法 | |---|---|---| |穿透| 查不存在的 key请求全打到 DB | 布隆过滤器BloomFilter先拦截 空值缓存短 TTL | |击穿| 单个热点 key 过期瞬间大量请求打 DB | 互斥锁SETNX 只放一个线程去 DB 重建逻辑过期value 里存过期时间异步重建 | |雪崩| 大量 key 同时过期 / Redis 宕机 | 过期时间加随机值多级缓存本地 Caffeine Redis熔断降级Redis 集群高可用 |Q3缓存与 DB 一致性为什么先更新 DB 再删缓存标准姿势是Cache Aside先更新数据库再删缓存。如果先删缓存再更新 DB在删缓存 → 更新 DB的窗口期并发读会把旧值重新写回缓存导致长期脏数据。延迟双删删缓存 → 更新 DB → 延迟几百毫秒再删一次兜住并发窗口期写回的旧值。兜底订阅 MySQL binlog如 Canal同步刷新缓存 / 设置 TTL最终保证最终一致性。面试官觉得含糊的点严格的缓存一致性无法 100% 保证关键在于权衡能说出延迟双删、binlog 订阅、TTL 兜底这套组合才是完整答案。Q4Kafka 削峰 不丢消息削峰原理MQ 是天然缓冲区。秒杀请求先全部写入 Kafka吞吐极高下游消费者按数据库能承受的速率慢慢消费落库实现流量整形防止瞬时洪峰压垮订单服务。不丢消息三端保障生产者acksallISR 全部副本确认retries重试 enable.idempotence幂等。Broker分区多副本 min.insync.replicas防止副本丢失。消费者手动提交 offset先处理完业务逻辑再提交避免提交后消费失败丢数据消费逻辑要做幂等用业务流水号去重。谢飞机含糊的地方Kafka 事务Exactly-Once、offset 提交时机、消费积压的排查与扩容方案都没讲透。第三轮支付与微服务Q1分布式事务怎么保证一致性业务场景下单同时要扣库存、扣账户、发积分、改优惠券状态跨越多个微服务单库本地事务管不了。方案对比2PC / XA强一致但同步阻塞、性能差、协调者单点适合对一致性要求极高且并发不高的场景。Seata 的AT 模式就是 2PC 的改良生成 undo_log 回滚日志无侵入。TCCTry预留资源→ Confirm确认→ Cancel补偿业务侵入强适合金融扣款等要注意空回滚和悬挂问题。SAGA长事务每一步有反向补偿操作适合跨多服务的编排型流程。本地消息表 MQ最终一致性本地事务里同时写业务表和消息表 → 定时任务投递 MQ → 消费方幂等处理是互联网最常用的做法。Q2对账怎么做目的发现外部渠道微信/支付宝/银联账单与本地账务的差异防止资金损失和错账。流程定时拉取渠道对账单 → 按订单号、金额、状态与本地流水/订单比对 → 差异分类长款/短款/未达账→ 生成差错单 → 自动或人工调账 → 复核对账闭环。技术点定时调度XXL-Job、大数据量比对用分片或 Spark 批处理、差错处理必须幂等同一笔差账不能重复入账。Q3Spring Cloud 服务治理注册发现Nacos / Eureka / Consul配合 Spring Cloud LoadBalancer 做负载均衡。远程调用OpenFeign 声明式 HTTP 客户端。熔断降级Resilience4j熔断器、信号量、舱壁隔离或 Alibaba Sentinel降级时返回兜底数据fallback。网关Spring Cloud Gateway 统一入口、鉴权、限流。配置中心Nacos / Apollo配置热更新。谢飞机只答了名词缺少选型理由和生产细节熔断阈值、超时重试要防重放、服务漂移与缓存等。Q4JWT 与 OAuth2 区别 支付接口防篡改防重放JWT无状态签名令牌自包含三段header.payload.signatureHS256对称/ RS256非对称签名用于认证。缺点是无法主动吊销过期前一直有效。OAuth2授权协议定义授权码 / 密码 / 客户端等模式颁发 access_token refresh_token用于第三方授权。两者可结合OAuth2 签发 JWT 格式的 token。支付接口安全三板斧防篡改对报文做摘要 商户私钥数字签名平台验签全程 HTTPS。防重放timestamp 过期校验 随机数 nonce用 Redis SETNX 记录已用 nonce 业务流水号幂等同一请求重复到达只处理一次。敏感数据RSA / AES 加密传输。Q5OOM / CPU 飙高排查OOM 排查保留现场jmap -dump:formatb,fileheap.hprof pid或启动参数-XX:HeapDumpOnOutOfMemoryError自动导出。分析用 MAT 看 Dominator Tree 找大对象、Leak Suspects 定位泄漏引用链。常见原因大 List 未释放、ThreadLocal 内存泄漏、静态集合无限增长、连接/IO 流未关闭。CPU 飙高排查top找到高 CPU 进程 →top -Hp pid找到高 CPU 线程。printf %x tid把线程 ID 转十六进制。jstack pid | grep -A 20 十六进制tid定位线程栈。常见原因死循环、频繁 Full GC、正则回溯、序列化、锁竞争自旋。谢飞机先重启的做法暴露了生产排查经验的欠缺——现场没了问题就永远查不明白了。写在最后这一场面试下来其实能看出大厂考察的分层逻辑第一层语言基础与 JVMJDK 版本、集合并发、Spring 原理——考察基本功扎不扎实。第二层核心中间件Redis、Kafka结合真实业务场景秒杀——考察能不能把组件用到业务里而不仅是背概念。第三层复杂分布式问题分布式事务、对账、微服务治理、安全、性能排查——考察深度与生产经验。谢飞机败在哪简单问题对答如流但一旦进入深度和细节就含糊其辞——这正是很多面经背得多、实战想得少的同学的通病。面试官要的不是你背过多少名词而是每个方案背后的为什么、取舍和坑。把上面每道题的业务场景 技术点 坑吃透你离大厂 offer 就不远了。祝各位面友好运
