“蘑菇街2019届校招后端笔试题”——第一次看到这个标题的人大概率会把它当成一份早就过期的试卷。移动互联网的招聘节奏一年一个样2019届的题放在现在还能有多少参考价值我的观点恰恰相反校招笔试题最经得起时间检验的从来不是具体题目而是题目背后那套考察逻辑。蘑菇街作为电商公司后端笔试的命题思路非常典型工具层面的知识只占一小部分大部分分数压在业务场景下的计算机基础能力上比如并发、存储、缓存、分布式。这篇文章会把这类笔试的科目权重、高频考点、典型题目方向和回答思路逐一拆开按科目讲清楚。无论你是马上要参加校招的应届生还是想系统补基础的后端新人都可以把这份拆解当作指向性的复习提纲。原始试卷内容没有公开所以我会结合电商后端岗位笔试的常见命题规律来还原考察重点方向性参考价值是很高的。1. 电商后端笔试的科目权重与题型结构1.1 笔试的筛选逻辑和面试不一样先明确一件事笔试不是面试的缩小版。面试是判断“这个人能不能共事”笔试是海选目标是在几百上千份简历里快速筛出基础扎实、具备工程潜力的人。所以笔试题普遍标准化考察内容覆盖面广很多题目看起来“偏基础”但基础题恰恰最能拉开差距。电商公司又和纯粹的大厂不太一样。大厂笔试算法题占比很高电商公司的笔试题在算法之外还会重点考察业务场景相关的基础知识——商品、订单、库存、营销、支付这些场景决定了后端笔试会大量出现并发编程、数据库、缓存、消息队列相关的考点。这不是巧合而是业务形态对技术要求的具体投射。1.2 高频科目权重参考表我按常见电商后端校招笔试的科目分布整理了一张权重参考表。这不是哪一年的官方数据而是基于多家电商公司笔试规律的经验估算方向可以参考具体比例以实际招聘为准考察科目估算权重典型题型考察能力Java基础与并发编程25%单选/简答/编程线程安全、集合、语法基础数据库MySQL为主15%简答/方案设计索引、事务、调优缓存Redis为主15%简答/方案设计缓存一致性、常见问题网络与操作系统10%单选/简答TCP/UDP、HTTP、进程线程分布式与消息队列10%简答/设计分布式事务、消息可靠性算法与数据结构20%编程题编码能力、复杂度分析其他Linux、设计模式等5%单选/判断工程基础素养1.3 从题型反推考察目标分析过这套权重之后你会意识到电商后端笔试的核心目标是找到两类人一是计算机基础扎实的人二是能快速理解业务并把技术落地到业务场景的人。前者靠算法题和基础题筛后者靠场景化简答题和设计题筛。所以复习的时候别只盯着一类题型。见过不少同学刷了三个月LeetCode算法题能拿高分却在“库存扣减如何保证线程安全”“如何设计一个秒杀系统”这类场景题上答得很空。反过来说只背八股不刷题也走不通笔试的编程题过不了后面全是零。平衡这两块才是这套笔试题真正想要你具备的能力。2. 并发编程题库存扣减如何暴露线程安全问题2.1 一个典型的并发编程笔试题电商后端笔试里“多线程同时扣减库存如何保证安全”几乎是绕不开的题。它可以是选择题给出几种写法让你判断哪个正确也可以是简答题让你写出一个线程安全的扣库存方法还可以升级成编程题直接实现一个限量秒杀的扣减逻辑。这道题的高频程度本质上是由电商业务决定的。任何商品的下单流程都涉及库存扣减并发高、一致性要求严一旦写错就是超卖。所以它不是单纯考synchronized怎么用而是考你面对真实的业务约束时能不能选择正确的并发方案。2.2 synchronized 和 ReentrantLock 的区别怎么答才完整最基础的答法是把两者区别列出来。synchronized是JVM层面的关键字不需要手动释放锁ReentrantLock是JDK提供的API需要显式lock和unlock一般配合try-finally使用。这两点谁都能说出来想拿分得继续往下答。ReentrantLock的优势在于灵活。它可以响应中断——lockInterruptibly线程在等待锁时可以被打断可以设置超时——tryLock(timeout)避免死等支持公平锁避免线程饥饿还可以配合多个Condition实现精细化的等待通知机制。这些特性在库存扣减场景下很实用比如高并发时用tryLock超时直接返回“活动太火爆”而不是让线程全部阻塞排队。回答时如果能主动给出场景选择说明你是真的理解而不是背了面试题。2.3 CAS的局限与AtomicInteger的适用边界再加一层深度的话题目会升级成用AtomicInteger做库存扣减行不行答案是可以但有边界。AtomicInteger底层是CAS无锁并发在低竞争场景下性能很好但它只能保证单个变量的原子性解决不了复合操作的问题。比如“检查库存是否充足再执行扣减”这两步如果用AtomicInteger分别做中间状态就可能被其他线程插进来。还有一个很多人忽略的细节——CAS存在ABA问题。线程A读到库存是10线程B扣到9又加回10线程A再进行CAS时会认为库存没变过继续操作。大部分业务场景下ABA的危害不明显但需要知道它的存在以及如何规避。这一点在简答题里主动提出来印象分会好很多。2.4 从题目到工程库存扣减的三种实现笔试里能拿分的答案往往不是只写一种方案而是给出方案对比和取舍。我一般建议按这个层次回答单机场景直接用JVM锁比如分布式锁太重的时候可以用synchronized或ReentrantLock也可以用AtomicIntegerCAS做无锁方案适合扣减数量固定且竞争不激烈的场景。单库场景数据库Update库存时带条件判断比如UPDATE stock SET count count - 1 WHERE id ? AND count 0利用行锁和受影响行数判断是否超卖。这是最稳妥的兜底方案。分布式场景单机锁和数据库锁都跨不了多个服务实例需要引入Redis分布式锁或Redis Lua脚本原子扣减或者使用数据库分布式事务。至于具体怎么选要结合并发量、一致性要求、团队运维成本综合判断。这样把场景一拆答题层次感就出来了。面试官看到这种答案会认为你不只是在背锁的用法而是真正考虑过业务落地。3. JVM考点从内存区域到线上故障定位3.1 笔试题里最常见的JVM题目JVM在电商后端笔试里占的比重不算最大但几乎每年都会出。常见的问法有三个方向JVM运行时内存区域划分、垃圾回收机制、OOM场景分析。这几个点在简答题里出现频率极高。这个板块为什么值得花时间复习因为它直接关联线上问题。电商系统最怕的就是服务突然OOM、GC频繁导致接口超时。笔试考JVM本质上是在考察你能否在将来的生产环境里定位和解决这类问题。很多同学把JVM当成纯理论去背其实亏了把它当成一门“故障排查工具”来学效率会高很多。3.2 内存区域题目的丢分点“请简述JVM运行时内存区域哪些区域会出现OutOfMemoryError”这道题看似基础丢分点却很多。堆、虚拟机栈、本地方法栈、程序计数器、方法区JDK8之后是元空间这五块大部分人都能写出来但细节才是区分度所在。比如虚拟机栈会抛出StackOverflowError和OutOfMemoryError这两者什么区别堆内存溢出通常怎么通过堆转储分析方法区在JDK8以后改成元空间使用本地内存默认情况下受物理内存上限约束——这些细化点很多人答不全。另一个容易漏的是程序计数器是唯一不会OOM的区域。这些细节在选择题和判断题里经常当作干扰项出现。3.3 GC题型的两种问法GC题目一般有两种问法。第一种是概念型垃圾回收如何判断对象已死答案要落到可达性分析而不是引用计数。能说出来GCRoots包括哪些对象虚拟机栈中引用的对象、静态变量引用的对象、本地方法栈中引用的对象等才算完整。顺带还要解释为什么不用引用计数——循环引用问题。第二种是场景型线上系统频繁Full GC可能是什么原因如何排查这种题的答案路径一般是先通过jstat观察YGC/FGC频率和耗时再通过jmapdump堆内存用MAT分析对象占用重点排查大对象、静态集合类、资源未关闭等问题。把命令和排查步骤写出来说明你真的处理过这类问题而不是只会背概念。3.4 把OOM题答成排查思路关于OOM笔试里最爱问的是“堆内存溢出如何排查”或者“哪些情况会导致OOM”。准备这类题时不要只背几个名词要整理出一条完整的排查链路确认异常类型和发生区域堆溢出还是元空间溢出查看服务启动参数里的-Xmx、-Xms配置是否合理用jmap -dump:formatb,fileheap.hprof导出堆快照用MAT或VisualVM分析大对象和内存泄漏嫌疑点结合代码定位到具体业务逻辑比如把整个文件导进内存、循环创建对象未释放。这套排查思路记下来不仅笔试能拿分以后线上出问题你也能照方抓药。4. MySQL索引与事务数据库题如何答出区分度4.1 为什么索引题几乎必考数据库是电商后端笔试的固定板块其中索引又是最高频考点。原因也不难理解电商系统几乎所有的核心链路——商品查询、订单列表、库存判断——都依赖MySQL的高效查询。而索引设计直接决定查询性能这是后端开发最基本的看家本领。索引考题有一个特点概念题少应用题多。它很少直接问你“什么是索引”而是给你一个表结构再给你一条SQL让你分析这条SQL为什么慢、怎么优化。这种命题方式非常贴近实际工作也是区分“背过八股”和“真会调优”的分水岭。4.2 B树、聚簇索引、回表查询的完整回答链条一道完整的索引题通常会从“InnoDB为什么用B树作为索引结构”问起。完整回答要覆盖三层磁盘IO越少越好B树的层级低、每个节点能放更多索引项查询少数几条数据时IO次数少范围查询方便叶子节点用双向链表串联可以高效遍历区间数据相比哈希索引B树支持排序和范围查询。再往下就会被问聚簇索引和二级索引。InnoDB的主键索引就是聚簇索引数据行直接存在B树叶子节点上二级索引叶子节点存的是主键值所以通过二级索引查数据时如果想要的列不在索引里就需要拿着主键再去主键索引树查一次这个过程叫回表。要避免回表可以用覆盖索引——把查询需要的列都放进索引里比如订单表上建立(user_id,status)联合索引查询这两个字段时就不用回表了。这个知识链条复述下来索引题至少能拿八成以上的分。4.3 事务隔离级别与MVCC的连问套路事务题也是高频板块尤其爱考隔离级别。MySQL默认隔离级别是可重复读这个要记准。四个隔离级别解决的问题——脏读、不可重复读、幻读——要能说清楚各自含义特别是幻读的定义。多数人在这一题丢分是因为说不清可重复读为什么能解决部分幻读。这里要带出MVCC。InnoDB的可重复读通过MVCC实现每条事务会生成一致性读视图通过undo log版本链和ReadView控制当前事务能看到哪些版本的数据从而避免同一事务内两次普通查询结果不一致。但要注意MVCC解决的是快照读下的幻读问题如果事务里使用SELECT ... FOR UPDATE这种当前读仍然可能出现幻读所以还需要间隙锁来辅助。能把MVCC和当前读、快照读的区别讲清楚这道题就真正答透了。4.4 慢SQL调优题笔试题里的压轴问很多电商笔试题里有一道综合性的慢SQL调优题给出一张订单表和几条慢查询SQL让分析原因并给出优化方案。这类题本质上是把索引、执行计划、分页、表设计串到一起考。建议按这个顺序作答先看SQL是否命中索引。用EXPLAIN看type字段如果出现ALL全表扫描优先考虑是否能在WHERE条件字段建索引。再看索引是否失效比如对索引列使用了函数计算、隐式类型转换、LIKE以%开头都会导致索引失效。然后是排序和分页文件排序会导致性能下降ORDER BY字段尽量也建进联合索引里。深分页问题也同样高频LIMIT 100000, 10这种写法在数据量大时非常慢可以用书签方式——先通过WHERE条件定位到上次查询的最后一条ID再用ID条件取下一页。把这些点答出来回答就会显得很完整、很落地。5. Redis与缓存一致性电商场景的高频考点5.1 缓存穿透、击穿、雪崩三个概念别只背定义Redis题里最经典的三件套缓存穿透、缓存击穿、缓存雪崩。这三个概念不是背定义就能拿分的往往题目会给出一个电商场景让你指出属于哪种情况并给出解决方案。穿透是查询一个一定不存在的key导致请求直接打到数据库。解法通常是布隆过滤器或者对空结果做短时间缓存。 击穿是某个热点key突然过期大量请求瞬间越过缓存打到数据库。解法可以是互斥锁也可以用“逻辑过期”——缓存中不设置物理过期时间而是带一个逻辑过期时间后台异步刷新。 雪崩是大量key同一时间集中过期或者Redis服务整体不可用。解法是过期时间加随机值分散以及做Redis高可用架构。关键点是概念要能区分方案要能落地。死记定义碰到场景题就会露馅。5.2 缓存与数据库一致性方案面试官想听到什么缓存一致性是电商笔试里的高分值题目几乎每年出现。一个典型的问法是更新数据库和更新缓存的顺序应该先操作哪个现在业界讨论最多、也相对推荐的方案是先更新数据库再删除缓存。为什么不是先删缓存再更新数据库因为先删缓存会导致缓存和数据库之间有一个时间的空窗期期间请求可能把旧数据写回缓存造成数据不一致。而先更新数据库、再删除缓存虽然也存在短暂不一致的风险但概率相对更低而且可以通过延迟双删、消息队列补偿等手段兜底。严谨一些的团队还会落地方案通过监听MySQL binlog比如Canal来异步删除缓存把缓存更新和业务代码解耦。回答时如果能对比几种方案的优缺点说出为什么选这个而不是扔出一个名词得分会明显不一样。5.3 Redis题目的进阶方向分布式锁的坑分布式锁在笔试里属于进阶考点但近年来出现频率越来越高。常见问法是如何用Redis实现分布式锁这里有一个容易踩坑的点很多人直接回答SETNX加锁、DEL解锁但这套方案有几个隐患。隐患一加锁后如果服务宕机锁没有过期时间会变成死锁。所以要用SET key value NX EX timeout一条命令同时设置过期时间。 隐患二锁过期时间设置太短业务还没执行完锁就自动释放了其他线程就可以拿到锁。解决方案是锁续期比如Redisson的看门狗机制在锁快到期时自动续期。 隐患三误删他人的锁。删锁时不能只判断key存在就删应该用唯一值做标识比如UUID释放锁前先比对再通过Lua脚本原子执行比对和删除两步。这几个坑在笔试简答题里主动讲出来就已经不是在背题了而是真的踩过坑才会有这种警惕性。6. 分布式与消息队列拉开分数差距的知识板块6.1 为什么电商笔试题里总出现消息队列电商后端笔试里消息队列相关题目出现的比例越来越高原因和电商业务形态强相关。一个下单流程如果全部同步执行——扣库存、加积分、发短信、更新订单状态、推送物流信息——接口延迟会高得离谱大促期间数据库连接也会被打爆。消息队列在这里起到两个核心作用削峰填谷和系统解耦。把非核心链路异步化比如下单成功后发送一条MQ消息由消费者去处理积分、短信、物流通知等操作。所以笔试题一般会直接给一个电商场景问下单成功后你如何设计异步化方案答的时候要能说出选了哪种MQ、为什么选它以及消息从生产到消费中间可能出的问题。6.2 消息可靠性传递的三个阶段围绕消息队列面试官很喜欢问“消息丢失问题如何解决”。这个问题其实有三个阶段生产者发送消息到Broker、Broker存储消息、消费者从Broker拉取消息。生产阶段要开启生产者确认机制比如RabbitMQ的publisher confirm发送失败可以重试。 存储阶段要配置持久化确保宕机后消息不丢同时可以考虑镜像队列或者多副本机制。 消费阶段要关闭自动ack改成手动ack处理成功后再确认否则消息会被重新投递。 把三个阶段分别答清楚再补一句“还可以通过补偿机制兜底比如定时扫描未完成任务”整个答案的完整度会高很多。6.3 分布式事务的典型问法分布式事务是另一个大考点。典型问法是“一个下单操作涉及订单服务和库存服务如何保证两个服务的数据最终一致”这种问题的正解方向一般落在最终一致性上。笔试题一般不需要你完整实现2PC或TCC但要知道几个主流思路的优缺点。2PC本地事务用的是二阶段提交强一致性但性能较差、协调者容易成为单点TCC是Try-Confirm-Cancel把业务操作拆成三个阶段灵活但实现成本高本地消息表方案是把消息记录和业务操作放在同一个本地事务里通过定时任务扫描和重发再结合消费者幂等最终达到一致。答题时表示自己知道强一致和最终一致的区别并选择合适方案就已经达到这个板块的基本要求。6.4 幂等性设计最容易被追问的一环幂等性和消息队列往往连着考。消息重复消费是常态因为网络超时、消费者宕机等原因同一条消息可能被投递多次。如果系统不做幂等处理就会出现重复加积分、重复扣库存等问题。幂等的常见做法有几个数据库唯一约束比如订单号加唯一索引重复插入直接报错或被忽略状态机校验比如订单从“待支付”到“已支付”的状态流转只允许一次业务唯一ID加去重表在处理请求前先查一下是否处理过。答幂等题时如果能结合前面说的场景提到“我们订单系统在消费消息时会先查订单状态已经支付就不再重复操作”就能把理论和实际串起来面试官会觉得你有真实场景的思考。7. 算法题与备考节奏最后一道关卡的应试策略7.1 校招笔试算法题的题型分布算法题在校招后端笔试里一般占20%-30%的分数一道题没写出来可能直接淘汰。电商公司的算法题通常不会特别偏门更多集中在基础数据结构和常见题型上。从命题规律看链表操作反转、合并、数组技巧双指针、滑动窗口、字符串处理、二叉树遍历、排序和查找、动态规划入门这几类是出现频率最高的。TopK问题也经常出现因为电商里有排行榜、热门商品这类业务场景。刷题时优先覆盖这些高频题型比盲目刷难题有效得多。7.2 刷题建议与时间分配这里分享一个实际验证过的备考节奏。提前三四个月开始每天两到三道题按类型做专项突破而不是随机乱刷。第一个月主攻数组、链表、哈希表第二个月主攻树、DFS/BFS第三个月开始动态规划、贪心最后一个月做套题模拟和总结模板。刷题的重心要放在中等难度题目上。见过太多人天天死磕困难题结果笔试连中等题都卡在边界条件上。笔试时间有限先把能稳稳拿下的题做对再谈突破难题。另外每一道题做完后要复盘复杂度面试官经常在编程题之后追问“这个解法的时间复杂度是多少”答不上来很可惜。7.3 我的个人备考体会最后说一点个人感受。准备这类校招笔试时最大的误区是追求“面面俱到”。市面上后端知识地图非常庞大从Java基础到微服务从网络到算法一个人想全部学完几乎不可能。更有效的策略是先抓高频考点把每个考点学透再往周边辐射。我见过不少同学简历上写着“熟悉分布式”“精通高并发”笔试基础题却答得磕磕绊绊。反观那些看起来只掌握“基础三板斧”的人反而因为每个知识点都能落到实处而顺利晋级。笔试题的考察逻辑就是这样——它不要求你什么都会但要求你会的东西真的能用。沿着这个思路去准备哪怕你面对的不是蘑菇街的题目而是任何一家电商公司的后端笔试题心里都会更有底。