并发编程场景题攻略：从场景建模到高并发系统设计

聊并发编程的场景题，我发现很多人容易走偏。背了一堆八股文，什么锁升级、CAS、AQS、ThreadLocal，结果面试官问一句“你项目里怎么用的”，就卡住了。场景题恰恰是专治这种死记硬背的：给你一个业务场景，让你设计方案，考察的是你遇到真实并发问题时，能不能从业务约束出发，做出合理的技术选型。

这篇文章不列“50道面试题答案大全”，那玩意儿网上到处都是。我按自己的理解，把并发编程场景题拆成几类高频原型，每一类讲清楚出题逻辑、核心考点、方案套路，最后用一个完整的“模拟抢券系统”从头到尾推演一遍，包括参数怎么算、锁怎么上、队列怎么选。面过别人也被面过的老手都知道，这类题答好了，比回答一百个概念题都管用。

1. 并发场景题的出题逻辑：面试官到底在考什么

1.1 表面是题目，内核是场景建模能力

一个场景题丢过来，比如“多个线程同时扣减库存怎么办”，新手的第一反应往往是“加锁”。这个答案对不对？对，但基本等于没答。真正的考点不是你知道synchronized，而是你能不能在五分钟内把一个模糊的业务描述，拆解成技术约束。

举个很常见的例子：“用户下单时扣减库存，高并发下不能超卖，请设计一个方案。”这句话信息量其实很大：第一，库存是共享资源，涉及原子性；第二，“高并发下不能超卖”意味着有吞吐要求，不能粗暴串行化；第三，没说的隐含条件是网络延迟、可能的重试、数据库性能、缓存一致性。面试官想看的，是你有没有把这些模糊的条件转化成“原子操作、锁粒度、失败重试、一致性等级”这些具体技术词的能力。

我见过一个很典型的回答套路：上来就写synchronized扣库存，然后滔滔不绝讲JVM锁优化。这就是典型的“没建模就动手”。场景题的第一步永远是反问和澄清：允许少量超卖吗？同一用户能买多件吗？库存是多个SKU还是一整个商品？缓存要不要保证强一致？这几个问题问出来，面试官基本心里就有底了——这人遇事会想，不蛮干。

1.2 一道题的三个隐性打分点

场景题不像概念题有标准答案，但面试官的评分维度其实很固定，我总结成三个：约束识别能力、方案演进能力、边界兜底能力。

约束识别能力指的是你能不能把业务要求翻译成技术指标。比如“订单不能丢失”翻译过来就是持久化和确认机制；“补偿后不能超卖”翻译过来就是乐观锁或原子更新；“容忍短暂的不一致”翻译过来就是最终一致性方案。

方案演进能力是拉开档次的关键。初级选手直接给最终方案，老手会从最简单的实现说起，再逐步演进。这个过程中展示的是权衡能力：你知道什么时候用synchronized就够了，什么时候必须换分布式锁，什么时候连锁都不用靠队列。这种演进不是背步骤，而是脑子里有一条决策链。

边界兜底能力是最后一个隐性打分点。方案给出之后，面试官往往会追问“如果这台机器挂了”“如果Redis挂了”“如果消息重复消费”。很多人挂在追问环节，因为前面的方案只考虑正常路径，完全没做失败预案。场景题答得好的人，通常会在主方案之外主动补一句兜底策略，比如“库存扣减失败就走对账补偿”“缓存失效时用数据库兜底并做降级开关”。这一句，往往决定了你能不能拿到下一轮。

2. 四类必刷的并发场景题型与解题套路

2.1 共享资源竞争：从计数器到库存扣减

共享资源竞争是所有并发面试题的万法之源。核心场景一句话：多个线程同时读写同一个数据，怎么保证安全又高效。

这类题的关键是锁粒度。很多人的第一反应是用一条大锁把所有操作串行化。安全是安全了，性能却一塌糊涂。这里我建议按一个顺序来思考：能不能用无锁方案，比如单线程写加内存队列；不行的话，能不能用原子类或者乐观锁靠版本号冲突重试；再不行，能不能缩小锁的粒度，比如分段锁、分离读写锁。从无锁到加锁，从大锁到细分锁，这个思考路径本身就是回答的主体。

举一个最基础的例子，一个统计接口访问次数的计数器。用AtomicLong是正解，用synchronized也能跑，但面试官想看到的不是API选择，而是你明白为什么AtomicLong在多线程下更快——那是因为CAS循环在低冲突下开销极小，而且不会引起线程挂起。能把这个原理讲清楚，比背诵“CAS是什么”有价值得多。

