蘑菇街2019届校招的后端笔试题这几年经常被拿出来当成电商场景面试的参考样例。原因挺简单它不像一般公司那样只考纯内存题而是把电商业务里真正会遇到的场景揉进了算法、数据库和系统设计里考察的东西非常“后端”。我当时刷完这套题有一个很强烈的感受——它不是考你会不会写代码而是考察你面对真实业务压力时能不能拆解问题、选对方案、落地实现。这篇文章我想以这套题为引子把后端校招笔试的考察逻辑、高频考点、答题思路和备考方法完整拆一遍适合正在准备校招后端岗位的同学也适合想系统梳理后端知识体系、查漏补缺的初中级开发。我会尽量用“当年我踩过的坑”和“面试官真正想看到的东西”来讲不堆概念说人话。1. 笔试题整体结构分析我接触到的蘑菇街2019届后端笔试题整体分为四个板块客观基础题、算法编程题、数据库与SQL题、系统设计题。题型覆盖了Java基础、并发编程、网络协议、数据结构与算法、MySQL、缓存、消息队列、分布式一致性等多个方向。最典型的特征是几乎所有题目都有一个“电商业务场景”的外壳比如商品秒杀、订单状态流转、优惠券发放、购物车合并。这不是为了花哨而是蘑菇街这种电商公司筛选后端工程师时最看重的就是“技术为业务服务”的能力。1.1 考察范围与题型分布从考察范围来看这套题基本画出了电商后端校招的“标准地图”。客观基础题通常占30%左右主要考察Java语言特性集合、异常、泛型、反射、JVM内存模型与GC机制、并发工具synchronized、volatile、ThreadLocal、线程池、网络协议TCP三次握手四次挥手、HTTP与HTTPS、HTTP状态码。算法编程题占30%-40%难度介于LeetCode Medium到Hard之间但题型偏“数据结构组合”比如哈希表链表、数组滑动窗口、二叉树递归很少考纯数学题。数据库与SQL题占20%-30%重点围绕索引优化、事务隔离级别、MVCC、锁机制、慢查询分析展开。剩余的10%-20%是系统设计题通常给一个具体业务场景要求画出架构图、说清数据流向、指出可能出现的性能瓶颈和解决方案。这里我要多说一句很多同学把精力全部压在算法题上拼命刷题结果到笔试时发现基础题丢分严重。这套卷子的基础题部分其实比算法题更容易拉开分差。因为算法题大家都会刷但JVM里“对象一定在堆上分配吗”、synchronized和ReentrantLock的底层区别这类细节如果没有系统梳理过很容易在选项之间犹豫。我的建议是备考前期以算法为主临近笔试的前两周重心一定要转回基础知识和SQL题。1.2 蘑菇街这类电商公司出题的底层逻辑为什么蘑菇街的笔试题值得单独拿出来分析因为它的出题逻辑非常清晰后端工程师的核心职责是保证系统在高并发、大数据量下的稳定性、一致性和可用性。所以你看它的算法题不会让你去求一个数学公式的推导而是会给你一个“用户浏览商品列表”的场景考你如何实现一个带过期时间的LRU缓存或者给你一个“订单超时未支付自动关闭”的场景考你如何设计延迟队列。说白了它考察的是“业务抽象能力”和“技术选型能力”的结合。你在笔试中写的每一行代码面试官都会在心里问一个问题换到真实环境里这个方案能扛住吗这段逻辑在高并发下会不会出问题所以我对这套题的评价是它的价值不在于“押中了几道原题”而在于它代表了电商后端岗位对候选人能力模型的真实期待。你把这套题吃透了再去面其他电商公司淘宝、京东、拼多多、唯品会的核心后端岗位会发现知识重叠度极高。2. 核心知识点详解与答题要点基础题部分表面上看都是“八股文”但蘑菇街这套卷子的基础题有一个特点题干会刻意设置一个“看起来正确”的干扰项。比如问你volatile是否能保证原子性选项里会写“volatile可以保证复合操作的原子性”问你HashMap在多线程下是否会抛出ConcurrentModificationException选项里会写“HashMap是线程安全的”。这些坑其实是在检验你是否有真实的使用经验而不是死记硬背结论。所以我在讲这部分时不会只给结论我会把每个知识点的底层逻辑和易错点一起讲清楚。2.1 Java集合HashMap原理与线程安全HashMap几乎是所有后端笔试的必考点。蘑菇街的考题通常不会直接问你“HashMap的底层数据结构是什么”而是会给你一段代码比如多个线程同时往一个HashMap里put数据问会出现什么问题。正常的答案是JDK 1.7及之前并发put可能导致链表成环从而在下次get时造成CPU 100%死循环JDK 1.8之后由于引入了红黑树和尾插法死循环问题基本解决但数据丢失和size不准确的问题依然存在。这里我要补充一个容易被忽略的细节JDK 1.8中HashMap的扩容机制是并发环境下数据丢失的另一个来源。当两个线程同时检测到哈希桶数组需要扩容时它们会各自创建新数组然后线程A的结果直接覆盖线程B的结果导致部分数据丢失。所以Java官方才推荐在高并发场景下使用ConcurrentHashMap。而ConcurrentHashMap在JDK 1.8中放弃了Segment分段锁改用CASsynchronized锁住桶首节点这也是笔试的常考点。我建议你把JDK 1.7和1.8的HashMap差异列表整理出来把ConcurrentHashMap的put源码读一遍然后画出它“CAS检查-锁桶-插入/树化”的流程这样面试官深问的时候你也不慌。2.2 并发编程线程池参数与拒绝策略线程池这块蘑菇街的题喜欢考察对ThreadPoolExecutor核心参数的理解。一般会给你一个场景某个电商大促活动中系统需要在短时间内处理大量订单状态更新请求问你会如何设置核心线程数、最大线程数、队列容量。这时候如果你只是背“CPU密集型设N1IO密集型设2N”那基本就落入了出题人的陷阱。因为订单状态更新这个操作既有CPU计算状态机判断也有IO操作写数据库、发消息通知同时在高峰期会出现短时间的流量尖峰。我个人的回答思路是核心线程数设置为CPU核心数的一半左右最大线程数设为CPU核心数的2到3倍队列容量不要设太大比如500-1000拒绝策略选择CallerRunsPolicy而不是AbortPolicy。原因是订单状态更新是延迟敏感型任务如果直接抛出RejectedExecutionException可能导致用户看到“系统繁忙”的提示影响体验而CallerRunsPolicy会让提交任务的线程自己执行该任务相当于给了系统一个“自我减速”的机制。这个思路不一定是最优解但能体现出你有“业务导向”的思考方式。另外线程池的坑还有很多比如线程池复用导致ThreadLocal值串线、父子任务共用线程池导致死锁、shutdown和shutdownNow的区别等建议你把这些场景逐一在本地代码里跑一遍观察日志输出印象会非常深刻。2.3 JVM内存区域与GC判定JVM题在后端笔试中属于“高区分度”题目。简单的考法问你堆内存和栈内存的区别稍微难一点的考法会给你一段代码问你某个对象在什么时候可以被GC回收。蘑菇街这套题里有一道让我印象很深一个局部变量指向一个对象局部变量出了作用域之后这个对象就一定可以被回收吗答案是“不一定”。因为JVM的垃圾回收是基于“可达性分析”的局部变量出了作用域后它对应的栈帧中的Slot会被复用或清空但如果这个对象的引用被某个静态变量或者被另一个存活对象持有那它依然是可达的不会被回收。还有一类高频题是JVM内存区域特别是“对象在堆上分配一定是这样的吗”这种反常识题。HotSpot虚拟机中如果开启逃逸分析并且对象没有发生逃逸即不会被外部方法访问那么这个对象可能直接在栈上分配方法结束后栈帧弹出对象随之销毁不需要GC介入。这种属于优化型知识点笔试中出现率极高因为大部分人只学了“对象分配在堆上”这个粗浅结论。我的建议是把《深入理解Java虚拟机》第2、3章的内容吃透重点理解可达性分析、三色标记、对象分配过程、SafePoint的概念。不需要背一堆参数而是要把“JVM如何判断对象生死”的完整链路说清楚。2.4 计算机网络HTTP、TCP与连接管理网络题在后端笔试中占的比重不会太大但几乎必考。蘑菇街那年考了TCP为什么需要三次握手、四次挥手中TIME_WAIT状态的意义、HTTP/1.1和HTTP/2的主要区别。其中最有“电商特色”的是一道关于HTTPS的题用户在蘑菇街下单从点击“提交订单”到请求到达服务器中间涉及TLS握手问这个过程中客户端和服务端分别做了哪些操作以及TLS1.2和TLS1.3有什么区别。这块我的答题经验是不要只背书要结合抓包结果来记忆。你可以用Wireshark抓一次HTTPS请求的包亲眼看一看ClientHello、ServerHello、证书、密钥交换、Finished这些报文你就很难再忘掉TLS握手的过程。对于TCP的TIME_WAIT我会强调两个点一是它保证了最后一个ACK如果丢失服务端能重发FIN客户端能通过2MSL时间内的等待收到重发的FIN二是大量短连接场景下TIME_WAIT会占用本地端口导致新连接无法建立这也是为什么高并发服务端要开启tcp_tw_reuse在客户端侧有效或使用长连接。这套组合拳打出来面试官会觉得你不只是会背协议而是真正处理过线上问题。2.5 MySQL索引、事务与锁数据库是蘑菇街这套笔试题的“重头戏”也是电商后端面试的必考项。其中最常见的考法是给你一条SQL让你分析它是否命中了索引或者让你看一个慢SQL找出优化的方案。这类题看起来简单实际上非常考察细节。蘑菇街的考题中有一个经典场景order表有联合索引(user_id, status, create_time)查询条件是“SELECT FROM WHERE user_id? AND create_time BETWEEN ? AND ?”问这条查询是否会走联合索引。答案是会走但只能用到索引的前缀列user_id后面的status不会用到create_time由于存在范围条件也不是索引使用的最优方式。如果还需要对结果排序那么文件排序filesort可能成为一个性能瓶颈。这种题在笔试中考察的其实就是“最左前缀原则”的理解深度。我在准备这类题时会专门用一组实验数据去验证创建一张100万行的表分别测试不同查询条件下Explain的输出观察type、key、rows、Extra列的变化。亲手做过一遍之后你对索引的理解绝对比只看文章要深入得多。事务隔离级别和锁机制也是重点。蘑菇街考过一道题在可重复读隔离级别下两个事务同时更新同一行数据会发生什么答案是后更新的那个事务会阻塞直到前一个事务提交或回滚。本质上是行锁的互斥。在此基础上还会延伸考察幻读问题以及InnoDB如何通过间隙锁Gap Lock来解决可重复读下的幻读。这里有一个细节只有在唯一索引等值查询且记录存在的情况下InnoDB才会退化为记录锁如果查询条件不是索引或者范围查询会加间隙锁或next-key lock这也解释了为什么有些更新操作会意外锁住一大片数据。我强烈建议你把“当前读”和“快照读”这两个概念搞清楚因为它们直接决定了你在可重复读下能不能看到其他事务新插入的数据。3. 系统设计题从“会写代码”到“会做方案”系统设计题是蘑菇街这类公司笔试里最拉开差距的部分。它不要求你写完整代码但要求你用文字、图表和逻辑表达出一个可落地的方案。通常会给一个场景比如“双十一大促期间商品详情页的QPS从平时的1000飙升到100000你会怎么做”或者“设计一个购物车系统要求支持多端同步、过期清理、价格实时计算”。这种题没有标准答案但面试官有一个默认的评分框架完整性是否能覆盖所有核心模块、合理性技术选型是否有依据、扩展性是否考虑了未来的容量增长。3.1 电商场景题秒杀系统的核心设计秒杀系统是我见过最经典的校招设计题蘑菇街也考过类似的方向题目大概是“设计一个秒杀系统需要支持高并发、防超卖、防刷单并且要在活动结束后及时释放资源”。这道题要拿高分不能只答“用Redis预扣库存”你必须把整个请求链路拆成几个阶段。我的答题思路是第一步把流量挡在系统入口之前。通过CDN和静态页面隔离把商品详情页做成静态页面动态请求只保留秒杀接口本身。第二步在Nginx层做限流比如对单个IP的访问频率限制到10次/秒同时对User-Agent和是否携带Cookie做简单判断把明显异常的请求直接拒绝。第三步在应用层加一道分布式锁使用Redis的SETNX命令确保同一时间只有一个请求能通过某个商品的秒杀入口但这个锁的粒度要尽量小按商品粒度而不是全局粒度避免不同商品之间互相阻塞。第四步把库存扣减放在Redis中使用Lua脚本保证原子性扣减成功后再发送MQ消息由下游服务异步落库。第五步订单创建和支付走异步流程前端通过轮询或WebSocket推送结果。这里有一个极其容易踩的坑很多同学会把库存扣减直接放到Redis事务或Watch/Multi中但Redis事务在集群模式下不支持跨节点事务而且WATCH在高并发下会出现大量重试性能反而不如Lua脚本。所以我的经验是直接用Lua脚本把“检查库存大于0 - 扣减库存 - 写入用户购买记录”这三步封装成一个原子操作Redis本身单线程执行Lua脚本天然保证原子性。这种细节如果能在答题里体现出来面试官会认为你确实有实战经验而不是临时背的方案。3.2 数据一致性与异步化订单超时关闭的经典解法说完秒杀再聊一个蘑菇街笔试出现过的高频系统设计题订单超过30分钟未支付自动关闭并释放库存。很多人的第一反应是“用定时任务每分钟扫一次订单表”但这在数据量大的场景下会有明显问题全表扫描慢、对数据库压力大、扫描间隔存在时间误差。比较合理的方案是分层处理第一层在用户下订单时把订单号写入一个延迟队列。实现方式可以是Redis的ZSETscore设为过期时间戳用一个专门的后台线程定期比如每5秒ZRANGEBYSCORE取出到期的所有订单逐条处理。线程数量不用太多一个就够了因为ZSET的range查询是O(logN)复杂度。第二层为了兼容Redis宕机的情况需要定期比如每5分钟把未支付订单的到期时间扫描一次只扫描status未支付且create_time小于当前时间-30分钟的数据并加上LIMIT限制防止一次拉取太多。第三层真正执行关闭操作时要调用库存服务回补库存并发送消息通知用户订单已超时关闭。这道题能拿高分的要点在于你要能说出“为什么不能只靠定时任务”“为什么延迟队列要选择Redis ZSET而不是简单的List”。因为List只能从一端写入从另一端取出时是FIFO顺序无法做到按时间优先级取出而ZSET支持按score排序天然适合延迟消息场景。如果你能再补充一句“生产环境还经常会用RabbitMQ的延迟消息插件或者RocketMQ的定时消息”那就更完整了。不过要注意RocketMQ的定时消息存在一个“延迟级别固定”的限制不能任意指定延迟秒数这在实际项目中也是需要权衡的点。3.3 缓存与DB一致性更新缓存的正确姿势很多后端笔试方案题里都会涉及缓存但如果只是写“先更新数据库再删除缓存”不会有太多加分。你要说清楚为什么不能“先删缓存再更新数据库”以及为什么“先更新数据库再删缓存”在极端情况下依然会有问题。简单说“先删缓存再更新数据库”的坑在于线程A删除缓存线程B查询请求发现缓存为空读取到旧的数据库值并回填缓存随后线程A更新数据库为新值导致缓存里一直是旧值。而“先更新数据库再删缓存”的坑在于线程A更新数据库期间线程B读到旧值并回填缓存之后线程A删除缓存这个窗口期非常短现实中发生的概率较低但依然存在。因此业界普遍采用“缓存延时双删”或者“订阅Binlog异步更新缓存”的方案。在笔试中我会建议你画一个对比表列出每种方案在一致性、可用性、复杂度上的得分然后给出结论中小流量场景下先用“先更新数据库再删缓存短延时双删”配合失败重试机制数据强一致要求极高的场景下考虑“基于Canal订阅Binlog删除缓存”或者“读写串行化”。关键是要让面试官看到你有“权衡”的意识而不是背了一个标准答案。4. 实操过程与核心环节实现笔试虽然是在线做题但备考阶段一定要动手实践。尤其是数据库SQL题和并发编程题纸上谈兵没有用。我建议你准备一个本地环境包含JDK 1.8、MySQL 5.7、Redis 5.0然后把我下面说的几个实操项目完整跑通。这对你做对笔试题的帮助比多刷100道LeetCode还大。4.1 从零搭建一个模拟订单系统的本地环境我在备考后端校招时做的最有价值的一件事就是自己搭了一个“mini电商后端”。整个项目非常小大概包含以下几个模块商品模块存储商品信息与库存、订单模块创建订单、支付、取消、用户模块注册、登录、优惠券。数据库用了MySQL和Redis接口用Spring Boot写。这个项目不需要非常完善但必须覆盖以下要点一个联合索引的设计、一个事务处理订单创建的流程、用Redis实现一个库存预扣减、用MQ我用的RocketMQ实现订单创建后的异步通知。搭建项目的过程比项目本身更有价值。因为在实现“下单扣库存”这个接口时你一定会遇到并发超卖问题于是你就会去查资料、设计乐观锁或Redis流水线然后你就真正理解了“乐观锁”和“悲观锁”的区别。你在实现“查询订单详情”时一定会遇到缓存与数据库一致性的问题于是你就会去查阅缓存穿透、缓存击穿、缓存雪崩的概念。这些知识点如果靠背可能一周后就会忘但如果你是自己写代码踩坑踩出来的一辈子都忘不掉。我在面试中聊到项目时自然地提到“当时我发现并发压测时库存出现了负数于是把扣减逻辑改成Redis Lua脚本”面试官往往都会露出认可的眼神。4.2 手写一个带过期时间的LRU缓存LRU缓存是蘑菇街这类电商公司笔试中最高频的算法题之一出现的概率极高而且经常是“直接手写”的要求。它非常契合电商场景用户最近浏览的商品、商品详情页的缓存、登录token的管理本质上都可以抽象为LRU。这道题写起来不难但拿满分需要做到两点第一使用LinkedHashMap实现时必须说明构造参数accessOrdertrue的作用第二能写出基于HashMap双向链表的版本并分析各操作的复杂度。我建议你直接手写HashMap双向链表版本。核心思路是HashMap负责O(1)快速查找双向链表负责维护访问顺序。每次get时如果key存在把对应节点移动到链表头部每次put时如果key存在更新value并移动到头部如果key不存在新建节点插入头部如果容量达到上限删除链表尾部节点并在HashMap中移除。最容易被忽视的是在移动节点到头部时要先处理“节点在链表中间位置”的指针重连问题如果指针写错轻则链表乱序重则内存泄漏或者死循环。我自己在笔试时这道题就翻过车当时为了省时间直接用LinkedHashMap结果面试官追问“如果让你不用LinkedHashMap你会怎么设计”我当场答得磕磕绊绊。所以我的建议是这道题一定要在本地实现了再去笔试不要以为看懂了就会写。4.3 SQL慢查询优化实操从Explain到索引设计数据库题在蘑菇街笔试中占比不低而“慢查询优化”几乎是必考。笔试中通常不会给你真实数据库环境而是给你表结构和SQL让你分析问题。但如果你在备考时做过真实优化这种题就是送分的。我自己做了一个练习题创建一个包含100万条模拟订单数据的表字段包括order_id、user_id、product_id、status、create_time、pay_time、amount然后造几个慢查询。比如“统计某用户在某个时间段内已支付订单的总金额”如果不加索引这条SQL可能耗时500ms以上。用Explain一看typeALL全表扫描rows100万Extra显示Using where。这时候加上联合索引(user_id, status, create_time)再用Explain验证type变成refrows大幅降低查询时间降到个位数毫秒。实际操作里你会学到几个课本上不会细讲的细节第一联合索引的顺序极其重要如果查询条件包含等值、排序、范围三种情况那么等值列放最前面排序列放中间范围列放最后第二范围查询后面的索引列不会生效这是最左前缀原则的一个推论第三如果查询需要回表有时覆盖索引比加多一个字段更有效。这些细节靠背是背不牢的只有自己动手调整过索引顺序、观察到执行时间的变化才能形成肌肉记忆。我在笔试时遇到SQL优化题基本可以在三分钟内完成“分析SQL—检查现有索引—设计新索引—说明效果”的完整回答。4.4 Redis高并发场景下的原子操作实现Redis几乎是后端笔试中必考的一个组件尤其是在电商公司里它的地位甚至超过MySQL。蘑菇街这套题里有一道关于秒杀库存扣减的题考察的就是Redis的原子操作。你必须能够写出并解释下面这段Lua脚本。local key KEYS[1] local stock tonumber(redis.call(get, key) or 0) if stock 0 then redis.call(decr, key) return 1 else return 0 end这段脚本的逻辑很简单但你要能解释出为什么不能在Java代码里先get再decr因为这两步之间会有并发窗口多个线程可能同时读到库存为1然后都执行decr最后变成负数。而Lua脚本在Redis中是原子执行的不会有其他命令插入所以不会有超卖问题。更进一步你还可以提到Redis在集群模式下Lua脚本中涉及的所有key必须落在同一个slot中否则会报错。这就是为什么设计Redis key时要用业务前缀加固定后缀让同一业务的key都带同一个哈希标签hash tag比如{product:1001}:stock和{product:1001}:lock利用大括号强制它们路由到同一个slot。这个细节很多工作了几年的人都未必知道但你在笔试中能写出来绝对是加分项。4.5 Spring Boot接口幂等性设计从防重表到Token机制电商系统里“接口幂等性”是个必须考虑的问题。笔试中不一定直接考“什么叫幂等”但它会藏在订单创建、优惠券领取、支付回调这些场景里。比如优惠券领取接口如果用户因为网络重试连续请求两次系统应该如何保证只发放一张优惠券这是典型的幂等性设计问题。我推荐的方案是Token预生成令牌机制客户端在请求前先调用“获取令牌”接口后端生成一个唯一token存入Redis并设置过期时间客户端提交业务请求时带上这个token后端在处理前先尝试删除Redis中对应的token如果删除成功说明这是第一次请求可以继续处理业务如果删除失败key不存在说明请求已经处理过或者token过期直接返回重复请求提示。这种方式比“防重表”更适合高并发场景因为Redis的原子删除操作天然保证了“只允许一个请求成功”。我这个方案也有一个需要补充的注意点Redis的del命令是原子的但如果在删除token之前业务处理耗时超过token过期时间会出现两个请求都能通过校验的情况。所以实际项目中token的过期时间设置为业务处理耗时的上限同时取一个合理的缓冲值。我在自己项目中设置的过期时间是10分钟对于订单创建这种操作足够了。另外如果你担心Redis故障导致服务不可用可以在本地JVM里再缓存一份token作为降级方案。这些细节你在笔试中能提出来会证明你考虑问题比较周全。5. 常见问题与排查技巧实录这套蘑菇街笔试准备过程中当年和我一起复习的同学基本都掉进过同一个坑觉得“我刷过LeetCode基础也应该没问题”结果真到笔试时时间分配一团糟前面基础题纠结太久算法题反而没时间写完整。我看过不少人的笔试复盘结合我自己的经历整理出一些踩坑记录和应对方法。5.1 笔试中的常见失误与应对方法最大的失误是做基础题时追求“完美”。笔试不是面试没有面试官会因为你一道题的选项犹豫而给你加分。基础题的价值是快速抢分应该以“会就选不会就标记跳过”为原则。一道JVM题如果两个选项你拿不准先凭第一印象选一个然后跳到下一题最后有时间再回头看。有些同学陷在一道题目里10分钟导致后面两个算法大题草草写了几行关键逻辑就交了非常可惜。第二个常见失误是算法题时间复杂度过高。笔试的判题系统一般有隐藏的性能测试如果你的解法时间复杂度是O(N^2)数据量一大就超时。比如一道“求最大不重复子串长度”的题如果你用双重循环枚举所有子串再Set去重大概率会超时。正确解法是滑动窗口配合HashSet或HashMap整体复杂度O(N)。我建议你在平时刷题时每做完一题都顺手算一下复杂度写注释标注在代码顶部形成习惯。笔试时如果时间紧张先写一个暴力版本保底再在注释里说明“当前实现为暴力法可优化为滑动窗口”这样至少不会完全丢分。第三个失误是SQL题没注意表名和字段名大小写。很多在线笔试系统跑的是MySQLLinux环境下表名区分大小写但Windows环境不区分。如果你在本地Windows下写SQL时习惯用大写表名到了在线判题环境可能直接报错。我遇到过一次明明逻辑完全正确但因为表名大小写不一致被判错交卷后才发现原因。从那以后我写SQL一律按题目给定的原样去写不自己改大小写。5.2 系统设计题的答题框架从“不知道”到“有逻辑”很多基础不错的同学一碰到系统设计题就卡壳不是不会技术而是不知道从哪里下手。我总结了一个简单的五步答题框架帮你稳住节奏。第一步明确需求把场景中的核心问题用一句话说清楚比如“在秒杀场景下避免库存超卖”。第二步估算流量和容量根据题干给出的QPS和数据量大致估算需要多少台机器、多大带宽、缓存容量够不够。不需要精确但要有量级概念比如“单台Redis读QPS约8-10万要扛住10万QPS至少需要2个副本”。第三步拆分模块把系统按职责拆成网关层、业务层、缓存层、存储层画出请求从头到尾经过的路径。第四步找出瓶颈分析请求链路上哪个环节会成为瓶颈比如数据库连接数、缓存穿透、热点数据集中在同一分片上。第五步给出方案针对每个瓶颈给出具体技术方案并说明为什么选择这个方案而不是另一个。5.3 一个易混淆知识点的排查笔记HashMap容量为什么是2的幂这个知识点单独拿出来说是因为它在蘑菇街笔试和后续面试里经常出现而且容易讲不完整。HashMap的初始容量是16扩容时翻倍容量始终是2的幂很多同学只知道这个结论不知道背后的原因。我当年专门做了一次源码分析和实验把过程记录下来。在HashMap的put流程中计算key的哈希值之后并不是直接用哈希值作为数组下标而是用“哈希值高16位与低16位异或”得到新的哈希值再与数组长度-1做按位与运算得到数组下标。因为数组长度是2的幂所以数组长度-1的二进制表示全是1这样按位与运算的结果分布会更均匀能减少哈希碰撞。如果是其他长度按位与运算会丢失部分位的特征增加碰撞概率。这就是为什么HashMap的容量要设计为2的幂。扩展开来在Redis的分布式锁中对key做哈希后取模运算也会为了分布均匀而选择2的幂作为槽位数量或者使用一致性哈希。这个知识点虽然小但能串联起数据结构、位运算、分布式系统多个领域体现了后端工程师扎实的基本功。5.4 “会做”和“能讲”是两回事笔试后的复盘方法笔试题做完不是结束一定要复盘。我在准备蘑菇街笔试时把每一道错题都归纳到一个错题本里按照“题目类型-错误原因-正确思路-相关知识盲区”四个字段记录。每周日晚把这个错题本过一遍不断强化记忆。这个习惯我保持到后来工作了也在继续收益非常大。刚开始错题本很厚整理了将近70道题到后面每周只新增2-3道说明知识体系在逐渐闭环。我还建议你把错题重写一遍不是看一眼答案而是合上笔记从零开始写代码或写答案。只有能独立输出才代表真正掌握了。复盘时最容易被忽略的是“主观题”的复盘。客观题错了你知道错在哪系统设计题答得一般你可能根本不知道哪里不完善。我的方法是把自己写的方案讲给同学或者论坛上的朋友听让对方扮演面试官来挑战你。比如我设计秒杀系统时朋友问了一句“如果Redis集群中的某一台机器挂了你的库存扣减怎么办”这一个问题就逼我去查了Redis持久化、主从切换、库存补偿机制。这种“被追问”的过程比独自写十篇设计方案都有效。所以在备考阶段强烈建议大家找一个战友互相模拟提问你会有种“原来我还有这么多漏洞”的惊喜感。6. 备考策略与避坑指南笔试备考是一个系统工程不能靠考前一周突击。以蘑菇街这套题的难度我建议你至少提前两个月开始准备把时间分成三个阶段。第一个阶段第1-3周以算法为主每天刷2-3道题重点覆盖数组、链表、二叉树、哈希表、动态规划、贪心。第二个阶段第4-6周转为基础知识和SQL把Java集合、并发、JVM、MySQL、Redis这些高频考点系统过一遍同时每天保留1道算法题保持手感。第三个阶段第7-8周集中做整套笔试题和系统设计题严格按照真实笔试的时间限制来训练比如2小时内完成整套试卷期间不看手机、不查资料、不中断。6.1 知识框架自查表我把这套笔试题涉及的知识点整理成一张自查表你可以对照检查自己的掌握程度。每一行如果你不能在一分钟内说出核心要点就说明还需要补齐。考点方向核心知识点自查标准Java基础HashMap/ConcurrentHashMap能说出底层结构、扩容机制、并发安全差异Java基础线程池参数与拒绝策略能给出一个具体场景的参数配置和理由JVM内存区域与GC回收能画出运行时数据区说明对象分配流程JVM类加载过程能说出加载-验证-准备-解析-初始化的顺序并发synchronized与ReentrantLock能对比用法、锁粒度、可中断性网络TCP三次握手与四次挥手能画出状态流转图并解释TIME_WAIT网络HTTPS握手流程能说明TLS1.2完整握手过程MySQL索引与Explain能根据SQL判断索引命中情况MySQL事务隔离级别与锁能说明可重复读下如何解决幻读Redis缓存穿透/击穿/雪崩能说明三种场景和解决方案RedisLua原子操作能写出一段库存扣减脚本算法LRU缓存实现能手写HashMap双向链表版本算法滑动窗口能快速解决最大不重复子串类问题系统设计秒杀系统能画出请求链路并说明每层方案系统设计订单超时关闭能说明延迟队列的实现方案这张表不是让你死记硬背而是给你一个检测自己知识边界的方法。你在复习时如果发现自己看到某一项大脑一片空白就停下来回到对应章节去补齐。6.2 蘑菇街2025届笔试的新变化与复习方向补充虽然这篇博文主要围绕2019届的题目展开但蘑菇街以及同类电商公司近几年的后端笔试题也在不断进化。前两年开始在线编程题的占比增加了并且部分题目要求在IDE中运行通过而不仅仅是写出伪代码。题目的场景化程度更高了像“双11大促流量染色”“多端购物车合并”这类业务背景更具体的题目越来越常见。同时对容器化和云原生知识的考察也开始出现。如果你手头在准备的是近两年的校招我建议你在原有基础上补充学习Docker的基础命令和镜像构建、Kubernetes的Pod工作方式、Spring Cloud Alibaba中的Nacos与Sentinel以及消息队列的可靠性投递原理。这些内容不一定在笔试题中出现但在面试环节被追问的概率很高。一套不错的复习路径是先把2019届这套题吃透再去针对当年的技术热点做增量补充。6.3 一些“说了容易踩坑”的细节提醒后端笔试过程中有几个细节看似无关紧要但真的会影响成绩。第一注意时间分配建议按“基础题:算法题:SQL题:系统设计题3:4:2:1”的比例来分配时间而不是从头做到尾。第二代码题即使不能完全通过测试用例也要保证基本思路和关键逻辑是完整的并且代码风格整洁变量命名有意义。判题系统可能部分通过而人工复审时一份注释清晰、逻辑完整的代码也能拿到不少过程分。第三遇到不会的题先把题目中已知的条件列出来写下几个可能的思路哪怕最后没写完整也能让面试官看到你的解题过程而不是白卷。我个人见过不少同学因为一个变量没初始化导致整段代码跑不起来其实是紧张导致的小失误。建议你在交卷前留3分钟检查一下代码里有没有数组越界、空指针、除零这类低级问题。另外还有一个很多人忽略的点笔试题的答案不要只写技术方案一定要考虑成本和收益。比如系统设计题你可以写“用三台Redis Cluster节点扛100万QPS”这种方案但如果能从成本角度补一句“单机Redis可以承受约8-10万读QPS如果业务峰值只持续30分钟可以考虑提前扩容或者限流降级”会显得更接地气。电商公司的面试官和出题人天然关注成本与稳定性的平衡你越能贴近真实业务思考得分越高。参加校招笔试尤其是蘑菇街这种电商公司的校招笔试本质上是把大学四年学到的计算机知识放到一个“真实业务是否可靠”的标尺下重新检验。刷题很重要但比刷题更重要的是形成自己的知识体系和思维框架。这套体系能帮你在一道陌生的题目面前快速拆解出它到底在考什么然后用已有的知识迁移过去。我在备考时反复练的就是这件事从看到题目到落笔中间不犹豫、不乱跳形成了稳定的答题节奏。如果你能把2019届这套题按我上面说的思路吃透再把近几年新增的技术热点补齐到真正笔试的时候你不仅会答得从容还能在面试官追问时拿出自己的独特见解。