搜狐畅游2019校招的这道“游戏开发工程师Java方向补录笔试题”放在今天回头看依然值得拿出来拆一拆。原因很简单它不像互联网公司Java岗那样纯堆八股也不像客户端岗那样抠图形学而是把Java基础、游戏业务逻辑、服务器并发、算法基本功全都揉在一起考。凡是目标指向游戏行业Java后端、或者想做游戏服务器开发的校招生这套笔试题的考察逻辑基本代表了那一批游戏公司的通用思路。这篇文章我会从题目背后的岗位定位讲起把每类高频考点的出题意图、核心知识点、以及我在实际开发中踩过的对应坑位全部展开。内容会尽量贴近真实笔试现场也会给出可以直接照着复习的路线希望对准备游戏公司Java岗的读者有实际帮助。1. 从笔试题反推岗位真相游戏公司的Java开发到底在做什么很多人对“游戏开发工程师Java”有误解第一反应是拿Java写游戏逻辑、做客户端。实际上国内游戏公司里Java的主战场几乎全在服务器端。搜狐畅游的产品线涵盖端游、手游、页游后端服务大量使用Java技术栈所以校招笔试题的考察重心非常明确你是否具备写游戏服务器的基础能力。1.1 为什么游戏公司用Java而不是C写服务器手游时代兴起之后Java在后端领域的优势被游戏公司充分挖掘一是生态成熟Spring Boot、Netty、MyBatis这些框架能把业务开发效率拉得很高二是JVM自带的内存管理和异常机制让团队在快速迭代版本时能少踩很多内存指针的坑三是招人成本比C服务端低校招生上手快。但这也意味着笔试题会重点考察JVM、并发、网络通信这些服务器开发的核心功底因为这些恰恰是Java后端最容易被问穿的地方。我见过不少同学C功底不错Java就是上课学过语法结果笔试里连HashMap扩容机制都答不全这种就很难过。游戏服务器对性能的要求是实打实的不是“能跑就行”所以考察深度和互联网后端几乎是同一水平线甚至更偏底层一些。1.2 补录批次意味着什么“补录”说明是秋招正式批之后又开放的少量名额时间上往往接近年底竞争压力相对小一点但题目难度并不会因此降低。补录笔试通常不会重新出全新题型而是在正式批题库里抽取或做微调所以往年的真题回忆、面经整理非常有价值。如果你正在准备补录批次最有效的策略就是地毯式刷历年同类岗位的笔试题尤其注意那些跟游戏场景结合紧密的题目。2. Java基础高频考点集合、并发与内存游戏场景下的真正用法游戏服务器的特点是什么高并发、低延迟、长连接、有状态。玩家上线、移动、战斗、聊天、组队、交易每个行为都在产生并发请求每个请求都涉及共享数据的读写。这套场景决定了Java基础部分的考题不会停留在语法层面而是会和并发、集合选型、内存模型深度绑定。2.1 集合框架不只要会API还要懂选型HashMap、ArrayList这些是必考的但游戏场景下考法会变。举个例子一张地图里有几千个玩家每个玩家有一个唯一ID需要快速根据ID找到玩家对象用什么结构很多人立刻说HashMap没问题。但接着问如果这个地图要频繁增删玩家而且要求遍历时按ID有序输出HashMap还合适吗这就是考TreeMap和ConcurrentSkipListMap的场景了。还有一个非常经典的坑就是HashMap在多线程环境下的扩容问题。JDK 7及以前并发put触发扩容可能形成环形链表导致get死循环CPU飙到100%。游戏服务器中如果用一个全局的HashMap管理在线玩家而多处线程都在并发读写就很容易踩雷。我实际开发中就遇到过类似问题后来统一换成ConcurrentHashMap才彻底解决。笔试如果问你“HashMap为什么线程不安全”“ConcurrentHashMap怎么保证线程安全”“JDK 8的ConcurrentHashMap为什么取消了分段锁”本质上就是看你对游戏服务器里共享玩家数据结构的理解够不够深。再补充一个游戏场景里经常被问到的点ArrayList的扩容机制。默认容量10扩容时变成1.5倍底层是Arrays.copyOf新数组。为什么游戏服务器里批量拉取玩家数据时最好预估容量new ArrayList(expectedSize)因为频繁扩容会触发数组复制在线人数多的时候一次全服公告推送就要遍历几万玩家如果集合反复扩容浪费的性能非常可观。笔试考这些其实是提醒你写业务代码时要有性能敏感度。2.2 并发编程锁、线程池与原子类游戏服务器的肌肉记忆游戏服务器是典型的I/O密集型短事务处理系统并发编程是笔试的重头戏。synchronized和ReentrantLock的区别、volatile的可见性与禁止指令重排、CAS与ABA问题、AQS原理这些都属于必背内容。但题目往往不会直接问定义而是给一段多线程操作玩家金币的代码让你找问题。比如多个线程同时对玩家的金币字段做“先读后写”操作怎么保证不出错你当然可以说加synchronized或ReentrantLock但更好的答案是使用AtomicInteger或LongAdder利用CAS避免线程阻塞。如果金币变动非常频繁LongAdder比AtomicInteger更适合高并发下的统计场景因为它在内部做了分段累加减少了CAS竞争。这个细节在游戏服务器里很实用比如统计在线时长、累计在线人数用LongAdder就很稳。线程池也是高频考点。ThreadPoolExecutor的核心参数含义、拒绝策略、为什么不能用Executors.newFixedThreadPool因为LinkedBlockingQueue无界任务堆积可能导致OOM这些必须熟练掌握。游戏服务器里玩家登录、存档加载、邮件推送往往要走异步线程池如果核心线程数和最大线程数设置不合理一旦遇到全服活动的高峰流量就可能出现任务排队严重、玩家操作卡顿的情况。我建议笔试题复习时一定要能自己画一遍ThreadPoolExecutor的执行流程核心线程满→任务入队→队列满→创建非核心线程→达到最大线程数→执行拒绝策略。这个流程基本是面试官百问不厌的点。2.3 JVM与内存OOM是游戏服务器的头号敌人游戏服务器最怕什么服务崩溃、玩家回档、GC长停顿。所以在Java基础考题里JVM内存区域划分、GC算法、常见OOM场景几乎必考。JVM内存区域堆、虚拟机栈、本地方法栈、方法区JDK 8后是元空间、程序计数器。线程私有的有哪些线程共享的有哪些必须一清二楚。游戏服务器中每个玩家连接通常对应一个IO线程或业务线程线程栈的大小、数量直接决定能支撑多少并发连接。接下来是GC。新生代用复制算法老年代用标记-整理或标记-清除CMS和G1的区别G1的Region划分和可预测停顿这些是笔试和面试都绕不开的。游戏服务器对停顿时间极其敏感一次Full GC如果达到秒级玩家会明显感觉到“卡了一下”王者荣耀这类游戏里这就是掉线的体验。所以考题可能会问怎么排查Full GC频繁怎么调整堆大小答案是结合jstat、jmap、jstack这些工具先看GC日志再dump堆分析大对象最后调整参数。这个思路我在实际运维中验证过无数次非常有效。OOM的类型也要会区分。Java heap space通常是堆内存不足GC overhead limit exceeded是GC回收效果太差unable to create new native thread是线程数超过系统限制Direct buffer memory是堆外内存不足。游戏服务器里如果玩家聊天、战斗日志打太多而且没及时释放很容易堆OOM如果用Netty收发大量数据包堆外内存配置不当则容易Direct buffer memory。笔试问这些本质上是在筛掉那些只会写CRUD、没有线上意识的人。3. 网络通信与服务器架构游戏后端笔试题的隐藏主角游戏服务器和普通Web后端最大的区别在于长连接、实时性、消息推送。Http短连接那套在游戏里只适合登录、支付等少数场景真正的高频交互全走TCP长连接或WebSocket。所以网络通信这块笔试一定会涉及而且难度不低。3.1 TCP/UDP选型与粘包拆包TCP是面向连接的可靠传输但游戏里不是所有数据都需要可靠。比如玩家移动坐标、战斗中的位置同步这些数据丢一两个包影响不大反而更在意实时性所以很多游戏用UDP或基于UDP的KCP协议。笔试喜欢问什么场景用TCP什么场景用UDP为什么MOBA游戏的技能释放用UDP而登录支付用TCP答清楚这两个问题说明你理解游戏网络层的基本设计逻辑。Java NIO和Netty也是高频点。Netty的Reactor线程模型、EventLoop机制、ChannelHandler流水线、ByteBuf与堆外内存都是必背内容。笔试可能会让你简述Netty如何解决TCP粘包拆包问题LineBasedFrameDecoder按换行符拆、DelimiterBasedFrameDecoder按自定义分隔符拆、FixedLengthFrameDecoder按固定长度拆、LengthFieldBasedFrameDecoder按长度字段拆。游戏协议通常采用最后一种包头放消息长度包体放消息内容Netty自带的LengthFieldBasedFrameDecoder用起来非常顺手。我在开发游戏服务器时踩过最狠的坑是ByteBuf的引用计数泄漏。Netty里ByteBuf默认是堆外内存用完后必须release否则会直接内存泄漏而且不好排查。后来我们全项目统一封装了发送消息的工具类在finally里确保释放才彻底解决。笔试如果问“Netty如何防止内存泄漏”你可以从Netty自带的内存泄漏检测级别DISABLED、SIMPLE、ADVANCED、PARANOID说起再讲实际项目中通过代码规范和工具类兜底这个回答会非常有亮点。3.2 游戏服务器架构从单服到分线再到跨服笔试题中如果出现“设计一个支持万人同时在线的游戏服务器架构”千万别慌。这种题不是要你设计出生产级方案而是考察你脑子里有没有基本的服务器拆分概念。游戏服务器通常分为登录服、网关服、场景服、玩法服、聊天服、日志服等。网关服负责维持客户端长连接和消息转发场景服负责地图、战斗、怪物AI等核心逻辑玩法服负责副本、活动等逻辑跨服服务器则处理跨服战场、跨服聊天。不同服之间通过RPC通信常用框架有Thrift、gRPC或自研RPC。数据落地走MySQL或Redis排行榜用Redis的ZSet热数据缓存用Redis的String和Hash。如果你能在笔试中把这类架构画出来并解释每个模块的职责、之间如何通信、挂了怎么容错就已经超过大部分候选人了。我当时笔试时遇到类似题目还额外补充了“场景服按地图分线单张地图设置上限人数超了开新线”这个思路面试官明显感兴趣。这个方案其实很多MMO在用本质上是把“大世界”拆成多个可水平扩展的分线实例。3.3 数据库与缓存玩家数据怎么存才安全又高效游戏服务器笔试基本离不开MySQL和Redis。MySQL必考索引原理为什么不建议用SELECT *为什么游戏玩家表要按玩家ID做分库分表为什么订单表不能随便加索引。Redis必考String、Hash、List、Set、ZSet的适用场景以及缓存穿透、缓存击穿、缓存雪崩的解决方案。游戏场景里玩家背包数据通常用MySQL存一份定期落地的快照同时用Redis做热数据缓存。玩家每次修改背包先更新Redis再由异步任务定期同步到MySQL。这个方案的好处是读性能高、数据库压力小坏处是如果服务器宕机Redis里还没落地的数据会丢。所以很多游戏会在玩家关键操作交易、充值时强同步落库普通打怪掉落则允许短暂丢失。这个取舍思路笔试如果深入追问非常能体现你对游戏业务的理解。排行榜功能是另一个经典考题。全服战力排行榜要求实时更新、高性能读取怎么实现答案是Redis的ZSetmember存玩家IDscore存战力值ZREVRANGE取TopN。如果同分玩家要按时间排序可以把时间戳编码进score的小数位。这个方案几乎所有游戏都在用笔试答出来就是标准分。4. 数据结构与算法游戏开发绕不开的必考硬功夫游戏开发工程师的笔试算法题一向比纯后端更“活”。除了常见的排序、链表、二叉树还会出与游戏场景强相关的算法题比如寻路、碰撞检测、洗牌、概率抽卡。复习的时候不能只刷LeetCode还得额外补游戏算法。4.1 排序算法从冒泡到快排代码要能默写热搜词里有“冒泡排序Java”和“快速排序Java实现”说明很多候选人在这个基础题上都要现查。但实际上游戏笔试里的排序题经常和业务场景结合。比如实现一个玩家战力排行榜按战力从高到低排序给一组NPC的刷新时间排序决定先刷新哪个。冒泡排序也要会写但更要知道它为什么慢。两层循环最好情况O(n)最坏O(n²)数据量稍大就扛不住。快速排序是笔试最常让手写的——挖坑法或指针交换法都要熟练平均O(n log n)但要注意数组基本有序时快排会退化到O(n²)所以实际工程里会用随机选基准或三数取中来优化。Java的Arrays.sort()对基本类型用双轴快排对对象类型用TimSort归并插入的混合这些细节都能体现功底。游戏场景里还有一类排序很常见权重随机。比如抽卡不同稀有度的卡有不同的权重怎么按权重随机出一张卡先算总权重随机一个[0,total)的数累加权重找到第一个超过随机数的位置。这个算法代码量很小但游戏笔试经常考因为抽卡系统是几乎所有游戏的标配。4.2 寻路算法A*是游戏开发者的必修课如果笔试中出现“实现一个A算法”别意外。A是游戏AI、自动寻路、地图寻径的基础笔试里考它的频率相当高。A*的核心公式是f(n) g(n) h(n)g(n)是从起点到当前节点的实际代价h(n)是当前节点到终点的启发式估计代价曼哈顿距离或欧几里得距离。用开放列表和关闭列表每次从开放列表取f值最小的节点扩展。写A时最容易出错的地方是开放列表的更新如果某个节点已经在开放列表中但新路径的g值更小要更新它的g值和父节点。另一个坑是距离函数选择不当导致寻路路径拐来拐去。实际游戏项目里A往往还要配合JPSJump Point Search做加速或者用分层寻路降低计算量但对笔试来说把基础A*写对、能解释清楚启发式函数的作用已经足够了。4.3 设计模式在游戏逻辑中的应用游戏开发是设计模式的重灾区状态机、观察者、策略、工厂、单例每一个在游戏代码里都有大量应用。笔试喜欢给一个场景让你选设计模式比如玩家有站立、移动、攻击、死亡等多种状态每个状态下行为不同怎么设计这个用状态模式最合适把每个状态封装成独立类通过状态机切换。再比如游戏里各种Buff加攻、加防、回血不同类型效果不同怎么设计才能方便扩展策略模式或装饰器模式都可以关键是别用一堆if-else硬写。单例模式也常考但要注意游戏服务器里滥用单例是灾难全局唯一的Manager类如果没有做好并发控制很容易出问题。笔试题可能会问“单例模式有几种写法哪种线程安全”答案里要提到双重校验锁和静态内部类两种主流方案并解释volatile为什么必要——防止指令重排导致拿到未初始化完成的对象。5. 笔试题型实战演练从做题思路到答题模板刷题归刷题真正到笔试现场答题思路和方法论同样重要。我结合自己参加过多场游戏公司笔试的经验整理了一套实战应对策略供参考。5.1 选择题与填空题基础概念的快速判断这部分考察范围广但深度不深。常见考点包括Java基本类型的取值范围和默认值、String/StringBuilder/StringBuffer的区别、和equals的区别、异常体系结构受检异常与非受检异常、内部类的分类与使用限制、Lambda表达式与函数式接口、Stream API的基本用法等。我的建议是考前一周把这些基础概念集中过一遍特别是容易混淆的String不可变但StringBuilder可变ArrayList和LinkedList底层实现不同HashSet底层是HashMapTreeMap的key必须实现Comparable或在构造时传入Comparator。这些都是送分题丢分太可惜。5.2 简答题游戏场景下的方案设计简答题往往是拉开差距的地方。比如“一个玩家进入游戏后服务器需要加载哪些数据按什么流程加载怎么保证加载过程不阻塞其他玩家”这种题的答题思路要分层次。第一层说清楚加载内容玩家基础信息、背包、装备、技能、任务、好友、公会等。第二层说清楚存储介质热数据在Redis冷数据在MySQL部分配置数据在本地缓存。第三层说清楚加载流程客户端请求登录→登录服验证→通知场景服→场景服从Redis拉取玩家数据→异步从MySQL补全冷数据→玩家进入场景。第四层说清楚性能优化数据按需加载而不是全量加载非关键数据后台异步加载加载期间客户端先显示加载画面。这样答层次清晰面试官一眼就能看出你有实战思维。还有一种常见简答题是“设计一个全服公告系统要求延迟低、不丢消息、支持定向推送。”这题考的是消息推送模型可以用发布-订阅模式来答。全服广播走Redis的Pub/Sub或自研消息队列定向推送走玩家ID到连接通道的路由表消息丢失问题通过持久化ACK机制解决。答的时候要提到Netty的ChannelGroup可以做群发但这个方案在玩家量大的时候性能一般生产环境更多是业务层做扇形分发。能说到这个层面已经超出及格线很多了。5.3 编程题手写代码的规范与边界编程题是笔试中最容易翻车的环节。游戏公司笔试编程题通常有2到4道难度从简单到中等不等。最容易丢分的地方不是算法想不出来而是代码习惯不好。比如没有处理边界条件、变量命名随意、没有考虑大数溢出、没有写注释。建议养成这些习惯先把题目读懂列出输入输出示例明确边界。写出框架再填核心逻辑。先保证正确性再谈优化。处理数组和字符串时先判断null和空值。数值运算前考虑是否会溢出用long而不是int。递归注意结束条件和递归深度。提交前自己用示例数据走一遍模拟执行过程检查逻辑漏洞。关于是否要写注释我的建议是关键逻辑写一行注释即可不需要逐行注释。面试官看的是思路清晰度和代码风格过于冗长的注释反而浪费时间。6. 避坑指南与复习路线游戏Java岗笔试的独家心得一道笔试题的终点不是答完而是通过它暴露自己的知识盲区。接下来这部分我结合亲身经历和辅导过的同学案例聊聊复习中最容易踩的坑以及怎么规划一条高效的备考路线。6.1 四个典型的复习误区第一个误区是只刷LeetCode不碰游戏业务题。游戏公司的笔试题算法题只占一部分另外还有大量和游戏业务结合的简答题、设计题。只看LeetCode遇到“设计一个玩家组队匹配系统”就会发懵。第二个误区是只背八股文不理解原理。HashMap的原理背得很熟但问“为什么玩家在线表用HashMap而排行榜用ZSet”就答不上来。这就是没把知识点和游戏场景建立连接。我建议每复习一个知识点都主动想一下这个知识点在游戏服务器里用在哪里不用行不行用了会有什么问题第三个误区是忽视JVM和网络通信。很多Java后端同学复习时重点关注Spring、MySQL对JVM只背结论、不学工具对Netty只看概念、不写代码。但游戏公司对JVM调优和网络编程的重视程度远超一般互联网公司。这块薄弱笔试很容易被拉分。第四个误区是代码写得少眼高手低。看懂了和写出来完全是两回事。快排看十遍不如手写一遍A*看十篇博客不如自己实现一遍再跑几个地图用例。我强烈建议复习期间每天保持至少一个小时的编码时间不要光看不练。6.2 三个月备考路线参考假设你从零开始、目标是游戏公司Java开发岗我给一个大概的复习节奏第一个月做基础夯实。Java核心集合、并发、JVM、IO、网络编程。每天动手写代码周末做一套完整的笔试模拟题重点是查漏补缺。第二个月做专项提升。MySQL索引与事务、Redis缓存与分布式锁、Netty网络编程、游戏服务器架构设计。这期间可以看一些开源游戏服务器的源码比如开源的Java版Minecraft服务端或者一些开源MMORPG服务器项目理解项目里是怎么组织模块、处理并发、管理玩家数据的。第三个月做真题冲刺。大量刷目标公司近两三年的笔试真题同时整理自己的错题本。有些公司会考与公司产品相关的题比如搜狐畅游可能会问“如果你来设计一款国风MMORPG的背包系统你会怎么做”这类题需要提前了解公司产品和竞品答题时才能有针对性。6.3 笔试现场的时间分配技巧游戏公司笔试时间一般比较紧张选择题和简答题占大头编程题往往只有一道或两道但分值最高。我的建议是先快速扫一遍所有题目判断难度分布。优先做有把握的题目确保基础分拿到手。简答题不要写太多废话分点作答条理清晰。编程题如果一时没思路先用最暴力的方法写一个正确解再优化。最怕的情况是纠结最优解结果连暴力解都没写出来。留出十分钟检查选择题有没有看错选项编程题有没有编译错误简答题有没有漏答。一个真实的教训我第一次参加游戏公司笔试时在编程题上死磕最优解花了一个小时结果暴力解都没来得及交前面简答题也写得匆匆忙忙最后分数非常难看。后来学乖了先保正确性、再谈复杂度笔试通过率明显提高。7. 从笔试到Offer题目之外的加分项笔试只是第一关但第一关的表现往往决定了面试官对你的第一印象。除了把题目做对还有一些软性的加分项值得注意。7.1 体现游戏热情和个人项目游戏公司非常看重候选人对游戏的理解。笔试中如果你能提到自己玩过哪些游戏、对某个游戏的系统设计有独到见解会显得非常加分。比如问“怎么设计匹配系统”你可以说“我玩过王者荣耀也玩过CSGO这两种匹配机制完全不同一个偏ELO一个偏天梯分我可以分析它们的适用场景”。这种回答即使是开放性问题也会让面试官眼前一亮。如果有个人项目哪怕是课程设计级别的游戏服务器Demo也要在笔试备注或后续面试中主动展示。我当时笔试时在代码注释里写了自己封装的一个小型游戏服务器框架的构思后来的面试官真的注意到了追问了很多细节最后还成了聊得最深入的话题。能体现你“真的做过”比任何八股文都更能打动面试官。7.2 学会复盘每一场笔试笔试结束不代表就完事了。每次笔试后尽量回忆并记录题目对照答案复盘尤其是那些做错的、不会的题。你会发现不同游戏公司的笔试题目有大量重叠你今天在一家公司栽的坑明天在另一家公司可能以同样的方式出现。我当时整理了一份自己的笔试错题集记录题目、考察知识点、错误原因、正确答案秋招后期这份笔记的价值远远超过任何教程。7.3 保持平和心态补录也是好机会补录批次虽然名额少但知晓的人相对也少竞争激烈程度有时反而不如正式批。很多同学在补录阶段心态容易崩觉得自己是被挑剩下的其实完全不是这样。补录往往是团队临时新增HC或者前面有人拒了Offer空出名额这时候面试官更倾向于快速找到合适的人反而不会有正式批那么多轮次和高难度压力测试。我认识一个学弟秋招正式批投了畅游连简历都没过补录阶段抱着试试的心态又投了一次结果进了笔试后来顺利拿到Offer。他事后总结补录时的笔试题目反而比正式批更注重基础只要准备充分机会很大。最后一点也是我最想强调的笔试只是起点不是终点。游戏开发这个行业真正需要的是持续学习、动手验证、对游戏有热情的人。即使一道笔试题答得不够完美只要你展现出清晰的思路、扎实的基础、以及诚恳的学习态度依然有很大机会。按这套方法踏实准备祝你早日拿到心仪的Offer。