2.2 突发流量削峰：秒杀与异步化思路

另一大类高频场景是突发流量。“一个商品限量100件，同一时间有十万人来抢”已经成了面试必考题。这类题的内核不是锁，而是削峰填谷。

秒杀链路如果全走数据库，哪怕只卖掉100件，那十万个并发请求也会把数据库压垮。所以标准套路是分层拦截：第一层在网关做限流，拒绝超出的流量；第二层用缓存预减库存，扛住瞬时流量；第三层异步落库，用消息队列把真正抢到的请求串行化处理。每一层过滤掉一部分流量，真正打到数据库的可能只有一两百个请求。

这里有个细节很多人答不好：为什么缓存预减库存能扛住十万并发？因为Redis单机就能跑每秒十万级读请求，而数据库行锁哪怕只锁一行，排队的时候请求一多也会拖垮连接池。所以削峰的本质不是把请求消灭，而是把高并发请求转换成低并发、可控的操作序列。面试时把这个转换过程讲清楚，比背十遍“消息队列削峰”要有说服力。

2.3 分布式锁与一致性：缓存与数据库的双写

到了微服务阶段，并发场景题必然上升到分布式。最常见的两个分支：分布式锁怎么实现，缓存与数据库数据不一致怎么办。

分布式锁的考点不在Redis的SET NX那条命令，而在锁的可靠性三层：第一层是加锁和解锁的原子性，必须用一条命令完成，不能用get再del两步；第二层是锁超时，防止持有锁的线程挂了导致死锁；第三层是锁的持有者标识，防止线程A的锁被线程B误删。能想到这三层，说明不只是在背命令，而是真的处理过锁的边界问题。

缓存与数据库双写的一致性，是评论区最容易被揪着问的场景。我的建议是：不要试图做到强一致，而是把“最终一致性”的路径和兜底讲明白。常规做法是先更新数据库，再删除缓存，延迟双删兜底。为什么不是先删缓存？因为先删缓存会导致缓存空窗期，查询直接打库，高并发下容易雪崩。这题的深度主要体现在你对空窗、失败、重试这几个细微处的处理是否到位。

2.4 本地并发治理：连接池、线程池与隔离策略

很多场景题最后会落地到“你的线程池怎么设计的”“连接池不够用怎么办”。这类题看着简单，实际上是对你真实编码经验的检验。

线程池的核心不是那几个核心参数怎么配，而是你有没有基于业务做过计算。IO密集型的任务，线程数一般按CPU核心数乘2左右来估；CPU密集型的，核心数加一就够。但更关键的是队列满了怎么办，拒绝策略是什么。很多人配线程池只配置corePoolSize和maxPoolSize，却忽略了队列长度与拒绝策略的联动关系，结果线上突然爆掉才发现兜底逻辑没写。

连接池的思路也是一样的。数据库连接池之所以被设计得比较保守，是因为连接本身是稀缺资源，每个连接背后都是一条真实的数据库会话。遇到连接池耗尽，第一反应不该是加大连接数，而是排查有没有慢SQL占用连接太久、有没有连接泄漏。我见过一个项目把连接池从20调到200，结果数据库被压垮了，根因其实是某条SQL没加索引。这类经验在面试里主动讲出来，很容易加分，因为它展示了你的排查思维，不只是配置思维。

3. 从场景到代码：一个抢券系统的完整推演

3.1 场景描述与需求边界

下面我用一个完整的模拟场景，把上面的套路串起来。场景是“某平台发放限量优惠券，共计1000张，每人限领1张，要求不能超发，阅读量大但抢券行为集中”。这个场景把并发编程的几大要素全占了：资源有限、高并发写入、幂等约束、缓存与数据库一致性。

在动手设计之前，我会先理清约束清单：不能超发是硬性要求；一人一券意味着要处理重复请求；抢券集中在活动开始的头几秒，需要一个削峰入口；领券结果不必极端实时，用户接受几秒内的延迟。有了这几个约束，方案选型就有了边界：普通数据库行锁显然扛不住瞬间流量，所以阻止直接操作库；允许异步落库，所以可以引入队列串行化处理；不能超发，所以必须在某个环节做精确的原子判断。

这里顺带说明一下，场景题里如果面试官没给“是否允许延迟到账”这个条件，你应该主动追问或自行假设说明。这种细节处理，往往比方案本身更能体现一个工程师的业务敏感度。

