Java面试场景题全解析：从库存扣减到CompletableFuture的实战框架-北京尧图网络

市面上讲Java面试的帖子一抓一大把但绝大多数都在堆八股文。背了三个月HashMap源码、JVM内存模型结果面试官一句“来个场景题”——给一个具体业务让你说说怎么设计、怎么落地、会遇到什么问题——很多人当场就懵了。这篇文章我就专门聊聊Java场景题这件事。场景题考察的从来不是记忆力而是你把技术点串起来解决实际问题的能力。我会从面试官的出题逻辑讲起把最经典的几类高频场景题拆开揉碎最后给你一套我自己这些年面试别人和被别人面试总结出来的解题框架。不管你是准备校招、跳槽还是单纯想提升系统设计能力这篇都值得认真看完。1. 场景题到底在考什么——先聊聊面试官的出题逻辑1.1 从背题到解题为什么场景题能区分候选人八股文有一个天然缺陷它是静态的。你可以背下来ConcurrentHashMap在JDK 7和JDK 8里分别是分段锁和CAS加synchronized但面试官问“一个电商系统里库存只有100件1万人同时抢你怎么保证不超卖”你背的那些知识点立刻就得重新组装。场景题的本质是把多个知识点放进一个具体业务上下文里让你现场做技术选型和方案设计。它考察的不再是“你知不知道”而是“你会不会用”。一个只背过八股文的候选人和一个真正写过线上系统的候选人在场景题面前高下立判——前者会努力回忆某个知识点后者会习惯性地问清楚业务约束、数据量级、并发峰值然后才开始画方案。所以我一直觉得场景题是面试里最公平的题型。它不看你简历上写了多少花哨的项目就看你当场能不能把问题拆明白、把方案说清楚。1.2 高频场景题背后的三个底层能力我面试过不少候选人也复盘过大量场景题总结下来无论题目怎么变考察的底层能力就三个。第一个是业务建模能力。拿到题目后能不能把模糊的业务描述转化为清晰的数据模型和接口设计。比如“设计一个秒杀系统”你要能说出需要哪些表、哪些字段、哪些状态流转而不是直接开始聊Redis。第二个是并发与一致性思维。Java场景题十个里有八个绕不开并发。库存扣减怎么保证不多扣订单状态怎么保证不混乱缓存和数据库的一致性怎么处理——这些都是并发场景下的经典命题。这里考察的是你对锁、CAS、事务、消息队列这些工具的理解深度以及你知不知道什么场景该用哪个。第三个是边界与容错意识。系统正常运行谁都会设计难的是异常情况下怎么办。接口超时、消息丢失、服务宕机、重复请求这些边界条件你能不能提前想到并且给出兜底方案。这往往是区分“背过答案”和“真正做过”的关键分水岭。2. 经典场景题分类——那些年面试官最爱出的题2.1 数据一致性类库存扣减、订单状态流转数据一致性是场景题的绝对主流。最常见的题目包括库存扣减如何防超卖、订单支付成功后如何保证状态一致、转账场景如何保证不丢钱、缓存与数据库如何保持同步。这类题目的核心矛盾是并发场景下多个请求同时操作同一份数据怎么保证结果正确。解法通常围绕锁、版本号、事务隔离级别、消息补偿这几个方向展开。面试官会不断追问“你这个方案在极端情况下会怎样”本质上就是在考察你对一致性的理解到底停留在表面还是深入到了原理层。2.2 时效性任务类订单超时关闭、延迟通知“用户在电商平台下单后30分钟未支付系统自动关闭订单”——这是另一道高频场景题。类似的还有外卖超时未接单自动取消、优惠券即将过期提醒、直播开播前提醒。这类题考察的是延迟任务调度的能力。实现方式五花八门定时任务扫表、延迟队列、时间轮、Redis过期键监听各有各的适用场景和坑。面试官想知道的是你能不能根据数据量、时效精度、系统复杂度选一个真正合适的方案。2.3 高并发防重类幂等设计、接口防刷“前端按钮没有做防抖用户疯狂点提交订单创建接口被调了十几次怎么保证只生成一个订单”——这几乎是互联网公司面试的必考题。它考察的是幂等设计能力如何通过全局唯一ID、状态机、数据库唯一索引等手段让同一个请求无论到达多少次对系统产生的影响都只有一次。这类题的陷阱在于很多人第一反应是“加个锁”但锁能解决单机问题解决不了分布式问题能解决并发问题解决不了重试问题。真正优秀的回答会从请求入口、业务处理、数据存储三层分别设计防线。2.4 海量数据与性能类多线程导出、深分页优化除了并发和一致性性能优化也是场景题的重头戏。“一张表5000万条数据前端要分页查询深翻页越来越慢怎么办”“要导出100万条数据到Excel怎么设计才能不OOM”——这类题目是让我筛选候选人的重要参考。说实话这两道题写出来的内容足够单独写两篇文章这里我先给出统一思路海量数据三大杀器——分页优化游标/延迟关联、分批处理流式读取批量写入、异步化任务拆分结果通知。几乎所有海量数据场景题都能套用这个框架。2.5 手写编码类多线程交替打印、LRU缓存还有一类场景题是在白板上直接写代码。常见的有三个线程交替打印ABC、手写一个阻塞队列、实现一个LRU缓存、使用CompletableFuture编排多个异步任务。这类题考察的是并发编程的基本功wait/notify的配合、锁的条件变量、volatile的可见性、链表和哈希表的组合使用。别看题目简单写对容易写得优雅、可扩展、不出并发bug很考验功力。场景类型典型题目核心考点常用技术数据一致性库存扣减、转账并发安全、事务乐观锁、Redis、消息队列时效性任务订单超时关闭延迟调度定时扫表、延迟队列、时间轮幂等防重重复提交、接口防刷幂等、去重唯一ID、唯一索引、状态机海量数据大表分页、批量导出性能、内存游标、分批处理、异步化手写编码交替打印、LRU并发基本功wait/notify、锁、CAS3. 场景题通用解题框架——“四步法”拆解任何业务场景3.1 第一步先问清楚业务边界很多候选人在场景题上栽跟头不是因为不会技术而是因为拿到题就开始说方案。这是大忌。真实业务里的约束条件千差万别同样是“设计一个订单系统”淘宝的订单系统和餐厅的点餐系统完全是两码事。我的建议是动手之前先抛出三组问题数据量级QPS多少、数据总量多少、峰值是多少、一致性要求能不能接受短暂不一致、要不要强一致、资源约束团队规模、现有技术栈、可用中间件。面试官给你题目的时候往往会故意漏掉这些信息你看不到就去问面试官反而会觉得你有真实项目的思维习惯。这一步看起来简单实则决定了后续所有技术选型。比如同样是防超卖QPS 100和QPS 10万的方案完全不同同样做延迟任务允许误差1分钟和允许误差1秒的方案也完全不同。3.2 第二步识别核心难点问清楚边界之后第二步是把问题里的核心难点抽象出来。这一步需要你对常见技术问题有敏感度能从描述里嗅到真正的技术挑战。我举个例子。题目是“设计一个秒杀系统”。如果你满脑子都是Redis、MQ这些名词说明你还没抓住重点。秒杀系统的核心难点其实是三个瞬时流量冲击怎么让流量平滑地经过系统、库存扣减的原子性怎么防止超卖、防作弊怎么防止脚本刷单。你要先把这三个难点摆出来让面试官知道你看到了问题然后再逐一给出方案。判断你有没有抓住核心难点有个很简单的标准你的方案是不是在解决业务最痛的那个点。如果用户最关心的是“我到底抢到没有”系统最怕的是“超卖导致发不出货”那你的方案就一定要围绕库存扣减和结果通知来设计。3.3 第三步技术选型讲清楚trade-off难点识别出来后第三步是给出具体的技术方案。这里要注意面试官听的不是单一答案而是你做决策的思考过程。比如解决库存超卖你可以说用数据库乐观锁update stock set count count - 1 where id ? and count 0。但如果你只丢出这一句话面试官会觉得你背过题。更好的回答是先说明这个方案利用数据库行锁和条件更新保证了原子性然后主动指出它的瓶颈——数据库的更新吞吐量有限QPS过高时数据库会成为瓶颈。从“说出方案”到“讲清楚方案的边界和代价”这就是有经验和没经验的分水岭。我在后面的章节里会结合具体题目详细演示这种trade-off该怎么讲。3.4 第四步枚举边界条件和异常路径场景题和八股文的另一个重要区别就是场景题必须考虑“挂了之后怎么办”。这块内容能明显增强面试官对候选人的好感度。一个完整的方案至少要覆盖这些异常路径接口超时了一个请求重试会不会造成重复数据消息队列挂了核心链路是不是就断了服务重启内存里的状态丢没丢数据库写入失败用户看到的是什么多实例部署本机锁还管不管用。我的习惯是在方案里专门提一句“万一出现最坏情况我的兜底方案是什么”。这句话不在多但一定要有。有了它面试官就会觉得你不是在背方案而是在真正设计一个能上线的系统。4. 拿下一道必考真题库存扣减如何防超卖4.1 第一版方案同步代码块查库存既然说到了框架我就用库存扣减这道经典母题带大家走一遍从简单到完善的完整演进过程。这道题不管面大厂还是中小厂都常被问到而且经常会换壳比如“火车票余票”“优惠券领取”“秒杀库存”。大多数候选人脱口而出的第一版是先select查一下库存如果大于0就update扣减。我把这个方案称为“查了再减”它最大的问题在并发场景下两个请求同时查到库存为1然后同时执行扣减结果库存变成-1超卖了。如果这时候面试官追问“那怎么办”很多人会立刻说“加Synchronized或Lock”。加锁确实能让同一时刻只有一个线程扣库存但如果你说“在服务里加个分布式锁”面试官八成会继续问锁的粒度是什么锁的key怎么设计锁挂了怎么办这些都是真实项目里回避不了的细节。如果锁直接加到整个方法上那等于把库存扣减的并发能力锁死到1秒杀场景下这个方案直接不可用。4.2 第二版方案数据库层面的原子扣减更靠谱的方案其实是在数据库层面用一个原子操作完成“判断扣减”update stock set count count - 1 where sku_id ? and count 0;这个SQL的巧妙之处在于count 0这个条件放在where里本身就充当了并发防线。如果库存已经为0update就匹配不到行影响行数为0代码里根据影响行数判断扣减是否成功即可。数据库的行锁会让并发的多个update排队执行因此这个方案在单库场景下是不会超卖的。这个版本解决了并发问题但有一个隐忧数据库的更新操作吞吐量有限如果QPS很高数据库行锁等待和事务提交会成为瓶颈。我实际测过单库单表在普通配置下也就支撑几千到一万左右的秒级更新这还取决于SQL复杂度和服务器配置。所以这个方案适合中小流量但对于秒杀这种瞬间几十万QPS的场景还需要继续演进。4.3 第三版方案Redis预扣减加异步对账高并发秒杀场景的标准打法是用Redis做前置扣减用数据库做最终落库。具体分三步第一步提前把库存加载到Redis。可以用String结构存一个skuId:stock的键或者用Hash结构存多个SKU的库存。第二步扣减时执行一段Lua脚本保证判断和扣减的原子性local stock redis.call(get, KEYS[1]) if tonumber(stock) 0 then return -1 end redis.call(decrby, KEYS[1], ARGV[1]) return 1这段脚本的核心价值是把“读库存-判断-扣减”整个流程放进Redis的单个命令执行周期里。Redis是单线程模型所以并发请求会被串行执行不会出现超扣。Lua脚本在Redis里是原子执行的这一点是这个方案能防超卖的根基。扣减成功之后通过MQ发送一条消息通知订单服务异步落库数据库里的库存作为最终对账的依据。库存数据在Redis里可能会和数据库出现短暂的不一致需要通过定时任务或者消息对账来最终修正。这个方案我到今天依然认为是应对超高并发的正道但我要提醒你在面试中讲这个方案一定要主动说明两个代价第一Redis和数据库之间的一致性保障变复杂了需要引入对账机制第二Redis本身也可能宕机所以生产环境需要主从加哨兵或者集群。你把这些代价讲清楚了面试官才会觉得你是真的懂而不是背了一个“秒杀四件套”。4.4 面试追问环节超卖、少卖、补偿怎么答讲完方案面试官一般会追加追问我来列举几个高频追问以及应该怎么应对。第一个追问“如果Redis和数据库的库存不一致了怎么办”标准的回答思路是引入对账机制定期比对Redis里的扣减流水和数据库里的订单流水把差异捞出来修正。说“定期”可能显得不够严谨你可以补充说明对账的频率和触发时机比如每5分钟跑一次离线任务或者基于MQ消息的延迟队列做准实时核对。第二个追问“用户扣减成功了但订单后续创建失败库存要不要回补”当然要回补回补方案是拿到订单创建失败的信号后发一条补偿消息把Redis库存加回去同时更新数据库库存状态。这里要强调回补操作也要做好幂等防止消息重试导致库存多加。第三个追问非常高级只有做过真实线上系统的面试官才可能会问“同一个用户连点两次怎么防止他一个人扣两次库存”这个问题的本质是请求幂等解决办法是给用户的每次请求生成一个全局唯一的请求ID扣减前先查流水表是否已经处理过这个请求ID处理过就直接返回不再扣减。数据库层面对request_id加唯一索引这样并发情况下即使两个请求同时进来也只有一个能插入成功。5. 订单超时关闭——延迟消息到底应该怎么选5.1 三种实现方式的对比没有银弹订单超时自动关闭不同体量的系统有不同的实现思路。我把它梳理成三种方案对比按照复杂度从低到高排列方案实现思路优点缺点适合场景定时任务扫表每N分钟扫一次订单表把超时订单批量更新简单直接无额外中间件扫表有延迟数据量大时对数据库有压力日订单量万级以内延迟消息队列下单后发送一条延迟消息消费端到期处理延迟精度高削峰填谷需要引入MQ消息量大会有堆积问题中大型电商时间轮在内存里维护时间轮定时触发回调高精度、低延迟不依赖外部组件进程重启状态丢失需要配合持久化单机高并发场景其实还有一个方案——Redis过期键监听但实际项目中不建议作为主力方案因为Redis的过期事件消息不保证可靠投递而且从键过期到收到通知有时间差生产环境里只适合做辅助兜底。5.2 定时扫表的边界问题与优化方案很多候选人觉得定时扫表太“低级”其实不是方案低级而是很多人不知道把定时扫表优化到什么程度。我先说一个连很多工作两三年的开发都容易忽略的点定时扫表不能做全表扫描必须让查询走索引。扫描的SQL一定要遵循最左前缀原则去命中订单创建时间或者超时时间这个索引字段select id, order_no from t_order where status UNPAID and created_at date_sub(now(), interval 30 minute) limit 1000;注意这里我只取了id和order_no没取全字段。批量任务的扫描范本就该这么设计一次只取一小批主键拿到主键后分批执行更新更新完再取下一条。这样既不会一次性加载过多数据撑爆内存也不会长时间锁住大量行。如果有更深一步的性能需求你可以考虑引入游标分页把where created_at ?和order by id组合起来走(status, created_at)复合索引。我把这些细节展开给读者最想强调的一个思路是——任何定时任务方案都要重点设计“扫描范本的边界”避免全表扫描对数据库的冲击。5.3 状态机设计订单状态靠什么往前推订单超时关闭是个业务动作但它背后藏着一个更重要的设计——订单状态机。最常见的状态模型是待支付→已取消/已支付→已发货→已完成。任何一个状态流转都必须有触发源和前置条件不能随随便便从“已支付”跳到“已取消”。代码层面可以用一个枚举类把状态机和允许流转的动作放在一起我用一个精简版的update条件来演示状态变更不能只按“当前状态等于某值”去更新而要把前置状态作为where条件一起带上防止并发下状态被覆盖。update t_order set status CANCELLED, cancel_time now() where order_no ? and status UNPAID这个更新的巧妙之处在于它相当于把状态机的“前置条件”下沉到了数据库层。就算支付超时关闭任务和用户手动取消同时触发也只有一个能把状态从“待支付”改成“已取消”另一个会因为影响行数为0而失败——这就是状态机设计里最核心的“条件更新”思想。6. 并发编排的常考点CompletableFuture如何优雅解决“等好几个异步任务”6.1 为什么面试官爱考CompletableFuture很多场景题的最后一问会落到代码层面“一个页面要渲染N个模块每个模块的数据都来自不同接口你怎么设计才能让响应时间最短”。这类题的最佳实践就是CompletableFuture。Java 8之后CompletableFuture是处理异步编排的标准手段。它解决的问题非常明确多个异步任务之间有依赖关系或并行关系如果硬用Future.get()一个个等性能就退化成串行了。场景题里只要牵扯到接口聚合、多方调用、批量处理就会自然而然地问到它。6.2 一个典型编排场景的代码演示拿一个最典型的场景举例查询一个商品详情页需要同时获取商品基本信息、库存信息、商家信息、推荐商品列表四个接口互不依赖最后汇总返回。串行调用总耗时是四个接口耗时的总和用CompletableFuture并行调用总耗时约等于最慢的那个接口。CompletableFutureProductInfo productFuture CompletableFuture.supplyAsync(() - productService.getProduct(productId), executor); CompletableFutureStockInfo stockFuture CompletableFuture.supplyAsync(() - stockService.getStock(productId), executor); CompletableFutureMerchantInfo merchantFuture CompletableFuture.supplyAsync(() - merchantService.getMerchant(productId), executor); CompletableFutureListRecommendInfo recommendFuture CompletableFuture.supplyAsync(() - recommendService.getRecommend(productId), executor); CompletableFutureDetailVO detailFuture CompletableFuture .allOf(productFuture, stockFuture, merchantFuture, recommendFuture) .thenApply(v - { DetailVO vo new DetailVO(); vo.setProduct(productFuture.join()); vo.setStock(stockFuture.join()); vo.setMerchant(merchantFuture.join()); vo.setRecommend(recommendFuture.join()); return vo; }); return detailFuture.get(3, TimeUnit.SECONDS);这段代码的关键点是allOf——它把四个并行任务合并成一个等所有任务都完成后再做汇总。第3秒超时这个get非常关键因为任何一个下游接口如果卡死不能让用户的请求无限等待必须兜底降级。你在面试中写代码时最后这个超时时间一定要带上这是细节加分项。6.3 面试追问线程池怎么配、异常了怎么办每次有人在我面前写CompletableFuture我基本都会追问三个问题你也可以拿这三个问题自检一下掌握程度。第一个问题supplyAsync不传线程池的话用的是哪个线程池答案是默认的ForkJoinPool.commonPool()它是全JVM共享的并发度默认是CPU核数减1。如果所有业务异步任务都往里丢流量一上来就会把公共池打满导致其他无关代码也变慢。所以我的习惯是永远自定义线程池传入supplyAsync不用默认的。第二个问题如果其中一个任务抛异常了allOf会怎样这里有个坑allOf不管任务成功还是失败都会等但异常信息不会主动抛出来必须调用join()或者get()的时候才会暴露。所以建议配合exceptionally或者handle做兜底给每个子任务设置默认值避免一个模块挂了拖垮整个页面。第三个问题线程池参数怎么定我会把核心线程数设为机器核数的2倍左右队列长度根据接口的尖峰流量来评估拒绝策略用CallerRunsPolicy让处理不过来的任务退回调用线程执行至少不会丢失请求还能天然起到背压效果。7. 面试现场的经验之谈——候选人常踩的坑和实用的建议7.1 听听那些一听就露馅的“背答案”痕迹我来面试别人做了很多年经常在场景题这部分听到千篇一律的答案。这里我挑三个最典型的“背答案”痕迹大家也可以对比一下自己有没有类似问题。第一个是不假思索地堆名词。问怎么防超卖立刻就答“Redis加锁、MQ削峰、Sentinel限流”但问锁的粒度、key的设计、Redis挂了怎么办就支支吾吾说不出细节。名词本身没有价值有价值的是你为什么不选别的方案。第二个是从不主动谈代价。方案讲得天花乱坠但自始至终没有一句提到这个方案的缺点。真实系统里任何技术选型都有取舍面试官想听的就是你知道自己方案的天花板在哪里。第三个是完全忽略异常路径。问订单超时关闭的方案从头到尾只讲正常流程怎么关单完全不提消息丢了的补偿、任务重复执行的幂等、多实例下任务分发会不会重复扫表。这三个问题其实问一个就能看出来候选人到底有没有线上经验。7.2 面试官真正想听的“追问应对”长什么样场景题考察的其实不是标准答案而是你跟面试官之间来回交锋的应对质量。这里我说一个我自己招人时印象非常深刻的反差。同样问“库存扣减怎么防超卖”一个候选人直接答update stock set count count - 1 where count 0问他万一Redis也扛不住怎么办他想了一会儿说“那就限流丢请求”。这个回答理论上没错但显得很粗糙因为倒垃圾式的“丢请求”虽然保住了系统却也损失了所有用户。另一个候选人讲完数据库条件更新之后主动补充了一句“如果库存是热点数据单库扛不住我会把扣减流量前置到Redis用Lua脚本做原子扣减然后异步把扣减结果同步到MySQL。Redis和MySQL的不一致我会用对账任务兜底。”一句主动的表达把方案的深度、广度、可靠性全讲到了。我当时心里的评价就是这个人值得进下一轮。7.3 给准备场景题的候选人几条实在建议最后结合我自己准备和面试的经验给正在看这篇文章的读者几条实在的建议。第一刷场景题的核心不在“刷”而在“拆”。每天找一道经典题不要急着看答案先自己花15分钟按四步法走一遍再去看别人的方案对比自己漏了哪个环节。十五分钟的独立思考效果远好于刷十道题的参考答案。第二表达顺序比答案更重要。面场景题时不要张口就扔方案先把你的思路框架说出来。“我先确认几个边界然后从数据一致性、性能、可用性三个角度给方案”——这句话会瞬间提升面试官对你判断力的认可。第三多问自己“如果挂了怎么办”。这是练就真实系统设计能力最快的方法。每个方案写完都问自己三遍要是Redis挂了怎么办要是MQ挂了怎么办要是数据库挂了怎么办。能把这三个问题回答好你的方案在面试里基本就稳了。第四代码题一定要动手写不能只看不练。CompletableFuture、手写LRU、三个线程交替打印这些高频编码场景题建议在本地IDE里运行过至少一遍光在脑子里过代码和实际跑通完全是两回事运行过程中你会踩到很多“面试时根本想不到”的细节问题。场景题这条路没有什么捷径可走唯一的路径就是把你学过的知识点放到一个个具体业务里去反复验证。练得多了你会发现那些看起来五花八门的题目背后其实是同一套思维方式——只要把边界问清楚、难点识别出来、方案讲明白、异常兜好底任何场景题都难不住你。

Java面试场景题全解析：从库存扣减到CompletableFuture的实战框架

相关推荐

Java GUI智慧公交系统开发：Swing界面、JDBC数据与多线程调度实战

Claude Code Router（CCR）Fusion 自定义 MCP 工具与文生图/视频生成实战指南

C++20 std::ranges 管道性能探秘：策略内联与编译期优化

更多资讯

HyperFrames v0.7.89：缓存目录的 Watch 过滤与项目签名隔离——预览刷新循环的根治方案

Sourcetrail 代码可视化工具教程：三步画出陌生代码库的符号关系图

ML-For-Beginners 聚类模块实战：用 K-Means 与数据可视化分析尼日利亚音乐品味

SpringBoot+Vue考务报名系统设计与实现全解析

Pretext：用语义化写作搞定长文档多格式排版引擎

Hermes Python：面向生产的Agent运行时契约框架

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？