1. 先给这份练习卷定个位
如果你跟我一样，是从大学实验室、或者从第一次找实习的慌乱里走过来的人，那“腾讯2015春招后台开发练习卷”这几个字应该不陌生。后台开发这个岗位，听名字像是“写接口、调服务”，但实际一练卷子你才发现，它考的是你过去三年到底有没有真的理解操作系统、网络、数据库和算法这几门课。这不是一份靠背题能过的试卷，它更像是一面镜子，照出你对计算机基础的理解是停留在“会背概念”，还是真的能在线上环境里拿它们解决问题。
这份练习卷适合谁来刷？我建议三类人重点看：第一类是准备进互联网公司做后台开发、服务端研发的应届生，第二类是工作一两年想系统补基础的后端工程师，第三类是单纯想检验自己计算机功底的人。无论你属于哪一类，这套练习卷都能帮你把零散的知识点串成一条线。它不直接给你答案，而是逼着你去思考“为什么”，这也是我推荐它的最大理由。
先说个结论：后台开发的面试核心，从来不是考察你写过多少业务代码，而是考察你在高并发、高性能、高可用的场景下，能不能用计算机底层原理解释现象、定位问题、设计出可靠的方案。练习卷中的题目看起来分散，实际都是围绕这个核心展开的。
1.1 后台开发到底在考什么
很多同学以为后台开发就是写Java或者C++，把框架用熟、CRUD写麻利就行。这个认知在实习面试里还能撑一阵，到了春招这种正式招聘节点，基本会被打回原形。练习卷里大量题目指向的是“服务端程序在处理请求时，从网卡收包到应用返回响应，中间每一层发生了什么”。你要懂TCP连接怎么建立和关闭，内核怎么调度线程，进程间怎么通信，内存满了会怎样，数据库的索引为什么快，缓存丢了数据怎么办。
说白了，后台开发的工作就是在一个高并发、大数据量的环境中，让服务又快又稳地响应用户请求。但凡对底层机制理解不透，线上一个诡异问题就能让你排查到怀疑人生。练习卷的意义就是帮你在“出问题之前”把这些机制逐一补齐。
1.2 这份练习卷的四个考察维度
这些年我带过不少新人，也模拟面试过很多候选人，发现练习卷里的考点基本集中在四个方向，掌握了这四个方向，不管题目怎么变形，你都能找到对应解法。
第一个方向是网络与并发，重点集中在TCP/IP、Socket编程、线程模型、锁与同步。后台服务的本质是处理网络请求，所以网络和并发是绕不开的主战场。
第二个方向是操作系统与内存，重点包括进程线程区别、内存分配、堆栈差异、上下文切换、文件描述符等。很多线上性能问题最后都排查到系统层面，不懂操作系统就谈不上做后台优化。
第三个方向是数据结构与算法，这是基本功。练习卷里的算法题不会特别偏门，但很考验你在限制条件下快速写出高效代码的能力。常见的排序、二分、链表、哈希、动态规划，都可能在题目变形后出现。
第四个方向是数据库与分布式，重点涉及索引、事务隔离级别、缓存、一致性、负载均衡、容灾等。这一块最接近真实业务场景，也最能在面试中拉开差距。
回头看，这四个方向正好对应后台开发的核心技能树。练习卷不需要你面面俱到，但要求你在每个方向下都有至少一个“能讲明白”的拳头项。
2. 后台开发的四块硬功底：网络、系统、算法、数据
2.1 网络协议不是背概念，是排查问题的工具
练习卷里只要出现网络题，大概率绕不开TCP。你光是能背出三次握手、四次挥手还不够，得明白为什么是三次而不是两次，为什么挥手要四次，以及TIME_WAIT状态到底在解决什么问题。
我给你打个比方。三次握手就好比两个人打电话，要先确认双方都能收发话。第一次A说“你能听到吗”，第二次B回“我能听到，你能听到我吗”，第三次A再回“我能听到”，到这步才真正建立起双向连接。如果只有两次握手，B并不知道A是否收到了自己的确认，连接状态就会悬空。
真正到了服务端开发，你会发现TIME_WAIT是个频繁出现的敌人。大量短连接接入时，服务端可能会出现大量TIME_WAIT状态，占用本地端口，导致新连接建立变慢。练习卷如果考到这个，你要能说出解决办法：一是开启端口复用，二是改短TIME_WAIT时间，三是从业务层改用长连接或连接池。实际生产里，我一般优先查是否可以用连接池，因为无脑改内核参数可能引入安全隐患。
再说TCP缓冲区、粘包拆包、流量控制和拥塞控制，这些看起来是纯理论，但一旦你处理过实时消息推送，就会明白粘包问题有多折磨人。自定义协议时一定要设计好消息边界，常见做法是“长度字段+消息体”，长度字段固定四字节，接收端先读长度，再按长度读消息体。这个思路是后台网络编程的基本功，练习卷里的小题常常会换成各种方式考你。
如果你想在面试时把这个点讲透，建议自己用Socket写一个小型echo服务端，并手动抓包看三次握手和四次挥手的序列号变化。这个过程比背十遍书都管用。
2.2 进程线程与内存管理：并发题的老熟人
练习卷里一定会出现这类题：“进程和线程的区别是什么，多线程共享哪些资源，不共享哪些资源”。你要是只答“线程轻量、进程重量”肯定不够，面试官更想听的是——每个进程有独立的地址空间，而线程共享进程的地址空间，因此线程切换成本低，但同一个进程内的数据共享也带来了同步问题。
我习惯用“厨房”来类比。进程就像一家餐厅，每个餐厅有自己的厨房、食材和灶台。线程则是厨房里的多个厨师，他们共享同一个灶台、同一袋米，但各自的围裙口袋是私有的。厨师之间协作效率高，但抢同一口锅的时候就得分清互相配合的规则，否则就可能炒糊菜。这个规则在编程里就是锁、条件变量、信号量这些同步机制。
很多同学会在并发编程题上翻车，不是不会写代码，而是说不出锁的代价。持有锁的线程如果迟迟不释放，其他线程只能阻塞等待，这就是锁竞争导致的性能恶化。练习卷里常考“如何减少锁竞争”，常见答案包括：缩小临界区范围、用读写锁分离读和写、用原子操作替代锁、使用无锁数据结构、或者用ThreadLocal避免共享。我自己的经验是，优先减少共享数据的范围，而不是一味优化锁本身，因为无锁编程对正确性要求极高，线上出bug代价更大。
内存管理也是重头戏，尤其是C++相关岗位。new和malloc的区别、栈和堆的区别、内存泄漏怎么排查、智能指针的底层引用计数怎么做，这些都是常客。我见过很多候选人能说出“栈区由编译器管理、堆区需要手动释放”，但一问他函数返回局部变量指针会怎样，就卡住了。这类问题不是靠记，而是靠写过、崩溃过、排查过才能理解。
2.3 算法题怎么准备才不白刷
练习卷里的算法题一般不会脱离LeetCode中等的难度，但它的坑在于，你需要在有限时间内写出没有明显bug的代码，并且能分析时空复杂度。很多同学刷题只追求AC，做完了就扔，下次遇到变体照样不会。这样刷一年题，效果远不如精刷一百道。
我的建议是，每一道算法题都要过四遍。第一遍独立思考，哪怕半小时没有思路也要先自己尝试；第二遍看题解，把别人的思路彻底看懂；第三遍关掉题解，白板重写；第四遍隔一周再做变体，检验是不是真的掌握了。这个过程很费时间，但练出来的不是“背答案”，而是“拆题能力”。
后台开发面试里算法题还有一个特点，就是经常要求你从工程角度优化。比如“实现一个支持过期时间的LRU缓存”，这题出现在后台面试里再正常不过，因为缓存是后端系统的标配。你不仅要用哈希表+双向链表实现O(1)的get和put，还要考虑并发访问时怎么加锁，过期清理怎么做。能把数据结构题和工程问题结合起来答，答案会明显高一个层次。
如果你时间有限，优先刷这几类：数组与哈希表、链表、二叉树、二分查找、动态规划、栈与队列。后台场景里最常考的是哈希表和链表，因为它们在缓存、倒排索引、消息队列里都频繁出现。别一上来就扎进困难的图论和状态压缩DP，那是竞赛路线，不是后台开发面试的主流方向。
2.4 数据库：从索引原理到缓存穿透
数据库在练习卷里的地位，几乎和网络平起平坐。最基础的是索引。你要能解释B+树为什么适合做数据库索引，而不是二叉树或者哈希表。简单说，B+树矮胖，层数少，一次磁盘IO能读取更多索引项；同时叶子节点用链表串联，适合范围查询。哈希表虽然单点查询快，但不支持有序遍历和范围查找，所以只适合等值查询场景。
事务隔离级别是另一个高频点。读未提交、读已提交、可重复读、串行化，每一种各自解决什么问题、存在什么问题，要能讲清楚。MySQL默认的可重复读，通过MVCC和间隙锁解决了大部分问题，但你在代码里处理并发扣减库存时，还是可能遇到超卖。根本原因在于多个事务同时读取到同一个库存数，又同时扣减，最终导致库存变负。解决方式可以是用行锁锁定记录，也可以用乐观锁带version字段，失败就重试。
缓存题在这个练习卷里也有很大占比，尤其喜欢问缓存穿透、缓存击穿、缓存雪崩。穿透是查询不存在的数据，每次都会打到数据库，解决方法是布隆过滤器或者缓存空值；击穿是某个热点key过期，大量并发同时打到数据库，解决方法是互斥锁重建缓存或者逻辑过期时间；雪崩是大面积缓存失效，导致数据库压力骤增，解决办法是过期时间加随机值、多级缓存、限流降级。
拿到这些题，不要只背方案，要把方案背后的代价说清楚。比如布隆过滤器有误判率，空值缓存会存大量无用key，互斥锁可能会阻塞请求，这些细节才是面试官真正想听的。
3. 把练习卷当项目做：我的复盘方法
3.1 先做一遍，再按“面试官视角”重做一遍
我拿这套练习卷练手的时候，做了两轮。第一轮就是正常做题，掐时间，模拟真实笔试环境，规定自己每道题不要超过二十分钟。这一轮的目的不是拿满分，而是找出自己的知识盲区，顺便培养时间分配的感觉。做完对答案时，我会把每道题涉及的知识点列成一张清单，标记出“完全会”“半会不会”“完全不会”三档。
第二轮很有意思，我会把自己想象成面试官，看着这份卷子问自己：出题人想考什么？这道题要是追问下去会说深挖什么？考生答到哪一步算过关？这样一翻转，很多考点立刻变得立体。比如一道看似考线程同步的题，背后可能是在考察死锁的四个必要条件，再往下可能是“你怎么在项目里避免死锁”。你能走到这一层，就不只是在做题，而是在建立后台开发的全局观。
3.2 每一道错题都补成一类知识
我见过太多同学做完一套卷子，对完答案，把错题丢到一边，然后继续做下一套。这种做题方式成长很低。练习卷的价值在于覆盖高频考点，如果你错了，说明这个考点存在缺口，那你要做的不是记住这道题，而是把这道题背后那一整块知识补齐。
比如，如果你错在一道“为什么TCP挥手需要四次”的题，那就可以借机把TCP状态机全过一遍：SYN_SENT、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、LAST_ACK、TIME_WAIT、CLOSED，每个状态在什么情况下进入、什么情况下退出，都查清楚。再把常见问题一起看，比如服务端出现大量CLOSE_WAIT是什么原因、怎么排查。这样补一个错题，可能花掉三个小时，但收获远超刷十道新题。
我在复习时习惯用一个电子表格记录错题和对应知识点，每补完一类就打一个勾。两周下来，我能很清楚地看出自己还有几块没补完。这个方法也推荐给准备春招的朋友。
3.3 用一句话解释每个核心概念
这个技巧是我从一位前辈那里学来的，后来一直用到现在。每学一个核心概念，就强迫自己用一句话向一个完全不懂技术的人解释清楚。解释不清楚，说明还没理解透。
比如“什么是上下文切换”——你正在写代码，突然肚子疼跑去上洗手间，回来后还要想起来自己刚写到第几行，这个“想起来”的过程就是上下文切换，代价就是浪费了几秒钟。再说“什么是多路复用”——一个服务员同时接待好几桌客人，记下每桌的需求，依次上菜，而不是每来一桌客人就雇一个服务员。这句话能讲清楚，面试官就知道你是真的理解。
练习卷里几乎每个概念都可以这样练。TAI状态、锁、索引、缓存穿透、一致性问题，都值得试试这个方法。它不单是为了面试，也是为了让你以后写技术方案时，能把复杂事情讲得通俗清楚——这在团队协作里是非常加分的软实力。
4. 实战中真正分高低的：系统设计与问题排查
4.1 系统设计题的通用回答框架
练习卷里可能不会直接出现“设计一个短链系统”这种大设计题，但会以小问的形式考察类似思路。比如“设计一个缓存系统，要考虑哪些问题”“如何设计一个支持高并发的接口”。这种题没有标准答案，面试官看的是你的思考过程。我自己总结了一套比较容易上手的回答框架，照着这个框架走，至少不会漏掉关键点。
第一步先聊业务场景和数据量。任何设计都离不开场景，是读多写少还是写多读少，预估QPS是多少，数据规模多大，这些决定了后续所有选型。第二步画核心流程，从客户端发起请求到服务端处理，再到数据存储，把主链路画出来。第三步再谈组件选型，语言、框架、中间件分别是什么，为什么选它。第四步重点谈高可用和扩展性，单点怎么办、流量突增怎么办、数据丢失怎么办。第五步是瓶颈分析与优化方案，哪里最容易成为瓶颈，你怎么监控和扩容。
用这个框架去套“缓存系统”设计题，你就可以说：场景是热点数据加速，QPS一万，数据量千万级；主流程是请求先到缓存，未命中再查数据库并回填；组件选型用Redis集群，因为读写性能高且支持集群扩展；高可用方面通过主从复制和哨兵减少单点风险；瓶颈在缓存穿透和热点key集中，所以需要布隆过滤器、热点key本地缓存、过期时间加随机值。这么一套下来，有骨有肉，比零散地抛出“可以用Redis”好太多。
4.2 Linux排查命令实战清单
后台开发日常离不开Linux服务器，练习卷里不一定直接考命令，但面试官非常可能问“线上CPU飙升你怎么办”“接口变慢你会怎么查”。这时候能完整说出排查套路，是很大的加分项。
我的标准套路是：先top看负载和CPU，再free看内存，再df看磁盘，再dmesg查内核日志，再做网络排查。top命令里重点关注CPU使用率、平均负载、僵尸进程数量。如果发现某个进程CPU接近100%，可以用perf top或gdb attach看它到底在干什么。如果是Java应用，还需要jstack导出线程栈，看看线程卡在哪个方法上。
网络排查上，netstat和ss是常用工具。当你说“连接数太多”的时候，要靠它们确认是TIME_WAIT还是ESTABLISHED状态居多。如果需要看具体接口耗时，可以用curl加-w参数输出时间明细，再配合tcpdump抓包确认慢在哪一层。这里的核心思路是分层排查：先看系统负载，再看进程资源，再看网络栈，最后看应用日志。顺序反了，很容易被假象带偏。
我建议你在准备阶段，就在自己的虚拟机里故意制造一次CPU飙升或内存不足，然后用上述命令完整排查一遍。这个过程很折腾，但对你理解系统有明显帮助。面试时你甚至可以直接说“我在练习环境里模拟过CPU满负载的场景，当时是这样定位的……”，这种真实经验比背命令有效得多。
4.3 分布式场景的常见坑
后台开发发展到今天，几乎绕不开分布式。练习卷里涉及分布式的题目，通常不是让你设计一套完整的架构，而是考你对分布式问题有没认识。常见的有：分布式session怎么存，分布式锁怎么实现，数据一致性怎么保证，负载均衡策略怎么选。
分布式锁我多说一句。很多人第一反应是Redis的SETNX，但在集群环境下，简单的SETNX锁存在主从切换导致锁丢失的问题，真正常见做法是Redlock或使用etcd/ ZooKeeper的分布式锁。讲这些不是让你去背方案，而是要理解背后的权衡：Redis锁性能好，但强一致性弱；ZooKeeper锁一致性更强，但性能和复杂度付出更多。没有银弹，只有场景匹配。
幂等性也是一个高频考点。后台接口在网络超时重试、消息重复投递时，很容易被执行两次，于是产生重复订单、重复扣款。常见的幂等方案是唯一ID + 去重表，或者状态机限制操作流转。你答到这个层面，面试官才会觉得你有真实项目经验，而不仅是停留在理论。
5. 常见问题与避坑清单
5.1 每次练习都会踩的五个坑
第一坑，只看不写。后台开发是动手能力极强的工作，网络编程、多线程、数据库调优，光看文章和书永远学不会。我见过太多同学收藏了一堆资料，最后面试写代码时手抖。练习卷做完后，一定要把涉及的核心代码手动敲一遍，比如一个简单的线程池、一个TCP回声服务器、一个带过期时间的缓存。
第二坑，深挖过度。有些同学复习时容易钻牛角尖，比如TCP种种细节都想吃透，结果时间全花在边际知识上，核心考点反而没复习透。一定要舍得放弃，后台开发的知识面很宽，你只要能保证每个方向都有自己的拳头项，就比东一榔头西一棒子强。
第三坑，只背结论不推过程。面试官只要追问一个“为什么”，你就露馅。比如“为什么用B+树做索引”，你光回答“层数少、范围查询好”还不够，最好能画出B+树的形态，对比二叉树和哈希表的差异，再聊聊磁盘预读的原理。这要求你对结论的推导过程有真实理解。
第四坑，忽略并发正确性。笔试里你写了一个线程安全函数，面试官问你怎么保证安全，你说加了锁。但如果一直加锁，性能又很差。正确的思路是，先考虑能否减少共享，再考虑用原子操作，最后才考虑锁。这个顺序代表你对并发问题的理解深度。
第五坑，不总结复盘。练习卷最大的价值是暴露问题，不总结就浪费了。我每次做完一套题，至少花两倍时间复盘，把错题和盲区整理成笔记，隔几天再回来看一遍。很多东西当时记住了，过几天就忘，复盘正是对抗遗忘的利器。
5.2 一套适合两周冲刺的复习节奏
如果你现在离笔试还有两周，推荐这么安排。第一周用来扫盲，把网络、操作系统、数据库、算法四个方向各过一遍，以练习卷上的错题为中心，向外扩展知识点。每天固定两小时刷算法题，保持手感，同时每天用一个小时手写代码，实现一个并发程序或网络程序，不要只做纸面题。
第二周进入实战模拟。每天按笔试时间完整做一套练习卷，做完后当天复盘。周末专门练系统设计题，用我前面说的框架套几个典型场景，比如短链系统、秒杀系统、消息队列。这个阶段要刻意练习“说出来”，模拟面试口述答案，不然面试时容易答得混乱。
最后三天不要再碰新知识，把所有错题和笔记过一遍，把高频考点的手写代码再敲一遍。心态上别慌，后台开发的知识不可能两周全部补齐，但你能在重点方向上形成体系，应付练习卷和大多数面试已经足够了。
这套练习卷对我来说，不只是找工作的敲门砖，更是系统梳理知识的契机。后来我写服务端代码时，很多下意识的设计判断都源于当时疯狂补基础的那段时间。如果你也在准备后台开发这条路，不妨也把这份练习卷当成一面镜子，照一照自己的知识体系，再一块一块把缺的地方填上。工作之后你会发现，面试考的是知识，但练的是解决问题的思维，这种思维会一直陪着你走很远。