3.2 方案演进：从粗暴锁到分层治理

第一版我也跟很多人一样，直接在数据库上加锁。伪代码大概是这样的：

@Transactional public boolean grabCoupon(Long userId, Long couponId) { CouponStock stock = stockMapper.selectForUpdate(couponId); if (stock.getRemaining() <= 0) { return false; } stockMapper.decrease(couponId); couponMapper.insert(userId, couponId); return true; }

selectForUpdate能防超发，但问题也很明显：所有抢券线程在行锁上排队，数据库连接被长时间占用，TPS上不去。这个版本能在低并发下工作，但你在面试里拿出来，肯定会被追问性能瓶颈在哪里。

第二版改成两段式：先用Redis原子扣减库存，抢到的请求再异步落库。核心判断在Redis端完成，用Lua脚本保证检查库存和扣减库存是一个原子操作。伪代码长这样：

-- 原子扣减库存 local remaining = tonumber(redis.call('GET', KEYS[1])) if remaining > 0 then redis.call('DECR', KEYS[1]) return 1 end return 0

高并发下Redis比数据库锁快几个数量级，而且扣减成功的请求才进入后续逻辑。但到这里还没完，Redis扣成功不代表数据库一定写成功，所以还要加一个消息队列，让真正抢到的请求排队落库，数据库再根据自己的能力慢慢消费。

最终版的完整链路是：限流拦截 + Redis原子预扣 + MQ异步落库 + 对账补偿。限流保证系统不被无效请求打垮，Redis保证不超发，MQ保证数据库写入压力可控，对账保证极端情况下不一致数据能纠正。每一层的职责边界很清楚，面试时讲这个方案，就比单纯说“用Redis减库存”深了一个层次。

3.3 关键代码实现与参数计算

拉通链路之后，我把几个关键位置的代码和参数选择讲细一点，方便直接参考复现。

首先是限流层。这里我选的是令牌桶算法，简单理解就是系统按固定速率生成令牌，请求进来必须先拿到令牌才能继续，拿不到就快速失败。为什么不用计数器限流？因为计数器在窗口临界点会突然放行大量请求，令牌桶天然能把突发流量平滑掉。限流阈值我建议按Redis和MQ处理峰值的80%来设定，留出20%的余量防止抖动。

然后是Redis原子扣减。上面那段Lua脚本是核心，但还需要考虑超时时间和库存键的初始化。库存键建议提前预热到Redis，活动开始后不要再从数据库加载，避免慢查询。超时时间不要设得太久，几秒钟就够了，因为抢券请求的生命周期本来就很短。

再然后是异步落库。MQ消费者端要保证幂等：同一个用户同一张券，可能因为重试被消费两次，所以落库前要先查一次用户券记录是否存在。这个查询不能走缓存，直接查数据库唯一索引，用数据库的唯一约束兜底是最稳的。

最后是线程池参数。消费者端是IO密集型的拉取与写入，我给出一个估算方式，感受一下量级：假设每秒需要处理1000条落库消息，每条消息数据库写入耗时50毫秒，那么单线程每秒能处理20条，1000条就需要50个线程。再加入一些余量，我会把核心线程数设在60左右，队列容量设在2000，拒绝策略选择丢弃后走对账补偿。这样既保证了处理速度，又避免了队列无限积压导致OOM。

4. 面试表达与常见误区

4.1 先聊约束，再谈方案

很多人的场景题答不好，不是不懂技术，而是不会开场。一上来就报方案，容易显得鲁莽。我自己的经验是，回答场景题一定要有一个“澄清需求”的环节，时长控制在几十秒内。

比如面试官问“设计一个秒杀系统”，你可以说：我先确认几个边界，一是库存量级和并发量级大概是多少，二是抢购结果是否需要实时反馈，三是是否有渠道隔离要求。这三个问题问完，面试官就会知道你不是在背模板，而是在做真正的技术判断。

这个习惯放之四海皆准。并发场景题和算法题不一样，算法题输入输出是固定的，场景题的需求是模糊的，正因为模糊，才有讨论和权衡的空间。把模糊变成清晰，本身就是最值钱的产出。

4.2 高频追问的避坑清单

面试官最喜欢在场景题之后连环追问，我整理几个出现频率极高的坑，可以说每一个背后都有真实项目踩过。

第一个坑是“Redis扣减成功了，但落库失败怎么办”。经典错误答案是“那就回滚Redis”。听起来对，但回滚本身可能会失败，而且回滚之后其他线程可能已经抢走了那一个库存名额，导致数据漂移。更靠谱的思路是保底对账：定期比对Redis预扣记录和数据库真实记录，把差异修复掉。

