1. 先给这份卷子画个像映客研发E卷到底在筛什么人每年春招的研发笔试题本质上不是考你会不会写代码而是在极短时间里判断你“能不能在映客这种体量的直播业务里活下来”。拿到这份2020春招研发E卷的时候我第一反应是出题人很聪明没有堆砌偏题怪题而是把直播业务里真实会踩的坑揉进了看起来平平无奇的基础题里。先说结论这份卷子整体难度中等偏上但区分度极高。它覆盖了四块核心内容——计算机网络与操作系统基础、缓存与并发场景设计、业务系统设计弹幕、排行榜这类直播高频组件、以及三道必须AC的编程题。你如果只是刷完了《剑指Offer》就去考大概率会在场景设计题上卡住但反过来如果你真在实习里碰过高并发读写哪怕算法题没全AC也能凭设计题的思路拿到不错的分数。为什么我敢这么说因为映客的业务模型太典型了千万级日活、直播间动辄几十万人同时在线、弹幕峰值每秒数万条、送礼和排行榜的写并发极高。这套卷子表面上是在考知识点实际上是在问一个问题你知不知道真实系统里那些“教科书没有告诉你”的坑比如卷子里有一道关于TCP四次挥手的题表面问TIME_WAIT状态出现在哪一端、为什么需要2MSL但展开问就是直播弹幕服务端主动断开连接时TIME_WAIT连接过多会导致端口耗尽你怎么解决这就是典型的“基础题背后藏着生产环境故障”。下面我把这份卷子按题型掰开揉碎了讲。2. 选择题里的送命题网络、并发与缓存的经典陷阱2.1 你以为在考TCP其实在考线上故障排查卷子开头几道网络题出的非常“映客”。比如这道关于TCP四次挥手下列说法正确的是 A. 主动关闭方最后进入TIME_WAIT状态 B. TIME_WAIT持续时间为1MSL C. 被动关闭方可以立即复用端口 D. 四次挥手过程中主动关闭方可以继续发送数据答案是A。但大多数人栽在B和D上。TIME_WAIT的持续时间是2MSL不是1MSL原因是主动关闭方发出的最后一个ACK可能丢失被动方会重发FIN主动方必须留出“发送ACK 等待对方重传FIN”的时间窗口2MSL是最保守的保证。D错得离谱主动关闭方发出FIN后就不能再发数据了只能接收。你以为这就完了不这道题的延伸才是重点。**直播场景里服务端向客户端推送弹幕如果服务端主动断开某个异常连接就会产生大量TIME_WAIT连接。**一次直播间卡顿导致客户端集体重连服务端可能瞬间积累几万个TIME_WAIT把可用端口耗尽新连接全部失败。如果你在答案里只写“选A”那只能拿基础分。如果你补充一句“生产环境里可以开启tcp_tw_reuse让TIME_WAIT连接用于新连接但要注意配合tcp_timestamps或者调整keepalive策略减少服务端主动断连的频率”那这道题就答出区分度了。我在帮学弟复盘这份卷子时就强调每道选择题都要准备一个“线上发生了什么”的答案。2.2 缓存穿透、击穿、雪崩直播业务里的真实版本这份卷子关于缓存的三连问几乎是必考题但出题人换了个业务外壳直播间热门礼物榜单缓存设置5分钟过期某热门主播开播瞬间大量用户同时请求榜单缓存刚好过期此时会发生什么答案是缓存击穿。热门key过期瞬间大量请求打到数据库。这里要区分穿透、击穿、雪崩三个概念穿透请求了一个缓存和数据库都不存在的key每次请求都直接打DB。恶意攻击最常利用这个。击穿缓存里存在但刚好过期的热点key大量并发请求瞬间涌入DB。雪崩大量key在同一时间集体过期DB瞬间被压垮。映客这种业务里击穿和雪崩都很常见。大主播的榜单是热点key用户送礼、点赞、评论全在读写它。解决方案我建议按这个顺序回答互斥锁Mutex当缓存失效时不是所有请求都去查DB而是只让一个请求去查其他请求等待或返回旧值。实现可以用Redis的SETNX获取不到锁就sleep后重试。逻辑过期缓存里不设物理过期时间而是存一个“逻辑过期时间”字段。当发现逻辑过期时起一个后台线程去刷新缓存请求继续返回旧值。这个方案对直播业务特别合适——就算榜单数据旧了几秒用户根本感知不到。热点key永不过期 异步更新像大主播的榜单key直接设置永不过期靠消息队列异步去更新。缺点是数据最终一致对直播业务来说完全够用。如果你能在选择题的空白处写下这套思路面试官基本会认定你有生产意识。2.3 volatile、synchronized与线程池并发题的低级错误多选题里有一道关于volatile的题目很典型关于volatile关键字下列说法正确的是 A. 保证线程可见性 B. 保证原子性 C. 禁止指令重排序 D. 可以替代synchronized答案是A和C。B是最大的坑无数人一看到volatile就想到“线程安全”但volatile不保证原子性。i这个操作volatile只能保证读取到最新值但读取和写入之间依然可能被其他线程插队最终结果还是会丢更新。D选项也是错的但错得很隐蔽。volatile能保证可见性和有序性但保证不了互斥。它不能把复合操作变成原子操作所以在“先检查后执行”这类场景下完全替代不了synchronized。再往下线程池那道题几乎是把答案喂到嘴边了线程池的拒绝策略中哪种策略会在任务提交时直接抛出RejectedExecutionException异常答案是AbortPolicy默认策略。但真正的加分项是你要说出四种拒绝策略的适用场景AbortPolicy默认策略直接抛异常。适合不允许丢弃任务、必须让调用方感知到压力的场景。CallerRunsPolicy任务由提交任务的线程自己执行。适合需要降速的场景相当于天然背压机制——谁提交任务谁自己扛。DiscardPolicy静默丢弃。适合可以容忍丢消息的场景。DiscardOldestPolicy丢弃队列里最老的任务然后重试提交。适合追求新数据、旧数据无所谓的场景比如直播里的实时在线人数统计。直播业务里弹幕推送的线程池就适合用CallerRunsPolicy——宁可让业务线程自己发也不能把弹幕抛弃掉而在线统计这种丢一两次无所谓的用DiscardPolicy就行。这种“业务场景技术选型”的搭配回答是拿高分的核心。3. 业务设计题直播弹幕和排行榜背后的系统取舍3.1 弹幕系统设计别一上来就聊WebSocket这份卷子的压轴设计题是最有映客风格的一道请设计一个支持千万级用户同时在线的直播间弹幕系统要求弹幕延迟低于500ms弹幕不丢失不重复。很多人拿到手就写客户端通过WebSocket连接到弹幕服务器服务端收到消息后广播给所有人。这种答案只能拿20分因为它完全没有体现分布式系统的设计思维。我建议分四步回答。第一步连接层。WebSocket确实是最合适的长连接方案但你要说清楚一台服务器最多维持几十万条TCP长连接千万级在线意味着需要集群部署 网关层负载均衡。客户端先通过HTTP接口拿到一台可用的弹幕网关地址再建立WebSocket连接网关层用一致性哈希或随机策略做负载均衡。注意WebSocket连接一旦建立就不能随意迁移所以网关的健康检查和断线重连机制必须设计好。第二步消息分发。最简单的模式是客户端把弹幕发给接入网关网关转发给消息中心消息中心再推送给直播间所有连着的客户端。但千万级在线全量广播任何一台机器都扛不住。这里的标准解法是分层分发——每个直播间是一个消息通道消息中心根据直播间ID把消息路由到对应的分发节点每个分发节点只负责一部分直播间节点内部再做本地广播。第三步削峰填谷。弹幕的峰值流量非常恐怖比如某主播说了一句“抽奖”瞬间几千条弹幕刷出来。如果消息中心直接处理所有写入很容易被打垮。所以要在写入路径上加消息队列客户端弹幕进来之后先进Kafka或RocketMQ消息中心异步消费再分发。好处是写入即返回客户端体验好消费端压力可控可以按需扩容。代价是这条链路天然带来了几十毫秒延迟但500ms的容忍度完全覆盖得住。第四步不丢不重。这其实是最难的部分。客户端发送弹幕时带一个全局唯一的消息IDUUID即可服务端在网关层做幂等去重——缓存最近N条消息ID重复到达的直接丢弃客户端断线重连后根据自己收到的最后一条消息ID从服务端拉取缺失的增量消息。这两招配合基本能保证“不重不漏”。这道题的满分关键不是方案多华丽而是你要主动说出**“哪些环节可能挂挂了怎么降级”**。比如消息队列满了怎么办答丢弃非关键消息保障核心弹幕直播间热度骤增导致单节点过载怎么办答建立直播间维度SLA监控提前扩容热门直播间所在节点。这些才是面试官真正想听的。3.2 排行榜设计从Redis ZSET到多级降级另一道高频设计题是排行榜设计一个主播排行榜要求支持百万主播实时排名支持按礼物价值排序且同分时按时间顺序排序读多写少。很多人第一反应是MySQL Order By这就是典型的没有生产经验。百万级主播按礼物值排序如果用MySQL每次查询都要全表扫描加排序即使有索引也扛不住高频读写。这里的主角是Redis的有序集合ZSET。ZSET的底层是跳表加哈希表每个成员有一个分数插入和查询都是O(logN)级别。主播开播时把他的主播ID和初始分数0塞进ZSET每次收到礼物用ZINCRBY leaderboard 10 anchorId给他的分数加10。查询Top100直接用ZREVRANGE leaderboard 0 99 WITHSCORES性能极高。但同分时按时间排ZSET的double分数无法直接表达我的做法是把时间信息编码进分数里。比如礼物价值占高32位时间戳占低32位分数 礼物价值 * 2^32 (基点时间戳 - 该主播最近一次礼物时间戳)。这样比较分数时礼物价值是主排序时间戳是次排序完全符合业务规则。代价是实时性要求极高时需要频繁更新分数但ZSET的写性能足够支撑。还需要考虑数据分片和降级方案。当一个ZSET装不下百万级数据可以按主播ID哈希分片到多个Redis实例查询Top榜时合并各分片结果。如果Redis挂了兜底方案是把排行数据定期沉到MySQL开启本地缓存等Redis恢复后再回放增量数据。回答时能把这些边界情况串起来分数会明显高一档。3.3 验证码与接口防刷直播业务绕不开的实战题这份卷子还有一道略冷门但很实际的设计题设计一个验证码服务要求能防机器刷又不影响用户体验。这里要抓住三个点生成端、校验端、风控策略。生成端不能只生成图片验证码还要为每个验证码生成一个唯一ID并把“ID 答案”存到Redis设置5分钟过期。校验端要设计成“校验一次即作废”防止重放攻击。风控策略最关键一个IP在1分钟内请求超过阈值直接升级为滑块验证或禁止请求手机号维度也要限制防止批量注册。进阶方案是二次校验验证码输入正确后再通过客户端SDK上报设备指纹和操作行为后端用规则引擎判断风险等级高风险的进入人工审核队列。这套思路在直播平台的反垃圾、防刷量场景下非常通用答出来会很加分。4. 编程题从读题到AC三道典型题目的完整解题思路4.1 合并两个有序链表递归与迭代的边界处理卷子里的第一道编程题是输入两个有序链表合并后依然有序。这题不难但能看出基本功。迭代解法核心是哑节点技巧ListNode dummy new ListNode(-1); ListNode cur dummy;然后循环比较两个链表当前节点的值谁小就接谁。循环结束后某个链表可能还有剩余节点直接cur.next (l1 ! null ? l1 : l2);一次性接上。这里要注意dummy.next才是真正的头节点最后返回它。递归解法更简洁if (l1 null) return l2; if (l2 null) return l1; if (l1.val l2.val) { l1.next mergeTwoLists(l1.next, l2); return l1; }但递归容易在链表很长时爆栈所以生产里更推荐迭代法。面试时我建议先写迭代再提递归作为对照展示你对两种写法的边界条件都清楚。易错点其实只有一个很多人最后会忘记接剩余链表而是写成循环逐个拼接白白浪费时间。这题只要AC说明基础扎实。4.2 设计LRU缓存HashMap 双向链表为什么是标准答案这道题放在编程题第二题实现一个LRU缓存要求get和set的时间复杂度都是O(1)。如果你用数组或普通LinkedList实现get是O(N)必然踩中性能坑。标准解法是HashMap 双向链表HashMap负责O(1)查找双向链表负责O(1)的插入和删除——因为通过HashMap找到节点后删除和移动节点都只需要调整前后指针不需要遍历链表。代码的话核心是维护好addToHead、removeNode、moveToHead三个私有方法get和set都复用它们。一个细节是插入新节点时先判断容量是否已满满了就删除尾节点并从HashMap中移除。这题的加分点是主动解释“为什么要用双向链表而不是单向链表”因为删除任意节点时单链表需要从头遍历找到前驱节点那就退化成O(N)了。能讲清楚“为什么”比闷头写对代码更让面试官认可。4.3 手写生产者消费者锁、队列与并发的协作第三题不是算法题而是多线程编程用Java实现生产者消费者模型。最标准、最不容易出错的写法是ReentrantLock ConditionLock lock new ReentrantLock(); Condition notFull lock.newCondition(); Condition notEmpty lock.newCondition(); int capacity 10; QueueInteger queue new LinkedList();生产者获取锁后如果队列已满就notFull.await()否则入队并notEmpty.signal()。消费者反过来队列空就notEmpty.await()否则出队notFull.signal()。这里有两个关键点await()和signal()必须持有锁注意在循环里判断条件防止虚假唤醒。signal()之后要检查是否真的需要唤醒对方否则可能产生没必要的上下文切换。如果时间紧张还可以提一嘴JDK自带的BlockingQueue比如ArrayBlockingQueue可以直接实现但面试官可能会追问底层原理所以两道方案都要会。这道题考的是你对“锁、等待通知机制、线程协作”的理解。能讲明白Condition为什么比synchronized wait/notify更灵活支持多个条件队列就已经是中级水平了。5. 从卷面看面试官的评分习惯易错点与加分项5.1 基础题正确率决定下限设计题决定上限我复盘过很多份笔试卷发现一个规律基础选择题决定你能不能进入面试环节而设计题和编程题决定你排在候选人里的名次。基础题的正确率是硬门槛如果选择题错超过3道编程题即使全AC也容易让人怀疑你是不是背题背出来的。因为选择题考察的是长期积累的确定性知识短期内突击很难全覆盖而设计题和编程题可以靠思路和代码风格弥补部分缺漏。所以备考策略应该是先把所有基础题的知识点过了三遍确保正确率在90%以上再花时间研究设计题的答题套路。相反很多人本末倒置花两周刷LeetCode Hard结果连TIME_WAIT状态都分不清这就很可惜。5.2 编程题最容易丢分的三个地方笔试系统一般不支持IDE调试纯记事本写代码。这时候最影响分数的是三个问题第一代码风格混乱。变量命名不重要错了。面试官看到ListNode l1和ListNode listNode1对他的印象会迅速打折。规范的命名、清晰的缩进、适当的空行这些跟你代码能不能跑通一样重要。我见过不少条件判断一堆嵌套还缩进不齐的卷子即使思路对也很难让人相信你能写出可维护的代码。第二边界条件覆盖不全。合并有序链表这题很多人不检查输入为null的情况写LRU时不处理容量为1的极端场景。这些边界情况不需要你花很多时间但在写的时候就要有意识地判断而不是写完才去检查。第三算法描述和代码分离。有些考生只写代码注释几乎没有面试官看着一团乱麻。正确做法是花30秒在代码上方写清楚思路“用一个哈希表存储key到节点的映射链表维护访问顺序越靠近头部越新。”这既帮助自己理清逻辑也能让面试官快速get到你的方案。5.3 “为什么”比“是什么”更容易拿分这份卷子我还有一点体会很深几乎每道题都可以往“为什么”方向延伸。TIME_WAIT为什么是2MSL为了确保最后一个ACK能送达同时让旧连接的报文在网络中过期消失。ZSET为什么用跳表不用平衡树因为跳表实现简单内存占用可控范围查询友好而平衡树旋转操作复杂在Redis这种内存数据库里跳表的优势更明显。线程池为什么默认用AbortPolicy因为默认策略要暴露问题让调用方感知压力而不是静默吞掉任务。当你在答案里多写一个“因为”阅卷人就知道你不是死记硬背而是真正理解了这个技术点的来龙去脉。这一点比任何应试技巧都管用。最后再分享一个实际经验这套卷子我前后帮十几个候选人复盘过凡是能同时答好基础题和设计题的人进到面试环节概率极大。而拿到offer的几乎都具备同一种特质——他们会把每一道题都还原到映客的真实业务场景里去思考。所以你复习的时候也试着问问自己这个知识点放在直播间里会以什么方式出现想通这个问题你离通过就不远了。