第二个坑是“消息队列消费很慢，用户一直看不到结果怎么办”。正确思路是不要把所有用户都做同步反馈，抢到的用户给一个“处理中”的状态，消费完成后回调通知状态。把异步链路封装成带状态的订单流程，用户侧体验就不会被底层延迟拖垮。

第三个坑是“本地锁能不能替代分布式锁”。答案是分场景。单机部署、单进程内共享数据时，本地锁完全够用。一旦实例扩到多个，本地锁就锁不住其他机器上的线程了。这里要讲清楚的是“锁的作用域”，而不是背着说“分布式的永远更好”。用本地锁还是分布式锁的决策依据是故障域和资源域边界，这是很多候选人没想清楚的。

第四个坑是“为什么不用数据库乐观锁然后CAS重试”。乐观锁的版本号机制在低冲突时很好用，但是秒杀场景冲突率极高，重试成本会成倍放大。CAS适合冲突少的场景，冲突率高的时候应该换一种思路，不是重试，而是排队。这一个简单的判断，能直接把你和只会背CAS的人区分开。

4.3 一道题的十分钟叙事结构

聊完避坑，我再分享一段完整的答题框架，我在准备面试时经常用，十分钟的时间分配大概是：前两分钟澄清需求并给出约束假设，中间四分钟讲主方案，按流量入口、核心判断、异步落库三个环节递进，再花两分钟做容灾与一致性兜底，最后一分钟可以提一句改进方向。

这套结构的好处是节奏稳定。你不会在前半段把细节全倒出来，也不会到最后草草收场。每一分钟都有明确的任务，面试官跟着你的节奏走，不容易被打断追问或者产生“逻辑混乱”的印象。

这里也提醒一下，结构只是骨架，真正的血肉是你在每个环节里展示的判断依据。讲方案的时候不要只报名词，Redis、MQ、线程池人人都知道，你要讲清楚为什么在这个场景里选它，以及它的边界在哪里。能给出取舍依据的方案，才算讲完了。

5. 常见问题排查与速查表

5.1 并发问题排查的几条实用路径

实战中的并发问题，远比面试题的“标准场景”复杂，因为代码往往不是刚写的，而是在线上跑了好几个月才偶尔出一次问题。我把排查经验浓缩成几条实用路径。

第一，线程栈优先。并发问题多少都会在某个时刻留下线程痕迹，比如死锁、线程阻塞、锁等待。先拿到一份线程dump，搜索BLOCKED、WAITING状态，往往能直接锁定问题位置。我处理过一次假死问题，就是靠线程栈发现所有线程都卡在一个缓存锁上，几分钟就定位了。

第二，看监控指标曲线。并发问题经常是“量变引起质变”，比如某个时间点开始，请求RT突然上升，那大概率是线程池排队或者在等数据库连接。把CPU、内存、活跃线程数、连接池使用率四条曲线放在一起对比，一般都能看出规律。

第三，关注超时时间。很多并发问题的根因不是逻辑错，而是超时时间不合理。数据库连接池的获取超时设得太短，流量一高就疯狂报错；设得太长，请求堆积等待，用户又超时。排查时把各层超时时间梳理一遍，经常能找到“连锁放大”的原因。

面试里主动讲这些排查路径，会给人一种“你真的处理过线上问题”的信任感。这不是背模板能装出来的气质，建议平时多积累几个自己真实的排查案例，沉淀成小故事。

5.2 面试高频追问速查表

我按面试中的追问频率整理了一张速查表，把常见问题和我的回答思路放在一起，方便考前过一遍。

这张表不要死记硬背。我建议每位准备面试的读者，都对着自己的项目重新回答一遍这些问题，用自己的业务场景、自己的排查案例来组织答案。面试官并不期待标准答案，他们期待的是“这个候选人真的在自己动手解决问题的过程中，形成了理解和判断”。

说到底，并发场景题是面试中的放大器。你对并发理解得有多深，方案设计得多合理，边界考虑得多周全，都会在这种题里暴露得明明白白。与其焦虑“被问到不会的题怎么办”，不如把常见场景抽象成自己的一套决策框架，多问自己几个“为什么”，然后回到真实系统里去验证和改进。我自己的体会是，准备这类面试题最有用的物料，从来不是那些高度凝练的考题答案，而是你平时代码里写过的每一处锁、每一次重试、每一条取舍记录。